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.

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.

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.

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.

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.

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.