Inleiding
...
- Voor de start van de usecase zou de Persoon moeten kunnen volstaan met het aanwijzen van die informatie in zijn Dossier die hij zou willen delen met een nader te benoemen Persoon, en er daarbij vanuit mogen gaan dat de Dienstverlener persoon daarbij weet welke Gegevensdienst daarbij aan de orde is.
- In tegenstelling tot in de functie Verzamelen moet Persoon moet de Aanbiederin de gelegenheid worden gesteld om zich al dan niet open te stellen voor ontvangst van de betreffende informatie. De Dienstverlener aanbiedermoet na authenticatie van de Persoon kunnen bepalen of de betreffende informatie welkom is bij de betreffende Aanbieder. Deze controle op de ontvankelijkheid zal geautomatiseerd plaatsvinden, met het oog op de synchrone gebruikservaring, maar de wijze van implementatie wordt vrijgelaten.
- Juridisch gezien is er geen expliciete toestemming van de Persoonvereist aan de Aanbiedervoor het mogen ontvangen van de gezondheidsinformatie; die volgt uit de verstrekking door de Persoon. Er zijn wel toestemmingsvereisten in de relatie Persoon-Dienstverlener persoon(inzake het mogen verstrekken van de gezondheidsinformatie), maar daarop ziet reguliere wet- en regelgeving toe. Niettemin wordt er, net als in de functie Verzamelen, om een bevestiging gevraagd van de Persoon.
- Aan het eind van de usecase wordt, indien de Aanbiederervoor ontvankelijk bleek, de betreffende informatie door de Dienstverlener persoongeplaatst bij de Aanbieder, via de Dienstverlener aanbieder. Net zoals in de functie Verzamelen geen nadere eisen worden gesteld aan hoe het ophalen van de informatie door de Dienstverlener aanbiederbij de Aanbiedergeschiedt, geldt dat in de functie Delen ook voor de plaatsing. Van belang is slechts dat de Persoonervan kan uitgaan dat de Aanbiederkennis kan hebben genomen van de betreffende informatie. Hoe dat wordt geborgd is niet triviaal, maar wordt gelaten aan de voorzieningen die de Dienstverlener aanbieder treft en de Dienstverleningsovereenkomst die hij dienaangaande aangaat met de Aanbieder.
...
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
...
- De Dienstverlener persoonpresenteert aan de Persoonde mogelijkheid om te delen.
- De Persoonkiest de Aanbiederwaarmee hij de informatie wenst te delen en de Gegevensdienst. 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 laat de Persoon zich authenticeren.
- Wanneer de Persoon de authenticatie heeft afgebroken geeft de Dienstverlener aanbieder de mogelijkheid alsnog te authenticeren of de flow af te breken.
- Dan breekt het moment aan waarop de Dienstverlener aanbiederop zijn vroegst ervoor instaat dat de Aanbiedervoor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon wenst te ontvangen, of anders de happy flow afbreekt. Het MedMij Afsprakenstelsel adviseert de ontvankelijkheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. Vooralsnog 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.
- De Dienstverlener aanbiedervraagt aan de Persoonof hij de wens bevestigt de informatie te laten verstrekken aan de Aanbieder. De vraag die hiervoor aan de Persoongesteld moet worden staat op de pagina Bevestigingsverklaring.
- De Dienstverlener aanbiederlogt die bevestiging en laat de Dienstverlener persoonweten of die geslaagd is.
- Voordat de flow dan wordt overgegeven aan de Dienstverlener persoon zal de Dienstverlener aanbieder ervoor instaan dat de Aanbiedervoor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon wenst te ontvangen, of anders de happy flow afbreken.
- Nu kan de Dienstverlener persoonde gezondheidsinformatie plaatsen bij de Dienstverlener aanbieder.
- Mocht de Gegevensdienst waartoe de Persoonheeft geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), plaatst de Dienstverlener persoondaarna mogelijk opnieuw bij de Dienstverlener aanbiedervoor de nog resterende Transacties, eventueel na nieuwe interactie met de Persoon.
- De Dienstverlener persoon tekent bij de informatie ook de meta-informatie aan die wordt bedoeld in verantwoordelijkheid 19 van de Processen- en Informatielaag.
De ontvankelijkheidsvoorwaarde is een aspect van de regie, niet van de 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. Deelnemers wordt echter aangeraden om, met het oog op de toekomst, in hun implementatie-architecturen een passend onderscheid tussen regie en uitwisseling te maken en de eerste geleding de tweede te laten sturen.
...
In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener aanbiederontdekt. Om te voorkomen dat de Dienstverlener persooninformatie over het bestaan van behandelrelaties verkrijgt zonder dat (al) bevestiging is gegeven, moet het onderscheid tussen de uitzonderingen 2, 3 en 4 niet te maken zijn door de Dienstverlener persoon.
| nr. | uitzondering | actie | vervolg |
|---|---|---|---|
| nr. | uitzondering | actie | vervolg |
| UC Delen 1 | Dienstverlener aanbieder vindt het ontvangen verzoek ongeldig. | Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoonhierover. | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. |
| UC Delen 2 | Dienstverlener aanbieder kan de identiteit van de Persoonniet vaststellen. | Dienstverlener aanbieder informeert Dienstverlener persoon dat delen niet toegelaten wordt. | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. |
| UC Delen 3 | Dienstverlener aanbieder stelt op enig moment vast dat betreffende informatie van Persoon bij Aanbieder niet welkom is. Hiervan is in elk geval sprake indien hetzij:
Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde. | ||
| UC Delen 4 | De bevestiging wordt niet gegeven. | ||
| UC Delen 5 | Dienstverlener aanbieder kan het antwoord op de bevestigingsvraag niet vaststellen. | Dienstverlener aanbieder informeert Dienstverlener persoon over deze uitzondering. Dienstverlener persoon informeert daarop Persoonhierover. | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. |
| UC Delen 6 | Dienstverlener persoon kan, zelfs na bevestiging, de gezondheidsinformatie alsnog niet plaatsen bij Dienstverlener aanbieder. | Dienstverlener persoon informeert daarop Persoonhierover, met opgave van oorzaak. | Mocht gezondheidsinformatie deels wel (geautoriseerd) geplaatst kunnen worden, dan kan de flow dat nog verzorgen. |
| UC Delen 7 | Persoon annuleert het inloggen. | Dienstverlener aanbieder presenteert een annuleringspagina en biedt Persoonde optie om toch in te loggen. | Indien Persoonkiest niet in te willen loggen, kan het scherm gesloten worden. Persoonkan 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 2; 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
IKdkaHY4zuAWgsnGIEO3-1Inc drawio border false pageId 82253822 diagramDisplayName lbox true diagramName Delen aspect VWMkXXox1a1iX5rb695w
trueincludedDiagram 1 simpleViewer
600false width
3f692057ecc54ce52954fdbf865ecba1723cc626400 aspectHash aaa03f115d781c33340d0a4332c5c055665fe154 links auto tbstyle top
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
...
- De DVP Server start de flow door in de User Agent van de Persoon de mogelijkheid te presenteren om een bepaalde Gegevensdienst met een zekere Aanbieder te delen. Het gaat altijd om precies één Gegevensdienst (één scope, in OAuth-termen). Uit de Aanbiederslijst weet de DVP Server welke Gegevensdiensten door een Aanbieder.
- aangeboden worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
- De Persoon maakt expliciet zijn selectie en laat de User Agent een deel-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 Agentverderop moet redirecten (met de authorization code).
- Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
- De Authorization Server vraagt de Persoon via zijn User Agent in te loggen.
- Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de User Agent 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.
- De Authentication Server vraagt van de Persoon via zijn User Agent om inloggegevens.
- 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.
- Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.
- Dan breekt het vroegste moment aan waarop de Authorization Server ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst überhaupt ontvankelijk is voor de gezondheidsinformatie van die Persoon, of anders de happy flow afbreekt. Daarvan maakt deel uit dat de Persoon daarvoor minstens 16 jaar oud moet zijn.
- Zo ja, dan presenteert de Authorization Server via de User Agent aan Persoon de vraag of laatstgenoemde bevestigt de gevraagde persoonlijke gezondheidsinformatie door de DVP Server (als OAuth Client) te laten aanbieden. Onder het stroomdiagram staat gespecificeerd welke informatie, waarvandaan, de OAuth Authorization Server verwerkt in de aan Persoon voor te leggen bevestigingsvraag.
- Bij akkoord logt de Authorization Server dit als bevestiging, 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.
- De DVP Server vat niet alleen deze authorization code op als ophaalbewijs, maar leidt er ook uit af dat de bevestiging is gegeven en logt het verkrijgen van het ophaalbewijs.
- 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.
- Daarop genereert de Authorization Server een access token. Dan breekt het uiterste moment aan waarop de Authorization Server ervoor moet instaan dat voor de betreffende Gegevensdienst de Aanbieder ontvankelijk is voor de gezondheidsgegevens van de betreffende Persoon. Is dat zo, dan verstuurt de Authorization Server het access token naar de DVP Server. Is dat niet zo, dan breekt de Authorization Server de happy flow af en stuurt zij geen access token naar de DVP Server.
- Nu is de DVP Server gereed om de gezondheidsinformatie aan de Resource Server aan te bieden, nadat hij de gebruiker eventueel nog nadere keuzes heeft laten maken. Het adres van het resource 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.
- De Resource Server controleert of het ontvangen token recht geeft op het aanbieden van de informatie, plaatst deze (al dan niet) bij achterliggende bestemmingen en verstuurt een antwoord in een FHIR-response naar de DVP Server.
- Deze maakt hierover een aantekeningen bij de aangeboden gezondheidsinformatie in het persoonlijke dossier. Mocht de Gegevensdienst waartoe de Persoon heeft geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), plaatst de DVP Serverdaarna mogelijk opnieuw bij de Resource Server voor de nog resterende Transacties, eventueel na nieuwe interactie met de Persoon. Dat geldt ook voor de situatie waarin één Transactie, blijkens de betreffende Informatiestandaard, uit meerdere FHIR creates bestaat. Zolang het access token geldig is, kan dat.
In de regel worden bij een eenmalig gebruik van de functie Delen het authorization interface, het token interface en het resource 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-combinatie, dan kan het onmiddellijk het resource interface aanspreken.
...
Technologielaag
| Inc drawio | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
In bovenstaand 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.
...