Samenwerken Huisarts en Thuiszorg

Hier werken we samen aan diverse use-cases ter bevordering van de samenwerking tussen huisarts en thuiszorg.

Notulen bijeenkomsten

Google doc

Zorginzage V6 hackathon spec

This document is in DRAFT

Purpose

The purpose of the hackathon is to demonstrate a simple implementation of Nuts Zorginzage in Nuts V6. The present Nuts Zorginzage 2022 spec uses Nuts V5, but has several limitations, which is why the intention is to make use of Nuts V6 in the future. This hackathon is the stepping stone towards creating V6 Zorginzage usecases in the future.

Scope

Zoals in de email van Maarten is gedeeld:

Zorgviewer

Nuts technisch team

Voorbereiding deelnemende leveranciers: (Allen)

Voorbereiding rol raadpleger: (HinQ/Topicus/Zorgviewer)

Voorbereiding rol dossierhouder: (ECare/Nedap)

Rol Discovery Service hoster: (Topicus)

Hosten van een Nuts-node die en discovery service aanbiedt voor de use-case met de bijbehorende presentation definition

Route hier naartoe

Start zal de output van de werkgroep zijn om via publieke documentatie de scope in te vullen. Leveranciers zullen onderling asynchroon de gemene deler en specificaties kunnen opstellen/delen binnen de Nuts bolt

Datum & Locatie hackathon Voorstel is 2 dagen met 2 technische gegadigden van de leveranciers bij Neap in Groenlo. Eventueel kunnen er overnagedacht worden.

Graag uiterlijk 1 augustus de datumprikker invullen, zodat we ook een doel hebben om naar toe te werken met elkaar

Vriendelijke groet, Maarten

For the overview of the roles and info per participaint, see this section

Functional design

Discovery Service (adressbook & use-case whitelist)

The Discovery Service serves the function of an adressbook for the organizations that are compliant and available for this specific usecase. Organizations can periodically publish themselves by presenting a set of Verifiable Credentials to the DS. Which credentials should be presented is part of the governance of the use-case. To automatically select these credentials from the organization wallet a query must be agreed upon and ran on each node. The syntax of this query must follow the Presentation Defenition of the PEX specification

For more info about how the DS works see the following presentation of a Nuts Tech session

Promedico will host the Discovery Service within this Hackathon.

Presentation definition

Verifiable Credential

The PDs credibility is determined by the combined assurance level of the required credentials (VC). During the hackathon, only one verifiable credential, NutsUraCredential will be used. This is very similar to the Nuts Organization Credential (RFC012), but the primary difference is that it is no longer issuer by the vendor, but rather issued by a trusted authority. Also it uses the URA number instead of the KVK number as primary identifier.

The contents of the new 2024 version of the NutsUraCredential will be discussed in this Github Issue #3324.

{
  "id":"did:nuts:123#demo-uracredential",
  "type": [
    "VerifiableCredential",
    "NutsUraCredential"
  ],
  "issuer":"did:tdw:cibg-issuer",
  "credentialSubject": {
    "@id":"did:nuts:123",
    "@type":"Organization",
    "legalName": "De Regenboog",
    "memberOf": {
      "@type": "ProgramMembership",
      "membershipNumber": "12345",
      "programName": "UZI Register Abonnee"
    }
  }
}

In the hackathon the NutsUraCredential will be sufficient, however it is likely that in a production V6 Zorginzage usecase more information is desired. For example: the public name, adress, department, or region. This information is not as important to be issued from a trusted-issuer. No authorization would be dependant on it for instance. Hence, this information could be packaged in a self-issued VC. The structure and contents of this VS (for example: NutsLocationCredetinal) would ideally be standardized by the use-case participants.

Credential issuer:

There will be one trusted party that issues these VCs to the organization wallets. The issuer needs a piece of software to issue credentials. There are a few available implementations which can issue such a credential.

Options:

The authority that will spin it up and issue the credentials for this hackathon will be ZorBijJou.

TODO: ZorgBijJou will choose a platform to issue NutsUraCredential and describe how it will work

Service Definition

TODO: Promedico to finalize the Service Definition

{
  "id": "hackathon_v2024.10",
  "endpoint": "https://example.com/usecase/hackathon/v2024.10",
  "presentation_max_validity": 259200,
  "presentation_definition": {
    "id": "pd_care_organization",
    "format": {
      "ldp_vc": {
        "proof_type": ["JsonWebSignature2020"]
      },
      "ldp_vp": {
        "proof_type": ["JsonWebSignature2020"]
      }
    },
    "input_descriptors": [
      {
        "id": "1",
        "constraints": {
          "fields": [
            {
              "path": ["$.type"],
              "filter": {
                "type": "string",
                "const": "NutsUraCredential"
              }
            },{
              "id": "name",
              "path": ["$.credentialSubject.legalName"],
              "filter": {
                "type": "string"
              }
            },{
              "id": "ura",
              "path": ["$.credentialSubject.memberOf.ura"],
              "filter": {
                "type": "string"
              }
            }
          ]
        }
      }
    ]
  }
}

PD logistical information

Alongside the VCs in the presentation definition, there following logistical information is also be presented

Endpoint discovery

In order to request data, the requestor needs to interact with several services. Once a source has been located, the services as defined in the DID Document of the source will be used to discover their endpoints. For more context see the documentation about endpoint-discovery. This does not differ from Nuts V5.

{
  "services": [
    {
      "id": "#hackathon_v2024.10",
      "type": "fhir-api",
      "serviceEndpoint": {
        "api": "https://fhir.example.com/api/",
        "auth": "https://auth.example.com/auth"
      }
    }
  ]
}

Localization

By localization we mean “finding out where a patient is in treatment”. That will not be in scope for this hackathon*. Instead, we will request directly to the other organizations in the discovery service without checking/finding out if there is a patient file there.

*Zorg bij jou intends to host a service (Care Plan Service) where every organization can check which other organizations have a care treatment with the patient by hosting CareTeam FHIR-resources. It's optional for other parties to make use of this during the Hackathon.

Data-access policies

Wheter or not a requestor gets access to the data they are requesting depends on whether they pass the access-polices of the source (bronhouder). To ensure interoperability, a uniform standard for the data-acces policies on a Policy Enforcement Point (PEP) is described for each usecase. The current intentino for the hackaton is to define this in the Open Policy Agent (OPA) scripting language. Validating the access-policies is a two part process. Firstly, the requester presents all the required verificable credentials to the bronhouder. Then, the bronhouder does their own checks and based on the outcome provides an access token or not.

Access policy step 1: requester presents required VCs

1.1 Organisation information (NutsUraCredential)

The same fields that are present in the Service Defention for the NutsUraCredential are required to be presented to the requested party.

1.2 Practitioner identification & authentication

The practitioner that initiates the request must be identifiable so that it can be verified at a later moment, who initiated what action (in line with NEN7513). Just having the identification information present has been deemed insufficient because that lacks the proof that a human performed an action (as opposed to a machine). To add some traceability and log who performed the action, the Employee Identity Credential will be used and checked in the data-access policy. This credential-issuance is part of the default Nuts node and is a required resource.

Access policy step 2: requester checks VCs and enforces the Policy

The Policy Decision will be based on input such as the identity of the requesting organisation and practitioner, a legal basis such as a patient consent and if the requestor is part of the care team. During the hackathon we reduce complexity, and not require a patient-consent. The technical implementation

2.1 Organisation information

Check whether the URA number provided is currently present in the Discovery Service.

2.2 Practioner information

Check wheter a valid Employee ID credential has been provided. Also check if it's expired.

TODO: decide whether RFC021 (service access token) is used v.s. user access token (OpenID4VP flow)

2.3 Authorization policy (checking legal base)

It is the responsibility of the source to check whether the requestor has a legal-base for accessing the data. A legal-base can be implied or be in the form of an explicit patient consent.

During the hackathon we will first attempt a retrieval without an authorization policy to validate the chain works. A, we can test an authorization policy based on being a participant of a CareTeam, using ZorgbijJou's Careteam service, is the intended secondary authorisation policy to use.

2.4 Requested resources

The requested party will check wheter the requested FHIR resources are in scope for the requester in this usecase.

Technical implementation access policy

In OPA, a policy is called with an "input" set and generates an output.

The input consists of the access token introspection result, the http-request and additional information such as results from FHIR queries for Consent and CareTeam.

The following policy and input can be developed using the OPA playground.

Policy (check it out in the playground:

package hackathon_v2024

import rego.v1

default allow := false

allow if {
	# this policy is applicable to the scope
	input.introspectionResult.scope[0] == "hackathon_v2024.10"
    # the requesting org is part of the care team
	care_team_members[requestor_ura]
    # the operation on the requested resource is alowed
	operation_allowed
}

resource_rights := {"Patient": ["read"]}

operation_allowed if {
	http_operations := {
		"GET": "read",
		"POST": "write",
		"PUT": "update",
		"DELETE": "delete",
	}
	operation := http_operations[input.request.http.method]
	some allowed_operation in resource_rights[resource_name]
	allowed_operation == operation
}

path := input.request.http.path

bsn := regex.find_all_string_submatch_n(`^.*identifier=http://fhir.nl/fhir/NamingSystem/bsn\|(\d+)$`, path, -1)[0][1]

resource_name := regex.find_all_string_submatch_n(`\/([A-Z]\w+)\??`, path, 1)[0][1]

requestor_ura := input.introspectionResult.input_descriptor_constraint_id_map[uracredential_uraNumber]

scope := input.introspectionResult.scope[0]

care_team_members contains identifier if {
	# select the care team for the patient with bsn
	care_team := [team |
		input.resources[_].resourceType == "CareTeam"
		input.resources[_].subject.identifier.value == bsn
		team := input.resources[_].participant[j]
	]

	# select the members with an ura as identifier (all organisations)
	some member in care_team
	identifier := member.member.identifier.value
	member.member.identifier.system == "$ura"
}

Input:

{
  "introspectionResult":{
    "active": true,
    "client_id": "did:web:nuts-node-gbz.nuts.example.nl:iam:d73ca5d4-4dc8-4137-8992-578e825e3f36",
    "exp": 1706689514,
    "iat": 1706688614,
    "input_descriptor_constraint_id_map": {
        "uracredential_uraNumber": "32475534"
    },
    "iss": "did:web:nuts-node-zkh.nuts.example.nl:iam:2333ea28-a719-4896-9a12-f855b225755b",
    "scope":["hackathon_v2024.10"]
  },
  "request": {
    "http": {
      "headers": {
        ":method": "GET",
        ":path": "/fhir/Patient?identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333",
        "accept": "*/*",
        "authorization": "Bearer Y2hhcmxpZTpwYXNzdzByZA==",
        "content-length": "0",
        "user-agent": "curl/7.68.0-DEV",
        "x-ext-auth-allow": "yes",
        "x-forwarded-proto": "http",
        "x-request-id": "1455bbb0-0623-4810-a2c6-df73ffd8863a"
      },
      "host": "example-app",
      "id": "8306787481883314548",
      "method": "GET",
      "path": "/fhir/Patient?identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333",
      "protocol": "HTTP/1.1"
    }
  },
  "resources": [{
    "resoureceType": "Consent",
    "subject" : {
      "reference" : "Patient/88eb7e81-a3b6-4236-b458-451cf6e437b3"
    }
  },
  {
    "resourceType" : "CareTeam",
    "id" : "cps-careteam-01",
    "meta" : {
      "versionId" : "1",
      "profile" : ["http://santeonnl.github.io/shared-care-planning/StructureDefinition/SCPCareTeam"]
    },
    "category" : [{
      "coding" : [{
        "system" : "http://snomed.info/sct",
        "code" : "135411000146103",
        "display" : "Multidisciplinary care regime"
      }]
    }],
    "subject" : {
      "identifier" : {
        "system" : "http://fhir.nl/fhir/NamingSystem/bsn",
        "value" : "111222333"
      }
    },
    "participant" : [{
      "member" : {
        "identifier" : {
          "system" : "$bsn",
          "value" : "111222333"
        }
      },
      "period" : {
        "start" : "2024-08-27"
      }
    },
    {
      "member" : {
        "identifier" : {
          "system" : "$ura",
          "value" : "32475534"
        }
      },
      "period" : {
        "start" : "2024-08-27"
      }
    }]
  }]
}

Access token specification

Access tokens follow the format of the Nuts v6 tokens: Example AccessToken introspection

Resources

The aim of the hackathon is model a simple data-request and validate each step in the proces. Therefore the set of resources is deliberately limited to a nl-core-patient.

Hackathon participant information

This table must be filled in by all the participants so it's clear what role they perform during the hackathon. The role can be a multiple of the following: (credential)Issuer, Discovery, (medical data)Requestor, (medical data)Source. The Issuer and Discovery roles can not be combined with the Requestor and Source roles. If a participant performs both roles, add more lines. The Requestor and Source lines need to provide a fictional URA as well.

Participant Fictional Org Role URA Connects with
Ecare Ecare PUUR. Development Source 66677777
Formelio HA het Piratenschip Source 66633333
Formelio HA het Piratenschip Requestor 66633333
Nedap VVT Grolle Source 66644444
Nedap HA Grolle Requestor 66655555
Nuts - Steven VVT de regenboog Source 66611111
Nuts - Steven HA de Leeuw Requestor 66622222
Topicus HA Topicus Requestor 66699999
Topicus RSO "om de hoek" Discovery none
Zorg Bij Jou CIBG Issuer none

Test Patients

The following patients and their BSNs will be used during testing:

Name BSN
Tanja Test 99999001
Tinus Test 99999002

Localisation overview hackathon

Since localisation is out of scope for this hackathon, we use this simple table. Every organisation who contains information about this patient should add a row to the following table:

BSN URA Fictional org
099999001 66677777 Ecare PUUR. Development
099999002 66677777 Ecare PUUR. Development
99999001 66611111 VVT de regenboog
99999001 66622222 HA de Leeuw
99999001 66633333 HA Het Piratenschip
99999002 66611111 VVT de regenboog
99999002 66622222 HA de Leeuw
99999002 66633333 HA Het Piratenschip
99999001 66644444 VVT Grolle
99999002 66644444 VVT Grolle

Deployment

Zorgtoepassing: HA-VVT inzage dossier v1.0

Scope

Doel

Het doel van deze toepassing is tweeledig:

  1. het verbeteren van de informatievoorziening van de huisarts die behoefte heeft aan informatie over wat er in het VVT domein met de patient gebeurt (en het gelijktijdig optimaliseren van het werkproces van een verpleegkundige die belast is met de taak om de huisarts waar nodig op de hoogte te houden).
  2. Als ook het het regelen van inzicht van de informatie die beschikbaar is in het huisartsendossier voor de verpleegkundige in de VVT instelling.

In de huidige situatie wordt de huisarts daarover vaak geïnformeerd doordat de VVT-medewerker een dubbele administratie bijhoudt in het eigen systeem (ECD) en dat de huisarts (HIS of samenwerkingsplatform). Deze toepassing beschrijft de techniek waarmee het mogelijk wordt voor de huisarts om rechtstreeks de informatie uit het ECD te raadplegen vanuit het eigen systeem. Andersom kan de verpleegkundige de informatie die bij de huisarts is vastgelegd inzien.

Scope:

Inzage is een eerste stap van een veel bredere en rijkere integratie. Hierbij gaat het bv om het uitzetten van taken. Deze functionaliteiten worden in latere versies van deze usecase toegevoegd. De usecase is iteratief ontwikkeld (eerst de ene kant op, de huisarts inzage geven en daarna de andere kant op) maar het ontwerp is generiek opgezet.

Governance

De Governance en besluitvorming rondom deelname is belegd bij de projectgroep VVT-Huisarts inzage van Nuts.

Functioneel Ontwerp

Deze usecase ondersteunt het ophalen van informatie twee kanten op: Usecase 1. informatie zoals vastgelegd door de (wijk)verpleging in de VVT om deze informatie beschikbaar te stellen aan de huisarts. Usecase 2. Informatie zoals vastgelegd door de huisarts beschikbaar te stellen aan de (wijk)verpleegkundige

Het proces werkt als volgt:

De huisarts wil informatie inzien in het bronsysteem (VVT). In het huisartsensysteem start de gebruiker de zoekopdracht. Gezocht wordt op een individuele patiënt. Gebaseerd op de informatie die door de VVT instellingen in de discoveryservice is vastgelegd in combinatie met het BSN van de patiënt wordt in het opvragende systeem een lijst getoond van instellingen waar potentieel informatie op te halen is voor de betreffende patiënt. De huisarts selecteert de juiste instelling. Op basis daarvan vindt een FHIR-request ‘Patient’ plaats naar het bronsysteem. Het bronsysteem beoordeelt deze op een aantal parameters:

Als middel wordt hiervoor wordt het URA nummer van de opvragende organisatie gebruikt. Deze informatie is door de (wijk)verpleging vastgelegd in het bronsysteem bij de patiënt. Indien er informatie beschikbaar is en deze vrijgegeven mag worden wordt het interne PatientID terugekoppeld aan het opvragende systeem. Openstaande vraag hierin is de informatie rondom de contactinformatie van de zorgverlener waarbij de patient in behandeling is. Dit kan verschillende verschijningsvormen hebben zoals de afdelingstelefoon of het hoofd van het behandelteam. Hiermee kan de vraag beantwoord worden ‘wie moet ik bellen voor deze patiënt?'. Deze vraag staat nog open, het huidige ontwerp voorziet hier nog niet in. In de komende tijd wordt een addendum op het ontwerp gemaakt waarin hiervoor een oplossing wordt geschetst.

Op basis van het PatientID kan verdere (medisch inhoudelijke) informatie opgevraagd worden. Er is een lijst beschikbaar van informatie die opgevraagd kan worden indien het bronsysteem deze informatie beschikbaar heeft. Deze bestaat uit rapportages en meetwaarden volgens een afgesproken stramien (in aantal / tijd). Zie hiervoor de paragraaf ‘zorginhoudelijke informatie’.

De verdere medisch inhoudelijke informatie wordt opgehaald op basis van FHIR (ZIB’s waar mogelijk). De informatie wordt in het doelsysteem getoond. Het doelsysteem is er verantwoordelijk voor de informatie in de juiste context te tonen (denk aan verschillen met eigen informatie). Logging vindt in de gehele keten plaats.

Voor usecase 2 geldt hetzelfde proces, alleen is de informatieflow omgekeerd. De informatie die beschikbaar gesteld wordt is wel verschillend tussen de 2 stromen, zie hiervoor de ZIB-specificatie verderop in dit ontwerp. Daarnaast wordt de autorisatie bepaald op basis van de toestemming voor gegevensuitwisseling die de patient heeft afgegeven aan de huisarts. Waarmee in de basis alle VVT instellingen de benodigde informatie op kunnen vragen.

Uitgangspunten

Shortcuts en Toekomstige ontwikkelingen: Sommige zaken kunnen we op dit moment niet invullen zoals we willen omdat dit (om verschillende redenen) nog niet realistisch is. Deze zaken plaatsen we in deze usecase buiten scope en worden later eventueel toegevoegd. Het gaat om:

Architectuur beschrijving

Gebruik van Nuts

Voor deze usecase wordt gebruikt gemaakt van de Nuts infrastructuur. Specifiek wordt gebruik gemaakt van de mogelijkheden die de V6.1 versie van Nuts biedt en daarmee dus ook van did:web. Voor de informatie specifiek over de Nuts-laag wordt verwezen naar de officiële documentatie: https://nuts-node.readthedocs.io/en/stable/

Registreren voor de use-case

X509CredentialTool: De Nuts community biedt op dit moment 2 tools aan om een X509Credential te genereren:

Beide tools geven instructies om stappen 9-10 uit te kunnen voeren.

Versies van ZIBs en FHIR:

Een bronhouder kan kiezen voor twee varianten qua versies. FHIR R4 en ZIBs 2020 of FHIR STU3 en ZIBs 2017. De bevrager achterhaalt de FHIR versie door het meta endpoint van de bronhouder aan te roepen. Zie https://hl7.org/fhir/STU3/http.html#capabilities voor meer informatie. Sommige FHIR clients hebben standaard functionaliteit om het metadata endpoint te bevragen.

Data ophalen

De volgende flow wordt gevolgd:

Lokalisatie

Bij gebrek aan een generieke lokalisatiedienst wordt lokalisatie lokaal ingevuld. Dit houdt in dat er in de systemen zelf bijgehouden wordt waar data opgehaald kan worden. Bijvoorbeeld door de VVT instelling waar de patient bij in behandeling is expliciet vast te leggen in het HIS. Of in geval van inzicht in het huisartsendossier door de betreffende huisarts vast te leggen in het ECD bij het dossier.

Grondslag

De grondslag voor uitwisseling is de toestemming (consent) die vastgelegd is bij de patient.

Consent: de verantwoordelijkheid voor het vastleggen en checken van consent wordt ingevuld door het bronsysteem zelf.

Adressering

Discovery Service

Discovery Definition

Algemene uitleg over wat is een Service Discovery is te vinden op de Nuts Wiki pagina Service Discovery

Input descriptors:

Qua benodigde credentials kennen wij 2 verschillende credentials, een X509Credential en een DiscoveryRegistrationCredential.

X509Credential

Dit betreft een X509Credential conform Nuts RFC023, ondertekend met een UZI-servercertificaat.

Aanmaken kan bijv. met de go-didx509-toolkit of de Java library. Als uitgever is besloten om hier de chain op te nemen het dichtst bij de leaf-certificaat.

Gezocht kan worden op de naam van de DID, organisatienaam, organisatie type, plaats & URA.

DiscoveryRegistrationCredential

Dit betreft een DiscoveryRegistrationCredential conform de uitleg op de Nuts Wiki pagina over Service Discovery.

Hierbij is een veld toegevoegd aan de credentialSubject genaamd fhirBaseURL. Deze kan gebruikt worden door gebruikers van de Discovery Service om te weten waar de daadwerkelijke FHIR data opgehaald kan worden.

Het is van belang het organisatie type mee te geven bij de registratie op de Discovery Service, zodat onderscheid gemaakt kan worden tussen een VVT-instelling en een huisarts. Hiervoor wordt het HL7 organisation type Codelijst gebruikt: https://zibs.nl/wiki/Zorgaanbieder-v3.4(2020NL)#OrganisatieTypeCodelijst

Voor deze usecase gelden er 2 types die gebruikt kunnen worden:

  1. Huisartsinstelling: H1
  2. Verplegings- of verzorgingsinstelling X3

Voor de technische uitwerking van het registeren maken we gebruik van de in het generieke functies traject gedefinieerde ZorgaanbiederType-credential. Die wordt straks uitgegeven door Vzvz maar zolang dat nog niet zo ver is wordt dat self-issued toegepast. HealthcareProviderRoleTypeCredential wordt geformaliseerd in de Generieke Functies IG, de definitie is daar te vinden: https://build.fhir.org/ig/nuts-foundation/nl-generic-functions-ig/credential-catalog.html

Note: dit is een uitbreiding op een eerdere versie van deze specificatie en vereist een aanpassing op de reeds bestaande fase 1 koppeling.

Authenticatie

Om veilig gegevens te kunnen delen tussen verschillende zorgaanbieders, is zorgaanbieder-overstijgende authenticatie van zorgorganisaties en zorgverleners essentieel. Vanuit de NEN wordt gewerkt aan een norm met betrekking tot identificatie en authenticatie. Op het moment dat deze norm gepubliceerd wordt zullen we de landelijke ontwikelingen mbt tot deze norm volgen. Om op korte termijn informatie uitwisseling mogelijk te maken, zal de authenticatie geborgd worden op de volgende manier:

Server & Client authenticatie

Voor server & client authenticatie is besloten om de volgende uitgangspunten te hanteren:

Identificatie

Om de raadplegende organisatie te identificeren wordt gebruik gemaakt van het UZI abonnee nummer ook wel bekend als het URA nummer. Als middel voor de authenticatie van dit nummer gebruiken we een verifiable credential en de OpenID Foundation standaarden voor authenticatie.

Omdat het UZI register als authentieke bron zelf nog geen URA Credentials uitgeeft wordt dit credential afgeleid van een UZI Servercertificaat van de betreffende organisatie. We gebruiken hiervoor een nieuw credential NutsX509Credential waarvan de ontwikkeling hier te volgen is: https://github.com/nuts-foundation/nuts-node/issues/3582

Policy Definition

Input descriptors:

Qua benodigde credentials kennen wij 2 verschillende credentials, een X509Credential en een NutsEmployeeCredential.

X509Credential

Zie de X509Credential onder Discovery Definition, deze is exact het zelfde.

NutsEmployeeCredential

Zie de Nuts Wiki pagina over Requesting Access voor context.

Autorisatie

Voor deze usecase gaan wij uit van autorisatie op 5 niveaus:

Discovery service

Om data bij een bronhouder op te halen, wordt de discovery service gebruikt om het adres te vinden. Hoewel het technisch mogelijk is om data op te halen bij een partij die niet (meer) aangemeld is bij de discovery service, is dit functioneel en qua beveiliging niet wenselijk. Daarom moet de bronhouder ook controleren of de partij waarvoor de aanvraag ingediend wordt nog steeds aangemeld is voor de toepassing op de discovery service.

Behandelrelatie

De standaard gaat er vanuit dat de juridische grondslag voor de uitwisseling de toestemming voor uitwisseling is die de patient gegeven heeft. Voor de route waarin de huisarts informatie ophaalt bij de VVT geldt dat optioneel ook de behandelrelatie als juridische grondslag toegepast kan worden. Dit betekent dat om toegang te krijgen tot gegevens van een patient het in dat geval vereist is dat huisarts vastgelegd en bekend is bij de patient in het bronsysteem. Er wordt een controle gedaan op basis van het URA-nummer waarmee een resource wordt opgehaald. Dit nummer is terug te vinden in het organization_ura veld van een token introspect op de Nuts node. Zie ook stap 11 in "Request data at VVT" onder de architectuurbeschrijving. Voor de route waarin de VVT instelling informatie op haalt bij de huisarts accepteren we dat er een generieke toestemming is voor VVT-instelling en dat bij de huisarts dus niet iets vastlegt is om te ‘borgen’ dat alleen VVT instelling X bij de informatie mag. Dat is inherent aan hoe de grondslag obv toestemming geregeld is.

Om een resource van een patient op te kunnen halen moet het bronsysteem toestemming van de patient geregistreerd hebben of op kunnen halen. Een algemene toestemming volstaat hier, waarbij de patient toestemming geeft om zijn of haar gegevens te delen.

Zib

Voor de inzage is een beperkte set aan Zibs beschikbaar. Deze zijn uitgewerkt in de lijst van ZIBs. Alleen deze Zibs kunnen opgehaald worden binnen de scope van deze usecase.

Fhir query parameters

Om te voorkomen dat er teveel informatie opgehaald kan worden (bijvoorbeeld middels het gebruik van _include parameters) wordt er ook autorisatie uitgevoerd op basis van de gebruikte query parameters. Hier wordt onderscheid gemaakt tussen verplichte parameters en toegestane parameters. Alle query parameters die gedefinieerd zijn in de set aan gebruikte Zibs (zie hieronder) zijn verplicht. Het gebruik van andere query parameters is niet toegestaan.

MedewerkerID

Uitgangspunt: Identificatie van de medewerker op basis van een (intern) MedewerkerID, gecombineerd met een VC gebaseerd op informatie binnen het UZI-servercertificaat.

Informatie

Lijst van ZIBs

Tabellen met FHIR resources en queries

Hieronder staan de endpoints die beschikbaar gesteld moeten worden door de partijen die toegang tot het ophalen van de informatie. Ter verheldering zijn de kolommen Sort en Count toegevoegd om aan te tonen hoeveel resultaten er geretourneerd worden en op welke manier deze worden gesorteerd. Het is van belang dat bij een aanroep alle parameters gebruikt worden die in de tabel staan en ook geen extra. Dit heeft te maken met de controle die de systemen doen op de verifiable credentials. Die controle wordt op die manier gedaan om te voorkomen dat met een parameter zoals een include extra gegevens meekomen.

Algemeen

De koppeling werkt twee kanten op, vandaar dat er hieronder twee tabellen worden getoond.

Voor de route waarin de informatie voor de (wijk)verpleegkundinge uit het Huisarts Dossier opgehaald wordt geldt dat in de basis hiervoor de MedMij specificaties zijn gebruikt. Deze zijn te vinden op: https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_GP_Data. Note: er zijn afwijkingen gedaan op de MedMij specificatie om het passend te maken op de usecase. Hoewel de basis van MedMij gebruikt is, kan die specificatie niet 1-op-1 toegepast worden. De verschillen zitten op het gebied van de zoekpaden (specifieke profiles opvragen ipv alles) en beperking van de informatie (maximaal aantallen ipv alles, gesorteerd op nieuwste eerst,profiles expliciteit opvragen ipv de hele set in 1 keer terug te krijgen). Daarnaast geldt dat de HISsen naast de STU3 versie uit de MedMij specificatie ook de R4 versie kunnen ondersteunen. Note: er zitten technische en inhoudelijke verschillen tussen deze 2 FHIR versies. Deze komen in de tabel tot uiting.

Voor het ophalen van de Patiënt geldt een standaard methodiek: POST /fhir/Patient/_search

Specifiek voor usecase 2: 'VVT haalt data op uit HIS' geldt dat de volgende includes meegegeven dienen te worden in de search query:

Usecase 1: Beschikbare informatie voor de huisarts in het VVT Dossier

ZIB Method Sort Count Endpoint Profiel
Alerts GET /fhir/Flag?patient={patientId}}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-Alert https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954733
Allergie GET /fhir/AllergyIntolerance?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.18/files/2317138
Bloeddruk GET Date DESC 5 /fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure&_sort=-date&_count=5 https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954744
Lichaamsgewicht GET Date DESC 5 /fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight&_sort=-date&_count=5 https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954750
Lichaamslengte GET Date DESC 5 /fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight&_sort=-date&_count=5 https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954746
Lichaamstemperatuur GET Date DESC 5 /fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature&_sort=-date&_count=5 https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954748
Patiënt POST Zie onder de tabel https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954638
Respiration GET /fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-Respiration&_sort=-date&_count=5 https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954947
TekstRapportage GET Date DESC 10 /fhir/Observation?patient={patientId}&_profile=https://nuts.nl/fhir/StructureDefinition/nl-core-nursingreport&_sort=-date&_count=10 https://simplifier.net/anw/nl-core-nursingreport
Wilsverklaring GET /fhir/Consent?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954726
Woonsituatie GET /fhir/Observation?patient={patientId}&_profile=http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954848



Usecase2: Beschikbare informatie voor de (wijk)verpleegkundige in het Huisarts Dossier



Onderdelen uit het Huisarts-EPD Beschrijving Count Sort ZIB STU3 Endpoint STU3 ZIB R4 Endpoint R4 Profile
1 Huisarts De huisarts waarvan de gegevens afkomstig zijn. https://zibs.nl/wiki/HealthProfessional-v3.1(2017EN) Zie kopje Algemeen https://zibs.nl/wiki/Zorgverlener-v3.5(2020NL) Zie kopje Algemeen http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
2 huisartsenpraktijk De huisartsenpraktijk waarvan de gegevens afkomstig zijn. https://zibs.nl/wiki/HealthcareProvider-v3.1(2017EN) Zie kopje Algemeen https://zibs.nl/wiki/Zorgaanbieder-v3.4(2020NL) Zie kopje Algemeen http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
3 Patiënt De patiëntgegevens van de patiënt van wie de gegevens zijn. https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/2.2.10/files/1954638 Zie kopje Algemeen https://zibs.nl/wiki/Patient-v3.2(2020NL) Zie kopje Algemeen http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
4 Episodes Een gezondheidsprobleem zoals een klacht of een aandoening, waarvan de aard in de loop van de tijd kan veranderen door voortschrijdend inzicht of door het verloop van de aandoening. 5 DESC Zie specs MedMij mbt episodes in STU3 Zie specs MedMij in STU3. Het daadwerkelijke endpoint zal ook met de *_sort=-date&_count=5, missende _profile filters en ook voor de verschillende meetwaarden aangeroepen moeten worden. Basis URL = GET [base]/fhir/stu3/EpisodeOfCare https://zibs.nl/wiki/ZorgEpisode-v1.0(2020NL) GET [base]/fhir/r4/EpisodeOfCare?patient={id}&_include=condition:diagnosis http://nictiz.nl/fhir/StructureDefinition/nl-core-EpisodeOfCare
5 Episodes met een attentievlag Episodes kunnen een attentievlag hebben om extra aandacht voor de episode te vragen. De attentievlag kan aanwezig blijven als een episode is afgesloten wordt/is, wanneer de gebruiker het belangrijk vindt dit probleem in beeld te houden. 5 DESC Zie specs MedMij mbt episodes in STU3 + https://zibs.nl/wiki/Alert-v3.2(2017EN) Zie specs MedMij in STU3. Het daadwerkelijke endpoint zal ook met de *_sort=-date&_count=5, missende _profile filters en ook voor de verschillende meetwaarden aangeroepen moeten worden. Basis URL = GET [base]/fhir/stu3/Flag https://zibs.nl/wiki/Alert-v4.1(2020NL) GET [base]/fhir/r4/Flag?patient={id} http://nictiz.nl/fhir/StructureDefinition/nl-core-Alert
6 Open en gesloten episodes Episodes kunnen open (actueel) of gesloten (niet langer actueel) zijn. Gesloten episodes met een attentievlag zijn functioneel interessant, overige gesloten episodes niet. 5 DESC Zie specs MedMij mbt episodes in STU3 Zie specs MedMij in STU3. Het daadwerkelijke endpoint zal ook met de *_sort=-date&_count=5, missende _profile filters en ook voor de verschillende meetwaarden aangeroepen moeten worden. Basis URL = GET [base]/EpisodeOfCare https://zibs.nl/wiki/ZorgEpisode-v1.0(2020NL) GET [base]/fhir/r4/EpisodeOfCare?patient={id} http://nictiz.nl/fhir/StructureDefinition/nl-core-EpisodeOfCare
7 Actuele medicatie Medicatie-afspraak
Het voorstel van een voorschrift tot gebruik van medicatie waarmee de patiënt akkoord gaat. De afspraak kan zowel starten, herhalen, wijzigen als stoppen van medicatie betreffen.		 5 DESC https://zibs.nl/wiki/MedicationAgreement-v1.0(2017EN) Zie specs MedMij in STU3. Het daadwerkelijke endpoint zal ook met de *_sort=-date&_count=5, missende _profile filters en ook voor de verschillende meetwaarden aangeroepen moeten worden. Basis URL = GET [base]/fhir/stu3/MedicationRequest?patient={id} https://zibs.nl/wiki/Medicatieafspraak-v1.2(2020NL) GET [base]/fhir/r4/MedicationRequest?patient={id}&category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
8 Medicatie-overgevoeligheid Een medicatie-overgevoeligheid beschrijft een overgevoeligheid van een patiënt voor een geneesmiddel, een stof of een geneesmiddelengroep, waarmee rekening gehouden moet worden bij het voorschrijven van medicatie. 5 DESC https://zibs.nl/wiki/AllergyIntolerance-v3.1(2017EN) Zie specs MedMij in STU3. Het daadwerkelijke endpoint zal ook met de *_sort=-date&_count=5, missende _profile filters en ook voor de verschillende meetwaarden aangeroepen moeten worden. Basis URL = GET [base]/fhir/stu3/AllergyIntolerance?patient={id} https://zibs.nl/wiki/AllergieIntolerantie-v3.3(2020NL) GET [base]/fhir/r4/AllergyIntolerance?patient={id}&category=medication http://nictiz.nl/fhir/StructureDefinition/nl-core-AllergyIntolerance
9 Resultaten van bepalingen – laatste veertien maanden Een bepaling is een objectiveerbare diagnostische verrichting. Het resultaat is de (uitkomst) van een bepaling. 5 (per profile) DESC Note: zoekvraag per profile . beschikbaar zijn: https://zibs.nl/wiki/LaboratoryTestResult-v4.0(2017EN) https://zibs.nl/wiki/BloodPressure-v3.1(2017EN) https://zibs.nl/wiki/BodyHeight-v3.1(2017EN) https://zibs.nl/wiki/BodyTemperature-v3.1(2017EN) https://zibs.nl/wiki/BodyWeight-v3.1(2017EN) https://zibs.nl/wiki/GeneralMeasurement-v3.0(2017EN) https://zibs.nl/wiki/HeartRate-v3.1(2017EN) https://zibs.nl/wiki/O2Saturation-v3.1(2017EN) https://zibs.nl/wiki/PulseRate-v3.1(2017EN) Zie specs MedMij in STU3. Het daadwerkelijke endpoint zal ook met de *_sort=-date&_count=5, missende _profile filters en ook voor de verschillende meetwaarden aangeroepen moeten worden. Basis URL = GET [base]/fhir/stu3/Observation?patient={id} Note: zoekvraag per profile . beschikbaar zijn:https://zibs.nl/wiki/LaboratoriumUitslag-v4.6(2020NL) https://zibs.nl/wiki/Bloeddruk-v3.2.1(2020NL) https://zibs.nl/wiki/Lichaamsgewicht-v3.2(2020NL) https://zibs.nl/wiki/Lichaamslengte-v3.1.1(2020NL) https://zibs.nl/wiki/Lichaamstemperatuur-v3.1.2(2020NL) https://zibs.nl/wiki/Polsfrequentie-v3.3(2020NL) GET [base]/fhir/r4/Observation?patient={id}&_sort=-date&_count=5&category=http://hl7.org/fhir/observation-category|vital-signs,laboratory
GET [base]/fhir/r4/Observation?patient={id}&_sort=-date&_count=5&_profile=http://nictiz.nl/fhir/StructureDefinition/nl-core-BloodPressure
GET [base]/fhir/r4/Observation?patient={id}&_sort=-date&_count=5&_profile=http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight
GET [base]/fhir/r4/Observation?patient={id}&_sort=-date&_count=5&_profile=http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight
GET [base]/fhir/r4/Observation?patient={id}&_sort=-date&_count=5&_profile=http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyTemperature
GET [base]/fhir/r4/Observation?patient={id}&_sort=-date&_count=5&_profile=http://nictiz.nl/fhir/StructureDefinition/nl-core-PulseRate
GET [base]/fhir/r4/Observation?patient={id}&_sort=-date&_count=5&_profile=http://nictiz.nl/fhir/StructureDefinition/nl-core-LaboratoryTestResult		 http://nictiz.nl/fhir/StructureDefinition/nl-core-BloodPressure, http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight, http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight, http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyTemperature, http://nictiz.nl/fhir/StructureDefinition/nl-core-PulseRate, http://nictiz.nl/fhir/StructureDefinition/nl-core-LaboratoryTestResult
10 E- en P-regels van de SOEP-structuur – vastgelegd na invoering van online inzage Informatie beschikbaar in het bronsysteem ten aanzien van de E- en P-regels van de SOEP-structuur 5 DESC Note: voor STU3 geldt dat Informatie uit een deelcontact dat in vrije tekst wordt geregistreerd volgens de SOEP-structuur. Zie MedMij specificatie Zie specs MedMij in STU3. Het daadwerkelijke endpoint zal ook met de *_sort=-date&_count=5, missende _profile filters en ook voor de verschillende meetwaarden aangeroepen moeten worden. Basis URL = GET [base]/fhir/stu3/Composition?type=http://loinc.org|67781-5&patient={id} https://zibs.nl/wiki/SOEPVerslag-v1.0(2020NL) GET [base]/fhir/r4/Composition?patient={id}&type=http://loinc.org|67781-5 -
11 Encounter (Contact) Informatie uit een deelcontact dat in vrije tekst wordt geregistreerd volgens de SOEP-structuur. 5 DESC https://zibs.nl/wiki/Encounter-v3.1(2017EN) Zie specs MedMij in STU3. Het daadwerkelijke endpoint zal ook met de *_sort=-date&_count=5, missende _profile filters en ook voor de verschillende meetwaarden aangeroepen moeten worden. Basis URL = GET [base]/fhir/stu3/Encounter?patient={id} https://zibs.nl/wiki/Contact-v4.0.1(2020NL) GET [base]/fhir/r4/Encounter?patient={id} http://nictiz.nl/fhir/StructureDefinition/nl-core-Encounter



Functioneel missen nog: Behandelgrenzen, andere zorgverleners, wilsonbekwaamheid. Specifieke afspraken rond PZP volgen we vanuit de PZP coalitie. Voor medicatie geldt dat er gewerkt wordt met wat er nu is. Toekomstbestendige communicatie omtrent Medicatie volgt uit het MP9 traject.

Foutafhandeling

In deze fase concentreren we ons op beveiliging – juist in de pilot zal bekeken moeten worden of dit ook leidt tot voldoende gebruiksgemak. In de basis wordt dus alleen getoond DAT er een fout is en geen specifiekere informatie zoals 'patient niet gevonden'. Informatie die publiekelijk beschikbaar is (bv inhoud van de usecase als zijnde 'deze resource valt buiten de usecase') zou toegevoegd mogen worden om nieuwe ontwikkelaars makkelijker te maken bij het testen

Versiebeheer

Het versiebeheer wordt momenteel uitgewerkt in usecase ANW. Het resultaat daarvan wordt hier opgenomen. In de toekomst wordt dit ontwerp omgeschreven naar een Implementation Guide (IG). Hiermee komen handvatten zoals een capability statement beschikbaar om in het ontwerp op te nemen.

Omgevingen

De volgende omgevingen zijn beschikbaar in de OTAP omgeving: -Ontwikkel: lokaal bij de ontwikkelaars zelf -Test: Testomgeving waar met UZI testcertificaten gewerkt wordt -Acceptatie: acceptatieomgeving waar met zowel test als productie UZI certificaten gewerkt kan worden (Dit omdat de leveranciers verschillend om gaan met acceptatie en staging). -Productie: productie omgeving waar met productie UZI servercertificaten gewerkt wordt.

Applicatie architectuur

In het volgende diagram zien we de benodigde applicatie-rollen voor Attributen Based Access Control. Deze rollen zullen door een of meerdere applicaties bij de IT-leveranciers moeten worden ingevuld.

De use-cases beschrijven:

  1. Het opvragen van patient data door een zorgverlener
  2. Het vastleggen van het patient netwerk door een zorgvelener
  3. Het vastleggen van de patient toestemming door de burger/zorgverlener
  4. Het uitgeven van een zorgaanbieder identiteit door de IT-dienstverlener
  5. Het aanmelden van een zorgaanbieder voor een zorgtoepassing

Zorgtoepassingsprofiel taakuitwisseling

Zorgtoepassingsprofiel inzage huisartsgegevens door VVT

Authenticatie risicoanalyse

Situatie

Fictieve case: huisartsen inzage geven in cliëntdossiers van cliënten wijkverpleging van een VVT-organisatie, met als doel verbetering van wijkzorg waarbij zowel de huisarts als de zorgorganisatie zijn betrokken. Deze risico-inventarisatie gaat alleen in op de risico’s rondom het type gegevensverwerking ‘inzage’.

Scope van de risicoanalyse

Deze risicoanalyse geeft een overzicht van verschillende risico’s, bekeken vanuit het oogpunt van compliancy, security en privacy en is bedoeld als input voor de verdere uitwerking van project(en) rondom netwerkzorg en specifiek rondom gegevensontsluiting van VVT-organisaties met huisartsen.

Bij de uiteindelijke keuze voor een bepaalde techniek tellen verschillende aspecten mee:

Partijen en rollen rondom dataverwerkingsproces

Relevante reguleringskaders

De kenmerken van de use case bepalen welke kaderstellende wet-regelgeving/normering van belang is rondom het in kaart brengen van risico’s. Hieronder is per kenmerk te vinden welke wet-regelgeving/normering van belang is.

Kenmerk van use case Kaderstellende wet-regelgeving/normering
Het werkveld: de gezondheidszorg Wgbo, NEN7510, -12 en -13
Het beoogde doel: elektronische gegevensuitwisseling in de zorg (via inzage in extern ECD) Begz, Wabpvz
Het type informatie: gevoelige persoonlijk identificeerbare informatie (PII) Avg

Context en aandachtspunten

AVG: Rechten van de Betrokkene in acht nemen

De AVG geeft aan dat de cliënt als betrokkene een aantal rechten heeft, die nagevolgd moeten worden door de partij die de gegevens van de betrokkene verwerkt. Rondom de verwerking Inzage door de huisarts zijn met name de onderstaande rechten relevant:

Wgbo: Vanuit Betrokkene toestemming voor inzage door huisarts

In het verleden heeft de cliënt ingestemd met de verwijzing naar de thuiszorgorganisatie door de huisarts. Ook is de huisarts nog betrokken bij de zorg voor de thuiszorg-cliënt. De Wgbo stelt dat er vanuit die gedachte sprake is van een vorm van gedeelde of ketenzorg: huisarts en VVT-organisatie verlenen samen zorg aan dezelfde patiënt. Hiermee is de huisarts te beschouwen als medebehandelaar. Daarmee heeft de huisarts veronderstelde toestemming van de cliënt voor inzage van het dossier. Belangrijk: dit geldt alleen voor de huisarts zelf. Andere zorgverleners of medewerkers van een huisartsenpraktijk hebben dit dus niet zomaar ook.

Discussie: Verder specificeren wat ‘Inzage’ hier precies inhoudt en onderbouwen of deze inzage ook echt ‘Inzage’ inhoudt, of alleen bijvoorbeeld het regelmatig delen van updates/brieven met de huisarts.

Vanuit zorgvuldigheid is het wel verstandig om de toestemming, ook al is die verondersteld, toch expliciet op te nemen, bijvoorbeeld door in de zorgovereenkomst met de cliënt op te nemen dat de zorgorganisatie met elke zorgverlener gegevens mag delen, mocht dat voor een goede zorgverlening noodzakelijk zijn.

AVG: Afspraken tussen Verwerkingsverantwoordelijke en Verwerker

De AVG schrijft specifieke rollen en verantwoordelijkheden voor rondom het verwerken van gegevens van een persoon. Bij inzage door de huisarts in het thuiszorg-cliëntdossier, is een logische rolstructuur rondom dataverwerking de volgende: de VVT-organisatie is Verwerkingsverantwoordelijke; de huisarts is Verwerker. De Verwerkingsverantwoordelijke bepaalt de grondslag (het waarom) en op welke wijze de huisarts als Verwerker de verwerkingsactiviteit Inzage mag uitvoeren.

De VVT-organisatie geeft als Verwerkingsverantwoordelijke de huisarts als Verwerker instructies hoe de gegevens uit het cliëntdossier te verwerken zijn (vaak via een Verwerkersovereenkomst). Het is goed om daarbij rekening te houden met bestaande kaders en cliëntafspraken. Andere aspecten die hierin rondom de use case van belang kunnen zijn:

Concreet betekent dit dat de technische authenticatie-opzet mogelijk ingericht moet worden op twee niveaus, verschillend per leverancier:

  1. Herkenning op organisatieniveau: tussen het ECD-systeem van de thuiszorgorganisatie en het HIS-systeem van de huisarts. Hiertussen is mogelijk alleen identificatie tot op organisatieniveau mogelijk, bijvoorbeeld via een api-endpoint. Wellicht zijn er ook mogelijkheden te verkennen die wel herkenning tot op persoonsniveau mogelijk maken, maar bij de voorgestelde api-endpoint is dit lastig.
  2. Identificatie/autorisatie op persoonsniveau: Binnen het HIS-systeem van de huisarts. Binnen dit systeem is in te richten, vast te leggen en te loggen wie gebruik mag maken en heeft gemaakt van de koppeling met het ECD-systeem. De logging moet voldoen aan de NEN7513.

Discussie: Gecertificeerd zijn op de NEN7513 zou het risico op niet afdoende logging afdekken. Hoe wordt er gecertificeerd voor de NEN7513? Dus hoe kun je aantonen dat je hieraan voldoet? En is dat dan voldoende ‘risico-afdekking’ voor het risico dat de logging mogelijk niet specifiek genoeg is, of is dat een te zwakke mitigering en is meer nodig dan ‘NEN7513’ gecertificeerd zijn?

Discussie: Een alternatieve opzet zou ook kunnen zijn om zowel de VVT-organisatie als de huisarts beide als Verwerkingsverantwoordelijke te zien en om vanuit die case samen te bepalen wat het doel van de verwerking gaat zijn, maar dit is voor deze concrete use case wellicht te uitgebreid. Kan wel relevant zijn bij andere cases rondom netwerkzorg.

Technisch en organisatorische aspecten

De informatie hierboven laat zien dat de risico’s die bij de inzage door de huisarts van een thuiszorg-cliëntdossier komen kijken, niet zwart-wit zijn en ook niet volledig technisch te borgen zijn. Goede keuzes, afspraken en instructies zijn daarom belangrijk om risico’s zoveel mogelijk te beheersen en te beperken.

Overzicht van mogelijke risico’s

Een overzicht van een aantal mogelijke risico’s rondom deze use case staat in de volgende tabel:

Situatie Risico Oorzaak risico Mitigeringsoptie
Verkeerde huisarts bij cliënt vastgelegd Verkeerde huisarts krijgt inzage Organisatorisch VVT-organisatie: In eigen werkprocessen zorgvuldig inregelen
Geen expliciete toestemming van cliënt voor inzage Niet echt risico, wel ‘grijs gebied’ en ruimte voor verschil van opvattingen van VVT versus cliënt. Organisatorisch VVT-organisatie: Toestemmingen vooraf duidelijk in zorgovereenkomst vastleggen
Onzekerheid over sterkte en correcte inzet van authenticatiemiddel (b.v. UZI) Risico dat het authenticatiemiddel niet identificeert dat de persoon die inzage vraagt, niet de feitelijke persoon is die inzage mag hebben (middel is niet sterk genoeg, middel wordt misbruikt, etc.) Hieruit volgt mogelijk onrechtmatige inzage. Technisch Organisatorisch VVT-organisatie: Een sterk authenticatiemiddel op persoonsniveau inzetten
Middelen om organisatie achter inzage-vragende zorgverlener te identificeren, zijn niet adequaat genoeg.
Daarom vertrouwt men nu:
  • op een verklaring van een leverancier over de identiteit van de klant en;
  • op de door de leveranciers ingerichte processen over de kwaliteit van die bewering.
 Risico dat niet gesignaleerd wordt dat het verzoek afkomstig is van een vertegenwoordiger van een organisatie zonder behandelingsovereenkomst met de client.
Hieruit volgt mogelijk onrechtmatige inzage.		 Technisch
Organisatorisch		 Technisch en organisatorisch:
  • Technische afdichting door werken met gezamenlijke technische infrastructuur
  • Afspraken met aansluitcriteria opstellen
Afhankelijkheid van de kwaliteit van en de opzet van de interne organisatie binnen huisartsenpraktijk Allerlei risico’s Organisatorisch VVT-organisatie: Duidelijke instructie aan huisarts om belangrijkste mogelijke risico’s rondom afhankelijkheid van diens bedrijfsvoering te beperken.
Cliënt wil recht als betrokkene uitoefenen om te weten wie cliëntdossier heeft ingezien. VVT-organisatie: risico dat de gevraagde gegevens niet adequaat opgeleverd kunnen worden, door:
  • afhankelijkheid van kwaliteit van logging van HIS
  • geen directe toegang/inzage/invloed op logging door HIS
 Technisch, Organisatorisch VVT-organisatie: Afhankelijkheid van HIS inperken door als VVT-organisatie zelf iets anders te regelen op technisch én/of organisatorisch gebied.
Certificering voor NEN7513 op orde hebben
Inzage-opzet generiek uit willen breiden naar (veel) huisartsen uit de regio. Opzet is mogelijk niet makkelijk schaalbaar naar eenzelfde opzet voor allerlei verschillende huisartspraktijken in de regio.
  • Ingewikkeld
  • Papierwerk op orde
  • Afspraken per huisartsenpraktijk lastig te ‘generaliseren’
 Technisch (verschillende HIS’sen), Organisatorisch Technisch en organisatorisch:
  • Technische afdichting door werken met gezamenlijke technische infrastructuur
  • Afspraken met aansluitcriteria opstellen

Functionele uitwerking Huisartsinzage

Hieronder volgt de uitwerking van Huisartsinzage (plateau 1: Huisarts inzicht geven in het VVT dossier) aan de kant van het doelsysteem (huisarts).

In het geval van Topicus is dit als volgt:

*Let op: dit zijn schermontwerpen, de daadwerkelijke software implementatie kan net iets afwijken van het design.

  1. De huisarts of POH logt in bij VIPLive en navigeert naar het patiëntoverzicht. Hier is een nieuw tabje te zien VVT dossier. Als je hierop klikt opent het VVT-dossier detailscherm. VVT tabje op patientpagina.png

  2. De huisarts of POH wil een VVT dossier koppelen aan de patiënt. Je klikt hiervoor op de knop Koppel dossier.

Koppel VVT dossier.png

  1. Er opent een modal waar je kunt zoeken naar de VVT-organisatie van de patiënt bij welke je het VVT-dossier wil opvragen. Je kunt in het invoerveld zoeken op de naam van de VVT-organisatie of de plaatsnaam van de VVT-organisatie. Vervolgens selecteer je de gewenste VVT-organisatie en je klikt op Bevestigen. VVT dossier koppelen flow.png

  2. Het VVT-dossier wordt nu opgehaald bij de gekoppelde VVT-organisatie.

VVT dossier ophalen.png

  1. VVT-dossier: Rapportages inzien. Onder het tabje Rapportages kun je de tekstrapportages van de VVT inzien. Hierbij wordt ook de datum-tijd en de zorgverlener die de rapportage heeft geschreven getoond.

VVT dossier tabje Rapportages.png

  1. Zoeken en filteren op rapportages. Als je op het filtericoontje of pijltje in de linker zijbalk naast de rapportages klikt, vouwt er een filter scherm uit.

Filteren in rapportages 2.png

Hiermee kan je zoeken op een bepaalde zoekterm die in de rapportages voorkomt, op een datum-tijds periode en door wie de rapportage is geschreven. Filteren in rapportages 1.png

  1. VVT-dossier: Meetwaardes inzien. Onder het tabjje Meetwaardes kun je de meetwaardes inzien die de VVT heeft gerapporteerd in hun dossier. Hierin zit je in eerste instantie een samenvatting van de meest recente meetwaardes. Vervolgens kan ju doorklikken op de meetwaardes waarin je bent geïnteresseerd om alle meetwaardes van dat type in te zien. VVT dossier tabje Meetwaardes.png

Klik bijvoorbeeld op Bloeddruk. Scherm­afbeelding 2024-12-04 om 16.18.45.png

Dan vouwt het bloeddrukscherm open waardoor je alle bloeddruk metingen kan inzien die de VVT heeft ingevoerd.

Scherm­afbeelding 2024-12-04 om 16.21.27.png

  1. VVT-dossier: Algemene informatie over de VVT-organisatie. Bovenaan het VVT-dossier kan je nog alemene informatie vinden over de gekoppelde VVT-organisatie bij welke je het VVT-dossier hebt opgehaald. Hier zie je in ieder geval de naam van de VVT-organisatie en het telefoonnummer van de VVT-organisatie.

Scherm­afbeelding 2024-12-04 om 16.23.57.png

  1. VVT-dossier loskoppelen. Indien de patiënt gewisseld is van VVT-organisatie dan kun je de oude VVT-organisatie loskoppelen. Klik hiervoor op de knop met de 3 puntjes en kies voor VVT-Dossier loskopelen en bevestig dat je wil loskoppelen. .

Hiermee opent het startscherm van het VVT-dossier weer en kun je eventueel de nieuwe (of dezelfde) VVT-organisatie van de patiënt opnieuw koppelen. Koppel VVT dossier.png