Interfaces Resource Broker GTK

1

Het systeem ontvangt een verzoek en start de verwerking.

2

Het systeem toetst of het verzoek voldoet aan de interface specificatie.

3

<exit>

core-FHIR-interactie-GTK-uit

1.2.0

AORTA Stelseltoken

>=*

>=*

core-FHIR-interactie-GTK-uit

1.2.0

AORTA-ID HTTP Header

>=1.0.0

>=1.0.0

core-FHIR-interactie-GTK-uit

1.2.0

AORTA-Version HTTP Header

>=1.0.0

>=1.0.0

core-FHIR-interactie-GTK-uit

1.2.0

Authorization HTTP Header

>=1.0.0

>=1.0.0

core-FHIR-interactie-GTK-uit

1.2.0

AORTA access_token

>=*

-

core-FHIR-interactie-GTK-uit

1.2.0

getMetadataZA

>=1.0.0

-

core-FHIR-interactie-GTK-uit

1.2.0

Issue TWIIN Assertions

>=1.*

-

1

Het systeem controleert of alle vereiste tokens zijn toegevoegd aan het request

Ontbrekend token

statuscode 401 Unauthorized

• In deze situatie wordt geen nadere informatie over de opgetreden fout geretourneerd. In deze situatie wordt, conform RFC 6750, ook een WWW-Authenticate HTTP response header met als auth-scheme "Bearer", maar zonder foutcode of nadere informatie omtrent de fout geretourneerd. Indien de WWW-Authenticate HTTP response header wordt geproduceerd door de resource broker, dan wordt een realm attribuut met waarde "aorta" toegevoegd.

2

Het systeem controleert de geldigheid van het AORTA access_token, zoals omschreven in de toelichting Controle en gebruik van het access_token.

Stap

Omschrijving

i

Het systeem controleert of het ontvangen resource request is toegestaan binnen de scope van het access_token. Zie ook de toelichting "Controle of request binnen scope valt" en de toelichting "Controle van batch en transaction requests".

3

Het systeem verkrijgt, o.b.v. de URA in de audience van het ontvangen AORTA access_token, via ZORG-AB het token endpoint en het resource endpoint van de zorgaanbieder aan wie het ontvangen resource request moet worden doorgezet (zie: “Specificaties gebruik ZORG-AB”).

Endpoints niet gevonden binnen Twiin

statuscode 500 Internal Server Error

Fout bij bepalen endpoints

statuscode 500 Internal Server Error

4

Het systeem verkrijgt m.b.v. Feature Issue TWIIN Assertions een client_assertion en zonodig een assertion om te gebruiken bij het gevonden authorization endpoint.

Geen assertions verkregen

5

Het systeem verzendt, conform het Twiin afsprakenstelsel, een token request naar het gevonden authorization endpoint.

Indien in de vorige stap een scope attribuut werd verkregen, dan gebruikt het systeem dit attribuut in het te verzenden token request.

Indien in de vorige stap géén scope attribuut werd verkregen, dan zijn er twee mogelijkheden:

• Het systeem vult de scope van het uitgaande token request o.b.v. relevante onderdelen van de ontvangen scope in het AORTA access_token. De scope van het AORTA access_token is altijd gevuld conform interacties die een Resource Server, eventueel na transformatie, daadwerkelijk gaat ontvangen. OF

• Het systeem stuurt géén scope mee in het uitgaande token request. Een scope is niet vereist, omdat in deze situatie een authorization_base zal zijn opgenomen in de assertion die wordt meegestuurd. Het externe GTK gebruikt deze authorization_base dan om de vereiste scope te bepalen.

Vooralsnog wordt de 2e mogelijkheid gehanteerd.

6

Het systeem ontvangt een token response.

Toegang geweigerd (403 met error=access_denied ontvangen)

Geen access_token verkregen (andere redenen)

7

Het systeem verzend, conform het Twiin afsprakenstelsel, het ontvangen resource request naar het gevonden resource endpoint.

8

Het systeem ontvangt een response.

Geen (tijdig) antwoord van secundaire actor

9

<exit>

core-FHIR-interactie-GTK-in

1.3.1

AORTA Stelseltoken

>=*

-

core-FHIR-interactie-GTK-in

1.3.1

AORTA access_token

>=*

-

core-FHIR-interactie-GTK-in

1.3.1

getMetadataZA

>=1.0.0

-

core-FHIR-interactie-GTK-in

1.3.1

Initiëren reguliere FHIR-interactie

>=1.*

-

core-FHIR-interactie-GTK-in

1.3.1

Uitvoeren push-aorta-data

>=1.*

-

Stap

Omschrijving

i

Het systeem ontvangt een verzoek en start de verwerking.

Het systeem toetst of het gevraagde type content (Accept header) en het gehanteerde type content (Content-Type header) worden ondersteund.

NB. wanneer het verzoek wordt ontvangen van een component van VZVZ, dan hoeft geen toets op type content te worden uitgevoerd.

Gevraagd type content niet ondersteund

statuscode 406 Not Acceptable

• Deze situatie kan slechts optreden wanneer requests worden ontvangen via HTTP(S)

Gehanteerd type content niet ondersteund

statuscode 415 Unsupported Media Type

• Deze situatie kan slechts optreden wanneer requests worden ontvangen via HTTP(S)

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

Stap

Omschrijving

i

Het systeem controleert of alle vereiste tokens zijn toegevoegd aan het request

Ontbrekend token

statuscode 401 Unauthorized

• In deze situatie wordt geen nadere informatie over de opgetreden fout geretourneerd. In deze situatie wordt, conform RFC 6750, ook een WWW-Authenticate HTTP response header met als auth-scheme "Bearer", maar zonder foutcode of nadere informatie omtrent de fout geretourneerd. Indien de WWW-Authenticate HTTP response header wordt geproduceerd door de resource broker, dan wordt een realm attribuut met waarde "aorta" toegevoegd.

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

ii

Het systeem controleert de geldigheid van de meegezonden, van toepassing zijnde, tokens

• AORTA access_token, zoals omschreven in de sectie "Toetsing AORTA access_token".

• DigiD Authenticatietoken, zoals omschreven in de sectie “Toetsing DigiD Authenticatietoken”.

NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.

Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.

Ongeldig token

statuscode 401 Unauthorized

• In deze situatie wordt, conform RFC 6750, ook een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_token" geretourneerd. Indien de WWW-Authenticate HTTP response header wordt geproduceerd door de resource broker, dan wordt een realm attribuut met waarde "aorta" toegevoegd.

• In deze situatie mag daarnaast ook een OperationOutcome met issue.code "security" worden geretourneerd.

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

iii

Indien van toepassing: Het systeem controleert de samenhang tussen het AORTA access_token en het DigiD authenticatietoken, zoals omschreven in de de sectie "Toetsing van samenhang tussen tokens".

NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.

Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.

Ongeldig token

statuscode 401 Unauthorized

• In deze situatie wordt, conform RFC 6750, ook een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_token" geretourneerd. Indien de WWW-Authenticate HTTP response header wordt geproduceerd door de resource broker, dan wordt een realm attribuut met waarde "aorta" toegevoegd.

• In deze situatie mag daarnaast ook een OperationOutcome met issue.code "security" worden geretourneerd.

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

1

Indien

• een get-aorta-data request OF

• een FHIR-search interactie wordt ontvangen die is gericht aan een zorgaanbieder (URA):

Het systeem achterhaald, m.b.v. de AORTA Token Interface (middels Feature AORTA Token Expansion), welke interactie(s) moet(en) worden geïnitieerd, en bij welke GBx-applicatie(s).

Interactie(s) en/of GBx-applicaties kunnen niet worden vastgesteld

statuscode 500 Internal Server Error

Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

Géén GBx-applicatie gevonden

Het systeem gaat direct naar stap 5 (samenstellen van response) van de main flow.

2

Voor elke GBx-applicatie, waar één of meerdere interacties moeten worden geïnitieerd, worden voor iedere te initieren interactie de volgende stappen doorlopen:

• Het systeem stelt, o.b.v. het, door de primaire actor, gevraagde protocol van de response en het al dan niet aanwezig zijn van een transformationId in de _vrb_ter_scope claim van het AORTA access_token, vast of een HL7-v3, of een HL7-FHIR interactie moet worden uitgestuurd, en of een transformatie moet worden uitgevoerd (zie ook de toelichtingen “Opbouwen van queries“ en “Vaststellen van het te hanteren protocol”).

• Het systeem stelt vast naar welke endpoint de interactie dient te worden doorgestuurd, zoals omschreven in de toelichting "Bepalen van de ontvangende resource servers".

• Indien het te initieren interactie een search-interactie is, dan bepaalt het systeem o.b.v. de AORTA interactietabel welke secundaire resources horen bij de search. Deze worden (indien nog niet aanwezig in het ontvangen request) als _include parameters toegevoegd aan de interactie.

• Het systeem initieert de vereiste interactie. Indien een transformatie is vereist, en de te initieren interactie is géén v3-query, een FHIR-read of een FHIR-search, dan initieert het systeem hiervoor eerst de use case Transformeer content middels de Transformatie Interface (zie ook de toelichting “Aanroep van de Transformatie Server”). De base-URL van de Transformatie Server wordt verkregen uit het AORTA Stelseltoken.

• Het systeem bepaalt of een Provenance resource moet worden toegevoegd aan het request.

NB. Indien een get-aorta-data request werd ontvangen dan wordt deze stap slechts uitgevoerd indien voor de betreffende GBx-applicatie een AORTA access_token werd ontvangen met een versie 4.* of hoger (get-aorta-data wordt pas ondersteund richting bronsystemen die zijn aangesloten o.b.v. AoF 2024 of hoger).

Ongeldige adressering

Er is bijvoorbeeld een probleem met het FQDN dat is opgenomen in de audience van het AORTA access_token.

Het systeem voegt een OperationOutcome toe (issue.severity=”warning”, issue.code "processing") met daarin informatie over de reden.

statuscode 500 Internal Server Error

Het systeem gaat verder met de volgende interactie of GBx-applicatie.

Transformatie niet geslaagd

statuscode 500 Internal Server Error

Het systeem genereert de vereiste foutresponse en gaat verder met de volgende interactie of GBx-applicatie.

Interactie kon niet worden geïnitieerd

Er is bijvoorbeeld een probleem met de scope van het AORTA access_token, waardoor het systeem een interactie niet kan opbouwen.

Het systeem voegt een OperationOutcome toe (issue.severity=”warning”, issue.code "processing") met daarin informatie over de reden.

statuscode 500 Internal Server Error

Het systeem gaat verder met de volgende interactie of GBx-applicatie.

3

Voor elke ontvangen response worden de volgende stappen doorlopen:

• Het systeem toetst of de response géén attachment met daarin malafide inhoud bevat (zie FHIR security, attachments).

• Indien een response wordt ontvangen en een transformatie moet worden uitgevoerd, dan initieert het systeem de use case Transformeer content middels de Transformatie Interface. In de toelichting “Transformatie van FHIR results naar v3-responses” is omschreven hoe moet worden omgegaan met ontvangen HTTP statuscodes, headers en OperationOutcomes van een FHIR Resource Server.

• Indien (eventueel na transformatie) een FHIR searchset Bundle is verkregen dan voegt het systeem er een Provenance resource aan toe, zodat voor iedere opgeleverde resource instance in de Bundle duidelijk is, van welk bronsysteem deze werd verkregen.

Indien geen (tijdige) response wordt ontvangen, dan worden bovenstaand stappen niet doorlopen en genereert het systeem zelfstandig de vereiste foutresponse.

Malafide inhoud

Het systeem logt de gebeurtenis, negeert de betreffende response en gaat verder met de volgende interactie of GBx-applicatie.

Geen (tijdig) antwoord van GBx-applicatie

statuscode 504 Gateway Timeout

Transformatie niet geslaagd

statuscode 500 Internal Server Error

Het systeem genereert de vereiste foutresponse en gaat verder met de volgende interactie of GBx-applicatie.

4

Het systeem consolideert alle ontvangen responses, zoals omschreven in "Consolidatie van responses" of, wanneer één v3-response moet worden opgeleverd, in AORTA documentatie voor v3-uitwisseling.

5

Bij opleveren van een FHIR-result: het systeem overschrijft eventuele URL's in het opgeleverde resultaat

• Absolute en relatieve URL's in fullUrl's en references van entries in Bundles dienen te worden aangepast conform het volgende formaat: <base endpointadres Resource Broker XXX-in>/<appID>/<type>/<id>.

• Absolute en relatieve URL's in link elementen van het type “self”, “first”, “next”, “previous” en “last” van entries in Bundles dienen te worden aangepast conform het volgende formaat: <base endpointadres Resource Broker XXX-in>/<appID>/<type>/<id>.

• DocumentReference.content.attachment.url dient, zowel voor absolute URL’s als voor relatieve URL’s, te worden aangepast conform het volgende formaat: <base endpointadres Resource Broker XXX-in>/<appID>/<type>/<id>.

• URL in Location header dient te worden aangepast conform het volgende formaat: <base endpointadres Resource Broker XXX-in>/<appID>/<type>/<id>/_history/[vid]

  waarbij <appID> het applicatie-id (zonder root OID) bevat van het bronsysteem. Het in te vullen appID kan worden bepaald door het opgeleverde base endpointadres in de Bundle, te vergelijken met het FQDN van iedere GBZ-applicatie, die eerder in de flow werd betrokken bij de verwerking van het resource request.

De juiste Resource Broker XXX-in wordt bepaald o.b.v. de inhoud van de vrb_client_id claim in het AORTA access_token. De base URL die hierbij hoort wordt verkregen uit het AORTA Stelseltoken.

Vooralsnog geldt, dat wanneer het verzoek was ontvangen van Resource Broker MedMij-in, het systeem haar eigen base URL gebruikt bij het overschrijven. Resource Broker MedMij-in zal de base URL van Resource Broker VnC weer overschrijven met haar eigen base URL.

6

<exit>

Het systeem retourneert een response naar de primaire actor.

Zie de toelichting "Consolideren van de responses naar één FHIR-result".

Verwerking succesvol

statuscode 200 OK

• Wanneer een geldige FHIR zoekparameter wordt ontvangen die niet wordt ondersteund, dan wordt een OperationOutcome met issue.code "not supported" opgenomen in het resultaat. 

• Wanneer een ongeldige FHIR zoekparameter wordt ontvangen, dan wordt een OperationOutcome met issue.code "invalid" en de van toepassing zijnde issue.details geretourneerd opgenomen in het resultaat.

• Wanneer een FHIR zoekparameter een geldige waarde bevat die niet wordt ondersteund, dan wordt een OperationOutcome met issue.code "not supported" en de van toepassing zijnde issue.details geretourneerd.

• Wanneer een optionele FHIR zoekparameter een ongeldige waarde heeft, dan wordt een OperationOutcome met issue.code "value" en de van toepassing zijnde issue.details geretourneerd.

Voor bovenstaande criteria geldt dat ze:

• voor FHIR-interacties die worden vertaald van naar HL7v3: worden getoetst in de resource broker;

• voor FHIR-interacties die niet worden vertaald: worden getoetst in de resource server.

Toelichting: wanneer een geldige FHIR-search is uitgevoerd, maar deze niets oplevert, wordt een lege bundle (met Bundle.total = 0) opgenomen in het resultaat.

Wanneer een feitelijk, door Resource Server, geretourneerde statuscode moet worden toegevoegd aan een response, dan wordt dit gedaan in een OperationOutcome met:

• voor statuscode 2xx: issue.severity=information, issue.code=processing. en issue.diagnostics="<appID van resource server>:<statuscode van resource server>", OF

• anders: issue.severity=warning, issue.code=processing. en issue.diagnostics="<appID van resource server>:<statuscode van resource server>".

Verwerking succesvol - resource instance gecreëerd

statuscode 201 Created