Inleiding

...

...

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.
   

   Info
   icon false title Toestemming voor meerdere Gegevensdiensten van een Aanbieder
   In een authorization request mogen meerdere Gegevensdiensten van eenzelfde Aanbieder worden gecombineerd wanneer: de gegevensdiensten worden aangeboden binnen één zelfde interfaceversie, EN de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen AuthorizationEndpoints met elkaar overeenkomen, EN 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 Servervraagt 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 Aanbiederkan 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 Aanbiedertoestaat 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 Serverstopt 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 Serverstopt de flow onmiddelijk.
       

       Info

       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.

...

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

...