Skip to main content

POC TTA Notifications v0.6

Status: opdracht gegeven, uitvoering te plannen door het COT Opdrachtgever: Steven van der Vegt, coördinator Kring Techniek Uitvoering: COT, subkring knooppunt Type: operationele opdracht van de coördinator, ter mededeling in de kringvergadering

Wat

Bouw een proof of concept van de TTA Notifications v0.6 in het knooppunt, op een losse branch. De nadruk ligt op het beantwoorden van de onderzoeksvragen, niet op de code. De code is wegwerpcode en hoeft niet aan de gebruikelijke kwaliteitseisen te voldoen. Of en in welke vorm het naar main gaat, besluiten we daarna op basis van de conclusies.

De POC implementeert beide rollen uit de TTA:

  • Subscription Server (verzendende kant): Subscriptions voor een vooraf afgesproken SubscriptionTopic, zowel in-band (POST door de client) als out-of-band (aangemaakt door de server); handshake-notification met status requested naar active; event-notifications met oplopende event-number; heartbeat-notification; de $status en $events operaties en read/search op Subscription; retry met exponential backoff; OperationOutcome bij fouten.
  • Subscription Client (ontvangende kant): notificatie-endpoint dat handshake, event en heartbeat ontvangt; continuïteitscheck op event-number; detectie van gemiste heartbeat en opvragen van $status of $events; idempotente verwerking.
  • Payloadmodes empty en id-only. Full-resource valt buiten de POC omdat die niet bij het notified-pullpatroon hoort.
  • Voorbeeld: een SubscriptionTopic op Task, zodat het aansluit bij de eOverdracht.
  • Logging van verzonden en ontvangen subscriptions en notificaties.

Optionele features en permutaties. De TTA laat een aantal keuzes open: in-band of out-of-band, heartbeat wel of niet, $events wel of niet, empty of id-only. Optionele features zijn meestal het resultaat van een onderhandeling waarin de ene partij iets belangrijk vond en de andere niet. De vraag is wat er gebeurt als die twee partijen samen gaan uitwisselen. Onderdeel van de opdracht is daarom de combinaties van deze keuzes te beproeven tussen een server en een client die verschillende keuzes maken. Als dat in code te duur wordt, mag het in de analyse worden afgehandeld, met per combinatie wat er volgens de spec zou moeten gebeuren en waar de spec dat open laat.

De TTA werkt authenticatie en autorisatie niet uit. Voor de POC mogen die worden gemockt, maar het is wel een onderzoeksvraag.

Waarom

  1. Feedback op de specificatie naar Twiin. Wij schrijven mee aan de harmonisatie van de TA Notified Pull en de TTA Notifications is daar het eerste resultaat van, zie Harmonisatie TA Notified Pull. Een implementatie is de snelste manier om te zien of de specificatie volledig en consistent is. De bevindingen brengen we in via de subwerkgroep en de consultatie van Twiin najaarsrelease 1.6.
  2. Input voor de toepassingen. De toepassingen (eOverdracht voorop) moeten een impactanalyse doen op de nieuwe TTA. Een referentie in het knooppunt laat zien wat er op hen afkomt en wat het knooppunt daarvan voor hen kan afvangen.

Onderzoeksvragen

  1. Is de specificatie volledig en correct? Waar loop je vast, waar moet je zelf een keuze maken die de spec had moeten maken, waar spreekt de spec zichzelf tegen?
  2. Hoeveel werk is het om te implementeren?
  3. Hoeveel werk neemt een referentie-implementatie in het knooppunt de implementator uit handen? Is de abstractie voldoende, of bouw je alsnog alles in je eigen applicatie? Wat beheert het knooppunt (subscriptionstate, event-numbers, retry, heartbeats) en wat blijft bij de toepassing?
  4. Op welke onderdelen helpt de knooppunt-implementatie je concreet, en op welke niet?
  5. Hoe past authenticatie en autorisatie in ons model? Waar landen de verplichte autorisatie- en consentchecks (voor activatie en voor iedere notificatie) in het knooppunt, en hoe verhoudt de mTLS-eis uit de TTA zich tot ons model? Is de autorisatiehint uit de huidige Twiin TA NP een zinvol onderdeel van de notificatie?
  6. Optionele features. Wat gebeurt er als server en client verschillende keuzes maken op de optionele onderdelen? Waar gaat het mis en zegt de spec daar iets over?
  7. FHIR-versie. De TTA schrijft R4 of R4B voor voor het subscriptionframework. De eOverdracht zit op STU3. Werkt het framework naast STU3-resources, en wat betekent dat voor een toepassing?
  8. Id-only eisen. De TTA stelt eisen aan resource-identifiers (stabiel, opaak, onvoorspelbaar). Voldoen de identifiers die onze toepassingen en gangbare FHIR-servers nu uitgeven daaraan? Zo niet, wat is de consequentie?
  9. Adressering. Hoe lost het knooppunt het notificatie-endpoint en het Subscription-endpoint op via GF Adressering (mCSD, Endpoint met payloadType Subscription)?
  10. Verschil met nu. Wat is het verschil met de huidige eOverdracht-notificatie en met de Nuts-variant van de TA NP, en wat is grofweg het migratiepad?

Wanneer

  • Start: na het COT-planningsoverleg van 7 september 2026.
  • Tijdsbesteding: 5 werkdagen, waarvan 3 voor de code en 2 voor de verslaglegging.
  • Oplevering: voorstel 21 september, zodat de bevindingen ruim voor het einde van de consultatie (30 oktober) bij Twiin liggen en de toepassingen ze kunnen gebruiken. Het COT geeft aan of dat haalbaar is.
  • Evaluatie: bij de demo bespreken we of de POC in enige vorm naar main gaat en of er vervolgwerk nodig is.

Wie

  • Uitvoering: te bepalen door het COT in het planningsoverleg.
  • Opdrachtgever en aanspreekpunt voor vragen over de specificatie en de werkgroep: Steven van der Vegt.
  • Terugkoppeling aan: Kring Techniek (mededeling), subwerkgroep TA NP (bevindingen), werkgroep Technische Convergentie (conclusie voor de toepassingen).

Waar

  • Code: losse branch in de knooppunt-repository.
  • Rapportage: deelbare documenten, zie resultaat.
  • Demo: in het COT, met de subwerkgroep TA NP en de werkgroep Technische Convergentie als genodigden.
  • Budget: integratiefaseplan, activiteit A (specsturing en consultatierespons). Als A te krap blijkt, wordt activiteit B als terugvaloptie in het CCT besproken.

Resultaat

  1. Werkende POC op een branch, beide rollen, demonstreerbaar.
  2. Een demo.
  3. Een deelbaar bevindingendocument met antwoorden op de onderzoeksvragen, met twee delen: fouten en gaten in de specificatie (naar Twiin) en implementatie-impact (naar de toepassingen).
  4. Een korte conclusie voor de werkgroep Technische Convergentie als input voor de impactanalyse van de toepassingen.

Samenhang met andere trajecten

Bronnen

Wat Waar
TTA Notifications v0.6 ontwikkelsupplement.twiin.nl
Concept notified-pull-specificatienotificatiespecificatie in de generieke-functies-IG build.fhir.org
Integratiefase: plan en budget, mei 2026 Google Doc
Oproep aan de eOverdracht-deelnemers over de impactanalyse, augustus 2026 Slack, #kring-toepassingen
Back to top