UC Resource Server - 0.7.x

Controle en gebruik van het access_token

Om meta-informatie te kunnen meegeven bij een FHIR interactie en om het beveiligingsniveau te verhogen wordt bij iedere FHIR interactie een AORTA access_token meegestuurd. Een FHIR interactie die wordt ingestuurd door de Resource Broker en waar geen geldig access_token is bijgevoegd dient te worden geweigerd.

Het JWT-based access_token wordt op basis van RS256 (RSA Signature met SHA-256), digitaal ondertekend met de private key van de Autorisatie Server. De public key waarmee de digitale handtekening kan worden gecontroleerd wordt conform RFC 7517, als een JWK beschikbaar gesteld.

De URL van waarop de JWK Set kan worden opgevraagd (jwks_uri) is opgenomen in de metadata van de autorisatieserver, die via de AS Metadata Interface, kan worden opgehaald.

De iss van het token is opgenomen in het token zelf, maar wordt vanwege security redenen ook via het AORTA Stelseltoken bij de resource server aangemerkt als een vertrouwde issuer. De resource server mag geen tokens verwerken van niet-vertrouwde issuers. De resource server moet controleren dat de waarde van <iss> overeenkomt met de waarde van issuer in de ontvangen metadata.

Iedere JSON Web Key (JWK) in de set bevat een kid parameter. De juiste JWK in de JWK Set wordt gevonden o.b.v. de waarde van het kid attribuut in de header van de ontvangen JWT, en waarvan het kty attribuut gelijk is aan "RSA" en het use attribuut gelijk is aan "sig".

Het access_token wordt door de resource server gebruikt om vast te stellen of een binnenkomend verzoek mag worden behandeld en om de gegevensverwerking te loggen.

Uit te voeren controles m.b.t. het access_token:

1. Is het token uitgegeven door een voor mij vertrouwde partij (issuer, in dit geval door de Autorisatie Server MedMij of door de Autorisatie Server ZA), vertrouwde autorisatieservers zijn opgenomen in het AORTA Stelseltoken.
2. Juistheid van de digitale handtekening (signature), inclusief de geldigheid van het certificaat waarmee de handtekening is geplaatst. Hierbij worden ook maatregelen genomen om bedreiging 2.1 uit RFC 8725 tegen te gaan.

3. Wordt het token gebruikt door de partij (resource client) aan wie het is uitgegeven.

   • JWT-based access_token: via controle van de client_id claim in combinatie met de geauthentiseerde TLS-client. Het FQDN van de client (Resource Broker VnC) is opgenomen in het AORTA Stelseltoken.

4. Mag het token door mij worden geconsumeerd.

   • JWT-based access_token: via controle van de aud claim

5. Is de geldigheidsduur van het token niet verstreken. Met betrekking tot het ingangstijdstip dient, wanneer problemen ontstaan door tijdsynchronisatie, een gracetime te kunnen worden gehanteerd. Deze bedraagt maximaal 15 seconden. Aanbevolen wordt om deze gracetime configureerbaar te maken.

6. Bij interactie door patiënt (te zien aan de role claim van het access_token):

   • JWT-based access_token: is de inhoud van de patient claim gelijk aan de inhoud van de sub claim.

   Toelichting: omdat machtigingen/mandateringen nog niet worden ondersteund, mag de sub claim niet afwijken van de patient claim, en moet een token, wanneer dit wel het geval is, worden beschouwd als "invalid". De Autorisatieserver MedMij component zou een dergelijk token, binnen deze versie van de access_token definitie, nooit uitgeven.

7. Valt de interactie onder het type interacties waarvoor het access_token geldig is (scope). NB. de exacte scope van MedMij gegevensdiensten en van AORTA zorgtoepassingen wordt getoetst door de Resource Broker. De resource server kan volstaan met het toetsen van het SMART-on-FHIR deel van de scope. Een search op Observation vereist dan bijvoorbeeld dat patient/Observation.read deel uitmaakt van de scope. Bij ontvangst van een FHIR read interactie dient expliciet te worden getoetst of de gevraagde resource instance deel uitmaakt van het dossier van de patient die is aangegeven in het access_token.

NB. de scope van een access_token kan meerdere interacties omvatten, die ook na elkaar kunnen worden uitgevoerd. Een resource server moet het daarom toestaan wanneer eenzelfde access_token meerdere malen wordt gebruikt.

Toelichting logging

Een resource server dient een log bij te houden van alle ontvangen request en van alle retourneerde responses. Een dergelijke log bevat, t.b.v. de traceerbaarheid van berichten in de keten tenminste de volgende attributen.

Ondersteunde mimetypes

De informatiestandaard van MedMij perkt het aantal mogelijke op te leveren mimetypes in tot application/pdf (en specifiek tot PDF/A, waarbij minimaal PDF/A1b wordt vereist).

Omdat de Resource Broker mimetypes kan vertalen is het voor Resource Servers toegestaan om documenten op te leveren conform de volgende mimetypes (let op! nog niet mogelijk in AoF 0.5, 0.6 en 0.7):

1. application/pdf
2. application/msword
3. application/vnd.openxmlformats-officedocument.wordprocessingml.document
4. application/rtf
5. text/plain
6. text/html
7. image/jpeg
8. image/tiff

Nader onderzocht zal worden of ook de volgende mimetypes kunnen worden opgeleverd:

1. application/xml
2. image/bmp
3. image/png
4. text/xml

Vulling content.attachment.url

Wanneer een Resource Server een DocumentReference retourneert, dan dient content.attachment.url als volgt te worden gevuld:

• <base endpointadres van resource server>/Binary/<id>, of
• Binary/<id>

Resource Broker MedMij-in of Resource Broker ZA-in transformeert content.attachment.url voor oplevering naar het volgende formaat:

• <base endpointadres van resource broker XX-in>/<appID>/Binary/<id>

Waarbij <appID> het applicatie-id (zonder root OID) bevat van de Resource Server.

Codering documenten

Binnen VIPP 5 bestaat correspondentie uit radiologieverslagen, specialistenbrieven, voortgangsbrieven en/of ontslagbrieven, opgesteld in de eigen organisatie. In onderstaande tabel zijn de bijbehorende, mogelijke, class en type coderingen opgenomen. De informatiestandaard stelt geen precieze eisen aan welke codes exact mogen worden toegepast.

Cardinaliteiten

Onderstaande tabel bevat een samenvatting van de gehanteerde cardinaliteiten in de informatiestandaard.

Toelichting beschikbaarheidsvoorwaarde

In de programma's van eisen die gelden voor bronsystemen zijn een aantal eisen opgenomen die gaan over het al dan niet beschikbaar stellen van bepaalde gegevens voor opvragende partijen:

1. Patiëntgegevens mogen pas worden opgeleverd nadat het BSN van patiënt door de zorgaanbieder is geverifieerd.
2. Patiëntgegevens moeten na vastlegging, automatisch of op commando van een zorgverlener/medewerker, vrijgegeven kunnen worden. Vrijgegeven patiëntgegevens moeten ook weer kunnen worden afgeschermd. Vrijgeven en afschermen moet kunnen op dossierniveau. Vrijgeven en afschermen moet mogelijk zijn per individuele patiënt. Bij afschermen dient onderscheid gemaakt te kunnen worden tussen bevragingen door patiënten en bevragingen door zorgverleners/medewerkers.
3. Alvorens gegevens van een patiënt op te leveren, dient er gecontroleerd te worden of de patiënt hiervoor toestemming heeft verstrekt. Dit kan worden afgeleid van het access_token in combinatie met het AORTA vertrouwensmodel, of uit een lokaal, in het GBZ vastgelegde toestemming.
4. Indien de opvrager een patiënt is, dan dient de resource server (het GBZ) te controleren of een behandelrelatie bestaat (danwel heeft bestaan) tussen patiënt en zorgaanbieder, en of de leeftijd van de persoon van wie gegevens worden opgevraagd minimaal 16 jaar is.
5. Bij het al dan niet beschikbaar stellen van gegevens mag het systeem dat de patiënt gebruikt, en de organisatie dit dit systeem aanbiedt niet als een criterium worden gehanteerd.

Tevens moet de resource server borgen dat gegevens die worden opgeleverd daadwerkelijk betrekking hebben op de patiënt (BSN), zoals opgenomen in het AORTA access_token.

Indien de opvrager een patiënt, is dan geldt dat in de volgende situaties niet wordt voldaan aan de MedMij beschikbaarheidsvoorwaarde:

• Er bestaat geen behandelrelatie tussen zorgaanbieder en patiënt en een behandelrelatie heeft ook nooit bestaan.
• De leeftijd van de opvrager is niet toereikend.
• De gevraagde gegevens zijn afgeschermd of niet vrijgegeven.

Gegevensdienst-specifieke UC extensions en implementatiehandleidingen

De gegevensdienst-specifieke delen van deze use cases maken deel uit van de betreffende <resourcetype> <interactietype> Verwerkend systeemrollen, bijvoorbeeld Observation Search Verwerkend Systeem of MedicationStatement Search Verwerkend Systeem.

FHIR-interacties: de implementatiehandleiding die van toepassing is voor een specifieke gegevensdienst is opgenomen in onderstaande tabel.

HL7v3-interacties: de implementatiehandleiding die van toepassing is, is opgenomen in onderstaande tabel.

Toelichting vulling BSN bij opleveren van gegevens

Alle use cases waarin de resource server gegevens op dient te leveren zijn gebaseerd op de MedMij FHIR informatiestandaarden van Nictiz. Omdat het de bedoeling is dat gegevens (op termijn) zowel kunnen opgeleverd aan PGO Servers in MedMij als aan Initiërende GBZ'en binnen AORTA gelden een aantal specifieke AORTA aanvullingen op de informatiestandaarden.

Het profiel voor nl-core-patient bevat een attribuut Patient.identifier, waarin het BSN van een persoon kan worden opgenomen. De MedMij FHIR informatiestandaarden beschrijven echter dat geen BSN mag worden opgenomen in de Patient resource, omdat PGO Servers geen wettelijke grondslag hebben om deze te mogen verwerken.

Omdat voor uitwisseling tussen zorgaanbieders onderling het BSN juist wel verplicht is, is het gewenst dat de Patient.identifier daarom wel wordt gevuld met het BSN van de betreffende persoon. Resource Broker MedMij-in zal het BSN filteren voordat de gegevens worden geretourneerd aan een PGO Server.

Toelichting vulling BSN bij ontvangen van gegevens

Alle use cases waarin de resource server gegevens dient te ontvangen zijn gebaseerd op de MedMij FHIR informatiestandaarden van Nictiz. Omdat het de bedoeling is dat gegevens (op termijn) zowel kunnen worden ontvangen van PGO Servers in MedMij als van Initiërende GBZ'en binnen AORTA gelden een aantal specifieke AORTA aanvullingen op de informatiestandaarden.

Het profiel voor nl-core-patient bevat een attribuut Patient.identifier, waarin het BSN van een persoon kan worden opgenomen. De MedMij FHIR informatiestandaarden beschrijven echter dat geen BSN mag worden opgenomen in de Patient resource, omdat PGO Servers geen wettelijke grondslag hebben om deze te mogen verwerken.

Omdat voor uitwisseling tussen zorgaanbieders onderling het BSN juist wel verplicht is, zal de Patient.identifier daarom wel worden gevuld met het BSN van de betreffende persoon. Resource Broker MedMij-in zal het BSN toevoegen voordat de gegevens worden verzonden richting een resource server. 

De resource server moet borgen dat gegevens die worden ontvangen en verwerkt daadwerkelijk betrekking hebben op de patiënt (BSN), zoals opgenomen in het AORTA access_token.