Interfaces Resource Broker ZA-in

AORTA FHIR Resource Broker Interface

De AORTA FHIR Resource Broker Interface ondersteunt de volgende versies van het AORTA access_token:

versie 2.0 (AoF 0.7)
versie 3.*
versie 4.*

Reguliere FHIR-interacties

Feature	core-FHIR-interactie-broker
Type	Abstracte Service
Versie	1.3.0
Groep	Broker
Gepubliceerd
Delta	Ondersteuning Mitz toestemmingsregistratie door zorgverlener: Kunnen doorzetten van FHIR-interactie naar Mitz toestemmingsregister Ook ondersteunen AoF 0.7 interface, en van oude formaat interactie-id’s. Gereed. Versie verhoogd van 1.2.6 naar 1.3.0. UC versie verhoogd van v6 naar v7.
Use case	AOF.UC.ZAIN.100.v7

Feature	Versie	Dependency	Aanbieder	Afnemer
core-FHIR-interactie-broker	1.3.0	AORTA Stelseltoken	>=*	>=*
core-FHIR-interactie-broker	1.3.0	AORTA-ID HTTP Header	>=1.0.0	>=1.0.0
core-FHIR-interactie-broker	1.3.0	AORTA-Version HTTP Header	>=1.0.0	>=1.0.0
core-FHIR-interactie-broker	1.3.0	Authorization HTTP Header	>=1.0.0	>=1.0.0
core-FHIR-interactie-broker	1.3.0	Formaat AORTA interactietabel	>=*	-
core-FHIR-interactie-broker	1.3.0	AORTA access_token	>=*	-
core-FHIR-interactie-broker	1.3.0	getMetadataZA	>=1.0.0	-

De AORTA FHIR Resource Broker Interface is, voor reguliere FHIR-interacties (search, read, update, batch/transaction) nagenoeg gelijk aan de AORTA FHIR Resource Interface, inclusief de gehanteerde HTTP-headers. Dit geldt zowel voor het generieke deel van de interface als voor de AORTA FHIR * interacties. In deze sectie worden daarom slechts de afwijkingen hierop beschreven.

M.b.t. de HTTP-headers die worden gebruikt geldt voor alle interacties de volgende uitzonderingen:

De AORTA-Version header is optioneel en mag worden weggelaten

De waarde van de base-URL van de FHIR endpoints die de Resource Broker biedt t.b.v. de AORTA FHIR Resource Broker Interface ( [base] dus ), dient voor alle FHIR-interacties gelijk te zijn aan:

https://<FQDN>{</path extension>}/fhir/<fhir-version>/<aorta-interface-version>{/<app-id>}

De waarde van <fhir-version> is dan bijvoorbeeld "STU3", "R4" of "R5".

De waarde van <aorta-interface-version> is de major versie van de AORTA FHIR Resource Broker Interface, bijvoorbeeld “v1”. Deze is gelijk aan de major versie van het Feature.

Voor instance-level interacties (bijvoorbeeld een FHIR-read of een FHIR-update) dient het <app-id> van de GBZ-applicatie die fungeert als Resource Server te worden toegevoegd aan de base-URL. Voor FHIR-search interacties mag een <app-id> ook worden toegevoegd, maar is het niet verplicht. Een <app-id> die wordt gebruikt in de base-URL dient overeen te komen met het app-id dat is opgenomen in de audience van het gebruikte AORTA access_token.

Let op: operation $is-allowed maakt geen deel uit van deze interface.

Totdat AoF 0.7 wordt uitgefaseerd, biedt Resource Broker ZA-in tijdelijk ook nog de interface, zoals beschreven in de AoF 0.7 specificaties.

HTTP statuscodes

HTTP statuscodes die kunnen worden geretourneerd zijn opgenomen in onderstaande tabel.

Omdat bepaalde Confluence macro’s nog niet worden ondersteund in de publicatie omgeving, bevat de tabel, in de publicatieomgeving, ook informatie over de wijze waarop de betreffende interface wordt geïmplementeerd in de server component. De statuscodes die kunnen worden geretourneerd zijn opgenomen in de kolom “Uitkomst”. De overige informatie mag worden genegeerd.

AOF.UCe.VAL.100.v1 - Toetsing type content		Uitkomst
Stap	Omschrijving	Uitkomst
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.

AOF.UCe.VAL.200.v1 - Toetsing tokens bij inkomend request		Uitkomst
Stap	Omschrijving	Uitkomst
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.
i		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.
ii		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

AOF.UCe.VAL.150.v2 - Inhoudelijke toetsing request		Uitkomst
Stap	Omschrijving	Uitkomst
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.
i		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.
ii		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.
iii		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

AOF.UCe.VAL.300.v1 - Toetsing scope van request

Uitkomst

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.

Stap

Omschrijving

Uitkomst

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.

AOF.UCe.SCR.100.v1 - Screening van response		Uitkomst
Stap	Omschrijving	Uitkomst
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>`".
i		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".

Stap

Omschrijving

Uitkomst

4

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

AOF.UCe.VAL.100.v1 - Toetsing type content		Uitkomst
Stap	Omschrijving	Uitkomst
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.

AOF.UCe.VAL.250.v1 - Toetsing van een intern RB-request		Uitkomst
Stap	Omschrijving	Uitkomst
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.
i		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.
ii		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.
iii		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

Stap	Omschrijving	Uitkomst
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 een AORTA Token Request), 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". 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	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 de toelichting "Consolideren van de responses naar één FHIR-result" 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 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>/<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.
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. 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

$get-aorta-data FHIR-operation

Feature	$get-aorta-data
Type	Service
Versie	1.2.4
Groep	Broker
Gepubliceerd	21 Jun 2024
Delta	Loggen jti van ontvangen AORTA access_token in componentlog.
Use case	AOF.UC.ZAIN.100.v7

Feature	Versie	Dependency	Aanbieder	Afnemer
$get-aorta-data	1.2.4	core-FHIR-interactie-broker	>=1.*	>=1.2.0

De resource client initieert een custom FHIR operation bij de resource broker en gebruikt hiervoor de HTTP GET Method op de volgende wijze:

GET [base]$get-aorta-data?[context]{&[destination]}{&[effective-time]}{&[therapy-identifier]}{&[classifier]}{&[instance-identifier]}

In Parameters:
Name	Conformance	Type	Toelichting
context	Verplicht	code	AORTA contextcode waarbinnen de operation wordt uitgevoerd. Bijvoorbeeld: "context=BGZ"
destination	Optioneel	token	URA van de zorgaanbieder die bevraagd moet worden, of het applicatieID van de Resource Server (GBZ-applicatie) die bevraagd moet worden. Wanneer de destination afwezig is, dan worden alle Resource Server waarvoor toestemming is geregistreerd bevraagd. Formaat: "destination=http://fhir.nl/fhir/NamingSystem/aorta-app-id\|<app-id>” "destination=http://fhir.nl/fhir/NamingSystem/ura\|<URA>” "destination=urn:oid:2.16.528.1.1007.3.3.<URA>" "destination=urn:oid:2.16.840.1.113883.2.4.6.6.<applicatie-id>"
effective-time	Optioneel	date	De periode waarop een geregistreerd gegeven betrekking heeft (bijv. medisch of logistiek relevant is). Bijvoorbeeld: “effective-time=ge2010-01-01&effective-time=le2011-12-31”
therapy-identifier	Optioneel	token	Een business identifier van een specifieke behandeling. Bijvoorbeeld: “therapy-identifier=<namingsystem>\|24834781“
classifier	Optioneel	token	Typering van bijv. het soort medicatie, observaties, diagnoses of problemen. Bijvoorbeeld: “classifier=urn:oid:2.16.840.1.113883.2.4.4.8\|13610554“
instance-identifier	Optioneel	token	Een business identifier van een specifieke bouwsteen instantie. Bijvoorbeeld: “instance-identifier=<namingsystem>\|999922448“
Out Parameters:
Name	Cardinality	Type	Toelichting
return	0..1	Bundle	Bundle.type = searchset. Note: as this is the only out parameter, it is a resource, and it has the name 'return', the result of this operation is returned directly as a resource.

HTTP statuscodes

HTTP statuscodes die kunnen worden geretourneerd zijn opgenomen in onderstaande tabel.

Omdat bepaalde Confluence macro’s nog niet worden ondersteund in de publicatie omgeving, bevat de tabel, in de publicatieomgeving, ook informatie over de wijze waarop de betreffende interface wordt geïmplementeerd in de server component. De statuscodes die kunnen worden geretourneerd zijn opgenomen in de kolom “Uitkomst”. De overige informatie mag worden genegeerd.

AOF.UCe.VAL.100.v1 - Toetsing type content		Uitkomst
Stap	Omschrijving	Uitkomst
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.

AOF.UCe.VAL.200.v1 - Toetsing tokens bij inkomend request		Uitkomst
Stap	Omschrijving	Uitkomst
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.
i		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.
ii		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

AOF.UCe.VAL.150.v2 - Inhoudelijke toetsing request		Uitkomst
Stap	Omschrijving	Uitkomst
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.
i		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.
ii		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.
iii		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

AOF.UCe.VAL.300.v1 - Toetsing scope van request

Uitkomst

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.

Stap

Omschrijving

Uitkomst

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.

AOF.UCe.SCR.100.v1 - Screening van response		Uitkomst
Stap	Omschrijving	Uitkomst
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>`".
i		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".

Stap

Omschrijving

Uitkomst

4

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

AOF.UCe.VAL.100.v1 - Toetsing type content		Uitkomst
Stap	Omschrijving	Uitkomst
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.

AOF.UCe.VAL.250.v1 - Toetsing van een intern RB-request		Uitkomst
Stap	Omschrijving	Uitkomst
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.
i		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.
ii		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.
iii		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.

Stap	Omschrijving	Uitkomst
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 een AORTA Token Request), 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". 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	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 de toelichting "Consolideren van de responses naar één FHIR-result" 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 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>/<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.
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. 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