Samenvatting

Waarom is deze RFC nodig?

Met deze RFC wordt de gebruiksvriendelijkheid van de MedMij UC Verzamelen voor Personen vergroot. Deze RFC vormt één van de stappen in het vergroten van de gebruiksvriendelijkheid.

Input van deelnemers

Loskoppelen van resource server (RS) en authorization server (AS) heeft impact op de markt, op gedane investeringen en op beoogde business modellen. Hier moet goed over worden nagedacht.
Hoe vaak komt het voor dat een zorgaanbieder gegevensdiensten aanbiedt via verschillende DVA's? Is het daarom wel echt nodig om RS en AS los te koppelen? Rondgang in de sessie gaf het beeld dat dit toch geregeld voor zal komen.

Oplossingsrichting

Requirements:

Toestaan dat één keer inloggen en één keer toestemming voor verzamelen van een set van (gegevens)diensten, die een aanbieder via eenzelfde dienstverlener aanbieder (DVA) aanbiedt, volstaat. D.w.z. voor een periode van 15 minuten, zoals gebruikelijk.
Dit geldt voor alle verzamel-gegevensdiensten die een zorgaanbieder aanbiedt binnen één zelfde interfaceversie.

Voor deze RFC zijn een aantal oplossingsrichtingen overwogen:

Toestemming voor lijst van gegevensdiensten;
Toestemming voor toestemmingscategorie;
Toestemming voor alle persoons- en gezondheidsgegevens van zorgaanbieder;
Introductie van overkoepelende gegevensdienst(en).

Oplossingsrichting 3 is naar voren gekomen als de gewenste richting en wordt hier verder uitgewerkt.

Oplossingsrichting 3 - Toestemming voor alle persoons- en gezondheidsgegevens van zorgaanbieder

Deze oplossingsrichting maakt een grofmazige toestemming mogelijk.

Om een interactie te mogen initieren is een access_token vereist die recht geeft op het gebruik van een Gegevensdienst. Een access_token wordt pas uitgegeven:

wanneer Persoon toestemming heeft gegeven voor beschikbaarstelling van alle persoons- en gezondheidsgegevens van een Aanbieder, en
wanneer de Aanbieder instaat voor beschikbaarheid van deze Gegevensdienst voor deze Persoon.

Nadere uitwerking:

Wanneer DVP een Authorization Request samenstelt, dan bepaalt zij m.b.v. de ZAL de aanbieder-gegevensdienst-combinaties die zij wil opnemen in de scope parameter van het request. Een DVP kan de gebruikersinteractie vormgeven op basis van de eigen visie, daarbij gebruikmakend van de use cases die zijn uitgewerkt in de beschikbare gegevensdiensten.
- Autorisatie mag vooralsnog slechts worden gevraagd en toegekend voor aanbieder-gegevensdienst-combinaties, waarvoor gebruik wordt gemaakt van eenzelfde autorisatieserver.
De Autorisatie Server toont een generieke brede toestemmingsvraag, met daar bij de daadwerkelijk door persoon gevraagde en door zorgaanbieder op dit moment beschikbaar gestelde gegevensdiensten. Hierbij worden zo mogelijk (bij vroege beschikbaarheidstoets) slechts gegevensdiensten getoond die daadwerkelijk beschikbaar zijn om te verzamelen.
Autorisatie Server geeft een access_token uit voor een scope (aanbieder-gegevensdienst-combinaties) die wordt bepaald door
- de aanbieder-gegevensdienst-combinaties die de DVA daadwerkelijk, binnen de gebruikte interfaceversie, ondersteunt
- de gegevensdiensten die de DVP daadwerkelijk, binnen de gebruikte interfaceversie, ondersteunt
- bij vroege beschikbaarheidstoets: de aanbieder-gegevensdienst-combinaties die daadwerkelijk beschikbaar zijn voor verzamelen door deze Persoon
De scope van de Token Response bevat derhalve de daadwerkelijk toegekende aanbieder-gegevensdienst-combinaties.
DVP kan vervolgens o.b.v. een verkregen access_token alle gegevensdiensten bij de betreffende aanbieder gebruiken, waarvoor autorisatie is gegeven.
Resource Server toetst of een ontvangen resource request past binnen één van de toegekende aanbieder-gegevensdienst-combinaties.
- NB. wanneer DVP vervolgens een nieuw Authorization Request laat sturen, dan zal Persoon wel weer opnieuw moeten inloggen en toestemmen.

Bovenstaande flow is hier grafisch uitgebeeld.

Huidige Toestemmingsverklaring

Toestemmingsverklaring

U geeft hierbij NaamZorgaanbieder toestemming om NaamGegevensdienst uit te wisselen met NaamLeverancierPGO voor het doel deze persoons- en gezondheidsgegevens op te nemen in uw persoonlijke gezondheidsomgeving.

Toelichting op de toestemmingsverklaring

Het doel van het MedMij Afsprakenstelsel is dat eenieder die dat wil, kan beschikken over een Persoonlijke Gezondheidsomgeving (PGO) waarin - onder uw eigen regie - (persoons)gegevens en/of informatie over uw gezondheid wordt opgenomen. Om de PGO te voorzien van de door u gewenste (persoons)gegevens en/of gezondheidsinformatie zijn in het MedMij Afsprakenstelsel afspraken gemaakt over de uitwisseling van deze gegevens. Het uitwisselen van gegevens tussen de zorgaanbieder en uw PGO verloopt zodoende via partijen die voldoen aan deze MedMij-afspraken.

Op grond van de Wet geneeskundige behandelingsovereenkomst (WGBO) is de zorgaanbieder verplicht ervoor te zorgen dat ‘anderen’ dan de patiënt (lees: u) geen inlichtingen hebben over, inzage hebben in of een afschrift hebben van uw medisch dossier, tenzij u hiervoor toestemming heeft verleend.

Aangezien uw PGO (en eventuele achterliggende partij die werkt volgens de MedMij-afspraken) een zogenaamde ‘andere’ is (in de zin van de WGBO) dient u de zorgaanbieder voor deze gegevensuitwisseling toestemming te verlenen. Deze toestemming heeft specifiek betrekking op de set van (persoons) gegevens en gezondheidsinformatie die, op uw verzoek, door de zorgaanbieder - overeenkomstig de afspraken in het MedMij Afsprakenstelsel - worden uitgewisseld met uw PGO.

Aangepaste Toestemmingsverklaring

Toestemmingsverklaring

Ik wil persoons- en gezondheidsgegevens opnemen in mijn persoonlijke gezondheidsomgeving (PGO). Persoonsgegevens zijn bijvoorbeeld je naam en geboortedatum. Gezondheidsgegevens zijn de gegevens die een zorgaanbieder van je heeft opgeslagen. Bijvoorbeeld de medicijnen die je slikt, en bloeduitslagen.

Hierbij geef ik NaamZorgaanbieder toestemming om de gegevens die ik opvraag aan NaamLeverancierPGO te sturen.

De volgende gegevens wil ik opvragen en in mijn PGO opnemen:
- NaamGegevensdienst;
- NaamGegevensdienst.

Uitleg over de toestemmingsverklaring

Met een persoonlijke gezondheidsomgeving (PGO) kun je gegevens over je gezondheid verzamelen. Voor het uitwisselen van deze gegevens van jouw zorgaanbieder – zoals je huisartsenpraktijk – naar jouw PGO is een veilige verbinding nodig. In PGO’s met een MedMij-label kunnen deze gegevens veilig worden uitgewisseld. Hierover zijn afspraken gemaakt en vastgelegd in het MedMij Afsprakenstelsel. Het uitwisselen van gegevens tussen de zorgaanbieder en jouw PGO verloopt via partijen die voldoen aan deze MedMij-afspraken.

Op grond van de Wet geneeskundige behandelingsovereenkomst is de zorgaanbieder verplicht ervoor te zorgen dat ‘anderen’ (lees: jouw PGO) dan de patiënt (lees: jij) geen inlichtingen hebben over, inzage hebben in of een afschrift hebben van jouw medische dossier, tenzij je hiervoor toestemming hebt gegeven.

Wil je bij jouw zorgaanbieder gegevens opvragen om in jouw PGO te zetten? Dan moet je de zorgaanbieder hier toestemming voor geven. Je geeft dan toestemming voor de specifieke gegevens die hij of zij mag uitwisselen. Niet voor andere gegevens.

De weergavenamen van de huidige gegevensdiensten zijn ter info opgenomen in onderstaande tabel.

ID	Gegevensdienst	NaamGegevensdienst in toestemmingverklaring
24	Verzamelen Laboratoriumresultaten (*) 1.1	Laboratoriumresultaten
46	Verzamelen Laboratoriumresultaten 2.0	Laboratoriumresultaten
25	Verzamelen Afspraken (*) 1.1	Afspraken
47	Verzamelen Afspraken 2.0	Afspraken
26	Verzamelen Basisgegevens zorg (*) 2.1	Basisgegevens zorg
48	Verzamelen Basisgegevens zorg 3.0	Basisgegevens zorg
28	Verzamelen Huisartsgegevens (*) 1.1	Huisartsgegevens
49	Verzamelen Huisartsgegevens 2.0	Huisartsgegevens
32	Verzamelen Basisgegevens GGZ (*) 1.1	Basisgegevens GGZ
50	Verzamelen Basisgegevens GGZ 2.0	Basisgegevens GGZ
33	Verzamelen Documenten (*) 1.2	Documenten
51	Verzamelen Documenten 3.0	Documenten
30	Verzamelen Medicatieoverzichten 9.0	Medicatieoverzichten
31	Verzamelen Medicatiegegevens 9.0	Medicatiegegevens
35	Verzamelen Medicatiegegevens 9.A	Medicatiegegevens
36	Verzamelen Meetwaarden vitale functies (*) 1.2	Meetwaarden vitale functies
52	Verzamelen Meetwaarden vitale functies 2.0	Meetwaarden vitale functies
38	Verzamelen Overgevoeligheden (*) 1.1	Overgevoeligheden
54	Verzamelen Overgevoeligheden 2.0	Overgevoeligheden
42	Verzamelen Medicatiegerelateerde Overgevoeligheden (*) 1.A	Medicatiegerelateerde Overgevoeligheden
58	Verzamelen Medicatiegerelateerde Overgevoeligheden 2.A	Medicatiegerelateerde Overgevoeligheden
43	Verzamelen Verwijzing naar vragenlijst (*) 1.0	Verwijzing naar vragenlijst
59	Verzamelen Verwijzing naar vragenlijst 2.0	Verwijzing naar vragenlijst
61	Verzamelen Basisgegevens Langdurige Zorg 3.0	Basisgegevens Langdurige Zorg

Gebruik van de ZAL

Een DVP mag meerdere gegevensdiensten van een aanbieder combineren in één Authorization Request wanneer (zie ook onderstaande voorbeeld):

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

Voorbeeld van de ZAL:

Zorgaanbieder - umcharderwijk@medmij
- Interfaceversie - 1.5.0
  - Gegevensdienst - 4
    - AuthorizationEndpoint - https://fc-medmij.xisbridge.net/oauth/authorize4
    - TokenEndpoint - https://bc-medmij.xisbridge.net/oauth/token4
    - ..
  - Gegevensdienst - 5
    - AuthorizationEndpoint - https://fc-medmij.xisbridge.net/oauth/authorize5
    - TokenEndpoint - https://bc-medmij.xisbridge.net/oauth/token5
    - ..
  - Gegevensdienst - 6
    - AuthorizationEndpoint - https://fc-78834.umcharderwijk.nl/oauth/authorize
    - TokenEndpoint - https://bc-78834.umcharderwijk.nl/oauth/token
    - ..

Gegevensdiensten 4 en 5, zoals aangeboden door umcharderwijk@medmij mogen in bovenstaand voorbeeld met elkaar worden gecombineerd in één AuthorizationRequest. Voor gegevensdienst 6 zal een afzonderlijk AuthorizationRequest moeten worden verstuurd.

Managementinformatie

Met het geven van toestemming over meerdere diensten van één aanbieder moet ook rekening worden gehouden bij het vastleggen van Managementinformatie. Voor het registreren van de Managementinformatie betekent dit dat:

Een Authorization Request meetelt bij de telling voor alle Gegevensdiensten waarvoor de scope van het request een overeenkomstig gegevensdienst id bevat (dit geldt voor zowel succesvolle als voor onsuccesvolle requests);
Een Token Request meetelt bij de telling voor alle Gegevensdiensten waarvoor de authorization code was uitgegeven (dit geldt voor zowel succesvolle als voor onsuccesvolle requests).

Aanpassing van

Authorization flow, toestemmingsverklaring, UC(I) Verzamelen

Impact op rollen

DVP (optionele functionaliteit), DVA (verplichte functionaliteit). Ook op wijze van telling requests t.b.v. managementinformatie.

Impact op beheer

Nee

Impact op RnA

Nee

Impact op Acceptatie

Ja, vereist aanpassingen in acceptatiescripts en testtooling.

Gerelateerd aan (Andere RFCs, PIM issues)

AF-1127

Eigenaar

Ron van Holland (Unlicensed) , Bouke de Boer | MedMij

Implementatietermijn

1.5.0

Motivatie verkorte RFC procedure (patch)

Goedkeuring

Beoordelaar	Datum	Toelichting	Beoordelaar	Datum	Toelichting
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	Positief	11 Stelselfuncties worden vanaf de start ingevuld	Positief
2 Dienstverleners zijn transparant over de (gegevens)diensten	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	Positief
4 Dienstverleners zijn aanspreekbaar door de gebruiker	Positief	14 Uitwisseling is een keuze	Positief
5 De persoon wisselt gegevens uit met de aanbieder	Positief	15 Het MedMij-netwerk is gebruiksrechten-neutraal	Positief
6 MedMij spreekt alleen af wat nodig is	Positief	16 De burger regisseert zijn gezondheidsinformatie als uitgever	Positief
7 De persoon en de aanbieder kiezen hun eigen dienstverlener	Positief	17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld	Positief
9 De dienstverleners zijn deelnemers van het afsprakenstelsel	Positief	18 Afspraken worden aantoonbaar nageleefd en gehandhaafd	Positief
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling	Positief	19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat	Positief

Uitwerking

Processen en Informatie - UC Verzamelen

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(en). 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.
Dan breekt het moment aan waarop de Bron op zijn vroegst ervoor instaat dat de Zorgaanbieder voor tenminste één van de gevraagde Gegevensdiensten überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Het MedMij Afsprakenstelsel adviseert de beschikbaarheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. In deze release 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 Bron vraagt aan de Zorggebruiker of hij toestemming geeft tot het verstrekken van de gevraagde informatie aan de Uitgever. Deze vraag staat op de pagina Toestemmingsverklaring.
De Bron logt die toestemming en geeft een autorisatie af aan de Uitgever.
Nu kan de Uitgever de Bron vragen om de gezondheidsinformatie.
Uiterlijk na de ontvangst van het verzoek zal de Bron ervoor instaan dat de Zorgaanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreken.
Bij ontvangst slaat de Uitgever die informatie op in het persoonlijke dossier.
Mocht een Gegevensdienst waartoe de Uitgever is geautoriseerd uit meerdere Transacties bestaan (zie hiervoor de Catalogus), dan bevraagt de Uitgever de Bron daarna mogelijk opnieuw voor de nog resterende Transacties, eventueel na nieuwe interactie met de Zorggebruiker. Hetzelfde geldt wanneer de Uitgever is geautoriseerd voor meerdere Gegevensdiensten van de betreffende Zorgaanbieder.
Bij de informatie wordt ook de meta-informatie opgeslagen die wordt bedoeld in verantwoordelijkheid 19 van de Processen- en Informatielaag.

In plaatje met de flows onderscheid maken tussen toestemming door Zorggebruiker en autorisatie door Bron. Dit staat er nu niet goed.

Applicatie - Use case implementaties - UCI Verzamelen

De flow kent de volgende stappen:

De PGO Server start de flow door in de PGO Presenter van de Zorggebruiker de mogelijkheid te presenteren om één of meerdere Gegevensdiensten 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 aan de Zorggebruiker de Gegevensdienstnamen uit de Gegevensdienstnamenlijst gepresenteerd.
De Zorggebruiker maakt expliciet zijn selectie en laat de OAuth User Agent een authorization request 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). Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Zorgaanbieder bevatten. Zie hiervoor de de toelichting "Toestemming voor meerdere Gegevensdiensten van een Zorgaanbieder".
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 Zorggebruiker via zijn PGO Presenter in te loggen.
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.
De Authentication Server vraagt ~~van~~ de Zorggebruiker via zijn PGO Presenter om inloggegevens.
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.
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 Zorgaanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Daarvan maakt deel uit dat de Persoon daarvoor minstens 16 jaar oud moet zijn.
Indien de Zorgaanbieder 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 PGO Presenter aan Zorggebruiker de Toestemmingsverklaring. ~~vraag of laatstgenoemde hem toestaat de gevraagde persoonlijke gezondheidsinformatie aan de PGO Server (als OAuth Client) te sturen~~. ~~Onder het flow-diagram staat gespecificeerd welke informatie, waarvandaan, de OAuth Authorization Server verwerkt in de aan Zorggebruiker voor te leggen Toestemmingsverklaring.~~ Indien op dit moment al bekend is dat een bepaalde Gegevensdienst niet beschikbaar is voor de Zorggebruiker, dan mag deze niet worden opgenomen in de Toestemmingverklaring.
Bij akkoord logt de Authorization Server dit als toestemming, genereert een authorization code en stuurt dit als ophaalbewijs, door middel van een OAuth User Agent redirect met de in het authorization request ontvangen redirect_uri, naar de PGO Server. De Authorization Server stuurt daarbij de local state-informatie mee die hij in het authorization request van de PGO Server heeft gekregen. Laatstgenoemde herkent daaraan het verzoek waarmee hij de authorization code moet associëren.
De PGO 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.
Met dit ophaalbewijs wendt de PGO Server zich weer tot de Authorization Server, maar nu zonder tussenkomst van de OAuth User Agent, voor een access token.
Daarop genereert de Authorization Server een access token en stuurt deze naar de PGO Server.
Nu is de PGO Server gereed om één of meerdere verzoeken om de gezondheidsinformatie naar de Resource Server te sturen, nadat hij de Zorggebruiker eventueel nog nadere keuzes heeft laten maken. Het adres van de juiste resource endpoints haalt hij uit de ZAL. Hij plaatst telkens het access token in het bericht en zorgt ervoor dat in het bericht geen BSN is opgenomen.
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 Zorgaanbieder de gezondheidsgegevens beschikbaar heeft. Is dat zo, dan verstuurt de Resource Server deze ze in een resource response naar de PGO Server. ~~Is dat niet zo, dan breekt de~~ Resource Server de happy flow af.
De PGO Server bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier. Mocht de Gegevensdienst waartoe de Zorggebruiker heeft geautoriseerd uit meerdere Transacties ~~bestaan (zie hiervoor de Catalogus), of mocht één Transactie volgens de betreffende Informatiestandaard uit meerdere requests bestaan, bevraagt de~~ De PGO Server bevraagt de Resource Server daarna mogelijk opnieuw ~~voor de nog resterende~~ ~~Transacties~~, eventueel na nieuwe interactie met de Zorggebruiker. Zolang het access token geldig is, kan dat.

In de regel worden bij een eenmalig gebruik van UCI Verzamelen het authorization interface, het token interface en het resource interface allemaal aangesproken, in die volgorde. Mocht de PGO Server echter nog beschikken over een nog niet verlopen access token voor de betreffende Zorgaanbieder-Gegevensdienst-combinatie, dan kan het onmiddellijk het resource interface aanspreken.

Toestemming voor meerdere Gegevensdiensten van een Zorgaanbieder

In een authorization request mogen meerdere Gegevensdiensten van eenzelfde Zorgaanbieder 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.

In plaatje met de flows onderscheid maken tussen toestemming door Zorggebruiker en autorisatie door Authorization Server. Dit staat er nu niet goed, maar werkt op verschillende plaatsen door. Bijv. "vraag om autorisatie" moet zijn "vraag om toestemming". N.a.v. daarvan kan de Zorgaanbieder vervolgens autorisatie verlenen aan PGO Server.

Communicatie - Toestemmingsverklaring

Toestemmingsverklaring

Ik wil persoons- en gezondheidsgegevens opnemen in mijn persoonlijke gezondheidsomgeving (PGO). Persoonsgegevens zijn bijvoorbeeld je naam en geboortedatum. Gezondheidsgegevens zijn de gegevens die een zorgaanbieder van je heeft opgeslagen. Bijvoorbeeld de medicijnen die je slikt, en bloeduitslagen.

Hierbij geef ik NaamZorgaanbieder toestemming om de gegevens die ik opvraag aan NaamLeverancierPGO te sturen.

De volgende gegevens wil ik opvragen en in mijn PGO opnemen:
- NaamGegevensdienst;
- NaamGegevensdienst.

Uitleg over de toestemmingsverklaring

Met een persoonlijke gezondheidsomgeving (PGO) kun je gegevens over je gezondheid verzamelen. Voor het uitwisselen van deze gegevens van jouw zorgaanbieder – zoals je huisartsenpraktijk – naar jouw PGO is een veilige verbinding nodig. In PGO’s met een MedMij-label kunnen deze gegevens veilig worden uitgewisseld. Hierover zijn afspraken gemaakt en vastgelegd in het MedMij Afsprakenstelsel. Het uitwisselen van gegevens tussen de zorgaanbieder en jouw PGO verloopt via partijen die voldoen aan deze MedMij-afspraken.

Op grond van de Wet geneeskundige behandelingsovereenkomst is de zorgaanbieder verplicht ervoor te zorgen dat ‘anderen’ (lees: jouw PGO) dan de patiënt (lees: jij) geen inlichtingen hebben over, inzage hebben in of een afschrift hebben van jouw medische dossier, tenzij je hiervoor toestemming hebt gegeven.

Wil je bij jouw zorgaanbieder gegevens opvragen om in jouw PGO te zetten? Dan moet je de zorgaanbieder hier toestemming voor geven. Je geeft dan toestemming voor de specifieke gegevens die hij of zij mag uitwisselen. Niet voor andere gegevens.

Ook HTML schermen aanpassen.

Applicatie - Interfaces - User interface (Autorisatieserver)

2a. 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 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~~;
de gebruikersvriendelijke weergave van een Gegevensdienst (NaamGegevensdienst) wordt betrokken uit de Gegevensdienstnamenlijst.

Applicatie - Interfaces - Authorization interface

1a. De parameters in de authorization request worden als volgt gevuld:

scope

Een zorgaanbieder-gegevensdienst-combinatie bestaat uit:

één Zorgaanbiedernaam, ontdaan van de suffix @medmij
gevolgd door een tilde (~)
gevolgd door één GegevensdienstId van een Gegevensdienst uit de Gegevensdienstnamenlijst.

Voor "verzamelen":

één of meerdere, door een enkele spatie van elkaar gescheiden, zorgaanbieder-gegevensdienst-combinaties
waarbij de Zorgaanbiedernaam telkens dezelfde moet zijn

Voor "delen":

één zorgaanbieder-gegevensdienst-combinatie.

Voor "abonneren":

de letterlijke waarde subscribe
gevolgd door een tilde ~
gevolgd door een niet-negatief geheel getal, aangevende de gevraagde maximale duur van het Abonnement
gevolgd door een forward slash /
gevolgd door één zorgaanbieder-gegevensdienst-combinatie.

Er worden geen andere scopes of onderdelen van scopes opgenomen dan de hier genoemde.

Voorbeelden van syntactisch juiste scopes zijn:

"eenofanderezorgaanbieder~42", voor het eenmalig afnemen van Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij;
"eenofanderezorgaanbieder~42 eenofanderezorgaanbieder~48", voor het eenmalig afnemen van Gegevensdiensten 42 en 48 bij eenofanderezorgaanbieder@medmij;
"subscribe~180/eenofanderezorgaanbieder~42", voor het aangaan van een Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij van maximaal 180 dagen, of het aanpassen van het Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij naar maximaal 180 dagen vanaf vandaag;
"subscribe~0/eenofanderezorgaanbieder~42", voor het beëindigen van het Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij.

2b. Vervolgens verifieert de Authorization Server dat:

alle gevraagde GegevensdienstId's voorkomen op de OAuth Client List, bij de betreffende client_id en voor de gehanteerde Interfaceversie;
zij namens deze Zorgaanbieder, voor de gehanteerde Interfaceversie, deze Gegevensdienst(en) ontsluit, in overeenstemming met de gepubliceerde Zorgaanbiederslijst;
indien in de scope meerdere GegevensdienstId's zijn opgenomen:
- alle Gegevensdiensten betrekking hebben op de UCI Verzamelen;
- de hostnames van de AuthorizationEndpoints, waarop de Gegevensdiensten worden aangeboden, met elkaar overeenkomen;
- de hostnames van de TokenEndpoints, waarop de Gegevensdiensten worden aangeboden, met elkaar overeenkomen.
indien in de scope ook subscribe voorkomt:
- de scope slechts één GegevensdienstId bevat;
- bij de betreffende client_id en Gegevensdienst op de OAuth Client List ook een subscription notification endpoint en een resource notification endpoint voorkomen;
- zij namens deze Zorgaanbieder ook Abonnementen op deze Gegevensdienst ontsluit;
- de waarde van de duur parameter in het request de waarde heeft van 0 of een waarde groter dan 0 die kleiner of gelijk is aan de maximale duur van het Abonnement zoals de betreffende Zorgaanbieder deze aanbiedt.

Als een van deze verificaties niet slaagt dan behandelt de Authorization Server dit als uitzondering 1b volgens verantwoordelijkheid 6.

6. Uitzondering Authorization interface 3

Authorization Server stelt tijdens de afhandeling van de authorization request vast dat:

in geval van UCI Verzamelen: van Persoon bij Zorgaanbieder voor geen van de gevraagde Gegevensdiensten gezondheidsinformatie beschikbaar is;
in geval van UCI Delen: Zorgaanbieder niet ontvankelijk is voor die Gegevensdienst van Persoon;
in geval van UCI Abonneren: Zorgaanbieder geen Notificaties beschikbaar maakt voor Persoon op die Gegevensdienst.

Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

Applicatie - Interfaces - Token interface

2. De parameters in de access token response worden als volgt gevuld:

scope

Conform sectie 5.1 van de OAuth 2.0-specificatie.

In toevoeging daarop:

Verplicht indien het authorization request verzocht om Verzamelen van meerdere Gegevensdiensten en hiervan niet alle Gegevensdiensten beschikbaar bleken voor Persoon. In dat geval is de scope-parameter gelijk aan die in de betreffende authorization request, met daaruit weggelaten de niet-beschikbare zorgaanbieder-gegevensdienst-combinaties.
Verplicht indien het authorization request verzocht om een Abonnement. In dat geval is de scope-parameter gelijk aan die in de betreffende authorization request, maar met de Abonnements-einddatum gesteld op de door de Authorization Server toegekende, en dus mogelijk beperkte, waarde. De toegekende duur van het Abonnement is:

- niet hoger dan de in de authorization request gevraagde duur van het Abonnement;
- niet hoger dan de maximale abonnementsduur die de Zorgaanbieder in de Zorgaanbiederslijst had opgenomen bij die Gegevensdienst en die Interfaceversie;
- bij een gevraagde beëindiging gelijk aan 0.

Managementinformatie

Telling bij requests voor meerdere Gegevensdiensten

Wanneer gebruik wordt gemaakt van de mogelijkheid voor het verlenen van toestemming voor meerdere Gegevensdiensten van één Zorgaanbieder in één actie, dan moet hier ook rekening mee worden gehouden in de Managementinformatie. Dit betekent dat:

Een authorization request dan meetelt bij de telling voor alle Gegevensdiensten die zijn opgenomen in de scope van het request;
Een token request dan meetelt bij de telling voor alle Gegevensdiensten waarvoor de authorization code was uitgegeven.

Dit geldt voor zowel succesvolle als voor onsuccesvolle requests.

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 beveiligingsrisico's. De impact van een aanval op een PGO Server, waardoor access_tokens zouden kunnen worden misbruikt wordt wel groter, doordat de scope van het access_token nu meerdere gegevensdiensten kan omvatten. De scope blijft echter nog altijd beperkt tot 15 minuten toegang tot de gezondheidsgegevens van één Persoon. Om deze reden zijn geen extra maatregelen nodig.

Bijlagen

Implementatie MV-toestemming.pptx

	File	Modified
Labels No labels Preview View	Microsoft Powerpoint Presentation Implementatie MV-toestemming.pptx	Feb 10, 2022 by Ron van Holland (Unlicensed)

Browser not supported