Inleiding

In de stroomdiagrammen van de functie Verzamelen is vertegenwoordiging toegevoegd:

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

De stroomdiagrammen tonen alleen de situatie waarin alle acties slagen tot en met het uiteindelijke verzamelen van de gezondheidsinformatie (de zogenaamde happy flow). De oranje banen horen, conform de MedMij-huisstijl tot het Persoonsdomein, de blauwe tot het Aanbiedersdomein.

Usecase Verzamelen

De acties in het stroomdiagram zijn soms gekleurd weergegeven. De lichtgrijs gekleurde acties vormen samen de autorisatieflow; de zachtgeel gekleurde acties vormen samen de authenticatieflow; de oranje gekleurde acties zijn toegevoegd ten behoeve van vertegenwoordiging.

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

Stroomdiagram

 Toelichting

De uitbreiding op het stroomdiagram van de functie Verzamelen, ten behoeve van vertegenwoordiging, is in oranje aangegeven. De extra stappen zijn:

• De Persoon geeft bij starten van de flow aan of hij informatie wil verzamelen van zichzelf of voor een ander. In het laatste geval is er sprake van vertegenwoordiging en is de Persoon dus de Vertegenwoordiger
• De Dienstverlener aanbieder laat de Vertegenwoordiger na authenticatie de Vertegenwoordigde selecteren
• De Dienstverlener aanbieder stelt de authenticatieverklaring vast

De rest van de flow is gelijk aan de oorspronkelijke usecase Verzamelen.

Uitzonderingen

Naast de uitzonderingen die beschreven zijn in de usecase Verzamelen zijn er specifieke uitzonderingen in relatie tot vertegenwoordigen:

Of de Aanbieder de gevraagde gezondheidsinformatie beschikbaar stelt aan de Vertegenwoordiger, is om te beginnen een zaak tussen de Aanbieder en Vertegenwoordigde, die daarvoor een behandelrelatie moeten hebben of hebben gehad. Gegeven zo'n behandelrelatie is er wetgeving van toepassing op deze ter beschikkingstelling. Daarbinnen is eigen beslisruimte voor de Aanbieder. Omdat Aanbieder en Vertegenwoordigde 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 Vertegenwoordigde minstens zestien jaar oud is (zie uitzondering Verzamelen 3). De Vertegenwoordiger vertegenwoordigt Vertegenwoordigde op basis van een machtiging. De Aanbieder valideert de machtiging.

De machtiging kan gezien worden als onderdeel van de beschikbaarheidsvoorwaarde.

Er zijn verschillende combinaties te maken van ondersteuning van vertegenwoordiging, die impact hebben op het verloop van de flow. Deze staan uitgewerkt in onderstaand diagram

1. Dienstverlener persoon en Dienstverlener aanbieder ondersteunen vertegenwoordiging: reguliere flow voor vertegenwoordiging
2. Dienstverlener aanbieder ondersteunt geen vertegenwoordiging: Vertegenwoordiging wordt afgebroken door Dienstverlener persoon. Om vermenging van gegevens tegen te gaan, mogen geen gegevens verzamelt worden.
3. Dienstverlener persoon ondersteunt geen vertegenwoordiging: Vertegenwoordiging wordt niet gestart door Dienstverlener persoon. Als, om welke reden dan ook, toch bij de Authentication Server gekozen wordt voor Vertegenwoordiging, wordt de flow afgebroken door Dienstverlener aanbieder. Om vermenging van gegevens tegen te gaan, mogen geen gegevens verzamelt worden.
4. Dienstverlener persoon en Dienstverlener aanbieder ondersteunen geen vertegenwoordiging: Vertegenwoordiging wordt niet gestart.

Implementatie usecase Verzamelen

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. Aan het oorspronkelijke diagram zijn in oranje de acties toegevoegd ter ondersteuning van vertegenwoordiging.

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 (als Vertegenwoordiger) de mogelijkheid te presenteren om gezondheidsinformatie van een andere Persoon (als Vertegenwoordigde) te verzamelen.
2. De DVP Server presenteert in de User Agent van de Vertegenwoordiger de mogelijkheid om één of meerdere Gegevensdiensten bij een zekere Aanbieder te verzamelen. Uit de Aanbiederslijst weet de DVP Server welke Gegevensdiensten door een Aanbieder aangeboden worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.

3. De Vertegenwoordiger maakt expliciet zijn selectie en laat de User Agent een authorization request 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). Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Aanbieder bevatten. Omdat gekozen is voor vertegenwoordiging moet de authorization request ook de indicatie voor vertegenwoordiging bevatten.
   

   Toestemming voor meerdere Gegevensdiensten van een Aanbieder

   In een authorization request mogen meerdere Gegevensdiensten van eenzelfde Aanbieder worden gecombineerd wanneer:

   1. de gegevensdiensten worden aangeboden binnen één zelfde interfaceversie, EN
   2. de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen AuthorizationEndpoints met elkaar overeenkomen, EN
   3. de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen TokenEndpoints met elkaar overeenkomen.
4. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren met de indicatie dat er sprake is van vertegenwoordiging.
5. De Authorization Server vraagt de Vertegenwoordiger via zijn User Agent in te loggen.
6. 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 Vertegenwoordiger.
7. De Authentication Server vraagt de Vertegenwoordiger via zijn User Agent om inloggegevens.
8. Wanneer deze juist zijn, dan vraagt de Authentication Server aan de Vertegenwoordiger om de Vertegenwoordigde te selecteren
9. Daarna 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 Vertegenwoordiger alsnog de mogelijkheid via zijn User Agent in te loggen.
10. Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server de authenticatieverklaring op.
11. Dan breekt het vroegste moment aan waarop de Authorization Server ervoor instaat dat de Aanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Vertegenwoordigde beschikbaar heeft, of anders de happy flow afbreekt. Daarvan maakt deel uit dat de Vertegenwoordigde daarvoor minstens 16 jaar oud moet zijn.
12. Indien de Aanbieder kan instaan voor de beschikbaarheid van tenminste één Gegevensdienst, of wanneer géén gebruik wordt gemaakt van dit vroegste moment, dan presenteert de Authorization Server via de User Agent aan Vertegenwoordiger in een Toestemmingsverklaring, de vraag of Vertegenwoordigde de Aanbieder toestaat de gevraagde persoonlijke gezondheidsinformatie aan de DVP Server (als OAuth Client) te sturen. Indien op dit moment al bekend is dat een bepaalde Gegevensdienst niet beschikbaar is voor de Vertegenwoordiger, dan mag deze niet worden opgenomen in de Toestemmingsverklaring.
13. Bij akkoord logt de Authorization Server dit als toestemming, genereert een authorization code en stuurt dit als ophaalbewijs, door middel van een User Agent redirect met de in het authorization request ontvangen redirect_uri, naar de DVP Server. De Authorization Server stuurt daarbij de local state-informatie mee die hij in het authorization request van de DVP Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization code moet associëren.
14. 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.
15. 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.
16. Daarop genereert de Authorization Server een access token en stuurt deze naar de DVP Server.
17. De DVP Server controleert de scope van de vertegenwoordiging. Hierbij zijn de volgende situaties mogelijk:
    
    1. De DVP Server stelt vast dat de scope van het access token geen onbehalfof bevat waar dit in de scope van het Authorization Request wel meegegeven was. DVP Server stopt de flow onmiddelijk.

    2. De DVP Server stelt vast dat de scope van het access token onbehalfof bevat waar dit in de scope van het Authorization Request niet meegegeven was. DVP Server stopt de flow onmiddelijk.
       

       De DVP Server kan deze situaties alleen vaststellen als de DVP Server Vertegenwoordiging ondersteunt. Omdat deze extensie optioneel is voor alle deelnemers, kan de situatie zich voordoen dat de uitzondering wel van toepassing is, maar niet opgemerkt wordt door de DVP Server. Daarom heeft ook de Authorization Server de verantwoordelijkheid controles uit te voeren. Deze staan beschreven bij de Authorization interface.

18. Nu is de DVP Server gereed om één of meerdere verzoeken om de gezondheidsinformatie naar de Resource Server te sturen, nadat hij de Vertegenwoordiger eventueel nog nadere keuzes heeft laten maken. Het adres van de juiste resource endpoints haalt hij uit de Aanbiederslijst. Hij plaatst telkens het access token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.
19. De Resource Server controleert bij ieder verzoek of het ontvangen token recht geeft op de gevraagde resources en haalt deze (al dan niet) bij achterliggende bronnen op. Dan breekt het uiterste moment aan waarop de Resource Server ervoor moet instaan dat voor de Gegevensdienst waartoe een verzoek behoort de Aanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Resource Server deze ze in een resource response naar de DVP Server.
20. De DVP Server bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. De DVP Server bevraagt de Resource Server daarna mogelijk opnieuw, eventueel na nieuwe interactie met de Vertegenwoordiger. Zolang het access token geldig is, kan dat.

In de regel worden bij een eenmalig gebruik van Verzamelen 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.

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.

Implementatie van het front- en backchannelverkeer

In het bovenstaande stroomschema geven de dikke pijlen het MedMij-verkeer weer en zijn daarbinnen de gevallen van frontchannel-verkeer (open pijlpunt) en gevallen van backchannel-verkeer (gesloten pijlpunt) aangegeven.