Zorginzage V6 hackathon spec
Dit document heeft de status DRAFT
Zorginzage V6 hackathon purpose
The purpose of the zorgingz
Functional design
Discovery Service (adressbook & use-case whitelist)
The Discovery Service serves the function of an adressbook for the organisations that are compliant and available for this specific usecase. The Discovery Service has its own use-case specific schema: Presentation Definition (PD). All the vendors in the usecase prove their compliance with the PD by periodically publishing their PD to the discovery service.
*For more info in DS see: https://docs.google.com/presentation/d/1LRnY5JfMAcMwwqEonX3n_uEDT1geQ3Kj_IKxS-ZeeVA/edit#slide=id*.g1f525990acb_0_159
Presentation defintion: VC component
The PDs credibility is determined by verifiability of the required credentials (VC). Only one verifiable credential will be used for the hackaton. This is very similiar to the Nuts Organition Credential in V5, but the primary difference is that it is no longer self-issued, but rather issued by a governing authority
Credential contents:
- URA (logical identifier)
- Adress
- ?
Credential issuer:
There will be one trusted party that issues these VCs to the server-side-wallets of the other vendors in this usecase. We can use the following open source implementation to issue the credentials:
- Add link from Rein
- Decide who spins it up
Presentation definition: logistical information component
Alongside the VCs in the presentation definition, there following logistical information must also be presented
- Usecase ID:
- Max validity:
60 minutes - Server endpoint(s
Localization
By localization we mean “finding out where a patient is in treatment”. That will not be in scope for this hackaton. Instead, we will request directly to the other organisations in the discovery service without checking/finding out if there is a patient file there.
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 bronhouder. To ensure interoperability, a uniform standard for the data-acces policies is described for each usecase. The intention for the hackaton is to define this in the Open Policy Agent (OPA) scripting languagen.
Practioner identification & authentication
The practioner that initiates the request must be identifiable so that it can be verified at a later moment who iniated 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 ensure the action is preformed by a human, an Employee Identity Credential is a required and checked in the data-access policy.
- Expand and describe how
Authorization (checking legal base)
It is the responsiblity of the bronhouder to check wheter the requestor has a legal-base for accessing the data. For this Hackaton it is not a requirement to perform this check, nor does it have to be standardized. However, it is important that we standardize the error-responses to be used and what they indicate.
- Are we indeed not going to do any authorization standardization in this hackton? Open Discussion
Access token specification
The eventual access-token will look like this
- to-do
Resources
The aim is to validate that a simple data-request can be succesful. Therefore the set of resources is deliberately limited.
Data-exchange
- Patient resource (link to Stu3 profile)
- Consent resource (link to Stu3 profile)
Technical design
- Todo: sequence diagrams
- Todo: architecture map
- Todo: specifying VC schemas
Dit document beschrijft het zorgtoepassingprofiel huisartsinzage in het thuiszorgdossier. Het profiel is gebaseerd op de Nuts Bolt Zorginzage 2022 en bevat specifieke afspraken de gelden voor de zorgtoepassing huisartsinzage in het thuiszorgdossier.
Dit artikel beschrijft achtereenvolgens
- de identifier van de zorgtoepassing;
- de governance;
- de informatiestandaarden;
- de toegestane authenticatiemiddelen;
- de toegestane grondslagen;
- organisatiebeleid en
- de access policy.
Identifier van de zorgtoepassing
De identifier van de zorgtoepassing huisartsinzage in het thuiszorgdossier is ‘zorginzage-thuiszorgdossier-door-huisarts’
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.
Informatiestandaarden
Er is op dit moment geen informatiestandaard beschikbaar rondom de inzage van het thuiszorgdossier. Zolang deze nog niet beschikbaar gebruiken we de resources die verderop in het document vermeld worden.
Daarbij is het belangrijk dat we een invulling geven aan het niet onnodig delen van rapportages die niet van nut zijn voor huisartsen. Het verdient aandacht om te zien op basis van welk criteria we daar het filter op kunnen zetten (bij de bron).
Toegestane authenticatiemiddelen
Om veilig gegevens te kunnen delen, tussen verschillende zorgaanbieders, is zorgaanbieder-overstijgende authenticatie van zorgverleners essentieel. Vanuit de NEN wordt gewerkt aan een norm met betrekking tot identificatie en authenticatie. Op het moment dat deze norm gepubliceerd wordt, is deze norm leidend. Om op korte termijn informatie uitwisseling mogelijk te maken, tot publicatie van de norm, zal vertrouwd worden op de authenticatie van het raadplegende systeem.
Toegestane grondslagen en bewijzen
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 gebeurd op organisatie niveau. Daarom gaan we uit van een autorisatie op AGB-niveau.
Expliciete toestemming wordt vooraf afgegeven voor mogelijk meerdere AGB’s.
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
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.
Voor deze resources wordt een bundel opgesteld. Iedereen die dit zorgtoepassingsprofiel ondersteund voldoet aan de voorgestelde bundel. Deze zal op een later moment ingediend worden bij NICTIZ.
Logistiek
Zorginhoudelijk
| Concept | ZIB | FHIR-resource |
|---|---|---|
| Tekst rapportages | nog niet beschikbaar | https://simplifier.net/anw/nl-core-nursingreport |
| Bloeddruk | https://zibs.nl/wiki/Bloeddruk-v3.1(2017NL) | https://simplifier.net/nictizstu3-zib2017/zib-bloodpressure |
| Lichaamsgewicht | https://zibs.nl/wiki/Lichaamsgewicht-v3.1(2017NL) | https://simplifier.net/nictizstu3-zib2017/zib-bodyweight |
| Lichaamslengte | https://zibs.nl/wiki/Lichaamslengte-v3.1(2017NL) | https://simplifier.net/nictizstu3-zib2017/zib-bodyheight |
| Pijnscore | nog niet beschikbaar | |
| Bloedglucose | https://zibs.nl/wiki/LaboratoriumUitslag-v4.6(2020NL) | https://simplifier.net/nictizstu3-zib2017/vitalsign-bloodglucose |