Toelichting

In de platen hieronder staat het stroomdiagram van de use case-implementatie Notificeren, in drie 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 Notificeren;
• 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 Notificeren.

De stroomdiagrammen tonen alleen de situatie waarin alle acties slagen (de zogenaamde happy flow). De drie oranje banen horen, conform de MedMij-huisstijl tot het Persoonsdomein, de twee blauwe tot het Zorgaanbiedersdomein. 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.

Toelichting

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  PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om een bepaalde Gegevensdienst met een zekere Zorgaanbieder te delen. Het gaat altijd om precies één Gegevensdienst (één scope, in OAuth-termen). Uit de Zorgaanbiederslijst weet de PGO Server welke Gegevensdiensten door een Zorgaanbieder aangeboden worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
2. De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een deel-verzoek sturen naar de Authorization Server . Het adres van het authorization endpoint komt uit de ZAL. De redirect URI geeft aan waarnaartoe de Authorization Server de OAuth User Agent verderop moet redirecten (met de authorization code).
3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
4. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de OAuth User Agent naar de Authentication Server te redirecten, onder meegeven van een redirect URI, die aangeeft waarnaartoe de Authentication Server straks de OAuth User Agent moet terugsturen, na het inloggen van de Zorggebruiker.
5. De Authentication Server vraagt van de Zorggebruiker via zijn PGO Presenter om inloggegevens.
6. Wanneer deze juist zijn, redirect de Authentication Server de OAuth User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs.
7. Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.
8. Dan breekt het vroegste moment aan waarop de Authorization Server ervoor instaat dat de Zorgaanbieder voor de betreffende Gegevensdienst überhaupt ontvankelijk is voor de gezondheidsinformatie van die Persoon, of anders de happy flow afbreekt. Daarvan maakt deel uit dat de Persoon daarvoor minstens 16 jaar oud moet zijn.
9. Zo ja, dan presenteert de Authorization Server via de PGO Presenter aan Zorggebruiker de vraag of laatstgenoemde bevestigt de gevraagde persoonlijke gezondheidsinformatie door de PGO Server (als OAuth Client) te laten aanbieden. Onder het stroomdiagram staat gespecificeerd welke informatie, waarvandaan, de OAuth Authorization Server verwerkt in de aan Zorggebruiker voor te leggen bevestigingsvraag.
10. Bij akkoord logt de Authorization Server dit als bevestiging, genereert een authorization code en stuurt dit als ophaalbewijs, door middel van een browser redirect met de in stap 1 ontvangen redirect URI, naar de PGO Server. De Authorization Server stuurt daarbij de local state-informatie mee die hij in de eerste stap van de PGO Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization code moet associëren.
11. De PGO Server vat niet alleen deze authorization code op als ophaalbewijs, maar leidt er ook uit af dat de bevestiging is gegeven en logt het verkrijgen van het ophaalbewijs.
12. Met dit ophaalbewijs wendt de PGO Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de OAuth User Agent, voor een access token.
13. Daarop genereert de Authorization Server een access token. Dan breekt het uiterste moment aan waarop de Authorization Server ervoor moet instaan dat voor de betreffende Gegevensdienst de Zorgaanbieder ontvankelijk is voor de gezondheidsgegevens van de betreffende Persoon. Is dat zo, dan verstuurt de Authorization Server het access token naar de PGO Server. Is dat niet zo, dan breekt de Authorization Server de happy flow af en stuurt zij geen access token naar de PGO Server.
14. Nu is de PGO Server gereed om de gezondheidsinformatie aan de Resource Server aan te bieden, nadat hij de gebruiker eventueel nog nadere keuzes heeft laten maken. Het adres van het resource endpoint haalt hij uit de ZAL. Hij plaatst het access token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.
15. De Resource Server controleert of het ontvangen token recht geeft op het aanbieden van de informatie, plaatst deze (al dan niet) bij achterliggende bestemmingen en verstuurt een antwoord in een FHIR-response naar de PGO Server.
16. Deze maakt hierover een aantekeningen bij de aangeboden gezondheidsinformatie in het persoonlijke dossier. Mocht de Gegevensdienst waartoe de Zorggebruiker heeft geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), plaatst de PGO Server daarna mogelijk opnieuw bij de Resource Server voor de nog resterende Transacties, eventueel na nieuwe interactie met de Zorggebruiker. Dat geldt ook voor de situatie waarin één Transactie, blijkens de betreffende Informatiestandaard, uit meerdere FHIR creates bestaat. Zolang het access token geldig is, kan datNotification Client detecteert een wijziging in (gezondheids)informatie waarop Zorggebruiker een Abonnement heeft genomen OF de Notification Client beëindigd, op eigen initiatief, een specifiek Abonnement.
17. De Notification Client bepaalt, 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 OF Subscription Notification Endpoint.
18. De Notification Client stuurt een Notificatie naar de Notification Server.
19. De Notification Server controleert de Notificatie en verstuurt een antwoord naar de Notification Client.