...
001. Voor Koppeltaal 2.0 wordt alleen het 'rest-hook' kanaal gebruikt (zie: Subscription.channel.type). Dit kanaal verstuurt een POST request naar een URL (Subscription.channel.endpoint).
002. De Subscription.channel.endpoint MOET een HTTPS endpoint bevatten.
003. In de notificatie wordt GEEN payload (body) meegestuurd. Het Subscription.channel.payload mag GEEN waarde bevatten.
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 (https - Subscription.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.
...
# | 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 | X | X | |
003 | De | X | X | |
004 | Het gebruikte endpoint ( | X | X | |
005 | Indien de waarde van | X | ||
006 | Bij het notificeren van de abonnementen op de Subscription dient dezelfde logica toegepast te worden als bij search narrowing op de | X | ||
007 | De in het notificatie request moeten de trace headers gevuld zijn. De | 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 | ||
009 | De FHIR resource service moet een AuditEvent van het type | X | ||
010 | De ontvangende applicatie moet een AuditEvent van het type | 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 |
{}