Interfaces Resource Client

Algemeen

Base endpoint en FHIR-versions

De waarde van de base-URL van de FHIR endpoints die een Resource Client biedt t.b.v. ontvangst van notificaties ( [base] dus ), dient voor alle FHIR-interacties gelijk te zijn aan "https://<FQDN>/fhir/<fhir-version>". De waarde van <fhir-version> is dan bijvoorbeeld "R4" of "R5".

HTTP-request headers

Bij iedere interactie, worden in ieder HTTP-request, de volgende HTTP headers meegezonden:

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.

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

AORTA-Version: contentVersion=<versienummer>; acceptVersion=<versienummer>

Wanneer een Resource Server een FHIR interactie ontvangt, dan kan het a.d.h.v. de syntax van het ontvangen request afleiden om welke interactie het gaat, bijvoorbeeld "een FHIR-search naar Obervations", of "een FHIR-read van een Binary". Daarnaast is iedere interactie voorzien van een versienummer. Voor versienummering wordt gebruik gemaakt van semantic versioning.

De acceptVersion geeft aan conform welke versie(s) de interactie mag worden verwerkt en beantwoord. Het versienummer in de acceptVersion wordt gespecificeerd conform semver, dus bijvoorbeeld "2.x" of "~1.2.3 || ^2.1.0". In het algemeen geldt dat een resource server een interactie dient te verwerken conform de hoogst aangegeven acceptVersion die het zelf op dat moment kan toepassen.

De contentVersion geeft aan welke versie van de interactie daadwerkelijk is gehanteerd. In de contentVersion dient het versienummer de exacte versie van de interactie te bevatten die is gehanteerd, dus zonder wildcards of ranges, bijvoorbeeld “1”, of "2.2". De versie van een FHIR-interactie is opgenomen in het interactie-id.

HTTP-response headers

Bij iedere interactie, worden in iedere HTTP-response, de volgende HTTP headers meegezonden:

geen specifieke eisen.

Abonnement Notificatie Interface

T.b.v. de Abonnement Notificatie Interface worden de volgende FHIR-versions ondersteund:

R4

FHIR-profielen

Feature	aorta-subscriptionNotification-bundle
Type	Subfeature
Versie	1.0.0
Groep	FHIR-profielen
Gepubliceerd	19 Oct 2023
Delta	Initiële versie van feature.

Voorbeelden:

Interacties

Notificatie

Feature	subscriptionNotification
Type	Service
Versie	1.0.0
Groep	Notificatie
Gepubliceerd	22 Dec 2023
Delta	AORTA-Version HTTP header verwijderd uit response op de notificatie.
Use case	AOF.UC.ABR.500.v1

Feature	Versie	Dependency	Aanbieder	Afnemer
subscriptionNotification	1.0.0	aorta-subscriptionNotification-bundle	1.0	1.0
subscriptionNotification	1.0.0	AORTA-ID HTTP Header	*	*
subscriptionNotification	1.0.0	AORTA-Version HTTP Header	*	*

Een notificatie betreft een POST van een Bundle van het type “subscription-notification” op het base endpoint.

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.

Stap

Omschrijving

Uitkomst

1

Het systeem ontvangt een notificatie

2

Het systeem verwerkt de notificatie.

Ongeldig verzoek

statuscode 400 Bad Request

3

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

Functionele datamodel van een Abonnement Notificatie

Het functionele datamodel van een Abonnement Notificatie, en de mapping ervan naar FHIR is beschreven in onderstaande tabel.

Element/attribuut		Cardinaliteit	Toelichting
Functioneel	Technisch	Cardinaliteit	Toelichting
abonnement-id	SubscriptionStatus.subscripton.identifier van de aorta-subscription instance in de Bundle	1..1	ID van het abonnement o.b.v. deze notificatie wordt verzonden. M.b.v. dit ID kan de ontvanger van de notificatie de andere attributen van het abonnement vinden in het eigen systeem.
gebeurtenis-object	aorta-DataReference of aorta-AuditEvent instance in de Bundle	1..1	Object met daarin informatie over de gebeurtenis die aanleiding was voor deze notificatie. Bijv. een VWI/ACT-entry of een LOG-regel. Ook aanwezig bij notificatie naar patiënt.
bron-organisatie-id	Via aorta-DataReference of aorta-AuditEvent instance in de Bundle	0..1	Bron van de gebeurtenis. Aanwezig indien beschikbaar in de melding aan het Abonnementenregister.
bron-applicatie-id	Via aorta-DataReference of aorta-AuditEvent instance in de Bundle	0..1	Bron van de gebeurtenis. Aanwezig indien beschikbaar in de melding aan het Abonnementenregister.

De notificatie bevat de volgende elementen:

een status (FHIR resource SubscriptionStatus), met een verwijzing naar de Subscription
een kopie van de aanpassing die tot de gebeurtenis/notificatie heeft geleid. De aanpassing is een FHIR resource die overeenkomt met het element dat in de criteria benoemd is. Bijv. een criteria = 'List?_query=vwi&patientid=123456789&gegevenssoort=12345' levert een FHIR List resource (aorta-DataReference) op.
deze resources zijn samengevat in een Bundle van het type collection.

Toestemming Notificatie Interface

T.b.v. de Toestemming Notificatie Interface worden de volgende FHIR-versions ondersteund:

R4