Inleiding

In de platen hieronder staat het stroomdiagram van de use case-implementatie UCI Notificeren, in vier perspectieven:

• het totaalperspectief, met zowel de happy flow als de uitzonderingen;
• het perspectief van de Notification Server, die onder de hoede van de Dienstverlener persoon valt. Laatstgenoemde kan deze plaat lezen als zijn verplichte aandeel in de use case-implementatie Abonneren;
• het perspectief van de Notification Client, die onder de hoede van de Dienstverlener zorgaanbieder valt. Laatstgenoemde kan deze plaat lezen als zijn verplichte aandeel in de use case-implementatie Abonneren;
• het perspectief van de Zorggebruiker (= OAuth Resource Owner).

De stroomdiagrammen tonen alleen de situatie waarin alle acties slagen tot en met het uiteindelijke aangaan van het Abonnement (de zogenaamde happy flow). De oranje banen horen, conform de MedMij-huisstijl tot het Persoonsdomein, de blauwe tot het Zorgaanbiedersdomein. Menige actie in de stroomdiagrammen is gekleurd weergegeven. De lichtgrijs gekleurde acties vormen samen de autorisatieflow volgens OAuth; de zachtgeel gekleurde acties vormen samen de authenticatieflow. Deze kleuren verwijzen dus alleen maar naar de gebruikte standaarden en zeggen niets over welke component de stap zou moeten uitvoeren. Authenticatie is dus ingebed in autorisatie. In de stroomdiagrammen voor de specifieke perspectieven hebben alleen de acties in de bij dat perspectief horende baan namen. De acties in de andere banen zijn gecomprimeerd en anoniem weergegeven.

Verantwoordelijkheden inzake uitzonderingen op de happy flow zijn opgenomen bij de respectievelijke interface, in tegenstelling tot op de Processen & Informatie-laag, waar de uitzonderingen bij de use cases zijn genoemd.

Totaalperspectief (happy flow)

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 Notification Client detecteert een inhoudelijke wijziging in de gezondheidsinformatie waarop Zorggebruiker een geldig Abonnement is aangegaan, respectievelijk de Notification Client detecteert dat de Zorgaanbieder een zeker abonnement beëindigt.
2. In beide gevallen bepaalt de Notification Client, o.b.v. de client_id die werd gebruikt bij het aangaan van het Abonnement, in de OAuth Client List het juiste Resource Notification Endpoint , respectievelijk Subscription Notification Endpoint.
3. De Notification Client stuurt subscription notification, respectievelijk resource notification naar de Notification Server.
4. De Notification Server controleert de Notificatie , laat deze eventueel aan de Zorggebruiker tonen, en verstuurt een antwoord naar de Notification Client.

Perspectief van de Notification Server

De Notification Server ontvangt een subscription notification of een resource notification en speelt deze mogelijk door aan de Zorggebruiker (PGO Presenter).

Perspectief van de Notification Client

De Notification Client detecteert een inhoudelijke wijziging, respectievelijk een abonnementswijziging, en stuurt een subscription notification, respectievelijk een resource notification, naar de Notification Server.

Perspectief van de Zorggebruiker

De PGO Presenter toont een subscription notification of een resource notification.

Frontchannel en backchannel

Beide soorten Notificaties betreffen backchannel-verkeer.