Versions Compared

Old Version 348

changes.mady.by.user Ron van Holland (Unlicensed)

Saved on

compared with

New Version 349

changes.mady.by.user Ron van Holland (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

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.


Info
iconfalse
titleHuidige 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.


Info
iconfalse
titleAangepaste 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)


...

  • alle gevraagde GegevensdienstId's voorkomen op de OAuth Client List, bij de betreffende client_iden 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.

...