Abonneren en Notificeren: Rollen, Functies, verantwoordelijkheden

Extensie Abonneren en Notificeren

Verantwoordelijkheden, Abonneren

Workflow komt als nieuwe functie binnen het Afsprakenstelsel en komt hiermee naast de bestaande functies te staan. Binnen workflow worden twee nieuwe processen voor abonneren en notificeren onderkent deze gaan op termijn de huidige versie van Abonneren en Notificeren vervangen.

Alle type Abonnementen en Notificaties in het kader van de functie Workflow worden gebaseerd op een generiek patroon. Voor deze taken komt een generiek FHIR R4B profiel.

Om de functie Workflow te ondersteunen in het MedMij afsprakenstelsel, is het noodzakelijk dat Persoon (tevens Uitvoerder) wordt genotificeerd wanneer een Aanbieder (tevens Aanvrager):

• een nieuwe taak voor haar heeft aangemaakt;

• wijzigingen heeft aangebracht in (de status, notities) van een bestaande taak.

Om te worden genotificeerd zal de Persoon zich moeten abonneren op notificaties betreffende een wijziging in een Task resource.

Een Abonnement zal altijd een relatie moeten hebben met de Persoon zelf. Het volgende criterium zal derhalve door een Procesbeheerder altijd worden toegevoegd aan een Abonnement door een Persoon:

• Persoon is Uitvoerder van tenminste één van de taken in de workflow. Een workflow bestaat uit één taak.

• Persoon neemt een abonnement op notificaties voor taak instanties die voldoen aan de voorgeschreven criteria.

• Een dergelijk abonnement eindigt niet automatisch na beëindiging van een taak.

We beschrijven in het afsprakenstelsel niet hoe een Aanbieder een abonnement kan nemen om genotificeerd te worden.

Gewijzigde rollen

De MedMij Core beschrijft rol Resource Server. Nauw gerelateerd aan deze rollen beschrijft deze extensie de gewijzigde rollen Subscription Server, Subscription Client, Notification Client en Notification Server.

• Subscription Server
  Als Dienstverlener aanbieder de functie Abonneren aanbiedt dan biedt deze een geautomatiseerde rol voor het namens Aanbieders aangaan van Abonnementen, bestaande uit Authorization Server en Subscription Server.

• Subscription Client
  Als Dienstverlener persoon de functie Abonneren aanbiedt dan biedt deze een geautomatiseerde rol voor het namens Personen aangaan van Abonnementen, genaamd Subscription Client.

• Notification Client
  De Dienstverlener persoon stelt, indien deze functie Notificeren aanbiedt, aan Aanbiedereen geautomatiseerde rol Notification Server ter beschikking, waarop de AanbiederNotificaties kan aanbieden.

Functies en gegevens

Op deze pagina staan de diagrammen behorende bij de functie Abonneren. De functie Abonneren hoort geheel bij de hoofdfunctie Regie. Zij omvat het aangaan, het veranderen van de duur en het beëindigen van Abonnementen. De diagrammen tonen allereerst de situatie waarin alle acties slagen tot en met het uiteindelijke afsluiten van een Abonnement (de zogenaamde happy flow). De oranje banen horen bij het Persoonsdomein, de blauwe bij het Aanbiedersdomein.

Businesslaag voor de functie Abonneren

In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de genoemde rollen.

De totale procesgang van de functie Abonneren kent de volgende stappen:

• De Dienstverlener persoon presenteert aan de Persoon de mogelijkheid om Abonnementen aan te gaan, aan te passen of te beëindigen.

• De Persoon selecteert voor het aangaan van een Abonnement expliciet de Aanbieder, en voor het aanpassen of beëindigen van het betreffende Abonnement. Het verzoek gaat naar de passende Dienstverlener aanbieder.

• De Dienstverlener aanbieder start het autorisatieproces.

• De Dienstverlener aanbieder laat de Persoon zich authenticeren en geeft autorisatie af aan de Dienstverlener persoon.

• Na de autorisatie kan de Dienstverlener persoon de Dienstverlener aanbieder vragen om diens vaststelling van het aangaan, aanpassen of beëindigen van het Abonnement.

• Bij ontvangst van het resultaat verwerkt de Dienstverlener persoon het nieuwe, aangepaste of beëindigde Abonnement in het persoonlijke Dossier.

• Bij de informatie wordt ook de meta-informatie opgeslagen die wordt bedoeld in verantwoordelijkheden core.logging.100 en core.logging.101.

Uitzonderingen op de Happy flow van de functie Abonneren

In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener aanbieder ontdekt. Ten alle tijden moet voorkomen worden dat de Dienstverlener persoon informatie over het bestaan van behandelrelaties verkrijgt zonder dat (al) bevestiging is gegeven door de Dienstverlener persoon.

Implementatie van de use case Abonneren onder Workflow

Verantwoordelijkheden inzake uitzonderingen op de happy flow zijn opgenomen bij de respectievelijke interface, waar de uitzonderingen bij de functies zijn genoemd.

In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.

De flow kent de volgende stappen:

1. De DVP Server start de flow door in de User Agent van de Persoon de mogelijkheid te presenteren om zich bij een zekere Aanbieder te Abonneren op Notificaties voor Taken. Het gaat altijd om precies één Taak.

2. De Persoon maakt expliciet zijn selectie en laat de User Agent een abonneer-verzoek sturen naar de Authorization Server.

3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.

4. De Dienstverlener aanbieder laat de Persoon zich authenticeren en geeft autorisatie af aan de Dienstverlener persoon.

5. Nu is de DVP Server gereed om het verzoek tot vaststelling van het Abonnement naar de Subscription Server te sturen. Hij plaatst het access-token in het bericht en zorgt ervoor dat in het bericht geen persoonsgegegevens (zoals bv. BSN) zijn opgenomen.

6. De Subscription Server controleert of het ontvangen token recht geeft op het gevraagde Abonnement.

7. De Subscription Server legt het Abonnement vast zodanig dat bij een optredende wijziging in de Taak voor deze Persoon een Notificatie verstuurd kan worden (zie functie Notificeren).

8. De DVP Server legt het Abonnement vast het Dossier van de Persoon.

In de regel worden bij een eenmalig gebruik van de functie Abonneren het authorization interface, het token interface en het subscription interface allemaal aangesproken, in die volgorde.

Bij de implementatie van de voorwaarde op beschikbaarheid bij de Aanbieder voor de te verzamelen taken is het zaak rekening te houden met privacy-vereisten. Wanneer de Dienstverlener aanbieder ten behoeve van de beschikbaarheidsvoorwaarde nieuwe gegevensverzamelingen zou aanleggen, vindt een verwerking altijd onder de verantwoordelijkheid van één Aanbieder plaats. Het combineren van verwerkingen of het onvoldoende segregeren moet worden vermeden. Afwijking hiervan is alleen mogelijk onder expliciete instructie van de Aanbieder(s) en vereist een zorgvuldige voorafgaande afweging, vanwege de daaraan verbonden privacyrisico's.

Businesslaag voor de functie Notificeren

Op deze pagina staan de stroomdiagrammen behorende bij de functie Notificeren. De oranje baan hoort (conform de MedMij-huisstijl) tot het Persoonsdomein, de blauwe tot het Aanbiedersdomein.

In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de genoemde rollen.

De totale procesgang van de functie Notificeren kent de volgende stappen:

• De Dienstverlener aanbieder detecteert een wijziging in een Taak waarop Persoon een Abonnement heeft genomen (een inhoudelijke wijziging).

• De Dienstverlener persoon toont de Persoon de Notificatie.

Uitzonderingen op de Happy flow van de functie Notificeren

In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener persoon ontdekt.

Implementatie van de use case Notificeren onder Workflow

Verantwoordelijkheden inzake uitzonderingen op de happy flow zijn opgenomen bij de respectievelijke interface, waar de uitzonderingen bij de functies zijn genoemd.

De flow kent de volgende stappen:

1. De Workflow Server informeert de Subscription Server over de nieuwe/gewijzigde Taak.

2. De Subscription Server doet een abonnementscheck om te controleren of er abonnementen actief zijn.

3. De Subscription Server kijkt bij de gevonden abonnementen of de wijziging in de Resource overeenkomt met de abonnementscriteria.

4. De Subscription Server stuurt een notificatie naar de Notification Client van de DVP. (Wanneer er een abonnement is, en de wijziging aan de criteria voldoet)

5. De Notification Client stuurt de notificatie door naar de DVP Server.

6. Optioneel: de DVP Server slaat de notificatie op in het dossier.

7. De DVP Server stuurt de notificatie door naar de User Agent.

8. De User Agent toont de notificatie aan de Persoon.

9. De Persoon opent de notificatie in de PGO.

Verantwoordelijkheden

Authorization Interface, Abonneren

De authorization interface hoort bij de hoofdfunctie Regie.

In dit hoofdstuk staan alleen de verantwoordelijkheden inzake de authorization interface die nog niet genoemd staan in de OAuth 2-specificatie. Deze verantwoordelijkheden vormen een uitbreiding op de al geldende verantwoordelijkheden voor de Authorization interface vanuit de MedMij Core.

In versie 0.8 (fase 2) zal het attribuut scope verbijzonderd worden.

Lijsten en Discovery zal hier impact op gaan hebben.

Subscription Interface

Het subscription interface hoort bij de hoofdfunctie Regie.

Er zijn drie typen subscription request:

• de subscription creation request voor het aanmaken van een nieuw Abonnement;

• de subscription modification request voor het wijzigen van de duur van een bestaand Abonnement;

• de subscription termination request voor het beëindigen van een bestaand Abonnement.

Met de subscription creation request biedt de DVP Server aan de Subscription Server een nieuwe Subscription-resource aan, die het Abonnement representeert, met daaraan verbonden het vooralsnog eenzijdige akkoord van de Persoon. Hij verzoekt daarmee bovendien om een subscription response, waarmee ook het akkoord van de Dienstverlener Aanbieder is verbonden. Zo ontstaat de overeenkomst.

Ook het aanpassen van de duur, via de einddatum parameter, van het Abonnement, door het versturen van een subscription modification request, ontvangt zo het akkoord van beide partijen.

Een beëindiging van een Abonnement, door het versturen van een subscription termination request, is een eenzijdige opzegging van de overeenkomst. De Dienstverlener Aanbieder mag deze niet weigeren en er is in die zin geen sprake van een akkoord van beide partijen.

Aanmaken van een abonnement (creation)

Voorbeeld van een subscription van een Uitvoerder:

{
  "resourceType": "Subscription",
  "status": "active",
  "criteria": "Task?_source=!12345&patient=12345&status!=completed,entered-in-error,
  "reason": "Notificeren van nieuwe taken",
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://patient-app.example.com/notifications",
    "payload": "application/fhir+json"
  },
  "end": "2025-12-31T23:59:59Z"
}

Na ontvangst van een subscription request, in de functie Workflow, zal de Subscription Server, indien in antwoord daarop een subscription response dient te worden gedaan, na maximaal zestig (60) seconden dit subscription response ter beschikking stellen aan de DVP Server. Dit gedrag van de Subscription Server is gedurende minimaal 98,5% van de tijd beschikbaar.

Zodra de Task resource is aangemaakt, wordt er via de eerder geconfigureerde Subscription een notificatie naar de patiënt gestuurd. Deze notificatie (Bundle) bevat informatie over de nieuwe taak, inclusief alle taakdetails.

Wijzigen van een abonnement (modification)

Bij een wijziging van het abonnement wordt de einddatum van het abonnement gewijzigd. De overige attributen worden hieronder niet genoemd. Dit is een HTTP PATCH-request.

Voorbeeld:

{
  "resourceType": "Subscription",
  "status": "active",
  "criteria": "Task?_source!=12345&patient=12345&status!=completed,entered-in-error,
  "reason": "Notificeren van nieuwe taken",
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://patient-app.example.com/notifications",
    "payload": "application/fhir+json"
  },
  "end": "2024-06-31T23:59:59Z"
}

Stopzetten van een abonnement (termination)

Dit is een HTTP DELETE-request zoals <base url>/Subscription/<subscription-id>.

Bij het verlopen van het Abonnement verstuurt de Subscription Server een notification naar de Notification Client van de Persoon.

Notification interface

Notificatie bundle na het aanmaken of wijzigen van een taak

Bij het ontvangen van een notification na het aanmaken van een nieuwe taak of het wijzigen van een bestaande taak zijn de volgende attributen inhoud van een Bundle met type: history.

Voorbeeld van een Bundle nadat de Zorgaanbieder een taak heeft aangemaakt of een wijziging heeft doorgezet:

POST /notify HTTP/1.1
Host: notification-server.example.com
Content-Type: application/fhir+json
Authorization: Bearer some-oauth-token

{
  "resourceType": "Bundle",
  "id": "bundle-004",
  "type": "history",
  "timestamp": "2024-08-21T11:00:00+01:00",
  "entry": [
    {
      "fullUrl": "https://fhir-server.example.com/fhir/Task/task-001",
      "resource": {
        "resourceType": "Task",
        "id": "task-001",
        "meta": {
          "versionId": "4",
          "lastUpdated": "2024-08-21T11:00:00Z",
          "source": "MedMijAanbieder"  // Belangrijk voor de ontvanger om te weten wie de wijziging heeft aangebracht
        },
        "status": "in-progress",
        "intent": "order",
        "description": "Deze taak betreft het dagelijks uitvoeren van een bloeddrukmeting."
      }
    }
  ]
}

Notification bundle na het verlopen van een abonnement

Bij het verlopen van een abonnement worden wel notificaties verzonden. De status van het abonnement is gewijzigd naar ‘off’.

Notification bundle na het annuleren van een abonnement

Bij het annuleren van een abonnement worden geen notificaties verzonden. De overweging hier is dat alleen een Persoon een abonnement kan starten en annuleren en deze Persoon is op de hoogte van het zelf stopzetten van het abonnement.

Subscription Notification interface

In het huidige afsprakenstelsel is er een Subscription Notification interface. Deze komt te vervallen en is vervangen door de Notification interface.

Resource Notification interface

In het huidige afsprakenstelsel is er een Resource Notification interface. Deze komt te vervallen en is vervangen door de Notification interface.

Schermen (User interface), Abonneren

In versie 0.8 komen er voorstellen voor de user interface betreffende de nieuwe invulling van de functie Abonneren.