Inleiding

In de platen hieronder staat het stroomdiagram van de functie Abonneren:

• De happy flow van de usecase Abonneren;
• De implementatie van de usecase Abonneren;
• De implementatie van het front- en backchannelverkeer.

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 stroomdiagrammen 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.

Usecase Abonneren

Menige actie in het stroomdiagram is gekleurd weergegeven. De lichtgrijs gekleurde acties vormen samen de autorisatieflow; de zachtgeel gekleurde acties vormen samen de authenticatieflow.

Omdat het stroomdiagram alleen de happy flow bevat, worden zijn daarna de uitzonderingen beschreven.

Stroomdiagram

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

De totale procesgang van de usecase 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 de specifieke Gegevensdienst, en voor het aanpassen of beëindigen het betreffende Abonnement. Daarvoor kunnen desgewenst de Gegevensdienstnamen worden gebruikt uit de Gegevensdienstnamenlijst. Het verzoek gaat naar de passende Dienstverlener aanbieder.
• De Dienstverlener aanbieder ontvangt de Persoon.
• De Dienstverlener aanbieder authentiseert de Persoon.
• Wanneer de Persoon de authenticatie heeft afgebroken geeft de Dienstverlener aanbieder de mogelijkheid alsnog te authenticeren of de flow af te breken.
• Indien het gaat om het aangaan of aanpassen van een Abonnement, breekt dan het moment aan waarop de Dienstverlener aanbieder op zijn vroegst ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Het MedMij Afsprakenstelsel adviseert de beschikbaarheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. In deze release staat het MedMij Afsprakenstelsel het toe die voorwaarde op een later moment van kracht te laten zijn, maar niet later dan het laatste in het figuur aangegeven moment. Het beëindigen van een Abonnement mag de Aanbieder niet weigeren.
• De Dienstverlener aanbieder vraagt aan de Persoon of hij toestemming geeft tot het verstrekken van de gevraagde informatie aan de Dienstverlener persoon. Deze vraag staat op de pagina Toestemmingsverklaring Abonneren. Indien het om de beëindiging van een abonnement gaat, staat de juiste informatie op de pagina Beëindigingsverklaring Abonnement.
  
• De Dienstverlener aanbieder logt die toestemming en laat de Dienstverlener persoon weten dat de toestemming gegeven is.
• Nu kan de Dienstverlener persoon de Dienstverlener aanbieder vragen om diens vaststelling van het aangaan, aanpassen of beëindigen van het Abonnement.
• Indien het gaat om het aangaan of aanpassen van een Abonnement, zal uiterlijk na de ontvangst van het verzoek de Dienstverlener aanbieder ervoor instaan dat de Aanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreken.
• 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, core.logging.101 en core.logging.102
  

De beschikbaarheidsvoorwaarde hoort bij Regie, niet bij Uitwisseling. De voorwaarde geeft de Aanbieder ruimte om deel te nemen in aan de Persoon gegeven Regie. Omdat echter bestaande implementatie-architecturen veelal uitwisseling centraal zetten, en niet Regie, hebben zij moeite de beschikbaarheidsvoorwaarde in de regiefase te implementeren. Daarom biedt het MedMij Afsprakenstelsel vooralsnog de gelegenheid om deze in de uitwisselingsfase te implementeren.

Uitzonderingen op de Happy flow van de usecase

In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener aanbieder ontdekt. Om te voorkomen dat de Dienstverlener persoon informatie over het bestaan van behandelrelaties verkrijgt zonder dat daarvoor (al) toestemming is gegeven, moet het onderscheid tussen de uitzonderingen 2, 3 en 4 niet te maken zijn door de Dienstverlener persoon.

Of de Aanbieder de gevraagde gezondheidsinformatie beschikbaar stelt aan de Persoon, is om te beginnen een zaak tussen de Aanbieder en Persoon, die daarvoor een behandelrelatie moeten hebben. Gegeven zo'n behandelrelatie is er wetgeving van toepassing op deze terbeschikkingstelling. Daarbinnen is eigen beslisruimte voor de Aanbieder. Omdat Aanbieder en Persoon evenwel geen Deelnemers in het MedMij Afsprakenstelsel zijn, specificeert het MedMij Afsprakenstelsel niet de exacte logica van de beslissing om de gezondheidsinformatie al dan niet ter beschikking te stellen. Om privacy-redenen vereist het MedMij Afsprakenstelsel echter wel dat er een behandelrelatie moet (hebben) bestaan waarbij de betreffende gezondheidsinformatie hoort én dat de Persoon minstens zestien jaar oud is (zie uitzondering Abonneren 3).

Voor het verstrekken van gegevens aan een minder dan zestienjarige moet toestemming of een machtiging tot toestemming worden verleend door degene die de ouderlijke verantwoordelijkheid of de wettelijke verantwoordelijkheid voor de minder dan zestienjarige draagt. Omdat in dergelijke toestemmingen of machtigingen nog niet is voorzien in deze versie van het MedMij afsprakenstelsel, kan deze controle vooralsnog als onderdeel van de beschikbaarheidsvoorwaarde worden opgevat. Wanneer een toekomstige release van het MedMij afsprakenstelsel wel zulke toestemmingen of machtigingen omvat, zal de leeftijdsvoorwaarde gescheiden moeten worden van de beschikbaarheidsvoorwaarde.

Implementatie van de usecase Abonneren

Menige actie in het stroomdiagram 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.

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

Stroomdiagram

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 een bepaalde Gegevensdienst. Het gaat altijd om precies één Gegevensdienst. Uit de Aanbiederslijst weet de DVP Server op welke Gegevensdiensten een Aanbieder Abonnementen aanbiedt worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
2. De Persoon maakt expliciet zijn selectie en laat de User Agent een abonneer-verzoek sturen naar de Authorization Server. Het adres van het authorization endpoint komt uit de Aanbiederslijst. De redirect_uri geeft aan waarnaartoe de Authorization Server de 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 Persoon via zijn User Agent 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 User Agent moet terugsturen, na het inloggen van de Persoon.
6. De Authentication Server vraagt van de Persoon via zijn User Agent om inloggegevens.
7. Wanneer deze juist zijn, redirect de Authentication Server de User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken geeft de Authorization Server de Persoon alsnog de mogelijkheid via zijn User Agent 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 Aanbieder 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 User Agent aan Persoon de vraag of laatstgenoemde hem toestaat de gevraagde persoonlijke gezondheidsinformatie (Notificaties) aan de DVP Server (als OAuth Client) te sturen. Onder het flow-diagram staat gespecificeerd welke informatie, waarvandaan, de OAuth Authorization Server verwerkt in de aan Persoon voor te leggen Toestemmingsverklaring Abonneren of Beëindigingsverklaring Abonnement.
    
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 DVP Server. De Authorization Server stuurt daarbij de local state-informatie mee die hij in de eerste stap van de DVP Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization code moet associëren.
12. De DVP 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 DVP Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de User Agent, voor een access token.
14. Daarop genereert de Authorization Server een access token en stuurt deze naar de DVP Server.
15. Nu is de DVP 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 Aanbiederslijst. 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 Aanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Subscription Server deze ze in de subscription response naar de DVP 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 functie Notificeren).
18. 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. Mocht de DVP Server echter nog beschikken over een nog niet verlopen access token voor de betreffende Aanbieder-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 Aanbieder voor de te verzamelen gezondheidsgegevens 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.

Front- en backchannel

In ovenstaand stroomschema 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.