Use Cases Resource Server

Overzicht Resource Server

Een GBZ-applicatie kan zowel fungeren in de rol van Resource Server als in de rol van Resource Client. Een Resource Server reageert op interacties die worden geïnitieerd middels een interface. Een Resource Server initieert zelf geen interacties. 

Onderstaande figuur toont een overzicht van de interfaces en services die worden geboden door de Resource Server, en van de interfaces die worden gebruikt door de Resource Server.

De services zijn toegankelijk via een geboden interface en worden beschreven in de vorm van use cases. Een aantal services maken gebruik van onderliggende services. Een dergelijk onderliggende service wordt dan beschreven in de vorm van een use case inclusion of als een use case extension.

Services behoren tot een bepaalde functie. Onderstaande figuur toont een overzicht van de services en functies van de Resource Server.

Verschillen tussen een HL7-FHIR Resource Server en een HL7v3 Resource Server zijn:

• Een HL7v3 Resource Server biedt een AORTA v3-interface i.p.v. een AORTA FHIR Resource Interface.

• Deze interface biedt toegang tot de generieke service "Verwerken AORTA v3-interactie".

HL7-FHIR Resource Server

Opleveren AORTA CapabilityStatement

Pre-condities

Triggers

• De resource broker wil de operationele status van de resource server toetsen.

Main flow

Post-condities

Verwerken AORTA FHIR-interactie

Pre-condities

Triggers

• De primaire actor initieert een FHIR-interactie.

Main flow

Post-condities

HL7-v3 Resource Server

Verwerken AORTA v3-interactie

Pre-condities

Triggers

• De primaire actor initieert een v3-interactie.

Main flow

Post-condities

Toelichtingen

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 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 Metadata Interface van de Autorisatie Server MedMij of van de Autorisatie Server ZA, 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.

Het AORTA Stelseltoken kan worden opgehaald via de AORTA Stelsel Metadata Interface.

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.

   • 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.

   • Voorbeeld: stel het client_id in het access_token is gelijk aan "urn:oid:2.16.840.1.113883.2.4.3.111.8.400”. Uit het stelseltoken wordt gelezen dat op het moment slechts één component bestaat met deze rol, en dat het FQDN ervan gelijk is aan “LSP110.csc-lsp.nl”. Om er zeker van te zijn dat het token wordt gebruikt door de juiste partij kan nu worden getoetst of de CN van het client certificaat dat wordt gebruikt op de TLS-verbinding gelijk is aan de genoemde FQDN. Om deze toets te kunnen doen, dient de TLS-server die wordt gebruikt door de Resource Server deze client informatie waarschijnlijk door te geven aan de Resource Server, bijvoorbeeld via een HTTP “X-SSL-Client-CN” header.

4. Mag het token door mij worden geconsumeerd.

   • 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):

   • 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 beschikbaarstelling

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 zogeheten 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.

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.

Toelichting ondersteunde mimetypes

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

Toelichting 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.

Toelichting 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.

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

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.

Informatiestandaard specifieke verwerking van requests

De implementatiehandleiding die van toepassing is voor een specifieke MedMij gegevensdienst is opgenomen in onderstaande tabellen.

Wanneer een request een interactie betreft die onderdeel is van een AORTA zorgtoepassing, dan is de implementatiehandleiding van de betreffende zorgtoepassing van toepassing.