Document toolboxDocument toolbox

RFC0039 Toestemming voor meerdere diensten van één aanbieder

Owned by Ron van Holland (Unlicensed)
Last updated: Feb 07, 2022

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

  1. 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.

  2. 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:

  1. 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.
  2. Dit geldt voor alle verzamel-gegevensdiensten die een zorgaanbieder aanbiedt binnen één zelfde interfaceversie.

Voor deze RFC zijn een aantal oplossingsrichtingen overwogen:

  1. Toestemming voor lijst van gegevensdiensten;
  2. Toestemming voor toestemmingscategorie;
  3. Toestemming voor alle persoons- en gezondheidsgegevens van zorgaanbieder;
  4. 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:

  1. wanneer Persoon toestemming heeft gegeven voor beschikbaarstelling van alle persoons- en gezondheidsgegevens van een Aanbieder, en
  2. 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.

IDGegevensdienstNaamGegevensdienst in toestemmingverklaring
24Verzamelen Laboratoriumresultaten (*) 1.1Laboratoriumresultaten
46Verzamelen Laboratoriumresultaten 2.0
25Verzamelen Afspraken (*) 1.1Afspraken
47Verzamelen Afspraken 2.0
26Verzamelen Basisgegevens zorg (*) 2.1Basisgegevens zorg
48Verzamelen Basisgegevens zorg 3.0
28Verzamelen Huisartsgegevens (*) 1.1Huisartsgegevens
49Verzamelen Huisartsgegevens 2.0
32Verzamelen Basisgegevens GGZ (*) 1.1Basisgegevens GGZ
50Verzamelen Basisgegevens GGZ 2.0
33Verzamelen Documenten (*) 1.2Documenten


51Verzamelen Documenten 3.0
30Verzamelen Medicatieoverzichten 9.0Medicatieoverzichten
31Verzamelen Medicatiegegevens 9.0Medicatiegegevens
35Verzamelen Medicatiegegevens 9.A
36Verzamelen Meetwaarden vitale functies (*) 1.2Meetwaarden vitale functies
52Verzamelen Meetwaarden vitale functies 2.0
38Verzamelen Overgevoeligheden (*) 1.1Overgevoeligheden
54Verzamelen Overgevoeligheden 2.0
42Verzamelen Medicatiegerelateerde Overgevoeligheden (*) 1.AMedicatiegerelateerde Overgevoeligheden
58Verzamelen Medicatiegerelateerde Overgevoeligheden 2.A
43Verzamelen Verwijzing naar vragenlijst (*) 1.0Verwijzing naar vragenlijst
59Verzamelen Verwijzing naar vragenlijst 2.0
61Verzamelen Basisgegevens Langdurige Zorg 3.0Basisgegevens Langdurige Zorg

Gebruik van de ZAL

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

  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

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

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

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