Use Cases Resource Broker ZA-in

Resource Client (GBZ-applicatie, Volgjezorg, GBK-applicatie)

ZA FHIR Processor

Autorisatie Server ZA, RB LOG, RB VnC, ACT/VWI Server, Mitz TR

AOF.UC.ZAIN.100.v7

core-FHIR-interactie-broker, $get-aorta-data

De primaire actor is aangesloten op het systeem.

Het systeem is slechts benaderbaar voor

• GBx-applicaties die zijn aangesloten op het AORTA netwerk

Het systeem is aangesloten op de secundaire actor(en).

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

Gehanteerd type content niet ondersteund

statuscode 415 Unsupported Media Type

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

• MedMij access_token, zoals omschreven in de toelichting de sectie "Toetsing MedMij access_token".

• DigiD Authenticatietoken, géén toetsing vereist door Resource Broker.

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

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.

Stap

Omschrijving

i

Het systeem toetst of het request geen malafide inhoud bevat  (zie FHIR security, input validation).

Ongeldig FHIR-verzoek

statuscode 400 Bad Request

• Wanneer een verplichte FHIR zoekparameter ontbreekt, dan wordt een OperationOutcome met issue.code "required" en de van toepassing zijnde issue.details geretourneerd.

• Wanneer een verplichte FHIR zoekparameter een ongeldige waarde heeft, d.w.z. een waarde die niet is gespecificeerd binnen de gegevensdienst, dan wordt een OperationOutcome met issue.code "value" en de van toepassing zijnde issue.details geretourneerd;

• Wanneer een ontvangen FHIR resource instance ongeldig is, dan wordt een OperationOutcome met issue.code "invalid" en de van toepassing zijnde issue.details geretourneerd.

• In deze situatie wordt, indien van toepassing, conform RFC 6750, ook een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_request" 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 bepaalt, m.b.v. de interactietabel en m.b.v. de _vrb_ter_scope claim in het AORTA access_token, welk interactie-id van toepassing is op het ontvangen request. Zie ook de toelichting "Bepalen van het interactie-id".

Ongeldig FHIR-verzoek

statuscode 400 Bad Request

• Wanneer een verplichte FHIR zoekparameter ontbreekt, dan wordt een OperationOutcome met issue.code "required" en de van toepassing zijnde issue.details geretourneerd.

• Wanneer een verplichte FHIR zoekparameter een ongeldige waarde heeft, d.w.z. een waarde die niet is gespecificeerd binnen de gegevensdienst, dan wordt een OperationOutcome met issue.code "value" en de van toepassing zijnde issue.details geretourneerd;

• Wanneer een ontvangen FHIR resource instance ongeldig is, dan wordt een OperationOutcome met issue.code "invalid" en de van toepassing zijnde issue.details geretourneerd.

• In deze situatie wordt, indien van toepassing, conform RFC 6750, ook een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_request" 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.

iii

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

Hierbij moet ook worden voldaan aan de toelichting "Controle van batch en transaction requests".

FHIR-requests dienen te worden getoetst tegen de core FHIR specificaties (RESTful API).

Indien een If-None-Exists HTTP header van toepassing is op de interactie, dan dient deze te worden behandeld als een reguliere zoekparameter.

Indien een specifieke FHIR-profiel van toepassing is voor het gevonden interactie-id, dan dient het FHIR-request hier ook tegen te worden getoetst. NB. toetsing tegen een volledig FHIR-profiel wordt nog niet gedaan - consequenties van deze toets worden eerst in kaart gebracht.

Ongeldig FHIR-verzoek

statuscode 400 Bad Request

• Wanneer een verplichte FHIR zoekparameter ontbreekt, dan wordt een OperationOutcome met issue.code "required" en de van toepassing zijnde issue.details geretourneerd.

• Wanneer een verplichte FHIR zoekparameter een ongeldige waarde heeft, d.w.z. een waarde die niet is gespecificeerd binnen de gegevensdienst, dan wordt een OperationOutcome met issue.code "value" en de van toepassing zijnde issue.details geretourneerd;

• Wanneer een ontvangen FHIR resource instance ongeldig is, dan wordt een OperationOutcome met issue.code "invalid" en de van toepassing zijnde issue.details geretourneerd.

• In deze situatie wordt, indien van toepassing, conform RFC 6750, ook een WWW-Authenticate HTTP response header met als auth-scheme "Bearer" en een error attribuut met waarde "invalid_request" 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.

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

Scope is niet toereikend

statuscode 403 Forbidden

• 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 "insufficient_scope" 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 "forbidden" of "security" worden geretourneerd.

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

1

Het systeem 

• interactie gericht aan GBZ: initieert de use case Verzenden & Consolideren benodigde interacties middels de Verzending & Consolidatie Interface. Het kan hierbij gaan om

  1. een get-aorta-data operatie (het ontvangen resource request is een $get-aorta-data FHIR operation)

  2. een push-aorta-data operatie (de ontvangen interactie wordt in de AORTA interactietabel gekenmerkt als een “push” interactie)

  3. een reguliere FHIR-interactie, bijvoorbeeld een FHIR-search of een FHIR-read (overige situaties)

• interactie gericht aan een VZVZ component anders dan Resource Broker VnC: stuurt de ontvangen interactie door aan de geadresseerde component, e.e.a. inclusief de vereiste HTTP headers

  1. List of $delete-dossier, bestemd voor ACT/VWI Server: conform de Actualiteitsregister Interface.

  2. AuditEvent, bestemd voor RB LOG: conform de RB Logging Interface.

  3. Subscription, bestemd voor het Abonnementenregister: conform de Abonnement Interface.

• interactie gericht aan Mitz TR: stuurt de ontvangen interactie door aan de geadresseerde component, e.e.a. inclusief de vereiste HTTP headers.

2

FHIR-result ontvangen van een VZVZ-component anders dan Resource Broker VnC, of ontvangen van een externe component/dienst (bijv. van Mitz): het systeem overschrijft eventuele URL's in het opgeleverde resultaat

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

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

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.

3

Het systeem ontvangt een response.

Stap

Omschrijving

i

Het systeem toetst of eventueel aanwezige patiënt BSN's uit het opgeleverde resultaat overeenkomen met het BSN dat is opgenomen in de patient claim van het gehanteerde AORTA access_token. Het al dan niet aanwezig zijn van voorloopnullen moet hierbij worden genegeerd.

BSN in resultaat komt niet overeen met access_token

statuscode 500 Internal Server Error

• In deze situatie wordt, voor iedere resource server die een fout produceerde, een OperationOutcome toegevoegd met issue.severity "warning", issue.code "processing" en issue.diagnostics "<appID van betreffende resource server>".

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

ii

Indien de response moet worden geretourneerd aan MedMij, dan verwijderd het systeem alle aanwezige BSN's uit de op te leveren response.

iii

Het systeem voert de filtering uit zoals beschreven in de toelichting "Filtering HTTP-response".

4

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

Het systeem heeft het verzoek op de juiste wijze verwerkt en heeft een daarbij passende response geretourneerd.

Het systeem heeft ontvangen request en de geretourneerde response gelogd, zoals beschreven in de Toelichting Logging.

Het systeem heeft van het ontvangen request, de volgende attributen gelogd:

• datum en tijd van ontvangst

• request-id

• initial-request-id

• sender-id

  • role-id wanneer de sender van het request een VZVZ component is, en de aanroep niet via TLS geschiedt

  • common name wanneer de aanroep via TLS geschiedt

==

Het systeem heeft voor ieder uitgaand request, dat bij het doorlopen van de use case werd verzonden, de volgende attributen gelogd:

• datum en tijd van verzending

• request-id

• initial-request-id

• receiver-id

  • role-id wanneer de receiver van het request een VZVZ component is, en de aanroep niet via HTTP geschiedt

  • FQDN wanneer de aanroep via HTTP geschiedt

Aanvullend daarop heeft het systeem van het ontvangen request de volgende attributen gelogd:

• jti van het ontvangen AORTA access_token

Het systeem heeft van de geretourneerde response, de volgende attributen gelogd:

• datum en tijd van response

• request-id van het bijbehorende request

• initial-request-id van het bijbehorende request

• receiver-id

  • role-id wanneer de receiver van de response een VZVZ component is, en de aanroep niet via TLS geschiedt

  • common name wanneer de aanroep via TLS geschiedt

• HTTP statuscode en eventueel geretourneerde foutinformatie

==

Het systeem heeft voor iedere response, die bij het doorlopen van de use case werd ontvangen, de volgende attributen gelogd:

• datum en tijd van response

• request-id van het bijbehorende request

• initial-request-id van het bijbehorende request

• sender-id

  • role-id wanneer de sender van de response een VZVZ component is, en de aanroep niet via TLS geschiedt

  • common name wanneer de aanroep via TLS geschiedt

• HTTP statuscode en eventueel geretourneerde foutinformatie