Interfaces ACT/VWI Server

ACT/VWI Interface

Algemeen

Deze interface wordt door Resource Clients aangeroepen via Feature core-FHIR-interactie-broker die wordt geboden door Resource Broker ZA-in. Daarom gelden voor het gebruik van Features van de ACT/VWI Interface ook de specificaties van core-FHIR-interactie-broker m.b.t. het gebruik van HTTP headers.

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.

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.1.1
Profiel	aorta-DataReference
Systeemrolcode	-
Groep	FHIR-profielen
Gepubliceerd	10 Jan 2025
Delta	Feature versie in lijn gebracht met versie van FHIR-profiel.

Voorbeelden:

https://simplifier.net/VZVZ/~resources?text=aorta%7Cdatareference&category=Example&fhirVersion=R4B

Interacties

Aanmaken of bijwerken entry

Feature	createOrUpdateDataReference
Type	Service
Versie	1.2.4
Systeemrolcode	aorta-DataReference:UIS:R4:1
Groep	Lokalisatie
Gepubliceerd	28 Mar 2025
Delta	Bug fix: VWI/AR wijzig datum vullen met actuele datum/tijd. Bijwerkdatum uit request slechts opslaan in VWI. Striktere formulering formaat van bijwerkdatum in request (List.date).
Use case	AOF.UC.VWI.100.v6

Feature	Versie	Dependency	Aanbieder	Afnemer
createOrUpdateDataReference	1.2.4	core-FHIR-interactie-broker	>=1	>=1
createOrUpdateDataReference	1.2.4	aorta-DataReference	>=1.*	>=1

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 nog niet 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. Het systeem toetst of het gevraagde type content (Accept header) en het gehanteerde type content (Content-Type header) worden ondersteund. 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 response 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 response 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". DigiD Authenticatietoken, zoals omschreven in de sectie “Toetsing DigiD Authenticatietoken”. NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd. Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.	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 response 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. Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.	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 response 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 response 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 response 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. Het systeem toetst hierbij of: Alle verplichte velden zijn gevuld. Velden op de juiste wijze zijn gevuld. De datum van laatste bijwerking mag niet in de toekomst liggen. Let op: de ontvangen geboortedatum wordt 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. Het veld “VWI wijzig datum” danwel “AR wijzig datum” dient vooralsnog te worden gevuld met de datum/tijd waarop de entry daadwerkelijk wordt verwerkt in het systeem. Een ontvangen “Datum bijgewerkt” in het request wordt vooralsnog slechts opgeslagen indien de Verwijsindex moet worden bijgewerkt, en wel in het veld ”GBZ wijzig datum”. 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 eerst 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.	Verwerking succesvol statuscode 200 OK
		Verwerking succesvol - resource instance gecreëerd statuscode 201 Created
		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. Indien de `WWW-Authenticate` HTTP response header wordt geproduceerd door de resource broker, dan wordt een `realm` attribuut met waarde "`aorta`" toegevoegd.
		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
4	Indien het ontvangen request geen informatie bevat over de reden van aanmelding/wijziging, of wanneer het request een reden bevat die, net als een reguliere aanmelding/wijziging, wel tot notificaties zou kunnen leiden, dan rapporteert het systeem de aanmelding/heraanmelding aan het Abonnementenregister. Vooralsnog is het zo dat geen enkele reden van aanmelding/wijziging die in een request kan worden doorgegeven kan leiden tot notificatie.
5 <exit>	Het systeem retourneert een response naar de primaire actor.

Verwijderen entry via RESTful API

Feature	deleteDataReference
Type	Service
Versie	1.1.2
Systeemrolcode	aorta-DataReference:DIS:R4:1
Groep	Lokalisatie
Gepubliceerd	17 Jan 2025
Delta	<patch - 1.1.2> Bug fix: Keuze VWI (gebruiken voor en tijdens migratie naar Mitz) of ACT (gebruiken na migratie)
Use case	AOF.UC.VWI.200.v4

Feature	Versie	Dependency	Aanbieder	Afnemer
deleteDataReference	1.1.2	core-FHIR-interactie-broker	>=1	>=1
deleteDataReference	1.1.2	aorta-DataReference	>=1.*	>=1

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 nog niet 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. Het systeem toetst of het gevraagde type content (Accept header) en het gehanteerde type content (Content-Type header) worden ondersteund. 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 response 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 response 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". DigiD Authenticatietoken, zoals omschreven in de sectie “Toetsing DigiD Authenticatietoken”. NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd. Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.	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 response 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. Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.	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 response 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 response 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 response 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 “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 response 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.3
Systeemrolcode	$delete-dossier:OIS:R4:1
Groep	Lokalisatie
Gepubliceerd	17 Jan 2025
Delta	<patch - 1.1.3> Bug fix: Keuze VWI (gebruiken voor en tijdens migratie naar Mitz) of ACT (gebruiken na migratie)
Use case	AOF.UC.VWI.300.v5

Feature	Versie	Dependency	Aanbieder	Afnemer
$delete-dossier	1.1.3	core-FHIR-interactie-broker	>=1	>=1

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".
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 No entry found

Voorbeeld

NONE

POST [broker-base]/$delete-dossier

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

CODE

POST [broker-base]/$delete-dossier

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "app-id": "[application ID]"
    }
  ]
}

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. Het systeem toetst of het gevraagde type content (Accept header) en het gehanteerde type content (Content-Type header) worden ondersteund. 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 response 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 response 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". DigiD Authenticatietoken, zoals omschreven in de sectie “Toetsing DigiD Authenticatietoken”. NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd. Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.	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 response 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. Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.	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 response 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 response 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 “gemigreerd” (), dan worden de entries verwijderd uit het Actualiteitsregister, in andere gevallen worden de entries verwijderd uit de Verwijsindex. ) Het systeem dient er in deze situatie 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 200 In deze situatie wordt ook een OperationOutcome geretourneerd met severity “information”, code “informational” en diagnostics “Entry not found”.
		Verwerking succesvol statuscode 200 OK
		Het systeem genereert de vereiste response 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
Systeemrolcode	aorta-DataReference:SIS:R4: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	>=1	>=1
searchDataReference	1.0.1	aorta-DataReference	>=1.*	>=1

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. Het systeem toetst of het gevraagde type content (Accept header) en het gehanteerde type content (Content-Type header) worden ondersteund. 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 response 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 response 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". DigiD Authenticatietoken, zoals omschreven in de sectie “Toetsing DigiD Authenticatietoken”. NB. wanneer het verzoek via een intern netwerk wordt ontvangen, en van een component van VZVZ, dan hoeft deze toets niet te worden uitgevoerd. Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.	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 response 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. Welke tokens van toepassing zijn is beschreven in de interface specificaties die horen bij deze use case.	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 response 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
Systeemrolcode	-
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	-	>=1.0.0
getEntries	1.0.0	AORTA-ID HTTP Header	>=1.0.0	>=1.0.0

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.

Deze interface is slechts bedoeld voor gebruik door VZVZ-componenten, en kan niet (rechtstreeks) worden gebruikt door GBx-applicaties.

Aanvullende eisen

AOF-I.GEN.110.v1 - Gebruik van veilig intern netwerk

De interface wordt aangeboden op een beveiligd besloten netwerk dat ter beschikking staat voor communicatie tussen componenten onderling, en tussen componenten en de ZIM.

AOF-I.GEN.150.v1 - Gebruik van HTTP

HTTP-requests en -responses op deze interface worden verzonden conform HTTP versie 1.1.

Alle HTTP-verkeer wordt verzonden binnen een TLS verbinding.

AOF-I.GEN.200.v1 - TLS verbindingen

TLS clients en TLS servers dienen tenminste TLS versie 1.2 te ondersteunen en mogen hierbij slechts gebruik maken van algoritmeselecties uit de categorie "Goed", zoals genoemd in bijlage C van de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS).

Bij het opzetten van een verbinding dient gebruik te worden gemaakt van de sterkste algoritmeselectie die door beide partijen wordt ondersteund. TLS clients en TLS servers maken bij voorkeur echter gebruik van een hogere TLS versie dan 1.2.

Binnen TLS verbindingen dienen tijdelijke sleutels te worden toegepast, die elke 5 minuten worden ververst door middel van TLS Secure Renegotiation.

TLS verbindingen worden opgezet middels PKIo servercertificaten of, voor zorgaanbieders, m.b.v. UZI-servercertificaten.

AOF-I.GEN.250.v1 - Systeem Authenticatie (mTLS)

Indien uitwisseling plaatsvindt binnen TLS verbindingen, dan dient op deze interface gebruik te worden gemaakt van tweezijdige authenticatie (mutual TLS, mTLS), waarbij de TLS client en de TLS server zich wederzijds authenticeren.

AOF-I.GEN.400.v1 - FHIR

Op deze interface gelden de generieke eisen uit de MedMij informatiestandaarden. Dit betekent ondermeer dat zowel JSON als XML moet worden ondersteund.

AOF-I.GEN.450.v1 - Verkrijgen base-URL van component

Deze interface wordt geboden door een component die is opgenomen in het AORTA Stelseltoken. In de specificaties is aangegeven welke component het betreft.

Wanneer deze interface wordt gebruikt via HTTP, dan mag deze slechts worden gericht aan de base-URL van een server/component die deze rol blijkens het AORTA Stelseltoken vervuld.

Het geldende AORTA Stelseltoken dient periodiek te worden opgehaald via de AORTA Stelsel Metadata Interface. De aangeven caching directives dienen hierbij te worden gevolgd.

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
Reden van update	List.meta.tag.updateReason	0..1	Aanwezig indien een bijzondere (niet-reguliere) reden van (her)aanmelding van toepassing is. Dit attribuut wordt bijvoorbeeld gebruikt om te bepalen of een (her)aanmelding al dan niet moet kunnen leiden tot notificaties n.a.v. een abonnement op VWI/ACT. Dit attribuut wordt niet opgeslagen, en wordt dus ook niet opgenomen in een zoekresultaat.