Skip to main content
Skip table of contents

Interfaces Abonnementenregister

Abonnement Interface

Algemeen

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

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

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 abonnement 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

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

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:

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

Groep

FHIR-profielen

Gepubliceerd

Delta

Initiële versie van feature.

Voorbeelden:

Interacties

Registreren Abonnement

Feature

createSubscription

Type

Service

Versie

1.0.0

Groep

Notificatie

Gepubliceerd

Delta

Initiële versie van feature.

Use case

AOF.UC.ABR.100.v1

Feature

Versie

Dependency

Aanbieder

Afnemer

createSubscription

1.0.0

core-FHIR-interactie-broker

Verplicht >=*

Verplicht >=1

createSubscription

1.0.0

aorta-subscription

Verplicht >=1.*

Verplicht >=1

Error rendering macro 'excerpt-include' : No location was provided.

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:

Voorbeeld:

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

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

HTTP statuscodes die kunnen worden geretourneerd zijn:

Stap

Omschrijving

Uitkomst

1

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content of AORTA acceptVersion niet ondersteund

statuscode 406 Not Acceptable

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

Gehanteerd type content of AORTA contentVersion niet ondersteund

statuscode 415 Unsupported Media Type

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

2

Het systeem controleert of er een access_token is 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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

3

Het systeem toetst of het ontvangen token een geldig AORTA access_token is op de wijze zoals beschreven in Toetsing AORTA access_token.

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.

  • In deze situatie mag daarnaast ook een OperationOutcome met issue.code "security" worden geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

4

Het systeem toetst of het verzoek voldoet aan de interface specificatie.

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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

5

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 het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "forbidden" geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

6

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

  • 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.

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 het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "forbidden" geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

7

Indien nog geen equivalent abonnement bestaat, zoals aangeduid door het equivalentie criterium (If-None-Exist) in het request, dan registreert het systeem het abonnement.

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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

8

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

Opvragen Abonnementen

Feature

searchSubscription

Type

Service

Versie

1.0.0

Groep

Notificatie

Gepubliceerd

Delta

Initiële versie van feature.

Use case

AOF.UC.ABR.200.v1

Feature

Versie

Dependency

Aanbieder

Afnemer

searchSubscription

1.0.0

core-FHIR-interactie-broker

*

*

searchSubscription

1.0.0

aorta-subscription

1.0

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:

Stap

Omschrijving

Uitkomst

1

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content of AORTA acceptVersion niet ondersteund

statuscode 406 Not Acceptable

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

2

Het systeem controleert of er een access_token is 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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

3

Het systeem toetst of het ontvangen token een geldig AORTA access_token is op de wijze zoals beschreven in Toetsing AORTA access_token.

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.

  • In deze situatie mag daarnaast ook een OperationOutcome met issue.code "security" worden geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

4

Het systeem toetst of het verzoek voldoet aan de interface specificatie.

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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

5

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

6

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

Wijzigen Abonnement

Feature

updateSubscription

Type

Service

Versie

1.0.0

Groep

Notificatie

Gepubliceerd

Delta

Initiële versie van feature.

Use case

AOF.UC.ABR.300.v1

Feature

Versie

Dependency

Aanbieder

Afnemer

updateSubscription

1.0.0

core-FHIR-interactie-broker

*

*

updateSubscription

1.0.0

aorta-subscription

1.0

Deze interactie is gebaseerd op de FHIR conditional update interactie:

PUT [base]/Subscription?[parameters]

Ondersteunde parameters zijn:

Voorbeeld:

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

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

HTTP statuscodes die kunnen worden geretourneerd zijn:

Stap

Omschrijving

Uitkomst

1

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content of AORTA acceptVersion niet ondersteund

statuscode 406 Not Acceptable

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

Gehanteerd type content of AORTA contentVersion niet ondersteund

statuscode 415 Unsupported Media Type

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

2

Het systeem controleert of er een access_token is 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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

3

Het systeem toetst of het ontvangen token een geldig AORTA access_token is op de wijze zoals beschreven in Toetsing AORTA access_token.

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.

  • In deze situatie mag daarnaast ook een OperationOutcome met issue.code "security" worden geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

4

Het systeem toetst of het verzoek voldoet aan de interface specificatie.

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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

5

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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

6

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 het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "forbidden" geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

7

Het systeem toetst of de wijziging van het abonnement is toegestaan:

  • 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 aan het bestaande abonnement zijn niet toegestaan

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 het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "forbidden" geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

8

Het systeem verwerkt de wijziging.

9

<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.0

Groep

Notificatie

Gepubliceerd

Delta

Initiële versie van feature.

Use case

AOF.UC.ABR.400.v1

Feature

Versie

Dependency

Aanbieder

Afnemer

deleteSubscription

1.0.0

core-FHIR-interactie-broker

*

*

deleteSubscription

1.0.0

aorta-subscription

1.0

Deze interactie is gebaseerd op de FHIR conditional delete interactie:

DELETE [base]/Subscription?[parameters]

Ondersteunde parameters zijn:

Voorbeeld:

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

HTTP statuscodes die kunnen worden geretourneerd zijn:

Stap

Omschrijving

Uitkomst

1

Het systeem ontvangt een verzoek en start de verwerking.

Gevraagd type content of AORTA acceptVersion niet ondersteund

statuscode 406 Not Acceptable

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

2

Het systeem controleert of er een access_token is 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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

3

Het systeem toetst of het ontvangen token een geldig AORTA access_token is op de wijze zoals beschreven in Toetsing AORTA access_token.

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.

  • In deze situatie mag daarnaast ook een OperationOutcome met issue.code "security" worden geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

4

Het systeem toetst of het verzoek voldoet aan de interface specificatie.

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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

5

Het systeem toetst 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.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

6

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.

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 het een FHIR-request betreft, dan wordt in deze situatie (ook) een OperationOutcome met issue.code "forbidden" geretourneerd.

Het systeem genereert de vereiste foutresponse en gaat verder met de exit stap van de main flow.

7

Het systeem beëindigt het abonnement.

8

<exit>

Het systeem retourneert een response naar de primaire actor.

Verwerking succesvol

statuscode 200 OK

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

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:

  • Gegevenssoort van de betreffende VWI/ACT-entry OF contextcode (“gegevenssoort” of “contextcode” attribuut in _query)

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.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.