Page tree

Versions Compared

Key

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

...

Waarom is deze RFC nodig?

Met deze RFC wordt de gebruiksvriendelijkheid van MedMij voor Personen vergroot.

Deze RFC vormt de eerste stap in het vergroten van de gebruiksvriendelijkheid. De visie en roadmap voor dit onderwerp is opgenomen in de presentatie die tijdens de expertsessie is gehouden.

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.

In een later stadium zal worden bekeken of binnen het afsprakenstelsel ook afspraken kunnen worden opgenomen om in één keer toestemming te kunnen geven voor een set van (gegevens)diensten van een aanbieder, die worden aangeboden via verschillende dienstverleners aanbieder. Dit behelst, naast een vertrouwens- en verwerkersrelatie tussen de betrokken DVA's, ook een (gestandaardiseerd) koppelvlak tussen de resourceserver van DVA-1 en de autorisatieserver van DVA-2.

Voor deze RFC zijn een aantal oplossingsrichtingen overwogen:

  1. Toestemming voor lijst van gegevensdiensten;
  2. Toestemming voor gegevenscategorie;
  3. Introductie van overkoepelende gegevensdienst(en).


Oplossingsrichting 1 - Toestemming voor lijst van gegevensdiensten

In het huidige afsprakenstelsel worden authorization- en token endpoints van een specifieke zorgaanbieder geadministreerd op het niveau van interfaceversie (release van het afsprakenstelsel) EN gegevensdienst. Om een meervoudige toestemming mogelijk te maken zal naast de bestaande ZAL een nieuwe lijst op de MedMij stelselnode worden geïntroduceerd: de Autorisatieserverlijst (ASL).

De ASL biedt een andere view op de gegevens die ook zijn opgenomen in de ZAL, en heeft de volgende logische structuur:

  • Autorisatieservers (1) - alle autorisatieservers in het MedMij netwerk
    • Autorisatieserver (0..n)
      • InterfaceversieId (1..n) - de interfaceversies die worden ondersteund door deze autorisatieserver
      • Aanbieder (0..n) - de aanbieders die diensten aanbieden middels deze autorisatieserver
        • Aanbiedernaam (1)
        • GegevensdienstId (1..n) - de gegevensdiensten die door de betreffende aanbieder worden geboden middels deze autorisatieserver
      • AuthorizationEndpointuri (1)
      • TokenEndpointuri (1)

Voor eenzelfde aanbieder kunnen meerdere autorisatieservers zijn opgenomen in de ASL. Ook is het mogelijk dat voor eenzelfde gegevensdienst van een aanbieder meerdere autorisatieservers zijn opgenomen in de ASL. Dit is nodig wanneer een gegevensdienst wordt aangeboden o.b.v. meerdere interfaceversies, en eenzelfde autorisatieserver niet alle interfaceversies ondersteunt.

Info
titleOverwogen alternatief voor ASL

Als nieuwe view op de ZAL is ook onderstaande structuur overwogen. Deze structuur is afgevallen omdat op basis ervan geen doorontwikkeling mogelijk is naar het geven van toestemming voor meerdere diensten van verschillende aanbieders.

  • Aanbieders (1) - alle aanbieders in het MedMij netwerk
    • Aanbieder (0..n)
      • Aanbiedernaam (1)
      • Autorisatieserver (0..n) - alle autorisatieservers die één of meerdere diensten aanbieden voor de betreffende aanbieder
        • InterfaceversieId (1..n) - de interfaceversies die worden ondersteund door deze autorisatieserver
        • GegevensdienstId (1..n) - de gegevensdiensten die door de betreffende aanbieder worden geboden middels deze autorisatieserver
        • AuthorizationEndpointuri (1)
        • TokenEndpointuri (1)

DVA's moeten bij MedMij beheer aangeven voor welke interfaceversies, aanbieders en gegevensdiensten zij de mogelijkheid tot meervoudige toestemming bieden. Dit wordt gereflecteerd in de ASL. De inhoud van de ZAL en ASL worden door MedMij beheer in sync gehouden.

Bepalen juiste authorization endpoint door DVP:

  1. Zoek in de ASL naar alle Autorisatieservers die de gewenste Interfaceversie en Aanbieder ondersteunen.
  2. Bepaal welk van de gevonden Autorisatieservers de gewenste Gegevensdiensten ondersteunen.

De flow voor verzamelen verloopt dan als volgt:

  1. Persoon kiest de (één) aanbieder en de gewenste (gegevens)diensten.
  2. DVP bepaalt, m.b.v. de ASL, het juiste authorization endpoint en het juiste token endpoint.
  3. De autorisatieserver ontvangt, van de OAuth User Agent, een Authorization Request met in de scope meerdere aanbieder-dienst-combinaties.
  4. Gebruiker authentiseert zich bij een Authenticatie Provider en wordt teruggestuurd naar de autorisatieserver.
  5. Optioneel: de autorisatieserver toetst de beschikbaarheidsvoorwaarde voor de gewenste (gegevens)diensten.
  6. De autorisatieserver toont een toestemmingscherm met de tekst:
    • U geeft hierbij Naamaanbieder toestemming om met NaamLeverancierPGO, voor het doel deze persoons- en gezondheidsgegevens op te nemen in uw persoonlijke gezondheidsomgeving, de volgende gegevens uit te wisselen:
      - <NaamGegevensdienst>;
      - <NaamGegevensdienst>;
      - <NaamGegevensdienst>.

      De volgende, van de door u gevraagde, gegevens worden door <Naamaanbieder> niet aan u beschikbaar gesteld en vallen daarom buiten de reikwijdte van de te verlenen toestemming:
      - <NaamGegevensdienst>.
  7. De PGO server verkrijgt een access_token voor de toegekende scope.
  8. DVP bepaalt, m.b.v. de ZAL, de juiste resource endpoints.
  9. De PGO server gebruikt het access_token bij de benodigde interacties met de resource server.


Oplossingsrichting 2 - Toestemming voor gegevenscategorie

  • Laat Persoon toestemming geven voor uitwisseling van gegevens die behoren tot een specifieke categorie van gegevens.
  • In de ZAL wordt iedere gegevensdienst voorzien van een id van de gegevenscategorie waaronder de betreffende gegevensdienst valt. Voor de gegevensdienst "verzamelen documenten" is de gegevenscategorie afhankelijk van de categorie waaronder de zorgaanbieder valt (zie onderstaande tabel).
  • In de GNL worden gegevensdiensten gegroepeerd in categorieën en wordt iedere gegevensdienstcategorie voorzien van een weergavenaam en een toelichtende tekst.
  • Als gegevenscategorieën zouden dezelfde kunnen worden gehanteerd als die binnen Mitz worden gebruikt, namelijk
    • Behandelgegevens - Dit is een beperkte set van gegevens die nodig is voor goede zorg. Bijvoorbeeld over uw gezondheid, medicijnen en eventuele allergieën.

    • Medicatiegegevens - Medicatiegegevens bestaan uit de medicatie die u bij uw apotheken heeft meegekregen. Ook worden uw overgevoeligheden, intoleranties en allergieën gedeeld.

    • Uitslagen - Uitslagen zijn bijvoorbeeld röntgenfoto’s, scans, en labuitslagen.

  • Wanneer DVP een Authorization Request samenstelt, dan bepaalt zij m.b.v. de ZAL de gegevenscategorie-id die moet worden opgenomen in de scope parameter.
  • DVA toont de weergavenaam en toelichtende tekst die hoort bij de gevraagde gegevensdienstcategorie.
  • DVA geeft vervolgens een access_token uit voor een scope die wordt bepaald door de set van gegevensdienst-id's die ermee kunnen worden gebruikt
  • DVP kan vervolgens o.b.v. een verkregen access_token de ertoe behorende gegevensdiensten gebruiken, mits (vooralsnog) deze worden aangeboden via de DVA die het access_token heeft uitgegeven, d.w.z. mits zij in de ZAL eenzelfde AuthorizationEndpointUri bevatten.
  • DVA toetst bij ontvangst van een resource request of deze past binnen één van de gegevensdiensten die deel uitmaakt van de scope van het access_token.

Onderstaande tabel toont de relatie tussen gegevensdiensten en gegevenscategorieën.

IDGegevensdienstHuidige weergavenaam in toestemmingverklaringTe verzamelen bij *Gegevenscategorie
24Verzamelen Laboratoriumresultaten (*) 1.1LaboratoriumresultatenDiagnostische centraUitslagen
46Verzamelen Laboratoriumresultaten 2.0
25Verzamelen Afspraken (*) 1.1AfsprakenAlle zorgaanbiedersBehandelgegevens
47Verzamelen Afspraken 2.0
26Verzamelen Basisgegevens zorg (*) 2.1Basisgegevens zorgMedisch-specialistische instellingenBehandelgegevens
48Verzamelen Basisgegevens zorg 3.0
28Verzamelen Huisartsgegevens (*) 1.1HuisartsgegevensHuisartspraktijken en -postenBehandelgegevens
49Verzamelen Huisartsgegevens 2.0
32Verzamelen Basisgegevens GGZ (*) 1.1Basisgegevens GGZGeestelijke gezondheidszorgBehandelgegevens
50Verzamelen Basisgegevens GGZ 2.0
33Verzamelen Documenten (*) 1.2DocumentenAlle zorgaanbieders

Uitslagen (voor diagnostische centra) **

Medicatiegegevens (voor apotheken) **

Behandelgegevens (voor de overige zorgaanbieders) **

51Verzamelen Documenten 3.0
30Verzamelen Medicatieoverzichten 9.0MedicatieoverzichtenAlle zorgaanbieders, behalve diagnostische centra

Behandelgegevens EN

Medicatiegegevens ***


31Verzamelen Medicatiegegevens 9.0Medicatiegegevens
35Verzamelen Medicatiegegevens 9.A
36Verzamelen Meetwaarden vitale functies (*) 1.2Meetwaarden vitale functiesAlle zorgaanbieders, behalve apothekenBehandelgegevens
52Verzamelen Meetwaarden vitale functies 2.0
38Verzamelen Overgevoeligheden (*) 1.1OvergevoelighedenAlle zorgaanbieders

Behandelgegevens EN

Medicatiegegevens ***

54Verzamelen Overgevoeligheden 2.0
42Verzamelen Medicatiegerelateerde Overgevoeligheden (*) 1.AMedicatiegerelateerde OvergevoelighedenApothekenMedicatiegegevens
58Verzamelen Medicatiegerelateerde Overgevoeligheden 2.A
43Verzamelen Verwijzing naar vragenlijst (*) 1.0Verwijzing naar vragenlijstAlle zorgaanbiedersBehandelgegevens
59Verzamelen Verwijzing naar vragenlijst 2.0
61Verzamelen Basisgegevens Langdurige Zorg 3.0Basisgegevens Langdurige ZorgVerpleegzorgBehandelgegevens


*) De kolom "Te verzamelen bij" is gevuld a.d.h.v. de categorieën van zorgaanbieders die binnen Mitz worden onderkend:

  1. Huisartspraktijken en -posten: huisartsenpraktijk, huisartsenpost, huisartsinstelling en apotheekhoudende huisarts
  2. Medisch-specialistische instellingen: ziekenhuis, zelfstandige kliniek, polikliniek (als onderdeel van ziekenhuis) en zelfstandig opererende ziekenhuisapotheek
  3. Verpleegzorg: thuiszorg en verpleeg-/verzorgingshuis
  4. Mondzorg, paramedische praktijken en JGZ: tandartspraktijk, orthodontiepraktijk, tandprothetische praktijk, mondhygiënistenpraktijk, centrum voor bijzondere tandheelkunde, optometriepraktijk, orthoptistenpraktijk, fysiotherapiepraktijk, ergotherapiepraktijk, oefentherapiepraktijk, huidtherapiepraktijk, diëtistenpraktijk, logopediepraktijk, podotherapiepraktijk, jeugdgezondheidszorg en verloskundigepraktijk
  5. Geestelijke gezondheidszorg: psychiatriepraktijk, psychologiepraktijk, psychotherapiepraktijk en geestelijke gezondheidszorg
  6. Apotheken: (openbare) apotheek
  7. Diagnostische centra: radiotherapeutisch centrum, laboratorium, echocentrum, diagnostisch centrum en bevolkingsonderzoek kanker

**) De gegevenscategorie waaronder de gegevensdienst "verzamelen documenten" valt, is afhankelijk van de categorie van de zorgaanbieder die de documenten aanbiedt.

***) Sommige gegevensdiensten vallen onder meerdere gegevenscategorieën, en kunnen dus worden gebruikt wanneer toestemming is verkregen voor één van de betreffende gegevenscategorieën.


Oplossingsrichting 3 - Introductie van overkoepelende gegevensdienst(en)

  • Introduceer voor sets van gegevensdiensten die vaak allen door een zorgaanbieder worden aangeboden een nieuwe, overkoepelende gegevensdienst, die alle gegevensdiensten uit de set bevat. De eerste kandidaat hiervoor is de set van "verzamelen huisartsgegevens" en "verzamelen documenten" die in VIPP OPEN beiden verplicht worden gesteld. De overkoepelende gegevensdienst zou zijn "verzamelen huisartsgegevens inclusief documenten".
  • Een DVA die is gekwalificeerd voor alle onderliggende gegevensdiensten mag dan zelf in de MedMij R&A zowel de onderliggende gegevensdiensten als de overkoepelende gegevensdienst opvoeren.
  • DVP's kunnen vervolgens in de ZAL kiezen welke gegevensdienst ze wensen te gebruiken.


Info
titleToestemming in de WGBO

WGBO artikel 457:
1. Onverminderd het in artikel 448 lid 3, tweede volzin, bepaalde draagt de hulpverlener zorg, dat aan anderen dan de patiënt geen inlichtingen over de patiënt dan wel inzage in of afschrift van de bescheiden, bedoeld in artikel 454, worden verstrekt dan met toestemming van de patiënt. Indien verstrekking plaatsvindt, geschiedt deze slechts voor zover daardoor de persoonlijke levenssfeer van een ander niet wordt geschaad. De verstrekking kan geschieden zonder inachtneming van de beperkingen, bedoeld in de voorgaande volzinnen, indien het bij of krachtens de wet bepaalde daartoe verplicht.
2. Onder anderen dan de patiënt zijn niet begrepen degenen die rechtstreeks betrokken zijn bij de uitvoering van de behandelingsovereenkomst en degene die optreedt als vervanger van de hulpverlener, voor zover de verstrekking noodzakelijk is voor de door hen in dat kader te verrichten werkzaamheden.
3. Daaronder zijn evenmin begrepen degenen wier toestemming ter zake van de uitvoering van de behandelingsovereenkomst op grond van de artikelen 450 en 465 is vereist. Indien de hulpverlener door inlichtingen over de patiënt dan wel inzage in of afschrift van de bescheiden te verstrekken niet geacht kan worden de zorg van een goed hulpverlener in acht te nemen, laat hij zulks achterwege.


Vergelijking van de oplossingsrichtingen

Aspect1 - Toestemming voor lijst van gegevensdiensten2 - Toestemming voor gegevenscategorie3 - Introductie van overkoepelende gegevensdienst(en)
Gebruiksvriendelijkheid

o

Niet meer of minder begrijpelijk voor gebruikers dan de huidige werkwijze.

++

Begrijpelijker teksten voor gebruikers en in lijn met Mitz toestemmingen die gebruikers ook gaan geven.

o

Niet meer of minder begrijpelijk voor gebruikers dan de huidige werkwijze.

Juridisch

o

Niet meer of minder passend dan de huidige werkwijze.

+

Mitz categorieën zijn juridisch uitvoerig getoetst. MedMij toestemming zou juridisch in lijn worden gebracht met de vereiste toestemming voor uitwisseling tussen zorgaanbieders onderling.

o

Niet meer of minder passend dan de huidige werkwijze.

Privacy

o

Reikwijdte van toestemming is in overeenstemming met reikwijdte van gegevens die daadwerkelijk door DVP (kunnen) worden verzameld. Staat gelijk aan de huidige werkwijze.

-

Reikwijdte van toestemming is in sommige gevallen groter dan de reikwijdte van gegevens die daadwerkelijk door DVP (kunnen) worden verzameld.

o

Reikwijdte van toestemming is in overeenstemming met reikwijdte van gegevens die daadwerkelijk door DVP (kunnen) worden verzameld. Staat gelijk aan de huidige werkwijze.

Impact voor DVP

--

ASL gebruiken naast ZAL.

Omgaan met nieuwe vulling van scope parameter in Authorization Request en Token Response.

-

Aangepaste ZAL gebruiken.

Omgaan met nieuwe vulling van scope parameter in Authorization Request en Token Response.

o

Gebruik van nieuw gegevensdienst-id inbouwen in PGO.

Impact voor DVZA

--

In RnA registeren voor welke gegevensdiensten een meervoudige toestemming mogelijk is.

Nieuwe vulling van scope aankunnen.

Nieuw toestemmingscherm met bijbehorende logica implementeren (lijsten en niet-beschikbaarheid).

-

In RnA zorgaanbiedercategorie van zorgaanbieders registreren.

Verwerken andere vulling scope parameter in Authorization Request.

Nieuw toestemmingscherm en vulling o.b.v. aangepaste GNL.

Nieuwe vulling van scope in Token Response

Toetsing van resource requests o.b.v. nieuwe vulling scope.

o

Autorisatie van nieuw gegevensdienst-id inbouwen/configureren in de resource server.

Registeren nieuwe gegevensdienst in RnA.

Impact op RnA

-

RnA moet registeren voor welke gegevensdiensten een meervoudige toestemming mogelijk is.

RnA moet ASL genereren en aanbieden.

-

Administratie nodig van gegevensdienstcategorieën en zorgaanbiedercategorieën.

Aanpassingen aan ZAL en GNL.

+

Opvoeren nieuwe gegevensdienst.

Toekomstvastheid

+

Is te gebruiken voor willekeurige combinaties van verzamel gegevensdiensten.

++

In lijn met visie op regie, d.w.z. starten met grote scope toestemming en desgewenst laten inperken door gebruiker op toestemmingsscherm.

In lijn met landelijke ontwikkelingen zorgaanbieder-zorgaanbieder toestemmingen.

Is te gebruiken voor willekeurige combinaties van verzamel gegevensdiensten.

--

Biedt geen lange termijnoplossing.

Totaalscore-4+1-1


Aanpassing van

De OAuth-flow in het MedMij afsprakenstelsel en de introductie van een nieuwe lijst op de stelselnode.

Impact op rollen

DVP (optioneel), DVA (optioneel).

Impact op beheer

Administreren van interfaceversies, aanbieders en gegevensdiensten waarvoor een DVA meervoudige toestemming ondersteunt.

Impact op RnA

Administreren van interfaceversies, aanbieders en gegevensdiensten waarvoor een DVA meervoudige toestemming ondersteunt. Beschikbaarstellen van een nieuwe lijst, de ASL.

Impact op Acceptatie

Ja, vereist aanpassingen in acceptatiescripts.

Gerelateerd aan (Andere RFCs, PIM issues)

AF-1127

Eigenaar
Implementatietermijn

1.4.0

Motivatie verkorte RFC procedure (patch)


...