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 Abonnement op notificaties te nemen voor een bepaalde Gegevensdienst bij een zekere Zorgaanbieder te verzamelen. 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 en of hierbij ook de optie wordt geboden om een Abonnement op notificaties te nemen. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
2. De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een verzamelabonnement-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 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.
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 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.Zo ja, dan betreffende Gegevensdienst überhaupt een Abonnement van die Persoon mag en wenst te ontvangen, door toetsing van de ontvankelijkheidsvoorwaarde.
9. Dan presenteert de Authorization Server via de PGO Presenter aan Zorggebruiker de vraag of laatstgenoemde hem toestaat de gevraagde persoonlijke gezondheidsinformatie notificaties m.b.t. de gekozen Gegevensdienst 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 autorisatievraagNotification Server te sturen.
10. 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.
11. 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.
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 en stuurt deze naar de PGO Server.
14. Nu is de PGO Server gereed om het verzoek om de gezondheidsinformatie voor een Abonnement naar de Resource Subscription Server te sturen, nadat hij de gebruiker eventueel nog nadere keuzes heeft laten maken. Het adres van het resource 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.
15. De Resource Subscription Server controleert of het ontvangen token recht geeft op de gevraagde resources, haalt deze (al dan niet) bij achterliggende bronnen ophet plaatsen van het beoogde Abonnement. Dan breekt het uiterste moment aan waarop de Resource Subscription Server ervoor moet instaan dat dat de Zorgaanbieder voor de betreffende betreffende Gegevensdienst überhaupt een de Zorgaanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Resource Server deze ze in een FHIR-response naar de PGO Server. Is dat niet zo, dan breekt de Resource Server de happy flow af.Deze bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. Mocht de Gegevensdienst waartoe de Zorggebruiker heeft geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), of mocht één Transactie volgens de betreffende Informatiestandaard uit meerdere requests bestaan, bevraagt de PGO Server de Resource Server daarna mogelijk opnieuw voor de nog resterende Transacties, eventueel na nieuwe interactie met de Zorggebruiker. Zolang het access token geldig is, kan datAbonnement van die Persoon mag en wenst te ontvangen.
16. De Subscription Server slaat het Abonnement op en retourneert een antwoord aan de PGO Server.
17. De PGO Server slaat het Abonnement op.

In de regel worden bij een eenmalig gebruik van UCI Verzamelen Abonneren het authorization interface, het token interface en het resource subscription interface allemaal aangesproken, in die volgorde. Mocht de PGO Server echter nog beschikken over een nog niet verlopen access token voor een Abonnement voor de betreffende Zorgaanbieder-Gegevensdienst-combinatie, dan kan het onmiddellijk het resource 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'ssubscription interface aanspreken.