Interfaces Resource Broker VnC

AOF.RB-I.VCI.050.v1

De waarde van de base-URL ( [base] ) van de FHIR endpoints die de Resource Broker VnC biedt , dient voor alle FHIR-interacties gelijk te zijn aan "https://<FQDN>{</path extension>}/fhir/<fhir-version>". De waarde van <fhir-version> is dan bijvoorbeeld "R4" of "R5".

Verzending & Consolidatie Interface

AOF.RB-I.VCI.060.v1

De Verzending & Consolidatie Interface ondersteunt de volgende versies van het AORTA access_token:

versie 1.1 (AoF 0.6)
versie 2.0 (AoF 0.7)
versie 3.0 (AoF 0.8)

Reguliere FHIR-interactie

Feature	Initiëren reguliere FHIR-interactie
Type	Abstracte Service
Versie	1.2.0
Groep	Broker
Gepubliceerd	08 Nov 2023
Delta	Opnemen OperationOutcomes (fatal en error) in messageLog en GBZ-log. Toevoeging geparameteriseerde $get-aorta-data en geparameteriseerde hybride generieke query.
Use case	AOF.UC.VNC.200.v1

Feature	Versie	Dependency	Aanbieder	Afnemer
Initiëren reguliere FHIR-interactie	1.2.0	core-FHIR-interactie-broker	*	*

AOF.RB-I.VCI.100.v2

De Verzending & Consolidatie Interface is voor reguliere FHIR-interacties (search, read, update, batch/transaction) nagenoeg gelijk aan de AORTA FHIR Resource Interface. 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 gelden voor alle interacties de volgende extra headers:

Conditionele request header: DigiD-Authenticatie: Bearer <authenticatietoken>

Een request die is gestuurd door een patiënt (via MedMij of een GBP) dient altijd een DigiD-Authenticatie header te bevatten.

Vooralsnog hoeven slechts JWT-based access_tokens, en SAML-based authenticatietokens te worden ondersteund.

Een token dat wordt meegezonden is in sommige gevallen een XML SAMLv2 Assertion, en in andere situaties een JSON Web Token (JWT). Een JWT bestaat uit een aantal base64 strings, die aan elkaar zijn gekoppeld met punten. Omdat een base64url geëncodeerde SAMLv2 Assertion geen punten kan bevatten, is de ontvanger altijd in staat om het type token bepalen.

Een SAML Assertion dient altijd base64url te worden gecodeerd conform RFC 4648.

HTTP statuscodes

HTTP statuscodes die kunnen worden geretourneerd zijn:

Extension Stap

Omschrijving

Uitkomst

i

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content of AORTA acceptVersion niet ondersteund

statuscode 406 Not Acceptable

Gehanteerd type content of AORTA contentVersion niet ondersteund

statuscode 415 Unsupported Media Type

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

Stap	Omschrijving	Uitkomst
1	Het systeem controleert de geldigheid van het AORTA access_token, zoals omschreven in de toelichting Controle en gebruik van het access_token.	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. In deze situatie mag daarnaast ook een OperationOutcome met issue.code "`security`" worden geretourneerd.
1		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
2	Het systeem toetst of het verzoek voldoet aan de interface specificatie.	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.
2		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
3	Afhankelijk van het type FHIR-interactie wordt nu de juiste generieke extension flow doorlopen, d.w.z. opleveren gegevens, ontvangen gegevens of opleveren ontvankelijkheidstatus.
4 <exit>	Het systeem retourneert een response naar de primaire actor.	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.
4 <exit>		Verwerking succesvol - resource instance gecreëerd statuscode 201 Created

get-aorta-data

Feature	Uitvoeren get-aorta-data
Type	Service
Versie	1.2.0
Groep	Broker
Gepubliceerd	08 Nov 2023
Delta	Opnemen OperationOutcomes (fatal en error) in messageLog en GBZ-log. Toevoeging geparameteriseerde $get-aorta-data en geparameteriseerde hybride generieke query.
Use case	AOF.UC.VNC.200.v1

Feature	Versie	Dependency	Aanbieder	Afnemer
Uitvoeren get-aorta-data	1.2.0	AORTA Stelseltoken	*	*
Uitvoeren get-aorta-data	1.2.0	AORTA-ID HTTP Header	*	*
Uitvoeren get-aorta-data	1.2.0	Authorization HTTP Header	*	*
Uitvoeren get-aorta-data	1.2.0	Formaat AORTA interactietabel	*	-
Uitvoeren get-aorta-data	1.2.0	AORTA access_token	3	-
Uitvoeren get-aorta-data	1.2.0	getMetadataZA	*	-

Via een get-aorta-data request kunnen gegevens worden opgehaald bij GBZ-applicaties die zijn aangesloten op het AORTA netwerk.

AOF.RB-I.ADI.100.v2

Het technische formaat van een protocol-agnostisch get-aorta-data request is:

POST [base endpointadres]/get-aorta-data/v1
Authorization: Bearer <AORTA access_token>
Content-Type: application/json; charset=utf-8AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>
{
"protocol": "",
"context": "",
"destination": "",
"effective-time": ["",""],
"therapy-identifier": "",
"classifier": "",
"instance-identifier": ""
}

Bij het verzenden van een protocol-agnostisch get-aorta-data request dienen de volgende HTTP headers te worden meegezonden:

Feature	Authorization HTTP Header
Type	Subfeature
Versie	1.0.0
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
Delta	Initiële versie van feature.

Authorization: Bearer <AORTA access_token>

Een AORTA access_token is altijd een JSON Web Token (JWT).

Een JWT bestaat uit een aantal base64 strings, die aan elkaar zijn gekoppeld met punten. Indien een token een SAML Assertion zou zijn, dan dient het altijd base64url te worden gecodeerd conform RFC 4648. Omdat een base64url geëncodeerde SAMLv2 Assertion geen punten kan bevatten, is de ontvanger altijd in staat om het type token bepalen.

In het token, dat wordt ontvangen in een Authorization header, is informatie opgenomen over welke type inhoudelijk token het betreft en welke versie, dus bijvoorbeeld dat het gaat om een AORTA access_token.

Content-Type: application/json; charset=utf-8

Feature	AORTA-ID HTTP Header
Type	Subfeature
Versie	1.0.0
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
Delta	Initiële versie van feature.

AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>

Het initialRequestID attribuut bevat het ID van het allereerste request in de hele keten en dient te worden opgenomen in de logbestanden van alle partijen in de keten, zodat bij foutopsporing de verschillende logbestanden aan elkaar kunnen worden gerelateerd.

Het requestID is voor iedere request message uniek. In requests wordt deze gegenereerd door de client. Ook het requestID dient te worden opgenomen in de verschillende logbestanden, zodat altijd duidelijk is op welk bericht een log entry van toepassing is.

Input parameters:

Name	Conformance	Type	Toelichting
protocol	Verplicht	String	Het gevraagde protocol in de response. Mogelijke waarden: application/fhir+xml application/fhir+json application/hl7-v3+xml
context	Verplicht	String	AORTA contextcode waarbinnen de operation wordt uitgevoerd. Bijvoorbeeld: "context” : ”BGZ"
destination	Optioneel	String	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	String array	De periode waarop een geregistreerd gegeven betrekking heeft (bijv. medisch of logistiek relevant is). Bijvoorbeeld: “effective-time” : [”ge2010-01-01 , ”le2011-12-31”]
therapy-identifier	Optioneel	String	Een business identifier van een specifieke behandeling. Bijvoorbeeld: “therapy-identifier” : ”http://example.nl/fhir/NamingSystem/pharmaceuticaltreatment\|24834781“
classifier	Optioneel	String	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	String	Een business identifier van een specifieke bouwsteen instantie. Bijvoorbeeld: “instance-identifier” : ”http://example.nl/fhir/NamingSystem/MedicationRequest\|999922448“

AOF.RB-I.ADI.200.v1

Het technische formaat van een get-aorta-data response is:

200 OK
Content-Type: application/json; charset=utf-8

{
"format": "",
"result": ""
}

Bij het verzenden van een protocol-agnostische get-aorta-data response dienen de volgende HTTP headers te worden meegezonden:

Content-Type: application/json; charset=utf-8

Output parameters:

Name

Cardinality

Type

Toelichting

format

1..1

Lege string of een string met waarde escape of base64.

Gehanteerde encodering voor result.

result

0..1

String waarop de benodigde escaping is toegepast, of die base64 geëncodeerde data bevat.

Wanneer om een FHIR-result wordt gevraagd, dan zal result een FHIR Bundle bevatte van het type = searchset.

Wanneer om een v3-response wordt gevraagd, dan zal result een batchAntwoord (MCCI_IN200101) bevatten, met daarin het resultaat van een verzameling bouwsteenspecifieke queries. Elke bouwsteenspecifieke query antwoord is dan als volledige interactie onder de batchwrapper opgenomen.

HTTP statuscodes

HTTP statuscodes die kunnen worden geretourneerd zijn:

Extension Stap

Omschrijving

Uitkomst

i

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content of AORTA acceptVersion niet ondersteund

statuscode 406 Not Acceptable

Gehanteerd type content of AORTA contentVersion niet ondersteund

statuscode 415 Unsupported Media Type

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

Extension 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.
i		Het systeem genereert de vereiste foutresponse 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".	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. In deze situatie mag daarnaast ook een OperationOutcome met issue.code "`security`" worden geretourneerd.
ii		Het systeem genereert de vereiste foutresponse 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".	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. In deze situatie mag daarnaast ook een OperationOutcome met issue.code "`security`" worden geretourneerd.
iii		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

Stap	Omschrijving	Uitkomst
2	Bij ontvangst van get-aorta-data request: 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 foutresponse 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.
3	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 (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 Het systeem voegt een OperationOutcome toe (issue.severity=”warning”, issue.code "processing") met daarin informatie over de reden en gaat verder met de volgende interactie of GBx-applicatie. In geval van foutieve informatie in het request of token wordt geretourneerd: statuscode 400 Bad Request In geval van een interne fout in het systeem wordt geretourneerd: statuscode 500 Internal Server Error
		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 Het systeem voegt een OperationOutcome toe (issue.severity=”warning”, issue.code "processing") met daarin informatie over de reden en gaat verder met de volgende interactie of GBx-applicatie. In geval van foutieve informatie in het request of token wordt geretourneerd: statuscode 400 Bad Request In geval van een interne fout in het systeem wordt geretourneerd: statuscode 500 Internal Server Error
4	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 in een protocol dat afwijkt van het, door de primaire actor, gevraagde protocol, 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.	Malafide inhoud Het systeem logt de gebeurtenis, negeert de betreffende response en 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.
5	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.
6	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 “first”, “next”, “previous” en “last”) dienen te worden aangepast conform het volgende formaat: `<base endpointadres Resource Broker XXX-in>/<appID>/<type>/<id>` of `<base endpointadres Resource Broker XXX-in>/role/<roleID>/<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>` of `<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>/<appID>/<type>/<id>/_history/[vid]` of `<base endpointadres Resource Broker XXX-in>//role/<roleID>/<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. Indien het resultaat is opgeleverd door een VZVZ component (bijv. RB VWI), dan wordt het roleID van de betreffende component ingevoegd, en dus niet een appID. 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.
7 <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

Extension Stap

Omschrijving

Uitkomst

i

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content of AORTA acceptVersion niet ondersteund

statuscode 406 Not Acceptable

Gehanteerd type content of AORTA contentVersion niet ondersteund

statuscode 415 Unsupported Media Type

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

Stap	Omschrijving	Uitkomst
1	Het systeem controleert de geldigheid van het AORTA access_token, zoals omschreven in de toelichting Controle en gebruik van het access_token.	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. In deze situatie mag daarnaast ook een OperationOutcome met issue.code "`security`" worden geretourneerd.
1		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
2	Het systeem toetst of het verzoek voldoet aan de interface specificatie.	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.
2		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
3	Afhankelijk van het type FHIR-interactie wordt nu de juiste generieke extension flow doorlopen, d.w.z. opleveren gegevens, ontvangen gegevens of opleveren ontvankelijkheidstatus.
4 <exit>	Het systeem retourneert een response naar de primaire actor.	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.
4 <exit>		Verwerking succesvol - resource instance gecreëerd statuscode 201 Created

push-aorta-data

Feature	Uitvoeren push-aorta-data
Type	Service
Versie	1.0.0
Groep	Broker
Gepubliceerd	19 Oct 2023
Delta	Initiële versie van feature.
Use case	AOF.UC.VNC.200.v1

Feature	Versie	Dependency	Aanbieder	Afnemer
Uitvoeren push-aorta-data	1.0.0	AORTA Stelseltoken	*	*
Uitvoeren push-aorta-data	1.0.0	AORTA-ID HTTP Header	*	*
Uitvoeren push-aorta-data	1.0.0	Authorization HTTP Header	*	*
Uitvoeren push-aorta-data	1.0.0	Formaat AORTA interactietabel	*	-
Uitvoeren push-aorta-data	1.0.0	AORTA access_token	3	-

Via een push-aorta-data request kunnen gegevens worden verzonden naar GBZ-applicaties die zijn aangesloten op het AORTA netwerk.

AOF.RB-I.ADI.300.v1

Het technische formaat van een protocol-agnostisch push-aorta-data request is:

POST [base endpointadres]/push-aorta-data/v1
Authorization: Bearer <AORTA access_token>
Content-Type: application/json; charset=utf-8AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>

{
"protocol":"",
"context":""
"destination":"",
"format": "",
"data": ""
}

Bij het verzenden van een protocol-agnostisch push-aorta-data request dienen de volgende HTTP headers te worden meegezonden:

Feature	Authorization HTTP Header
Type	Subfeature
Versie	1.0.0
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
Delta	Initiële versie van feature.

Authorization: Bearer <AORTA access_token>

Een AORTA access_token is altijd een JSON Web Token (JWT).

Een JWT bestaat uit een aantal base64 strings, die aan elkaar zijn gekoppeld met punten. Indien een token een SAML Assertion zou zijn, dan dient het altijd base64url te worden gecodeerd conform RFC 4648. Omdat een base64url geëncodeerde SAMLv2 Assertion geen punten kan bevatten, is de ontvanger altijd in staat om het type token bepalen.

In het token, dat wordt ontvangen in een Authorization header, is informatie opgenomen over welke type inhoudelijk token het betreft en welke versie, dus bijvoorbeeld dat het gaat om een AORTA access_token.

Content-Type: application/json; charset=utf-8

Feature	AORTA-ID HTTP Header
Type	Subfeature
Versie	1.0.0
Groep	HTTP Headers
Gepubliceerd	19 Oct 2023
Delta	Initiële versie van feature.

AORTA-ID: initialRequestID=<UUID conform RFC4122>; requestID=<UUID conform RFC4122>

Het initialRequestID attribuut bevat het ID van het allereerste request in de hele keten en dient te worden opgenomen in de logbestanden van alle partijen in de keten, zodat bij foutopsporing de verschillende logbestanden aan elkaar kunnen worden gerelateerd.

Het requestID is voor iedere request message uniek. In requests wordt deze gegenereerd door de client. Ook het requestID dient te worden opgenomen in de verschillende logbestanden, zodat altijd duidelijk is op welk bericht een log entry van toepassing is.

Input parameters:

Name	Cardinality	Type	Toelichting
protocol	1..1	String	Het gehanteerde protocol. Mogelijke waarden: application/fhir+xml application/fhir+json application/hl7-v3+xml
context	1..1	String	Code van de context waarbinnen de operation wordt uitgevoerd. Bijvoorbeeld: "context” : ”BGZ"
destination	1..1	String	URA van de zorgaanbieder, of het applicatieID van de Resource Server (GBZ-applicatie) waarnaar de gegevens verzonden moeten worden. Formaat: "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>" NB. vooralsnog dient destination gevuld te zijn met een applicatieID.
format	1..1	Lege string of een string met waarde escape of base64.	Gehanteerde encodering voor `data`.
data	1..1	String waarop de benodigde escaping is toegepast, of die base64 geëncodeerde data bevat.	De inhoud van de push interactie (v3-request of FHIR-request).

AOF.RB-I.ADI.400.v1

Het technische formaat van een push-aorta-data response is:

<HTTP statuscode returned by destination>
Content-Type: application/json; charset=utf-8
<any other HTTP headers returned by destination>

{
"format": "",
"result": ""
}

Bij het verzenden van een protocol-agnostische push-aorta-data response dienen de volgende HTTP headers te worden meegezonden:

Content-Type: application/json; charset=utf-8

Output parameters:

Name	Cardinality	Type	Toelichting
format	1..1	Lege string of een string met waarde escape of base64.	Gehanteerde encodering voor `result`.
result	0..1	String waarop de benodigde escaping is toegepast, of die base64 geëncodeerde data bevat.	Afhankelijk van de waarde van protocol in het push-aorta-data request betreft het een v3-response of een FHIR-response.

HTTP statuscodes

HTTP statuscodes die kunnen worden geretourneerd zijn:

Extension Stap

Omschrijving

Uitkomst

i

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content of AORTA acceptVersion niet ondersteund

statuscode 406 Not Acceptable

Gehanteerd type content of AORTA contentVersion niet ondersteund

statuscode 415 Unsupported Media Type

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

Extension 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.
i		Het systeem genereert de vereiste foutresponse 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".	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. In deze situatie mag daarnaast ook een OperationOutcome met issue.code "`security`" worden geretourneerd.
ii		Het systeem genereert de vereiste foutresponse 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".	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. In deze situatie mag daarnaast ook een OperationOutcome met issue.code "`security`" worden geretourneerd.
iii		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

Stap	Omschrijving	Uitkomst
2	Bij ontvangst van get-aorta-data request: 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 foutresponse 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.
3	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 (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 Het systeem voegt een OperationOutcome toe (issue.severity=”warning”, issue.code "processing") met daarin informatie over de reden en gaat verder met de volgende interactie of GBx-applicatie. In geval van foutieve informatie in het request of token wordt geretourneerd: statuscode 400 Bad Request In geval van een interne fout in het systeem wordt geretourneerd: statuscode 500 Internal Server Error
		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 Het systeem voegt een OperationOutcome toe (issue.severity=”warning”, issue.code "processing") met daarin informatie over de reden en gaat verder met de volgende interactie of GBx-applicatie. In geval van foutieve informatie in het request of token wordt geretourneerd: statuscode 400 Bad Request In geval van een interne fout in het systeem wordt geretourneerd: statuscode 500 Internal Server Error
4	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 in een protocol dat afwijkt van het, door de primaire actor, gevraagde protocol, 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.	Malafide inhoud Het systeem logt de gebeurtenis, negeert de betreffende response en 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.
5	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.
6	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 “first”, “next”, “previous” en “last”) dienen te worden aangepast conform het volgende formaat: `<base endpointadres Resource Broker XXX-in>/<appID>/<type>/<id>` of `<base endpointadres Resource Broker XXX-in>/role/<roleID>/<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>` of `<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>/<appID>/<type>/<id>/_history/[vid]` of `<base endpointadres Resource Broker XXX-in>//role/<roleID>/<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. Indien het resultaat is opgeleverd door een VZVZ component (bijv. RB VWI), dan wordt het roleID van de betreffende component ingevoegd, en dus niet een appID. 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.
7 <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

Extension Stap

Omschrijving

Uitkomst

i

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content of AORTA acceptVersion niet ondersteund

statuscode 406 Not Acceptable

Gehanteerd type content of AORTA contentVersion niet ondersteund

statuscode 415 Unsupported Media Type

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

Stap	Omschrijving	Uitkomst
1	Het systeem controleert de geldigheid van het AORTA access_token, zoals omschreven in de toelichting Controle en gebruik van het access_token.	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. In deze situatie mag daarnaast ook een OperationOutcome met issue.code "`security`" worden geretourneerd.
1		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
2	Het systeem toetst of het verzoek voldoet aan de interface specificatie.	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.
2		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
3	Afhankelijk van het type FHIR-interactie wordt nu de juiste generieke extension flow doorlopen, d.w.z. opleveren gegevens, ontvangen gegevens of opleveren ontvankelijkheidstatus.
4 <exit>	Het systeem retourneert een response naar de primaire actor.	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.
4 <exit>		Verwerking succesvol - resource instance gecreëerd statuscode 201 Created