Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


...

001. Vervallen

...

#

Eis

FHIR service

Bron applicatie

Domein

001

De Subscriptions (abonnementen) werken zoals beschreven in de FHIR REST API en FHIR Subscription resource met uitzondering van de verdere eisen.

X

X


002

De Subscription.channel.type MOET als waarde rest-hook  hebben

X

X


003

De Subscription.channel.payload mag geen waarde hebben. Er mag geen payload gebruikt worden bij de Subscription of Notification.

X

X


004

Het gebruikte endpoint (Subscription.channel.endpoint)

...

003. Na goedkeuring wordt de Subscription.status op 'active' gezet . 

004. De volgende runtime validaties MOETEN worden uitgevoerd, voordat de notificatie wordt verstuurd:

a. de criteria van het abonnement (Subscription.criteria), moet aan de lees (READ) criteria van de Autorisatie Matrix voldoen.

005. De ontvanger van het Post bericht (notificatie) MOET een beveiligd URL (httpsSubscription.channel.endpoint) beschikbaar stellen voor ontvangst per type notificatie.

006. In de notificatie wordt er geen payload (body) meegestuurd. De payload is NIET aanwezig in het abonnement (zie: Subscription.channel.payload)

007. Aanbeveling, Voor het verder specificeren van notificaties voor de ontvanger, adviseren we unieke headers te definiëren en toe te voegen, bij het gebruik van het versturen van notificaties. Alleen op deze manier kan men een notificatie correleren aan één Subscription resource instantie (abonnement)

008. De applicaties mag alleen zijn eigen abonnementen wijzigen en/of verwijderen.

009. Domein beheerders mogen via het Beheerportaal abonnementen wijzigen en/of verwijderen.

Oude tekst

001. Een applicatie die het abonnement (Subscription resource) aanvraagt (requested), het registreren van een gebeurtenis, wordt de abonnement aanvrager genoemd.

002. Subscription resources (abonnementen) worden (standaard) door applicatie instanties aangevraagd, waarbij de Subscription.status op 'requested' wordt gezet. De volgende validatie moeten worden uitgevoerd:

a. criteria van het abonnement (Subscription.criteria), moet aan de lees (READ) criteria van de Autorisatie Matrix voldoen.

b. Voor Koppeltaal 2.0 wordt alleen het 'rest-hook' kanaal gebruikt (zie: Subscription.channel.type). Dit kanaal wordt gebruikt door een Post bericht (notificatie) naar een URL (Subscription.channel.endpoint) te sturen.

003. Na goedkeuring wordt de Subscription.status op 'active' gezet . 

004. De volgende runtime validaties MOETEN worden uitgevoerd, voordat de notificatie wordt verstuurd:

a. de criteria van het abonnement (Subscription.criteria), moet aan de lees (READ) criteria van de Autorisatie Matrix voldoen.

005. De ontvanger van het Post bericht (notificatie) MOET een beveiligd URL (httpsSubscription.channel.endpoint) beschikbaar stellen voor ontvangst per type notificatie.

006. In de notificatie wordt er geen payload (body) meegestuurd. De payload is NIET aanwezig in het abonnement (zie: Subscription.channel.payload)

007. Voor het verder specificeren van notificaties voor de ontvanger, adviseren we unieke headers te definiëren en toe te voegen, bij het gebruik van het versturen van notificaties. Alleen op deze manier kan men een notificatie correleren aan één Subscription resource instantie (abonnement)

008. De applicaties mag alleen zijn eigen abonnementen wijzigen en/of verwijderen.

...

moet een https endpoint zijn.

X

X


005

Indien de waarde van Subscription.criteria niet een valide search query is mag de FHIR Resource service deze afwijzen met een foutcode in de 400 range. 

X



006

Bij het notificeren van de abonnementen op de Subscription dient dezelfde logica toegepast te worden als bij search narrowing op de Subscription.criteria.

X



007

De in het notificatie request moeten de trace headers gevuld zijn. De X-Request-ID moet een nieuwe waarde hebben, de X-Correlation-ID moet de waarde hebben van het originele request dat de Subscription-activatie heeft veroorzaakt en het X-Trace-ID moet gevuld worden als deze in het originele request voorkomt of als de FHIR resource service ervoor kiest deze te vullen.

X



008

In de requests die de applicatie uitvoert in de context van de notificatie dienen de waarden gevuld te zijn met de waarden van de X-Request-ID en X-Trace-ID headers uit het notificatie request. Deze worden respectievelijk geplaatst in de X-Correlation-ID  en X-Trace-ID  headers.


X


009

De FHIR resource service moet een AuditEvent van het type transmit aanmaken bij het uitvoeren van de rest-hook met de waarden voor de tracing zoals deze in het request wordt meegezonden.

X



010

De ontvangende applicatie moet een AuditEvent van het type recieve bij het ontvangen van een notificatie met de waarden voor de tracing zoals deze in het request is ontvagen.


X


011

Indien er zich een probleem voordoet in de ontvangende applicatie bij de verwerking van de resources die voortkomen uit de notificatie moet de applicatie een AuditEvent aanmaken, zie voor details TOP-KT-012b - FHIR REST Client foutafhandeling.


X



{}