Versie 1.5.1
Zie ook de omgeving waarin voortaan de verplichte versie van het afsprakenstelsel staat
In de platen hieronder staat het stroomdiagram van 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 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.
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.
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 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.
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.
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 kan de identiteit van de Persoon niet vaststellen. | 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 stelt op enig moment namens Aanbieder vast dat niet wordt voldaan aan de beschikbaarheidsvoorwaarde. Hiervan is in elk geval sprake indien hetzij:
Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde. | ||
Abonneren 4 | Persoon geeft geen Toestemmingsverklaring Abonneren of Beëindigingsverklaring Abonnement af. | ||
Abonneren 5 | Dienstverlener aanbieder kan het antwoord op de toestemmingsvraag niet vaststellen. | 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 6 | 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 7 | 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. Persoon kan er ook voor kiezen toch in te loggen. In dat geval vraagt Dienstverlener aanbieder weer om credentials. |
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.
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:
redirect_uri
geeft aan waarnaartoe de Authorization Server de User Agent verderop moet redirecten (met de authorization code).redirect_uri
, die aangeeft waarnaartoe de Authentication Server straks de User Agent moet terugsturen, na het inloggen van de Persoon.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.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.
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.