Abonneren

Inleiding

Op deze pagina staan de diagrammen behorende bij de functie Abonneren. 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 diagrammen 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.

Businesslaag

In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de genoemde rollen.
De totale procesgang van de functie 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 start het autorisatieproces.
- De Dienstverlener aanbieder laat de Persoon zich authenticeren en geeft autorisatie af aan de Dienstverlener persoon.
- Na de autorisatie 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 en core.logging.101.

Uitzonderingen op de Happy flow van de functie Abonneren

In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener aanbieder ontdekt. Ten alle tijden moet voorkomen worden dat de Dienstverlener persoon informatie over het bestaan van behandelrelaties verkrijgt zonder dat (al) bevestiging is gegeven door de Dienstverlener persoon.

nr.	uitzondering	actie	vervolg
Abonneren 1	Dienstverlener aanbieder vindt het ontvangen verzoek ongeldig.	Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoon hierover.	Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
Abonneren 2	Dienstverlener aanbieder stelt op enig moment namens Aanbieder vast dat niet wordt voldaan aan de beschikbaarheidsvoorwaarde. Hiervan is in elk geval sprake indien hetzij: er geen behandelrelatie is aan te wijzen als grondslag voor het verzamelen; Persoon nog geen zestien jaar oud is. Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.	Dienstverlener aanbieder informeert Dienstverlener persoon dat verzoek niet wordt ingewilligd.	Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
Abonneren 3	Dienstverlener aanbieder kan, zelfs na toestemming, de gezondheids- of Abonnements-informatie alsnog niet ter beschikking stellen aan de Dienstverlener persoon.	Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoon hierover, met opgave van oorzaak.	Mocht de gezondheidsinformatie deels wel (geautoriseerd) ter beschikking staan, dan kan de flow dat nog verzorgen.
Abonneren 4	Persoon annuleert het inloggen.	Dienstverlener aanbieder presenteert een annuleringspagina en biedt Persoon de optie om toch in te loggen.	Indien Persoon kiest niet in te willen loggen, kan het scherm gesloten worden. De flow wordt gestopt. Persoon kan er ook voor kiezen toch in te loggen. In dat geval vraagt Dienstverlener aanbieder weer om credentials.

Implementatie van de usecase Abonneren

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

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:

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.
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). Binnen het autorisatieproces valt ook het eerst mogelijke moment waarop de Dienstverlener aanbieder moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft.
Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
De Dienstverlener aanbieder laat de Persoon zich authenticeren en geeft autorisatie af aan de Dienstverlener persoon.
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.
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.
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).
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.

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.