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:

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.

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

Voorbeelden:

• https://simplifier.net/VZVZ/~resources?text=aorta-subscription-notification&category=Example&fhirVersion=R4B

Interacties

Abonnement Notificatie

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.

Aanvullende eisen

Functionele datamodel van een Abonnement Notificatie

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

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

FHIR-profielen

Voorbeelden:

• https://simplifier.net/VZVZ/~resources?text=mitz%7Cbundle%7Cnotif&category=Example&fhirVersion=R4B

Interacties

Toestemming Notificatie

Een notificatie betreft een POST van een Bundle van het type “transaction” 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.

Aanvullende eisen

Functionele datamodel van een Toestemming Notificatie

De inhoud van een Toestemming Notificatie is beschreven in het Mitz afsprakenstelsel, zie:

• Koppelvlakken

• Bijlage | Architectuurdocumenten - Implementatiehandleiding_Migreren-Abonneren-Notificeren-Registreren Toestemming

Register Sync Client Interface

FHIR-profielen

Over de register sync client interface wordt gebruik gemaakt van CommunicationRequest en Communication FHIR profielen. Meer informatie over de gehanteerde FHIR-profielen op deze interfaces:

Voorbeelden:

• https://simplifier.net/vzvz/nl-vzvz-notify-document-retrieved-example

Voorbeelden:

• https://simplifier.net/vzvz/nl-vzvz-notify-document-ready-example

Interacties

De interacties van de Register Sync Client Interface zijn inhoudelijk gelijk aan de interacties van de Register Sync Broker Interface.

Register Sync Notification (Client)

Deze interactie is inhoudelijk gelijk aan de Register Sync Notification (Broker) interactie van de Register Sync Broker.

De inhoud van de Register Sync Notificatie is beschreven in het functioneel datamodel en in aorta-notifyDocumentRetrieved.

Register Sync Request (Client)

Deze interactie is inhoudelijk gelijk aan de Register Sync Request (Broker) interactie van de Register Sync Broker.

De inhoud van het Register Sync Request (Client) is beschreven in het functioneel datamodel en in aorta-notifyDocumentReady.

Aanvullende eisen

Functioneel datamodel Register Sync Notification

Het functionele datamodel van een Register Sync Notification, en de mapping ervan op een FHIR Communication is beschreven in onderstaande tabel.

Attribute		Cardinaliteit	Toelichting
Functioneel	FHIR
Verzoek-id	Communication.identifier	1..1	Unieke id van het verzoek.
Referentie naar gerelateerde CommunicationRequest	Communication.basedOn	1..1	Verwijzing naar de identifier van het aan de Communication gerelateerde CommunicationRequest wat eerder ontvangen is Moet de waarde van de CommunicationRequest.identifier bevatten
status	Communication.status	1..1	Status van het verzoek. Moet waarde completedbevatten.
Type register sync	Communication.reasonCode	1..1	Reden dat de communicatie nodig is. Geeft aan welke register gesynct moet worden. Moet een van de onderstaande waardes bevatten: vwi-sync act-sync abr-sync
Document referentie	Communication.reasonReference	1..1	Verwijzing naar de DocumentReference welke opgehaald is.

Functioneel datamodel Register Sync Request

Het functionele datamodel van een Register Sync Request, en de mapping ervan op een FHIR CommunicationRequest is beschreven in onderstaande tabel.