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.
ToegestaneIdentiteit authenticatiemiddelenen authenticatie
TODO: Hier de Organisatie Identitiet op basis van UZI Server certificaat via X509Credentials opnemen. Zie ook de hackathon specificatie.
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,wordt iszullen we de landelijke ontwikelingen mbt tot deze norm leidend.volgen. Om op korte termijn informatie uitwisseling mogelijk te maken, tot publicatie van de norm, zal de authenticatie geborgd worden op de volgende manier:
Organisaties
Om de gebruikenderaadplegende organisatie te authenticerenidentificeren wordt gebruik gemaakt van het UZI Servercertificaatabonnenumummer zoalsook beschikbaarwel inbekend als het deelnemendeURA applicatie.nummer. HetAls uniekmiddel indentificerendevoor 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 datafgeleid gebruiktvan wordteen UZI Servercertificaat van de betreffende organisatie. We gebruiken hiervoor een nieuw credential NutsX509Credential waarvan de ontwikkeling hier te volgen is.
Zorgverleners
De gebruikerraadplegende zorgverlener zelf wordt niet geauthenticeerd, er wordt vertrouwd op het authenticeringsmechanisme van de deelnemendegebruikte applicatie. Wel wordtworden eener uniekidentificerende medewerker-ID meegegevenattributen tbh logging- en auditdoeleinden.auditdoeleinden meegestuurd in de vorm van een NutsEmployeeCredential.
Toegestane grondslagenGrondslag en bewijzentoestemming
Voor de zorgtoepassing huisartsinzage in het thuiszorgdossier worden de volgende grondslagen ondersteund:
‘expliciete toestemmingvooraf’
In een later stadium kan onder de in de Nuts Bolt Zorginzage beschreven voorwaarden desgewenst de ‘Wabvpz-toestemming vooraf’'vooraf worden toegevoegd.
Voor ‘expliciete toestemming vooraf’vooraf zijn de volgende bewijzen toegestaan:
- registratie in het bronsysteem (bijvoorbeeld door middel van een 'vinkje')
- ingescand, door de betrokkene ondertekend, toestemmingsformulier
Toestemming gebeurdvoor het delen van data gebeurt op organisatie niveau. DaaromEen gaantoestemming wemoet uitdus vannaar een autorisatieURA opnummer AGB-niveau.
Explicietete toestemmingleiden wordt vooraf afgegeven voor mogelijk meerdere AGB’s.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 |