Samenwerken Huisarts en Thuiszorg
Hier werken we samen aan diverse use-cases ter bevordering van de samenwerking tussen huisarts en thuiszorg.
- Notulen bijeenkomsten
- Zorginzage V6 hackathon spec
- Zorgtoepassingsprofiel huisartsinzage in het thuiszorgdossier v0.2
- Applicatie architectuur
- Zorgtoepassingsprofiel taakuitwisseling
- Zorgtoepassingsprofiel inzage huisartsgegevens door VVT
- Authenticatie risicoanalyse
- Functionele uitwerking Huisartsinzage
Notulen bijeenkomsten
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)
- Nuts v6 Node met een domainnaam draaien
- FHIR Server met een test Patient
- FHIR Client die een request kan maken
- Interface om zorginstellingen te beheren en identiteiten aan te maken in de Nuts-Node
- Een plek om informatie op te halen en te tonen
Voorbereiding rol raadpleger: (HinQ/Topicus/Zorgviewer)
- FHIR Client mot een access token kunnen aanvragen
- FHIR Client moet het acces token gebruiken in een FHIR request
- Nuts-node moet een OrgCredential kunnen aanvragen/verkrijgen
- Nuts node configureren voor het abonneren op de discovery-service
- FHIR Client kan zoeken binnen list van de discovery-service
Voorbereiding rol dossierhouder: (ECare/Nedap)
- Een PEP inrichten die een token introspectie doet bij de Nuts-node
- Het request en introspectie resultaat naar een OPA server sturen
- De OPA server moet in stat zijn het opgestelde policy te enforcen en een ja/nee antwoord aan de PEP te geven
- De zorginstelling aanmelden bij de discovery-service
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:
- Issue through Nuts Node, optionally using Nuts Admin. Holders will have to receive the credential(s) out of band, and load it into their Nuts node using its REST API or Nuts Admin. The needed software is part of https://github.com/nuts-foundation/nuts-admin
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
- Usecase ID:
- Max validity:
60 minutes
- Server endpoint: T.B.D by Promedico
- ?
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"
}
}]
}]
}
- Design an OPA policy
- Decide on error-responses for authorization
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
Zorgtoepassingsprofiel huisartsinzage in het thuiszorgdossier v0.2
Dit document heeft de status DRAFT
Dit betreft v0.2 van het Zorgtoepassingsprofiel huisartsinzage in het thuiszorgdossier en bouwt voor op versie 0.1, maar maakt gebruik van de nieuwe inzichten van de hackathon en Nuts versie 6.
Dit artikel beschrijft achtereenvolgens
- Doel, plan van aanpak en scope van de toepassing
- de identifier van de zorgtoepassing;
- de governance;
- de informatiestandaarden;
- de toegestane authenticatiemiddelen;
- de toegestane grondslagen;
- organisatiebeleid en
- de access policy.
Voor een impressie van de functionele uitwerking aan de kant van de raadpleger kan op deze pagina gekeken worden: Functionele uitwerking.
Doel van de toepassing
Het doel van deze toepassing is tweeledig: 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 optimaliseren van het werkproces van een verleegkundige die belast is met de taak om de huisarts waar nodig op de hoogte te houden.
In de huidige situatie wordt de huisarts daarover vaak geinformeerd 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 mogelijkl wordt voor de huisarts om rechtstreeks de informatie uit het ECD te raadplegen vanuit het eigen systeem.
Plan van aanpak
Uitgangspunten
Het ontwerp van een toepassing kan grofweg opgedeeld worden in twee aspecten: de techniek en de informatiestandaard. Om te voorkomen dat we te lang in een ontwerpfase blijven hangen werken we kort-cyclisch samen aan beide aspecten. Het plan is om met minstends 2 bronleveranciers en 2 raadpleeg leveranciers samen te werken aan producten die iteratief worden verbeterd.
Minimal Viable Product
Er wordt een start gemaakt met een Minimal Viable Product (MVP).
Het doel van de MVP is om van de kant te komen en een goede samenwerking te starten tussen leveranciers en koepels die een basis vormt voor een verdere uitwerking in volgende fase. De MVP moet aantonen aan de markt dat deze toepassing resultaten kan leveren en dat deze aanpak het waard is om eventueel lopende trajecten naar toe te sturen. Leveranciers maken kennis met de onderliggende technieken implementeren en tonen aan dat deze bruikbaar zijn om deze toepassing op te kunnen doorontwikkelen.
Dit betekent dat voor de MVP bewust en beperkte scope wordt gekozen:
-
De raadpleger haalt gegevens op bij één bronhouder.
-
We gebruiken enkel de ZIBs die bij beide bronhouders al beschikbaar en bruikbaar zijn. Deze komen overeen met de ZIBs van ANW.
-
Zodra er twijfel is over de invulling of bruikbaarheid van de ZIBs schuiven we deze door naar een volgende fase.
-
Voor het MVP geldt dat er geen specifieke lokalisatie functionaliteit in scope zit. In de praktijk weet de huisarts bij welke zorginstelling de patient in zorg is en wordt dit handmatig geregistreerd in het huisartssysteem.
-
Authenticatie vindt plaats op basis van een URA Credential afgeleid van het UZI Server Certificaat. Het aanmaken van dit credential is nog een handmatige stap.
-
Versiebeheer van de diverse onderdelen van deze specificatie wordt in het ontwerp zoveel mogelijk meegenomen, maar mogelijk nog niet in techniek worden verwerkt.
Volgende versies
Voor volgende versies van de specificatie staan de volgene onderwerpen op de roadmap:
- Het uitwisselen van een zorgteam.
- Bloed glucose metingen
- Pijnscore
- Versiebeheer(?)
Identifier van de zorgtoepassing
De identifier van de zorgtoepassing huisartsinzage is een string die wordt gebruikt bij het discover, authenticatie en autorisatie proces. Op basis van deze identifier wordt er een set aan credentials van de raadpleger gevraagd en een autorisatie policy toegepast. Gezien we incrementeel hier aanpassingen aan willen maken is het waarschijnlijk handig om een versienummer toe te voegen. Deze string is human-readable, maar het is niet de bedoeling om hem te parsen.
Het voorstel is de volgende identifier: zorginzage-ha-vvt-v2025.1
Toelichting
Deze toepassing is een profiel op zorginzage
.
De toevoeging ha-vvt
laat de bronhouder weten dat het om informatie uit het vvt domein gaat. Als een zorginstelling meerdere domeinen bedient is dit handig om te weten. De bronhouder weet nu ook dat het een huisarts is die de raadpleging doet.
v2025.1
geeft de versie aan. 2025
Is de "major" versie, de 1
staat voor de "minor" versie. Versiebeheer dient nog verder te worden uitgewerkt.
Governance
Governance van het zorgtoepassingsprofiel wordt uitgevoerd door intiatiefnemende leveranciers, te weten: Nedap, HINQ, Ecare en Topicus. Leveranciers die op een later moment ook het zorgtoepassingsprofiel zullen ondersteunen maken daarmee per direct onderdeel uit van ‘governance groep’. Partijen zorgen zelfstandig voor het raadplegen van de achterban om te komen tot een goede beslisvoering.
Partijen streven naar het overdragen van deze governance aan zorgpartijen als InEen en Actiz.
Informatiestandaard
Er is op dit moment geen landelijke informatiestandaard beschikbaar rondom de inzage van het thuiszorgdossier. Zolang deze nog niet beschikbaar is definieren we hier een eigen informatiestandaard.
Daarbij is het belangrijk dat we een invulling geven aan het de eis van proportionaliteit bij data deling. Dit om zowel de privacy van de patient te beschermen alsmede alleen relevante informatie aan de raadpleger te tonen. Het verdient aandacht om in kaart te brengen op basis van welke criteria er bij de bron kan en moet worden gefilterd.
Identiteit en 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:
Organisaties
Om de raadplegende organisatie te identificeren wordt gebruik gemaakt van het UZI abonnenumummer ook wel bekend als het URA nummer. Als middel voor de authenticatie van dit nummer gebruiken we een verifiable credenial 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.
Zorgverleners
De raadplegende zorgverlener zelf wordt niet geauthenticeerd, er wordt vertrouwd op het authenticeringsmechanisme van de gebruikte applicatie. Wel worden er identificerende attributen tbh logging- en auditdoeleinden meegestuurd in de vorm van een NutsEmployeeCredential.
Grondslag en toestemming
Voor de zorgtoepassing huisartsinzage in het thuiszorgdossier worden de volgende grondslagen ondersteund: expliciete toestemming vooraf.
In een later stadium kan onder de in de Nuts Bolt Zorginzage beschreven voorwaarden desgewenst de Wabvpz-toestemming vooraf worden toegevoegd.
Voor expliciete toestemming vooraf zijn de volgende bewijzen toegestaan:
- registratie in het bronsysteem (bijvoorbeeld door middel van een 'vinkje')
- ingescand, door de betrokkene ondertekend, toestemmingsformulier
Toestemming voor het delen van data gebeurt op organisatie niveau. Een toestemming moet dus naar een URA nummer terug te leiden zijn.
Organisatiebeleid
- Iedere partij die de zorgtoepassing huisartsinzage in het thuiszorgdossier aanbiedt is zelf verantwoordelijk voor de beschikbaarheid van de eigen infrastructuur, het bron- en/of afnemersysteem en de Nuts-node.
- De leveranciers van de actor voldoet aan de eisen zoals gesteld in de NEN7510, NEN7512 en NEN7513.
- De leveranciers van de actor voldoet aan de eisen zoals gesteld in de Algemene verordening gegevensbescherming (AVG).
- De leveranciers van de actor voldoet aan de eisen zoals gesteld in de Wet aanvullende bepalingen verwerking persoonsgegevens in de zorg (Wabvpz).
Access Policy
Niet-persoonsgebonden resources
Momenteel niet van toepassing.
Persoonsgebonden resources
Dit hoofdstuk beschrijft de afspraken die gelden voor persoonsgebonden resources.
Autorisatie-record
Nuts Authorization Credentials zijn deprecated.
TODO: Dit stuk moet worden omgeschreven naar een Policy Based Access Controll (ABAC). Tijdens de hackathon is daar een OPA policy ontwikkeld die gebruik maakt van het zorgnetwerk en de introspectie resultaten van het access token.
Het ophalen van huisartsinzage in het thuiszorgdossier vereist een geregistreerd autorisatie-record in de vorm van een Nuts Authorization Credential. Het credential moet voldoen aan de volgende eisen:
- De issuer moet het DID bevatten van de bronhouder.
- credentialSubject.id moet het DID van de afnemer bevatten
- credentialSubject.purposeOfUse moet gelijk zijn aan zorginzage-thuiszorgdossier-door-huisarts.
- credentialSubject.legalBase.consentType moet gelijk zijn aan implied bij veronderstelde toestemming of explicit bij expliciete toestemming
- credentialSubject.subject moet het BSN bevatten als OID: urn:oid:2.16.840.1.113883.2.4.6.3:999999990.
Normatieve einddatum autorisatie
Bij het aanmaken van een autorisatie-record dient door middel van het veld 'expirationDate' een einddatum aan de autorisatie te worden gegeven. Ten eerste dient deze einddatum gebaseerd te zijn op de wensen van de cliënt in kwestie. De zorgverlener dient de cliënt te vragen naar de gewenste duur van een toestemming. Wanneer de wens van de cliënt ten aanzien van de duur van de toestemming niet is vastgelegd, gelden de volgende normen Bij een 'expliciete toestemming vooraf' is geen einddatum.
Intrekken autorisatie
Er zijn verschillende redenen denkbaar voor het intrekken van een autorisatie:
- Wanneer een autorisatie is gebaseerd op een expliciete toestemming dient deze te worden ingetrokken wanneer de expliciete toestemming wordt ingetrokken. Het autorisatie-record moet in deze gevallen worden ingetrokken door de bronhouder.
Access token
Bij de aanvraag van het access token moet het autorisatie-record volgens bovenstaande eisen worden meegestuurd in het credentials-element. Daarnaast moet er gebruikersinformatie meegestuurd worden in het uzi-element. Het purposeOfUse-element moet de waarde ‘zorginzage-thuiszorgdossier-door-huisarts‘ bevatten.
Levensduur access token: 300 seconden (5 minuten)
Authenticatiecontract
Levensduur authenticatiecontract: 36.000 seconden (10 uur)
Authenticatie vindt plaats op basis van inrichting van het bevragend systeem. Bij deze bevraging wordt het UZI-nummer meegegeven als identificatie voor in de logging.
Autorisatie policy
Wanneer een bronhouder een binnenkomend request afhandelt moet op basis van de BSN, zoals vermeld in het autorisatie-record, toegang worden gegeven tot de gerelateerde resources zoals benoemd in het hoofdstuk Resources.
Er wordt gewerkt met een eenvoudig autorisatiemodel op basis van de identiteit van de raadplegende organsiatie. De gebruikersrol wordt niet meegenomen in de autorisatie beslissing.
Resources
Deze sectie beschrijft de ZIBS en bijbehorende FHIR profielen die moeten worden ondersteund. In de specificatie is een set van ZIBs opgenomen waarin de huisarts geïnteresseerd is. Die set is een subset van de set die is gerealiseerd in de NUTS toepassing voor ANW. De beschikbaar stellende partijen in fase 1 (Nedap en eCare) hebben die gebreidere set al beschikbaar. Het ligt daarom voor de hand de ANW set te hanteren als startpunt en te bezien in hoeverre en onder welke voorwaarden die voor de huisarts relevant zijn.
Logistiek
Concept | ZIB(s) | FHIR-resource |
---|---|---|
Patient/Client | https://zibs.nl/wiki/Patient-v3.1(2017NL) en https://zibs.nl/wiki/BurgerlijkeStaat-v3.0(2017NL) | https://simplifier.net/nictizstu3-zib2017/nl-core-patient |
Zorginhoudelijk
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:
- Het opvragen van patient data door een zorgverlener
- Het vastleggen van het patient netwerk door een zorgvelener
- Het vastleggen van de patient toestemming door de burger/zorgverlener
- Het uitgeven van een zorgaanbieder identiteit door de IT-dienstverlener
- 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:
- Aansluiting bij relevante wet- en regelgeving
- Aansluiting bij het werkproces van zowel de VVT-organisatie als van de huisartsenpraktijk.
- Aansluiting bij de visie van de betrokken partijen op het gebied van netwerkzorg en gegevensontsluiting.
- Aansluiting bij bewaken van belangen van de betrokken cliënten.
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:
- Recht op inzage wie het cliëntdossier ingezien heeft
- Recht om bezwaar te maken
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:
- Specifiek vastleggen wie de huisarts is (op persoonsniveau)
- Hoe om te gaan met allerlei soorten wijzigingen
- Hoe om te gaan met (tijdelijke) vervanging van de huisarts
- Hoe om te gaan met evt. delegering van de inzagebevoegdheid door de huisarts binnen de praktijk
Concreet betekent dit dat de technische authenticatie-opzet mogelijk ingericht moet worden op twee niveaus, verschillend per leverancier:
- 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.
- 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:
|
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:
|
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:
|
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.
|
Technisch (verschillende HIS’sen), Organisatorisch | Technisch en organisatorisch:
|
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.
-
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.
-
De huisarts of POH wil een VVT dossier koppelen aan de patiënt. Je klikt hiervoor op de knop Koppel dossier.
-
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.
-
Het VVT-dossier wordt nu opgehaald bij de gekoppelde VVT-organisatie.
- 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.
- 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.
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.
- 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.
Klik bijvoorbeeld op Bloeddruk.
Dan vouwt het bloeddrukscherm open waardoor je alle bloeddruk metingen kan inzien die de VVT heeft ingevoerd.
- 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.
- 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.