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 toestemmingscategorie;
  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 toestemmingscategorie

  • Laat Persoon toestemming geven voor uitwisseling van gegevens die behoren tot een specifieke toestemmingscategorie.
  • In de GNL worden gegevensdiensten gegroepeerd in categorieën en wordt iedere toestemmingscategorie voorzien van een weergavenaam en een toelichtende tekstalle toestemmingscategorieën, toestemmingsonderdelen en gegevensdiensten opgenomen, inclusief weergavenamen en hun onderlinge relaties.
  • In de ZAL wordt iedere systeemrol voorzien van een id van het toestemmingsonderdeel waaronder de betreffende systeemrol valt. Voor de systeemrollen binnen de gegevensdienst "verzamelen documenten" is het toestemmingsonderdeel namelijk afhankelijk van de categorie waaronder de zorgaanbieder valt (zie onderstaande tabel). Om deze reden moet het toestemmingsonderdeel-id ook worden opgenomen in de ZAL en niet slechts in de GNL.
  • Als toestemmingscategorieën zouden (initieel) de gegevenscategorieën kunnen worden gehanteerd die binnen Mitz worden gebruikt, aangevuld met de noodzakelijke eigen categorieën, dus
    • <Mitz> Behandelgegevens - "Dit is een beperkte set van gegevens die nodig is voor goede zorg. Bijvoorbeeld over uw gezondheid, medicijnen en eventuele allergieën."

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

    • <Mitz> Uitslagen - "Uitslagen zijn bijvoorbeeld röntgenfoto’s, scans, en labuitslagen."

    • Logistieke gegevens - "Logistieke gegevens zijn bijvoorbeeld planningen, afspraken en taken."
  • Wanneer DVP een Authorization Request samenstelt, dan bepaalt zij m.b.v. de ZAL en de GNL de toestemmingscategorie-id's en/of de toestemmingsonderdeel-id's die moet worden opgenomen in de scope parameter.
  • DVA toont de weergavenaam en toelichtende tekst die hoort bij de gevraagde toestemmingscategorieën en/of toestemmingsonderdelen.
  • DVA geeft vervolgens een access_token uit voor een scope die wordt bepaald door de set van toestemmingsonderdeel-id's waarvoor daadwerkelijk toestemming is gegeven. De scope van de Token Response bevat derhalve één of meerdere toestemmingsonderdeel-id's.
  • DVP kan vervolgens o.b.v. een verkregen access_token de alle gegevensdiensten/systeemrollen gebruiken waarvoor toestemming is gegeven, mits (vooralsnog) deze worden aangeboden via de DVA die het access_token heeft uitgegeven, d.w.z. mits de gegevensdiensten in de ZAL eenzelfde AuthorizationEndpointUri hanteren.
  • DVA toetst bij ontvangst van een resource request of deze past binnen één van de systeemrollen die is verbonden aan de scope van het access_token.

Gewijzigde structuur van de GNL:

  • Root
    • ToestemmingsCategorieën
      • Toestemming Categorie
        • ToestemmingsCategorieId
        • ToestemmingsCategorieWeergave
    • ToestemmingsOnderdelen
      • ToestemmingsOnderdeel
        • ToestemmingsOnderdeelId
        • ToestemmingsOnderdeelWeergave
        • ToestemmingsCategorieën
          • ToestemmingsCategorie
            • ToestemmingsCategorieId
    • Gegevensdiensten
      • Gegevensdienst
        • GegevensdienstId

Gewijzigde structuur van de ZAL (slechts deels getoond):

  • Gegevensdienst
    • GegevensdienstId
    • Systeemrollen
      • Systeemrol
        • Systeemrolcode
        • ToestemmingsOnderdeelId

Onderstaande figuur toont het gehanteerde metamodel.

Een toestemmingscategorie bestaat uit één of meerdere toestemmingsonderdelen.

Een gegevensdienst bestaat uit één of meerdere systeemrollen. Bij het gebruik van een systeemrol kunnen één of meerdere informatiebouwstenen worden uitgewisseld. Een dergelijke informatiebouwsteen kan een ZIB zijn, zoals beheert door het ZIB-centrum, maar dit is niet altijd het geval.

Om gegevens te mogen verzamelen bij een systeemrol is een access_token vereist die is uitgegeven voor het toestemmingsonderdeel dat is gekoppeld aan de systeemrol. Wanneer toestemming wordt verkregen voor een toestemmingscategorie, dan wordt een access_token uitgegeven voor alle toestemmingsonderdelen waaruit de toestemmingscategorie bestaat.

Onderstaande tabel toont de relatie tussen de huidige verzamel-gegevensdiensten, systeemrollen, de initiële toestemmingscategorieën en de toestemmingsonderdelen.

IDGegevensdienstHuidige weergavenaam in toestemmingverklaringSysteemrolToestemmingsonderdeelToestemmingscategorieTe verzamelen bij *
24Verzamelen Laboratoriumresultaten (*) 1.1LaboratoriumresultatenLAB-1.1-LRB-FHIRLabuitslagenUitslagenDiagnostische centra
46Verzamelen Laboratoriumresultaten 2.0LAB-2.0-LRB-FHIR
25Verzamelen Afspraken (*) 1.1AfsprakenEA-1.1-AFB-FHIRAfsprakenLogistieke gegevensAlle zorgaanbieders
47Verzamelen Afspraken 2.0EA-2.0-AFB-FHIR
26Verzamelen Basisgegevens zorg (*) 2.1Basisgegevens zorgMM-2.1-BZB-FHIRBehandelgegevensBehandelgegevensMedisch-specialistische instellingen
48Verzamelen Basisgegevens zorg 3.0MM-3.0-BZB-FHIR
28Verzamelen Huisartsgegevens (*) 1.1HuisartsgegevensMM-1.1-HGB-FHIRBehandelgegevensBehandelgegevensHuisartspraktijken en -posten
49Verzamelen Huisartsgegevens 2.0MM-2.0-HGB-FHIR
32Verzamelen Basisgegevens GGZ (*) 1.1Basisgegevens GGZMM-1.1-GGB-FHIRBehandelgegevensBehandelgegevensGeestelijke gezondheidszorg
50Verzamelen Basisgegevens GGZ 2.0MM-2.0-GGB-FHIR
33Verzamelen Documenten (*) 1.2Documenten

MM-1.2-PLB-FHIR

MM-1.2-PDB-FHIR    

Uitslagen (voor diagnostische centra) **

Medicatiegegevens (voor apotheken) **

Behandelgegevens (voor de overige zorgaanbieders) **


Uitslagen (voor diagnostische centra) **

Medicatiegegevens (voor apotheken) **

Behandelgegevens (voor de overige zorgaanbieders) **

Alle zorgaanbieders


51Verzamelen Documenten 3.0

MM-3.0-PLB-FHIR

MM-3.0-PDB-FHIR    

30Verzamelen Medicatieoverzichten 9.0MedicatieoverzichtenMP-9.0.7-MOB-FHIR

Medicatiegegevens (voor apotheken) **

Behandelgegevens (voor de overige zorgaanbieders) **



Medicatiegegevens (voor apotheken) **

Behandelgegevens (voor de overige zorgaanbieders) **

Alle zorgaanbieders, behalve diagnostische centra
31Verzamelen Medicatiegegevens 9.0MedicatiegegevensMP-9.0.7-MGB-FHIR
35Verzamelen Medicatiegegevens 9.AMP-9.A.1-MGB-FHIR
36Verzamelen Meetwaarden vitale functies (*) 1.2Meetwaarden vitale functiesMM-1.2-MVB-FHIRMeetwaardenBehandelgegevensAlle zorgaanbieders, behalve apotheken
52Verzamelen Meetwaarden vitale functies 2.0MM-2.0-MVB-FHIR
38Verzamelen Overgevoeligheden (*) 1.1OvergevoelighedenMM-1.1-AIB-FHIROvergevoeligheden

Medicatiegegevens (voor apotheken) **

Behandelgegevens (voor de overige zorgaanbieders) **

Alle zorgaanbieders
54Verzamelen Overgevoeligheden 2.0MM-2.0-AIB-FHIR
42Verzamelen Medicatiegerelateerde Overgevoeligheden (*) 1.AMedicatiegerelateerde OvergevoelighedenMM-1.A-AIB-FHIROvergevoelighedenMedicatiegegevensApotheken
58Verzamelen Medicatiegerelateerde Overgevoeligheden 2.AMM-2.A-AIB-FHIR
43Verzamelen Verwijzing naar vragenlijst (*) 1.0Verwijzing naar vragenlijstVL-1.0-QLB-FHIRTakenLogistieke gegevensAlle zorgaanbieders
59Verzamelen Verwijzing naar vragenlijst 2.0VL-2.0-QLB-FHIR
61Verzamelen Basisgegevens Langdurige Zorg 3.0Basisgegevens Langdurige ZorgMM-3.0-LZB-FHIRBehandelgegevensBehandelgegevensVerpleegzorg


*) 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 toestemmingscategorie waaronder de gegevensdienst "verzamelen documenten" valt, is afhankelijk van de categorie van de zorgaanbieder die de documenten aanbiedt.


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)


...