Interfaces ACT/VWI Server

ACT/VWI Interface

Algemeen

Base endpoint en FHIR-versions

De waarde van de base-URL van de FHIR endpoints die de ACT/VWI Server biedt t.b.v. de ACT/VWI Interface ( [base] dus ), 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".

T.b.v. de ACT/VWI Interface worden de volgende FHIR-versions ondersteund:

R4

Let op! De ACT/VWI Server wordt door Resource Clients aangeroepen via Resource Broker ZA-in. Een Resource Client dient de base-URL van Resource Broker ZA-in te gebruiken. Resource Broker ZA-in hanteert de base-URL van de ACT/VWI Server.

HTTP-request headers

Bij iedere interactie, worden in ieder HTTP-request, de volgende HTTP headers 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.

Het BSN van de patient waarop een entry betrekking heeft wordt bij alle interacties meegegeven in het AORTA access_token. Alle interacties hebben dus betrekking op een en dezelfde patiënt. Dit geldt ook voor interacties die worden verstuurd in een batch of transaction Bundle.

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:

Subfeature	AORTA-Version HTTP Header
Versie	1.0.0

AORTA-Version: contentVersion=<versienummer>

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.

Generieke parameters

Het gewenste formaat (JSON of XML) kan op de gebruikelijke manier via de Accept Header opgegeven worden, maar kunnen ook via de FHIR _format parameter doorgegeven worden.

Ondersteunde waarden voor de _format parameter zijn voor alle interacties, waar van toepassing:

de mogelijke opties die duiden op het FHIR JSON formaat of op het FHIR XML formaat.

Indien beide (Accept header en _format parameter) in een request voorkomen, geldt de waarde van de _format parameter. Indien geen enkele voorkomt, dan geldt het formaat van het Content-Type.

Search parameters

In het algemeen ziet een request met search parameters (conditional-update, conditional-delete of search) er als volgt uit:

XML

[HTTP verb] [base url]/List?source:Device.identifier=http://fhir.nl/fhir/NamingSystem/aorta-app-id|[app id]&code=[codesystem url]|[value]{&_format=[mime-type]}

De vereiste vulling is hieronder beschreven:

Parameter

Verplicht

Omschrijving

[app id]

verplicht (voor GBZ)

applicatie id behorende bij het bronsysteem. Codesystem is een van:

urn:oid:2.16.840.1.113883.2.4.6.6
http://fhir.nl/fhir/NamingSystem/aorta-app-id

maar wordt bekend verondersteld, dus het mag weggelaten worden

code

verplicht (voor GBZ)

het codesysteem + waarde voor een gegevenssoort of bouwsteentype

_format

optioneel

gewenste mime-type waarin het resultaat opgeleverd moet worden.

Voorbeeld voor gegevenssoort 'Huisartswaarneemgegevens' en application ID 12345

XML

[PUT|DELETE] [base url]/List?source:Device.identifier=http://fhir.nl/fhir/NamingSystem/aorta-app-id|12345&code=urn:oid:2.16.840.1.113883.2.4.15.4|460320

Voorbeeld voor bouwsteentype 'Contactverslag' en application Id 12345

XML

[PUT|DELETE] [base url]/List?source:Device.identifier=http://fhir.nl/fhir/NamingSystem/aorta-app-id|12345&code=urn:oid:2.16.840.1.113883.2.4.3.111.15.3|CONTACTVERSLAG

Voorbeeld met zoeken op meerdere gegevenssoorten en bouwsteentypes

Voor het aanmaken, bijwerken en verwijderen van een entry geldt dat de actie alleen uitgevoerd wordt als de resultaat set tot 1 instantie leidt. Zoekacties kunnen meerdere resultaten opleveren. Hieronder staan voorbeelden waarbij gezocht wordt naar meerdere application-id's en meerdere gegevenssoorten en/of bouwsteentypes.

XML

GET [base url]/List?source:Device.identifier=http://fhir.nl/fhir/NamingSystem/aorta-app-id|12345&code=urn:oid:2.16.840.1.113883.2.4.3.111.15.3|CONTACTVERSLAG,urn:oid:2.16.840.1.113883.2.4.15.4|460320

FHIR-profielen

Informatie over de gehanteerde FHIR-profielen op deze interface:

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

Voorbeelden:

Interacties

Aanmaken of bijwerken entry

Feature	createOrUpdateDataReference
Type	Service
Versie	1.2.2
Groep	Lokalisatie
Gepubliceerd	22 Mar 2024
Delta	Verhelderd dat toets op geldigheid van access_token en toets op content_type in sommige situaties achterwege mag worden gelaten.
Use case	AOF.UC.VWI.100.v4

Feature	Versie	Dependency	Aanbieder	Afnemer
createOrUpdateDataReference	1.2.2	core-FHIR-interactie-broker	*	*
createOrUpdateDataReference	1.2.2	aorta-DataReference	1.0	1.0

Deze interactie is gebaseerd op de FHIR conditional update interactie. Hierdoor is het niet nodig om een administratie van het resource ID bij te houden. De entry wordt geïdentificeerd m.b.v. zoekparameters applicatie-id en gegevenssoort/bouwsteentype. Als de entry nog niet bestaat in het Actualisatieregister, dan wordt het aangemaakt, anders wordt het bijgewerkt. Voor de specifieke fouten zie hieronder.

Een entry kan op de volgende wijze worden aangemaakt of bijgewerkt:

Voorbeeld in JSON

JS

PUT [broker-base]/List?source:Device.identifier=http://fhir.nl/fhir/NamingSystem/aorta-app-id|12345&code=urn:oid:2.16.840.1.113883.2.4.3.111.15.3|CONTACTVERSLAG
Content-Type: application/fhir+json

{
    "resourceType": "List",
	......
}

Voorbeeld in XML

XML

PUT [broker-base]/List?source:Device.identifier=http://fhir.nl/fhir/NamingSystem/aorta-app-id|12345&code=urn:oid:2.16.840.1.113883.2.4.3.111.15.3|CONTACTVERSLAG
Content-Type: application/fhir+xml

<List xmlns="http://hl7.org/fhir">
....
</List>

Zoekresultaat	Actie	Retour code	Headers	Body
geen resultaat	entry wordt aangemaakt	201 Created	`Location` (url van zojuist gecreëerde resource)	-
1 resultaat	entry wordt bijgewerkt	200 OK	`Location` (url van zojuist bijgewerkte resource)	-
meerdere resultaten	-	412 Precondition Failed		OperationOutcome (vergelijkbaar met huidige situatie)

Zie rejecting updates voor aanvullende foutsituaties.

Deze functionaliteit wordt pas in een latere versie dan 0.8 ondersteund.

Meerdere interactie van dit type kunnen, wanneer de entries betrekking hebben op eenzelfde patiënt, op de volgende wijze worden gebundeld in een Bundle van het type "batch":

JS

POST [broker-base]
Content-Type: application/fhir+json
{
  "resourceType": "Bundle",
  "type": "batch",
  "entry": [
    {
      "resource": {
        "resourceType": "List",
...
      },
      "request": {
        "method": "PUT",
        "url": "/List?[search-parameters]"
      }
    },
    {
      "resource": {
        "resourceType": "List",
...
      },
      "request": {
        "method": "PUT",
        "url": "/List?[search-parameters]"
      }
    }
  ]
}

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. 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 foutresponse 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 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". NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.	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 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". NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.	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 foutresponse en gaat verder met de exit stap van de main flow.

Stap	Omschrijving	Uitkomst
1	Het systeem bepaalt welke operatie wordt gevraagd - aanmaken of bijwerken.	Het systeem kan niet eenduidig vaststellen welke entry wordt bedoeld statuscode 412 In deze situatie wordt een OperationOutcome met issue.code "`multiple-matches`" en de van toepassing zijnde issue.details geretourneerd.
1		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
2	Het systeem haalt de status van het bronsysteem in het Applicatieregister op m.b.v. feature migratedToMitz.	Mitz migratie status kan niet worden vastgesteld statuscode 500
2		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
3	Het systeem slaat de ontvangen entry, behoudens de geboortedatum van de patient, op, of werkt een reeds bestaande entry bij. Let op: indien een geboortedatum is ontvangen, dan dient deze te worden opgeslagen in een Itinerary, die wordt gebruikt voor HL7v3 (her)aanmeldingen, zodat deze wordt meegenomen in een bestaand abonnement proces t.b.v. Mitz. Indien de status van het bronsysteem in het Applicatieregister gelijk is aan “migrerend” of “gemigreerd”, dan wordt een entry in het Actualiteitsregister geplaatst, in andere gevallen in de Verwijsindex. Indien de status van het bronsysteem in het Applicatieregister gelijk is aan “migrerend”, EN het bericht bevat geen indicatie (tag) die aangeeft dat het gaat om een (her)aanmelding in het kader van een beheeractiviteit, dan wordt de entry ook in de Verwijsindex geplaatst, dus niet slechts in het Actualiteitsregister. Toelichting: in de periode waarin een bronsysteem migrerend is, staan notificaties vanuit het Actualiteitsregister voor dit systeem uit. Vanuit de Verwijsindex kunnen dan nog nog dan wel notificaties worden getriggered. Indien het ontvangen request informatie bevat over de reden van aanmelding of wijziging, dan dient deze informatie beschikbaar te worden gesteld aan het Abonnementenregister, zodat deze kan bepalen of al dan niet notificaties moeten worden verzonden naar abonnees.	Verwerking succesvol statuscode 200 OK
		Verwerking succesvol - resource instance gecreëerd statuscode 201 Created
		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
4 <exit>	Het systeem retourneert een response naar de primaire actor.

Verwijderen entry via RESTful API

Feature	deleteDataReference
Type	Service
Versie	1.1.1
Groep	Lokalisatie
Gepubliceerd	22 Mar 2024
Delta	Verhelderd dat toets op geldigheid van access_token en toets op content_type in sommige situaties achterwege mag worden gelaten.
Use case	AOF.UC.VWI.200.v3

Feature	Versie	Dependency	Aanbieder	Afnemer
deleteDataReference	1.1.1	core-FHIR-interactie-broker	*	*
deleteDataReference	1.1.1	aorta-DataReference	1.0	1.0

Deze interactie is gebaseerd op de FHIR conditional delete interactie. Met de conditional delete is het niet noodzakelijk om een administratie van de Resource IDs aan te leggen in het bronsysteem.

Een entry kan op de volgende wijze worden verwijderd:

CODE

DELETE [broker-base]/List?[search params]

Voorbeeld

CODE

DELETE [broker-base]/List?source:Device.identifier=http://fhir.nl/fhir/NamingSystem/aorta-app-id|12345&code=urn:oid:2.16.840.1.113883.2.4.3.111.15.3|CONTACTVERSLAG

Zie de sectie Search parameters voor de exacte eisen m.b.t. de vulling van de search parameters in de URL.

Zoekresultaat	Actie	Retour	Voorbeeld
geen resultaat	-	200 OK + OperationOutcome met 'entry niet gevonden'	OperationOutcome No entry found
1 resultaat	entry wordt verwijderd	204 No Content
meerdere resultaten	-	412 Precondition Failed	OperationOutcome multiple matches

(zie: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/DELETE )

NB. wanneer en entry op deze wijze wordt verwijderd, dan blijft een eventueel abonnement bij Mitz gewoon bestaan. Indien verwijdering van een Mitz abonnement ook is gewenst, dan dient de FHIR operation te worden gebruikt.

Deze functionaliteit wordt pas in een latere versie dan 0.8 ondersteund.

Meerdere interactie van dit type kunnen, wanneer de entries betrekking hebben op eenzelfde patiënt, op de volgende wijze worden gebundeld in een Bundle van het type "batch":

JS

POST [broker-base]
Content-Type: application/fhir+json
{
  "resourceType": "Bundle",
  "type": "batch",
  "entry": [
    {
      "request": {
        "method": "DELETE",
        "url": "/List?[search params]"
      }
    },
    {
      "request": {
        "method": "DELETE",
        "url": "/List?[search params]"
      }
    }
  ]
}

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. 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 foutresponse 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 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". NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.	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 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". NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.	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 foutresponse en gaat verder met de exit stap van de main flow.

Stap	Omschrijving	Uitkomst
1	Het systeem bepaalt welke entry moet worden verwijderd.	Het systeem kan niet eenduidig vaststellen welke entry wordt bedoeld statuscode 412 In deze situatie wordt een OperationOutcome met issue.code "`multiple-matches`" en de van toepassing zijnde issue.details geretourneerd.
1	Het systeem bepaalt welke entry moet worden verwijderd.	Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
2	Het systeem haalt de status van het bronsysteem in het Applicatieregister op m.b.v. feature migratedToMitz.	Mitz migratie status kan niet worden vastgesteld statuscode 500
2		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
3	Het systeem verwijdert de entry. Indien de status van het bronsysteem in het Applicatieregister gelijk is aan “migrerend” of “gemigreerd”, dan wordt een entry verwijderd uit het Actualiteitsregister, in andere gevallen wordt een entry verwijderd uit de Verwijsindex. Verwijdering van de laatste entry (van een bronsysteem-patient-combinatie) heeft geen gevolgen voor het Mitz abonnement. Deze wordt slechts verwijderd bij $delete-dossier.	Entry niet gevonden statuscode 200 OK In deze situatie wordt een OperationOutcome met issue.code “`informational`" en de van toepassing zijnde issue.details geretourneerd.
		Entry verwijderd statuscode 204 No Content
		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
4 <exit>	Het systeem retourneert een response naar de primaire actor.	Verwerking succesvol statuscode 200 OK

Verwijderen entries via een FHIR operation

Feature	$delete-dossier
Type	Service
Versie	1.1.1
Groep	Lokalisatie
Gepubliceerd	22 Mar 2024
Delta	Verhelderd dat toets op geldigheid van access_token en toets op content_type in sommige situaties achterwege mag worden gelaten.
Use case	AOF.UC.VWI.300.v3

Feature	Versie	Dependency	Aanbieder	Afnemer
$delete-dossier	1.1.1	core-FHIR-interactie-broker	*	*

Deze custom operation wordt als volgt aangeroepen:

CODE

POST [broker-base]/$delete-dossier

Zie ook FHIR Operations voor de wijze waarop wordt moet worden omgegaan met de parameters. Een HTTP POST is vereist, omdat de operation een wijziging tot stand brengt op de resource broker.

In Parameters
Name	Cardinality	Type	Toelichting
app-id	1..1	string	gelijk is aan het applicatie-id van het bronsysteem, en wel zonder de root OID prefix, dus bijvoorbeeld "12345678".
unsubscribe	1..1	boolean	true, wanneer een eventueel Mitz abonnement voor de combinatie BSN en appID ook dient te worden verwijderd. false, wanneer dit niet is gewenst. NB. deze parameter wordt nog niet ondersteund. Vraag is ook of deze parameter nodig is.
Out Parameters
Name	Cardinality	Type	Toelichting
return	0..1	OperationOutcome	Indien de operation: succesvol kan worden verwerkt, dan wordt een HTTP statuscode 200 geretourneerd. geen entries gevonden: HTTP 200 + OperationOutcome

2023-05-02 De unsubscribe parameter wordt nog niet gebruikt

Voorbeeld

CODE

POST [broker-base]/$delete-dossier

<Parameters xmlns=http://hl7.org/fhir>
  <parameter>
    <name value="app-id"/>
    <valueString value="[application ID]"/>
  </parameter>
  <parameter>
    <name value="unsubscribe"/>
    <valueBoolean value="[true|false]"/>
  </parameter>
</Parameters>

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. 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 foutresponse 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 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". NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.	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 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". NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.	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 foutresponse en gaat verder met de exit stap van de main flow.

Stap	Omschrijving	Uitkomst
1	Het systeem haalt de status van het bronsysteem in het Applicatieregister op m.b.v. feature migratedToMitz.	Mitz migratie status kan niet worden vastgesteld statuscode 500
1		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
2	Het systeem verwijdert de entries. Indien de status van het bronsysteem in het Applicatieregister gelijk is aan “migrerend” of “gemigreerd”, dan worden de entries verwijderd uit het Actualiteitsregister, in andere gevallen worden de entries verwijderd uit de Verwijsindex. Let op: het systeem dient er nu ook voor te zorgen dat de betreffende bronsysteem-patient-combinatie wordt meegenomen in het bestaande abonnement beëindiging proces t.b.v. Mitz.	Entry niet gevonden Het systeem genereert de vereiste foutresponse en keert terug naar de exit stap van de main flow. statuscode 404 Not Found In deze situatie wordt een OperationOutcome met issue.code "`not-found`" en de van toepassing zijnde issue.details geretourneerd.
		Verwerking succesvol statuscode 200 OK
		Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.
3 <exit>	Het systeem retourneert een response naar de primaire actor.

Zoeken naar entries

Feature	searchDataReference
Type	Service
Versie	1.0.1
Groep	Lokalisatie
Gepubliceerd	22 Mar 2024
Delta	Verhelderd dat toets op geldigheid van access_token en toets op content_type in sommige situaties achterwege mag worden gelaten.
Use case	AOF.UC.VWI.400.v2

Feature	Versie	Dependency	Aanbieder	Afnemer
searchDataReference	1.0.1	core-FHIR-interactie-broker	*	*
searchDataReference	1.0.1	aorta-DataReference	1.0	1.0

Deze interactie is gebaseerd op de FHIR-search interactie. Er kan op de volgende wijze worden gezocht naar entries betreffende een specifieke patiënt:

CODE

GET [broker-base]/List{?[parameters]{&_format=[mime-type]}}

Zie de sectie Search parameters voor meer uitleg over de parameters.

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. 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 foutresponse 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 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". NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.	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 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". NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd.	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 foutresponse en gaat verder met de exit stap van de main flow.

Stap

Omschrijving

Uitkomst

1

Het systeem zoekt naar verwijzingen die voldoen aan de zoekcriteria.

2

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

Feature	getEntries
Type	Service
Versie	1.0.0
Groep	Lokalisatie
Gepubliceerd	19 Oct 2023
Delta	Initiële versie van feature.
Use case	AOF.UC.VWI.400.v1

Feature	Versie	Dependency	Aanbieder	Afnemer
getEntries	1.0.0	AORTA Stelseltoken	-	*
getEntries	1.0.0	AORTA-ID HTTP Header	*	*

De getEntries interactie maakt het mogelijk om:

Verwijsindex entries op te vragen op basis van een BSN en een set van bouwsteentypen of gegevenssoorten. De response bevat een set van appID’s en per appID een set van bouwsteentypen of gegevenssoorten waarover de betreffende GBZ-applicatie, voor de gegeven patiënt, beschikt.

Functionele datamodel van een ACT/VWI-entry

Het functionele datamodel van een VWI/ACT-entry, en de mapping ervan naar FHIR is beschreven in onderstaande tabel.

Attribuut		Cardinaliteit	Toelichting
Functioneel	FHIR	Cardinaliteit	Toelichting
Patiënt-id	List.subject.(contained Patient).identifier	1..1	BSN van de patiënt
Patiënt-geboortedatum	List.subject.(contained Patient).birthDate	1..1	Geboortedatum van de patiënt, nodig voor Mitz
Verantwoordelijke organisatie	List.source.(contained Device).owner.identifier	1..1	URA van organisatie
Applicatie-id	List.source.(contained Device).identifier	1..1	AppID van de GBx-applicatie.
Bouwsteentype/Gegevenssoort	List.code.coding.system	1..1	Gegevenssoort: `system value='urn:oid:2.16.840.1.113883.2.4.15.4'` Bouwsteentype: `system value='urn:oid:2.16.840.1.113883.2.4.3.111.15.3'`
Datum bijgewerkt	List.date	1..1	Datum waarop het gegeven voor het laatst is bijgewerkt