Inleiding

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

• het totaalperspectief, met zowel de happy flow als de uitzonderingen;
• het perspectief van de PGO Server (= OAuth Client), 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 Authorization Server/Subscription Server/Authentication 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 PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om zich bij een zekere Zorgaanbieder te Abonneren op Notificaties voor een bepaalde Gegevensdienst. Het gaat altijd om precies één Gegevensdienst. Uit de Zorgaanbiederslijst weet de PGO Server op welke Gegevensdiensten een Zorgaanbieder Abonnementen aanbiedt worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
2. De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een abonneer-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. De Authorization Server vraagt de Zorggebruiker via zijn PGO Presenter in te loggen.
5. Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de browser 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.
6. De Authentication Server vraagt van de Zorggebruiker via zijn PGO Presenter om inloggegevens.
7. Wanneer deze juist zijn, redirect de Authentication Server de OAuth User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken geeft de Authorization Server de Zorggebruiker alsnog de mogelijkheid via zijn PGO Presenter in te loggen.
8. Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.
9. Dan breekt het vroegste moment aan waarop de Authorization Server ervoor instaat dat de Zorgaanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Daarvan maakt deel uit dat de Persoon daarvoor minstens 16 jaar oud moet zijn.
10. Zo ja, dan presenteert de Authorization Server via de PGO Presenter aan Zorggebruiker de vraag of laatstgenoemde hem toestaat de gevraagde persoonlijke gezondheidsinformatie (Notificaties) aan de PGO Server (als OAuth Client) te sturen. Onder het flow-diagram staat gespecificeerd welke informatie, waarvandaan, de OAuth Authorization Server verwerkt in de aan Zorggebruiker voor te leggen Toestemmingsverklaring Abonneren.
11. Bij akkoord logt de Authorization Server dit als toestemming, 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.
12. De PGO Server vat niet alleen deze authorization code op als ophaalbewijs, maar leidt er ook uit af dat de toestemming is gegeven en logt het verkrijgen van het ophaalbewijs.
13. 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.
14. Daarop genereert de Authorization Server een access token en stuurt deze naar de PGO Server.
15. Nu is de PGO Server gereed om het verzoek tot vaststelling van het Abonnement naar de Subscription Server te sturen. Het adres van het subscription 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.
16. De Subscription Server controleert of het ontvangen token recht geeft op het gevraagde Abonnement. Dan breekt het uiterste moment aan waarop de Subscription Server ervoor moet instaan dat voor de betreffende Gegevensdienst de Zorgaanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Subscription Server deze ze in de subscription response naar de PGO Server. Is dat niet zo, dan breekt de Subscription Server de happy flow af.
17. De Subscription Server legt het Abonnement vast zodanig dat bij een optredende wijziging in de Gegevensdienst voor deze Persoon een Notificatie verstuurd kan worden (zie UCI Notificeren).
18. De PGO Server legt het Abonnement vast het Dossier van de Persoon.

In de regel worden bij een eenmalig gebruik van UCI Abonneren het authorization interface, het token interface en het subscription interface allemaal aangesproken, in die volgorde. Mocht de PGO Server echter nog beschikken over een nog niet verlopen access token voor de betreffende Zorgaanbieder-Gegevensdienst-Interfaceversie-combinatie, dan kan het onmiddellijk het subscription interface aanspreken.

Het MedMij Afsprakenstelsel adviseert de beschikbaarheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. Vooralsnog staat het MedMij Afsprakenstelsel toe die voorwaarde op een later moment van kracht te laten zijn, maar niet later dan het laatste in het figuur aangegeven moment.

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

Perspectief van de PGO Server

De PGO Server start de UC Abonneren. Via een redirect ontvangt hij een authorization code, waarmee hij een access token aanvraagt op het token interface. Na ontvangst van dat access token, spreekt hij de Subscription Server aan om de start, de wijziging of de beëindiging van het Abonnement te laten vaststellen.

Perspectief van de Authorization Server, Authentication Server en Subscription Server

De Authorization Server creëert op verzoek van de Zorggebruiker een sessie voor UC Abonneren en doorloopt de gebruikelijke authenticatie- en autorisatiestappen. Via een redirect ontvangt hij een authorization code, waarmee hij een access token aanvraagt op het token interface. Na ontvangst van dat access token, spreekt hij de Subscription Server aan om de start, de wijziging of de beëindiging van het Abonnement te laten vaststellen.

Perspectief van de Zorggebruiker

De Zorggebruiker selecteert de Zorgaanbieder en de Gegevensdienst waarop hij zich wenst te (her)abonneren, authenticeert zich en geeft Toestemming. Daarna tekent de PGO Server de abonnementswijziging (die hij heeft laten vaststellen door de Subscription Server) aan in het Dossier.

Frontchannel en backchannel

In onderstaand stroomschema van UCI Abonneren geven de dikke pijlen het MedMij-verkeer weer en zijn daarbinnen de vijf gevallen van frontchannel-verkeer (open pijlpunt) en vier gevallen van backchannel-verkeer (gesloten pijlpunt) aangegeven.