Interfaces Abonnementenregister

Abonnement 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 Abonnement 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 het Abonnementenregister biedt t.b.v. de Abonnement 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 Abonnement Interface worden de volgende FHIR-versions ondersteund:

R4

Let op! Het Abonnementenregister 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 het Abonnementenregister.

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.

FHIR-profielen

Informatie over de gehanteerde FHIR-profielen op deze interface:

Feature	aorta-subscription
Type	Subfeature
Versie	1.0.0
Profiel	aorta-subscription
Systeemrolcode	-
Groep	FHIR-profielen
Gepubliceerd	05 Dec 2023
Delta	Initiële versie van feature.

Voorbeelden:

Interacties

Registreren Abonnement

Feature	createSubscription
Type	Service
Versie	1.0.4
Systeemrolcode	aorta-subscription:CIS:R4:1
Groep	Notificatie
Gepubliceerd	28 Mar 2025
Delta	Fix: Voorkomen van dubbele abonnementen. Toets op gebeurtenis-subtype toegevoegd (slechts contextcode toestaan)
Use case	AOF.UC.ABR.100.v5

Feature	Versie	Dependency	Aanbieder	Afnemer
createSubscription	1.0.4	core-FHIR-interactie-broker	>=1	>=1
createSubscription	1.0.4	aorta-subscription	>=1.*	>=1

Deze interactie is gebaseerd op de FHIR conditional create interactie, zodat de situatie ondervangen kan worden dat dezelfde interactie meerdere keren aangeboden wordt:

CODE

POST [base]/Subscription
If-None-Exist: [parameters]

Ondersteunde parameters zijn:

identifier (de waarde van extension http://vzvz.nl/fhir/StructureDefinition/aorta-subscription-identifier van de Subscription, ofwel het abonnement-id)

Voorbeeld:

CODE

POST [base]/Subscription
If-None-Exist: identifier=<system>|<value>

{
  "resourceType": "Subscription",
  ..
}

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 toetst of het BSN in de patient claim van het AORTA access_token overeenkomt met het BSN in het criterium van het beoogde abonnement.	BSN in criterium komt niet overeen met token statuscode 403 Forbidden Indien een `Authorization` header werd gebruikt in het request, dan wordt in deze situatie, conform RFC 6750, een `WWW-Authenticate` HTTP response header met als auth-scheme "`Bearer`" en een `error` attribuut met waarde "`access_denied`" geretourneerd. Indien de `WWW-Authenticate` HTTP response header wordt geproduceerd door de resource broker, dan wordt een `realm` attribuut met waarde "`aorta`" toegevoegd. Indien het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "`forbidden`" geretourneerd.
1		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
2	Het systeem toetst of de registratie van het abonnement is toegestaan: een zorgverlener mag slechts een abonnement nemen op de Verwijsindex een patient mag zich abonneren op zowel de Toegangslog (LOG) als op de Verwijsindex/Actualiteitsregister (gebeurtenis-type) het abonnement mag de maximum toegestane duur niet overschrijden (de maximale toegestane duur is een configureerbare parameter). Indien geen gewenste einddatum wordt meegegeven, dan geldt de maximaal toegestane duur. het gebeurtenis-subtype van het abonnement (bijv. de contextcode) moet in overeenstemming zijn met de _vrb_ter_scope claim van het ontvangen AORTA access_token. de aanvrager-functie van het abonnement moet, indien aanwezig, overeenkomen met de role claim van het ontvangen AORTA access_token.	Registratie niet toegestaan statuscode 403 Forbidden Indien een `Authorization` header werd gebruikt in het request, dan wordt in deze situatie, conform RFC 6750, een `WWW-Authenticate` HTTP response header met als auth-scheme "`Bearer`" en een `error` attribuut met waarde "`access_denied`" geretourneerd. Indien de `WWW-Authenticate` HTTP response header wordt geproduceerd door de resource broker, dan wordt een `realm` attribuut met waarde "`aorta`" toegevoegd. Indien het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "`forbidden`" geretourneerd.
2		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
3	Het systeem toetst het gebeurtenis-subtype een abonnement op de Verwijsindex/Actualiteitsregister kan slechts worden genomen voor subtype “contextcode”.	Abonnement niet mogelijk statuscode 422 Unprocessable Entity In deze situatie wordt een OperationOutcome met issue.code “`business-rule`” geretourneerd, met in de issue.diagnostics meer informatie over aan welke business-rule niet is voldaan.
3		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
4	Het systeem toetst of er al een abonnement bestaat met dezelfde kenmerken: voor abonnementen die zijn genomen door een zorgaanbieder: er bestaat al een abonnement met dezelfde abonnee-organisatie-id, abonnee-applicatie-id, aanvrager-functie, gebeurtenis-type, gebeurtenis-subtype, gebeurtenis-subject. voor abonnementen die zijn genomen door een patiënt: er bestaat al een abonnement met dezelfde abonnee-organisatie-id, abonnee-applicatie-id, aanvrager-id, gebeurtenis-type, gebeurtenis-subtype, gebeurtenis-subject.	Vergelijkbaar abonnement bestaat al statuscode 422 Unprocessable Entity In deze situatie wordt een OperationOutcome met issue.code “`duplicate`” geretourneerd.
4		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
5	Indien nog geen equivalent abonnement bestaat, zoals aangeduid door het equivalentie criterium (`If-None-Exist`) in het request, dan registreert het systeem het abonnement. Zie ook de toelichting “Interne verwerking van abonnementen en signalen”.	Meer dan één equivalent abonnement gevonden statuscode 412 In deze situatie wordt een OperationOutcome met issue.code "`multiple-matches`" en de van toepassing zijnde issue.details geretourneerd.
5		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
6 <exit>	Het systeem retourneert een response naar de primaire actor.	Verwerking succesvol statuscode 200 OK

Opvragen Abonnementen

Feature	searchSubscription
Type	Service
Versie	1.0.2
Systeemrolcode	aorta-subscription:SIS:R4:1
Groep	Notificatie
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.ABR.200.v2

Feature	Versie	Dependency	Aanbieder	Afnemer
searchSubscription	1.0.2	core-FHIR-interactie-broker	>=1	>=1
searchSubscription	1.0.2	aorta-subscription	>=1.*	>=1

Deze interactie is gebaseerd op de FHIR-search interactie.

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

Ondersteunde parameters zijn:

-

Voorbeeld:

GET [base]/Subscription

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 voert de zoekopdracht uit:

voor zorgaanbieder abonnementen worden slechts abonnementen opgeleverd waarvoor
- het abonnee-applicatie-id van het abonnement overeenkomt met het app-id in de vrb_client_id claim van het AORTA access_token, EN
- het BSN in het criterium van het abonnement overeenkomt met de patient claim van het AORTA access_token
voor patiënt abonnementen worden slechts abonnementen opgeleverd waarvoor
- het aanvrager-id van het abonnement overeenkomt met het sub claim van het AORTA access_token, EN
- het BSN in het criterium van het abonnement overeenkomt met de patient claim van het AORTA access_token

2

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

Wijzigen Abonnement

Feature	updateSubscription
Type	Service
Versie	1.0.5
Systeemrolcode	aorta-subscription:UIS:R4:1
Groep	Notificatie
Gepubliceerd	28 Mar 2025
Delta	Verhelderd dat via “wijzigen abonnement” slechts de einddatum kan worden aangepast. Bug fix: Toetsing van appID van Resource Client tegen appID in abonnement wordt uitgevoerd door RB ZA-in en niet door het Abonnementenregister. Toets op gebeurtenis-subtype toegevoegd (slechts contextcode toestaan).
Use case	AOF.UC.ABR.300.v6

Feature	Versie	Dependency	Aanbieder	Afnemer
updateSubscription	1.0.5	core-FHIR-interactie-broker	>=1	>=1
updateSubscription	1.0.5	aorta-subscription	>=1.*	>=1

Deze interactie is gebaseerd op de FHIR conditional update interactie:

PUT [base]/Subscription?[parameters]

Ondersteunde parameters zijn:

identifier (de waarde van extension http://vzvz.nl/fhir/StructureDefinition/aorta-subscription-identifier van de Subscription, ofwel het abonnement-id)

Voorbeeld:

CODE

PUT [base]/Subscription?identifier=<system>|<value>

{
"resourceType": "Subscription",
...
}

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 toets of er inderdaad een abonnement bestaat met de identifier, zoals doorgegeven in het request.	Abonnement bestaat niet statuscode 422 Unprocessable Entity In deze situatie wordt een OperationOutcome met issue.code "`search-none`" en de van toepassing zijnde issue.details geretourneerd. 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 toetst of het BSN in de patient claim van het AORTA access_token overeenkomt met het BSN in het criterium van het bestaande abonnement.	BSN in criterium komt niet overeen met token statuscode 403 Forbidden Indien een `Authorization` header werd gebruikt in het request, dan wordt in deze situatie, conform RFC 6750, een `WWW-Authenticate` HTTP response header met als auth-scheme "`Bearer`" en een `error` attribuut met waarde "`access_denied`" geretourneerd. Indien de `WWW-Authenticate` HTTP response header wordt geproduceerd door de resource broker, dan wordt een `realm` attribuut met waarde "`aorta`" toegevoegd. Indien het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "`forbidden`" geretourneerd.
2		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
3	Het systeem toetst of de wijziging van het abonnement is toegestaan: het gebeurtenis-subtype van het abonnement (bijv. de contextcode) moet in overeenstemming zijn met de _vrb_ter_scope claim van het ontvangen AORTA accesstoken. de aanvrager-functie van het abonnement moet, indien aanwezig, overeenkomen met de role claim van het ontvangen AORTA access_token. een patient mag een abonnement slechts wijzigen wanneer de aanvrager-id van het abonnement overeenkomt met het sub claim van het AORTA access_token. het abonnement mag de maximum toegestane duur niet overschrijden (de maximale toegestane duur is een configureerbare parameter). Indien geen gewenste einddatum wordt meegegeven, dan geldt de maximaal toegestane duur. Een abonnement kan dus telkens met een maximaal toegestane duur worden verlengd. indien bij een zorgaanbieder abonnement een aanvrager-id van een zorgverlener/medewerker wordt meegegeven, dan mag deze afwijken van een eventueel reeds geregistreerd aanvrager-id (de aanvrager-functie echter mag niet worden gewijzigd) andere wijzigingen dan de einddatum, en bij zorgaanbieder abonnementen eventueel de aanvrager-id (zie boven), aan het bestaande abonnement zijn niet toegestaan Een zorgaanbieder abonnement mag verder slechts worden gewijzigd wanneer de abonnee-applicatie-id van het abonnement overeenkomt met het app-id van de client GBx-applicatie. Dit wordt geborgd door Resource Broker ZA-in via toetsing van de scope van het access_token, die is beperkt tot dit app-id).	Wijziging niet toegestaan statuscode 403 Forbidden Indien een `Authorization` header werd gebruikt in het request, dan wordt in deze situatie, conform RFC 6750, een `WWW-Authenticate` HTTP response header met als auth-scheme "`Bearer`" en een `error` attribuut met waarde "`access_denied`" geretourneerd. Indien de `WWW-Authenticate` HTTP response header wordt geproduceerd door de resource broker, dan wordt een `realm` attribuut met waarde "`aorta`" toegevoegd. Indien het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "`forbidden`" geretourneerd.
3		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
4	Het systeem toetst het gebeurtenis-subtype een abonnement op de Verwijsindex/Actualiteitsregister kan slechts worden genomen voor subtype “contextcode”.	Abonnement niet mogelijk statuscode 422 Unprocessable Entity In deze situatie wordt een OperationOutcome met issue.code “`business-rule`” geretourneerd, met in de issue.diagnostics meer informatie over aan welke business-rule niet is voldaan.
4		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
5	Het systeem verwerkt de wijziging. Zie ook de toelichting “Interne verwerking van abonnementen en signalen”.
5 <exit>	Het systeem retourneert een response naar de primaire actor.	Verwerking succesvol statuscode 200 OK

Beëindigen Abonnement

Feature	deleteSubscription
Type	Service
Versie	1.0.2
Systeemrolcode	aorta-subscription:DIS:R4:1
Groep	Notificatie
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.ABR.400.v3

Feature	Versie	Dependency	Aanbieder	Afnemer
deleteSubscription	1.0.2	core-FHIR-interactie-broker	>=1	>=1
deleteSubscription	1.0.2	aorta-subscription	>=1.*	>=1

Deze interactie is gebaseerd op de FHIR conditional delete interactie:

DELETE [base]/Subscription?[parameters]

Ondersteunde parameters zijn:

identifier (de waarde van extension http://vzvz.nl/fhir/StructureDefinition/aorta-subscription-identifier van de Subscription, ofwel het abonnement-id)

Voorbeeld:

DELETE [base]/Subscription?identifier=<system>|<value>

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 toetst of er inderdaad een abonnement bestaat met de identifier, zoals doorgegeven in het request.	Abonnement bestaat niet statuscode 200 OK In deze situatie wordt een OperationOutcome met issue.severity “`warning`“, issue.code "`not-found`" en de van toepassing zijnde issue.details geretourneerd, in dit geval “`SEARCH_NONE`”. 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 toetst of de beëindiging van het abonnement is toegestaan: het BSN in de patient claim van het AORTA access_token moet overeenkomen met het BSN in het criterium van het abonnement een zorgaanbieder abonnement mag slechts worden beëindigd wanneer de abonnee-applicatie-id van het abonnement overeenkomt met het app-id in de vrb_client_id claim van het AORTA access_token. een patient mag een abonnement slechts beëindigen wanneer de aanvrager-id van het abonnement overeenkomt met het sub claim van het AORTA access_token. het gebeurtenis-subtype van het abonnement (bijv. de contextcode) moet in overeenstemming zijn met de _vrb_ter_scope claim van het ontvangen AORTA accesstoken.	Beëindiging niet toegestaan statuscode 403 Forbidden Indien een `Authorization` header werd gebruikt in het request, dan wordt in deze situatie, conform RFC 6750, een `WWW-Authenticate` HTTP response header met als auth-scheme "`Bearer`" en een `error` attribuut met waarde "`access_denied`" geretourneerd. Indien de `WWW-Authenticate` HTTP response header wordt geproduceerd door de resource broker, dan wordt een `realm` attribuut met waarde "`aorta`" toegevoegd. Indien het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "`forbidden`" geretourneerd.
2		Het systeem genereert de vereiste response en gaat verder met de exit stap van de main flow.
3	Het systeem beëindigt het abonnement.
4 <exit>	Het systeem retourneert een response naar de primaire actor.	Verwerking succesvol statuscode 200 OK

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 Abonnement

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

Element/attribuut		Cardinaliteit	Toelichting
Functioneel	FHIR	Cardinaliteit	Toelichting
abonnement-id	extension: aorta-subscription-identifier	1..1	Uniek ID van het abonnement
-	id	0..1	Logical ID van de FHIR Subscription Niet aanwezig bij het aanmaken van een Abonnement.
-	reason	1..1	Reden van creatie Abonnement. Vaste waarde, conform FHIR-profiel.
abonnee-organisatie-id	extension: aorta-subscription-managingEntity:PractionerRole.organization:Organization.identifier OF extension: aorta-subscription-managingEntity:Patient.managingOrganization:Organization.identifier	1..1	URA of organisatie-id van abonnee
abonnee-applicatie-id	extension: SourceSystem	1..1	appID van GBx-applicatie van de abonnee Formaat: OID
aanvrager-id	extension: aorta-subscription-managingEntity:Patient.identifier	0..1	Slechts aanwezig wanneer de aanvrager een patiënt is. BSN van patiënt (abonnee)
aanvrager-functie	extension: aorta-subscription-managingEntity:PractionerRole.code	0..1	Slechts aanwezig wanneer de aanvrager een zorgverlener is. rolcode abonnee (UZI-rolcode) Deze rolcode bepaalt welke signalen het systeem ontvangt als gevolg van een abonnement. Dit moet namelijk passen binnen de autorisaties van de aanvrager-functie.
gebeurtenis-type	criteria (zie bij gebeurtenis-subject)	1..1	Het type gebeurtenis, waarop een abonnement wordt/is genomen. Mogelijke typen: Wijzigingen in VWI/ACT (_query bevat attribuut “vwi” en resource type in criteria is “List”) Wijzigingen in LOG (_query bevat attribuut “log” en resource type in criteria is “AuditEvent”) - notificaties bij opvragen/sturen patiëntgegevens (agerend)
gebeurtenis-subtype	criteria (zie bij gebeurtenis-subject)	0..1	Verplicht bij abonnement op wijzigingen in VWI/ACT: Bij opvragen van abonnementen: gegevenssoort van de betreffende VWI/ACT-entry OF contextcode (“gegevenssoort” of “contextcode” attribuut in _query) Bij aanmaken of wijzigen van een abonnement: contextcode (gegevenssoort wordt hier niet ondersteund). De combinatie van contextcode en rolcode is in de SDS gekoppeld aan een set van bouwsteentypen/gegevenssoorten. Niet aanwezig bij abonnement op wijzigingen in LOG.
gebeurtenis-subject	criteria Criteria bestaat uit: <resource type>? named query (bijv. `vwi` of `log`) met parameter `patientid` = BSN Voor VWI-entries zijn er extra parameters: parameter `gegevenssoort` met als waarde de code voor de gegevenssoort OF parameter `contextcode` met als waarde de code voor de betreffende context code. Voorbeelden zijn opgenomen in het FHIR-profiel.	1..1	BSN van patiënt (“patientid” attribuut in _query)
einddatum	end	0..1	Moet vallen binnen een vastgestelde maximum duur van een abonnement. Niet verplicht bij het aanmaken van een nieuwe Subscription. Wordt dan door het Abonnementenregister zelf gevuld. Wel verplicht bij andere interacties.

Gebeurtenis Afhandeling Interface (Notificeren)

Vooralsnog geen aanpassingen t.o.v. bestaande situatie.

Als er een gebeurtenis plaatsvindt die overeenkomt met de criteria zoals gedefinieerd in de Subscripton.criteria dan wordt een Notificatie gestuurd, op de wijze zoals gespecificeerd in de use case Afhandelen Gebeurtenis.