Document toolboxDocument toolbox

RFC0032 Het spoor volgen naar de Zorgaanbieder

Owned by Former user (Deleted)
Last updated: Oct 29, 2020 by Casper van der Harst
10 min read

Samenvatting

Waarom is deze RFC nodig?

Om de Persoon in Regie te houden bij zijn gebruik van de use cases Verzamelen, Delen en Abonneren, moet hij ook steeds weten wie hij tegenover zich heeft in de verschillende stappen. Om te beginnen is dat steeds precies die Zorgaanbieder die hij uit de Zorgaanbiederslijst heeft gekozen om er een Gegevensdienst van af te nemen.

Nadat de authorization request is uitgegaan naar de Authorization Server, moet de Persoon ervan op de hoogte worden gesteld dat hij het domein van de Zorgaanbieder is binnengetreden. Dat kan door middel van een landingspagina. Die landingspagina biedt de mogelijkheid om de Persoon ervan op de hoogte te brengen dat hij zo gaat inloggen bij de geselecteerde Zorgaanbieder. Dit is in lijn met de eisen die door authenticatievoorzieningen wordt gesteld.

In sommige gevallen wil de Zorgaanbieder zijn wettelijke authenticatieplicht vervullen door de Persoon zich bij een door de Zorgaanbieder aangewezen Authenticerende derde te laten authenticeren. In geval van DigiD zal die Authenticerende derde dan aansluithouder moeten zijn. MedMij onderzoekt of zij dit onder voorwaarden kan gaan toestaan, omdat hiermee besparingen kunnen worden behaald. De DVZA-rol is daarvoor niet geschikt, omdat die als verwerker van de Zorgaanbieder niet kan optreden namens de Zorgaanbieder. Zie bijvoorbeeld de toepasselijke /wiki/spaces/MedMijAfsprakenstelsel120/pages/135105575, artikel 3 lid 1 en punt III onder "Overwegende dat".

Een andere aanleiding voor deze RFC is de wens om het gebruik van een zo hoog mogelijk niveau authenticatiemiddel te bevorderen. Ook wanneer de Zorgaanbieder die aanbiedt naast lagere niveaus authenticatiemiddelen, is de Persoon vaak nog niet genegen de hogere niveaus te gebruiken. De Zorgaanbieder kan met zijn authenticerende rol in MedMij hierbij helpen.

Oplossingsrichting
  • Invoeren van een landingspagina, dat wil zeggen, een pagina die door de Zorgaanbieder aan de Persoon wordt gepresenteerd voorafgaand aan de authenticatie. Deze pagina maakt duidelijk dat de Persoon het Aanbiedersdomein heeft betreden en biedt ook de mogelijkheid (niet verplichting) van de aankondiging dat een Authenticerende derde namens de Zorgaanbieder gaat optreden. Vooralsnog wordt de volgende tekst getoond: "Welkom bij NaamZorgaanbieder. Voordat u toestemming kunt geven voor het verzamelen of delen van informatie, moet u inloggen." Tevens wordt op een gereserveerde positie de inlogknop getoond conform de eisen van de gebruikte Authenticatieprovider ZA.
  • Mocht de Zorgaanbieder authenticatiemiddelen van meerdere niveaus aanbieden, zal hem gevraagd worden op zijn landingspagina de Persoon ertoe te bewegen te kiezen voor het hoogste niveau dat door de Zorgaanbieder wordt aangeboden. Zaak blijft daarbij:
    • dat het de Zorgaanbieder is die kiest welke authenticatiemiddelen van welke niveaus hij voorlegt aan de Persoon, en
    • dat MedMij niet discrimineert tussen authenticatiemiddelen, anders dan op hun niveau;
  • Invoeren van een pagina "geannuleerde inlog" met de volgende tekst: "U hebt uw inlog bij NaamZorgaanbieder geannuleerd. Voordat u toestemming kunt geven voor het verzamelen of delen van informatie, moet u alsnog inloggen. Als u wilt stoppen, kunt u dit scherm sluiten."Tevens wordt op en een gereserveerde positie de inlogknop getoond conform de eisen van de gebruikte Authenticatieprovider ZA en een "Sluiten" knop waarmee teruggekeerd wordt naar de PGO.
  • Toevoegen aan het toestemmings-/bevestigingsscherm dat bij het nalaten van toestemming/bevestiging de sessie bij de Zorgaanbieder onmiddellijk wordt beëindigd. Dit door de volgende zin toe te voegen: "Als u uw keuze heeft gemaakt of deze pagina sluit, wordt u uitgelogd bij NaamZorgaanbieder."
  • Op alle schermen mag het logo van de zorgaanbieder te voeren. Dit kan in de hoeks links boven in het scherm.

Voorwaarden Authenticerende derde:

  • De Persoon heeft geen juridische relatie met de Authenticerende derde en gaat die ook niet aan.
  • De Authenticerende derde is, in geval van DigiD, de DigiD-aansluithouder.
  • De rol van de Authenticerende derde respecteert de principes van MedMij inzake gelijk speelveld.
  • De Authenticerende derde heeft een overeenkomst met de Zorgaanbieder die regelt dat, als een Persoon zich authenticeert bij de Authenticerende derde, dit geldt als een vervulling van de wettelijke plicht van de Zorgaanbieder de Persoon te authenticeren.
  • De Authenticerende derde heeft een dienstverlenings-/verwerkersovereenkomst met de Dienstverlener zorgaanbieder van Zorgaanbieder, of is die Dienstverlener zorgaanbieder zelf.

Het invoeren van de landingspagina en een pagina voor annuleren kan onafhankelijk van het gaan toestaan van een Authenticerende derde. Omdat dat laatste complexer is, kan deze RFC ook opleveren dat in release 1.3.0 alleen het eerste wordt ingevoerd.

Op korte termijn (per heden) al toestaan en stimuleren om de nieuwe pagina's te gebruiken. Dus wanneer een landingspagina en annuleringspagina worden toegepast, dan moet de pagina gebruikt worden als omschreven. Eveneens worden de toegevoegde zin op de toestemmings- en bevestigingsschermen en het voeren van het zorgaanbiederslogo toegestaan.

Zie ook bijgevoegd factsheet:

Aanpassing van
  • Landingspagina
  • Toestemmingsscherm
  • Bevestigingsscherm
  • Toevoegen van Authenticerende derde aan rollenplaten en in verantwoordelijkheden op de lagen Processen en Informatie, en Applicatie
  • Als deze RFC wordt aangenomen, moet RFC0018 worden genuanceerd.
Impact op rollen

Zorgaanbieder, Dienstverlener zorgaanbieder, Authenticerende derde

Impact op beheer

geen

Impact op RnA

geen

Impact op Acceptatie

landingsscherm testen

Gerelateerd aan (Andere RFCs, PIM issues)

RFC0018

Eigenaar

Paul Oude Luttighuis, Bouke de Boer | MedMij

Implementatietermijn

1.3.0

Motivatie verkorte RFC procedure (patch)

n.v.t.

Goedkeuring

BeoordelaarDatumToelichtingBeoordelaarDatumToelichting
Productmanager Stichting MedMij

Productmanager Beheerorganisatie

Leadarchitect Stichting MedMij

Leadarchitect Beheerorganisatie

Ontwerpteam




Deelnemersraad

Eigenaarsraad

Principe's

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Neutraal

11 Stelselfuncties worden vanaf de start ingevuld

Neutraal

2 Dienstverleners zijn transparant over de gegevensdiensten 

Positief

12 Het afsprakenstelsel is een groeimodel

Positief

3 Dienstverleners concurreren op de functionaliteiten

Positief

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Neutraal

4 Dienstverleners zijn aanspreekbaar door de gebruiker

Positief

14 Uitwisseling is een keuze

Neutraal

5 De persoon wisselt gegevens uit met de zorgaanbieder

Positief

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Neutraal

6 MedMij spreekt alleen af wat nodig is

Neutraal

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Neutraal

7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener

Positief

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Neutraal

9 De dienstverleners zijn deelnemers van het afsprakenstelsel

Neutraal

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Neutraal

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

Neutraal

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Neutraal

Uitwerking

UC Verzamelen 

Toevoegen ontvang in diagrammen

Toevoegen annuleer in diagrammen met mogelijkheid om te stoppen of in te loggen

Totaalperspectief (happy flow)

Toelichting

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 UC Verzamelen kent de volgende stappen:

  • De Uitgever presenteert aan de Zorggebruiker de mogelijkheid om te verzamelen.
  • De Zorggebruiker kiest expliciet de zorgaanbieder waarbij hij de informatie wenst te verzamelen en de specifieke Gegevensdienst. Daarvoor kunnen desgewenst de Gegevensdienstnamen worden gebruikt uit de Gegevensdienstnamenlijst. Het verzoek gaat naar de passende Bron.
  • De Bron ontvangt de Zorggebruiker.
  • De Bron laat de Zorggebruiker zich authenticeren.
  • Wanneer de Zorggebruiker de authenticatie heeft afgebroken geeft de Bron de mogelijkheid alsnog te authenticeren of de flow af te breken. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.
  • Dan breekt het moment aan waarop de Bron op zijn vroegst ervoor instaat dat de Zorgaanbieder voor de betreffende Gegevensdienst überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of

/wiki/spaces/MedMijAfsprakenstelsel120/pages/135105526

Toevoegen ontvang in diagrammen

Toevoegen annuleer in diagrammen met mogelijkheid om te stoppen of in te loggen

Totaalperspectief (happy flow)

Toelichting

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 UC Delen kent de volgende stappen:

  • De Uitgever presenteert aan de Zorggebruiker de mogelijkheid om te delen.
  • De Zorggebruiker kiest de zorgaanbieder waarmee 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 Lezer.
  • De Lezer ontvangt de Zorggebruiker.
  • De Lezer laat de Zorggebruiker zich authenticeren.
  • Wanneer de Zorggebruiker de authenticatie heeft afgebroken geeft de Lezer de mogelijkheid alsnog te authenticeren of de flow af te breken. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.

UC Abonneren

Toevoegen ontvang in diagrammen

Toevoegen annuleer in diagrammen met mogelijkheid om te stoppen of in te loggen

Totaalperspectief (happy flow)

Toelichting

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 UC Abonneren kent de volgende stappen:

  • De Uitgever presenteert aan de Zorggebruiker de mogelijkheid om Abonnementen aan te gaan, aan te passen of te beëindigen.
  • De Zorggebruiker selecteert voor het aangaan van een Abonnement expliciet de Zorgaanbieder 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 Bron.
  • De Bron ontvangt de Zorggebruiker.
  • De Bron laat de Zorggebruiker zich authenticeren.
  • Wanneer de Zorggebruiker de authenticatie heeft afgebroken geeft de Bron de mogelijkheid alsnog te authenticeren of de flow af te breken. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.


/wiki/spaces/MedMijAfsprakenstelsel120/pages/135103689(Autorisatieserver)

1. Het welkomstscherm dat aan de Zorggebruiker wordt gepresenteerd bij ontvangst op de Autorisatieserver in de UCI Verzamelen, UCI Delen en UCI Abonneren en staat gespecificeerd op de pagina /wiki/spaces/MedMijAfsprakenstelsel130/pages/135627886. Daarbij geldt dat:

  • de gebruikersvriendelijke weergave van de identiteit van de Zorgaanbieder (NaamZorgaanbieder) wordt bepaald door de betreffende Dienstverlener Zorgaanbieder, in haar dienstverleningsrelatie met de betreffende Zorgaanbieder;

2. Het Annuleringsscherm, dat aan de Zorggebruiker wordt gepresenteerd na afbreken van de authenticatie in de UCI Verzamelen, UCI Delen en UCI Abonneren en staat gespecificeerd op de pagina /wiki/spaces/MedMijAfsprakenstelsel130/pages/135627902. Daarbij geldt dat:

  • de gebruikersvriendelijke weergave van de identiteit van de Zorgaanbieder (NaamZorgaanbieder) wordt bepaald door de betreffende Dienstverlener Zorgaanbieder, in haar dienstverleningsrelatie met de betreffende Zorgaanbieder;

1a. 3a. De vraag die aan de Zorggebruiker gesteld moet worden in de stap "autoriseer" in UCI Verzamelen staat gespecificeerd op de pagina Toestemmingsverklaring. Daarbij geldt dat:

  • de gebruikersvriendelijke weergave van de identiteit van de Zorgaanbieder (NaamZorgaanbieder) wordt bepaald door de betreffende Dienstverlener Zorgaanbieder, in haar dienstverleningsrelatie met de betreffende Zorgaanbieder;
  • de gebruikersvriendelijke weergave van de Gegevensdienst (NaamGegevensdienst) wordt betrokken uit de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen, die overeenkomt met de Weergavenaam die bij de betreffende Gegevensdienst in de Gegevensdienstnamenlijst is opgenomen;
  • de gebruikersvriendelijke weergave van de identiteit van de Uitgever (NaamLeverancierPGO) wordt betrokken uit de OAuth Client List, op basis van de redirect_uri (van OAuth) die in stap 1 is verkregen.

1b. 3b. De vraag die aan de Zorggebruiker gesteld moet worden in de stap "bevestig" in UCI Delen staat gespecificeerd op de pagina Bevestigingsverklaring. Daarbij geldt dat:

  • de gebruikersvriendelijke weergave van de identiteit van de Zorgaanbieder (NaamZorgaanbieder) wordt bepaald door de betreffende Dienstverlener Zorgaanbieder, in haar dienstverleningsrelatie met de betreffende Zorgaanbieder;
  • de gebruikersvriendelijke weergave van de Gegevensdienst (NaamGegevensdienst) wordt betrokken uit de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen, die overeenkomt met de Weergavenaam die bij de betreffende Gegevensdienst in de Gegevensdienstnamenlijst is opgenomen;
  • de gebruikersvriendelijke weergave van de identiteit van de Uitgever (NaamLeverancierPGO) wordt betrokken uit de OAuth Client List, op basis van de redirect_uri (van OAuth) die in stap 1 is verkregen.

1c. 3c. De vraag die aan de Zorggebruiker gesteld moet worden in de stap "autoriseer" in UCI Abonneren staat gespecificeerd op de pagina Toestemmingsverklaring Abonneren. Daarbij geldt dat:

  • de gebruikersvriendelijke weergave van de identiteit van de Zorgaanbieder (NaamZorgaanbieder) wordt bepaald door de betreffende Dienstverlener Zorgaanbieder, in haar dienstverleningsrelatie met de betreffende Zorgaanbieder;
  • de aangeboden looptijd van het Abonnement (Duur) door de beleid van de Zorgaanbieder wordt bepaald, op basis van de door de Persoon gevraagde looptijd, en nooit langer dan de maximale looptijd die in de Catalogus bij de betreffende Gegevensdienst staat genoemd;
  • de gebruikersvriendelijke weergave van de Gegevensdienst (NaamGegevensdienst) wordt betrokken uit de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen, die overeenkomt met de Weergavenaam die bij de betreffende Gegevensdienst in de Gegevensdienstnamenlijst is opgenomen;
  • de gebruikersvriendelijke weergave van de identiteit van de Uitgever (NaamLeverancierPGO) wordt betrokken uit de OAuth Client List, op basis van de redirect_uri (van OAuth) die in stap 1 is verkregen.

/wiki/spaces/MedMijAfsprakenstelsel120/pages/135105533

Toelichting

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 PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om een bepaalde Gegevensdienst bij een zekere Zorgaanbieder te verzamelen. Het gaat altijd om precies één Gegevensdienst (één scope, in OAuth-termen). Uit de Zorgaanbiederslijst weet de PGO Server welke Gegevensdiensten door een Zorgaanbieder aangeboden worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
  2. De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een verzamel-verzoek sturen naar de Authorization Server. Het adres van het authorization endpoint komt uit de ZAL. De redirect_uri geeft aan waarnaartoe de Authorization Server de OAuth User Agent verderop moet redirecten (met de authorization code).
  3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  4. De Authorization Server vraagt de Zorggebruiker via zijn PGO Presenter in te loggen.

4. 5  Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de browser naar de Authentication Server te redirecten, onder meegeven van een redirect_uri, die aangeeft waarnaartoe de Authentication Server straks de OAuth User Agent moet terugsturen, na het inloggen van de Zorggebruiker.

5. 6. De Authentication Server vraagt van de Zorggebruiker via zijn PGO Presenter om inloggegevens.

7. Wanneer deze juist zijn, redirect de Authentication Server de OAuth User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken geeft de Authorization Server de Zorggebruiker alsnog de mogelijkheid via zijn PGO Presenter in te loggen. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.


Daarna hernummeren

UCI Delen

  1. De PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om een bepaalde Gegevensdienst met een zekere Zorgaanbieder te delen. Het gaat altijd om precies één Gegevensdienst (één scope, in OAuth-termen). Uit de Zorgaanbiederslijst weet de PGO Server welke Gegevensdiensten door een Zorgaanbieder aangeboden worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
  2. De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een deel-verzoek sturen naar de Authorization Server . Het adres van het authorization endpoint komt uit de ZAL. De redirect URI geeft aan waarnaartoe de Authorization Server de OAuth User Agent verderop moet redirecten (met de authorization code).
  3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  4. De Authorization Server vraagt de Zorggebruiker via zijn PGO Presenter in te loggen.

4. 5.Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de OAuth User Agent naar de Authentication Server te redirecten, onder meegeven van een redirect URI, die aangeeft waarnaartoe de Authentication Server straks de OAuth User Agent moet terugsturen, na het inloggen van de Zorggebruiker.

5. 6. De Authentication Server vraagt van de Zorggebruiker via zijn PGO Presenter om inloggegevens.

5. 7. Wanneer deze juist zijn, redirect de Authentication Server de OAuth User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken geeft de Authorization Server de Zorggebruiker alsnog de mogelijkheid via zijn PGO Presenter in te loggen. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.


Daarna hernummeren

/wiki/spaces/MedMijAfsprakenstelsel120/pages/135105537

  1. De PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om zich bij een zekere Zorgaanbieder te Abonneren op Notificatiesvoor een bepaalde Gegevensdienst. Het gaat altijd om precies één Gegevensdienst. Uit de Zorgaanbiederslijst weet de PGO Server op welke Gegevensdiensten een Zorgaanbieder Abonnementen aanbiedt worden. Desgewenst worden de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gebruikt.
  2. De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een abonneer-verzoek sturen naar de Authorization Server. Het adres van het authorization endpoint komt uit de ZAL. De redirect_uri geeft aan waarnaartoe de Authorization Server de OAuth User Agent verderop moet redirecten (met de authorization code).
  3. Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
  4. De Authorization Server vraagt de Zorggebruiker via zijn PGO Presenter in te loggen.


4. 5.Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de OAuth User Agent naar de Authentication Server te redirecten, onder meegeven van een redirect URI, die aangeeft waarnaartoe de Authentication Server straks de OAuth User Agent moet terugsturen, na het inloggen van de Zorggebruiker.

5. 6. De Authentication Server vraagt van de Zorggebruiker via zijn PGO Presenter om inloggegevens.

5. 7. Wanneer deze juist zijn, redirect de Authentication Server de OAuth User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken geeft de Authorization Server de Zorggebruiker alsnog de mogelijkheid via zijn PGO Presenter in te loggen. Dit is een 'alternative flow' en wordt daarom niet aan het diagram toegevoegd. Wel wordt het beschreven bij de uitzonderingen.


Daarna hernummeren

/wiki/spaces/MedMijAfsprakenstelsel120/pages/135105558

Nieuwe pagina: Landingspagina, zie bijlage

Nieuwe pagina: Annuleringspagina, Zie bijlage


Toestemmingsverklaring

Gewijzigde schermen opnemen, zie bijlage.


Toestemmingsverklaring Abonneren

Gewijzigde schermen opnemen, zie bijlage.


Bevestigingsverklaring

Gewijzigde schermen opnemen, zie bijlage.

Bijlage

20201027medmij-toestemmingen-en-bevestiging.zip

Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

Deze RFC introduceert geen nieuwe (privacy)risico's, het wordt voor de persoon juist duidelijker met wie hij van doen heeft.

DreigingKansImpactDreigingsID (intern)Maatregelen