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 de MedMij UC Verzamelen voor Personen vergroot. Deze RFC vormt één van de stappen in het vergroten van de gebruiksvriendelijkheid.

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

Deze oplossingsrichting maakt zowel meer grofmazige als meer fijnmazige toestemmingen mogelijk, e.e.a. afhankelijk van de gekozen omvang van een toestemmingscategorie.

Onderstaande figuur toont het gehanteerde metamodel.

Een gegevensdienst bestaat uit één of meerdere systeemrollen. Binnen een systeemrol zijn één of meerdere interacties gespecificeerd, waarmee gegevens kunnen worden uitgewisseld.

Om een interactie te mogen initieren is een access_token vereist. Een access_token wordt pas uitgegeven:

  1. wanneer Persoon toestemming heeft gegeven voor de toestemmingscategorie waaraan de betreffende systeemrol is gekoppeld, en
  2. wanneer de Aanbieder instaat voor beschikbaarheid van de gegevensdienst(en) voor Persoon.


Nadere uitwerking:

  • In de GNL worden ook alle toestemmingscategorieën opgenomen, inclusief weergavenamen.
  • In de ZAL wordt iedere systeemrol voorzien van een id van het toestemmingscategorie waaronder de betreffende systeemrol valt (een gegevensdienst zou in theorie dan meerdere categorieën kunnen omspannen). Voor de systeemrollen binnen de gegevensdienst "verzamelen documenten" is de toestemmingscategorie namelijk afhankelijk van de categorie waaronder de zorgaanbieder valt (zie onderstaande tabel). Om deze reden moet de toestemmingscategorie worden opgenomen in de ZAL en niet in de GNL.
  • Als toestemmingscategorieën worden mogelijk de gegevenscategorieën gehanteerd die binnen Mitz worden gebruikt, aangevuld met de noodzakelijke eigen categorieën, ofwel
    • <Mitz> Behandelgegevens

    • <Mitz> Medicatiegegevens

    • <Mitz> Uitslagen

    • <MedMij> Logistieke gegevens
  • 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.
  • DVA bepaalt de benodigde toestemmingscategorie of -categorieën  en toont bijbehorende weergavenaam en toelichtende tekst. Hierbij worden zo mogelijk (bij vroege beschikbaarheidstoets) slechts toestemmingen gevraagd voor categorieën die daadwerkelijk beschikbaar zijn om te verzamelen, en waar de DVP, blijkens de OCL, ook voor is gekwalificeerd.
  • DVA geeft vervolgens een access_token uit voor een scope die wordt bepaald door de set van toestemmingscategorieën waarvoor daadwerkelijk toestemming is gegeven, en die (bij vroege beschikbaarheidstoets) daadwerkelijk beschikbaar is voor verzamelen. De scope van de Token Response bevat de 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, 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 het request past binnen één van de toegekende gegevensdiensten.

Gewijzigde structuur van de GNL:

  • Root
    • ToestemmingsCategorieën
      • Toestemming Categorie
        • ToestemmingsCategorieId
        • ToestemmingsCategorieWeergave
    • Gegevensdiensten
      • Gegevensdienst
        • GegevensdienstId

Gewijzigde structuur van de ZAL (slechts deels getoond):

  • Gegevensdienst
    • GegevensdienstId
    • Systeemrollen
      • Systeemrol
        • Systeemrolcode
        • ToestemmingsCategorieId

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

IDGegevensdienstHuidige weergavenaam in toestemmingverklaringSysteemrolToestemmingscategorieTe verzamelen bij *
24Verzamelen Laboratoriumresultaten (*) 1.1LaboratoriumresultatenLAB-1.1-LRB-FHIRUitslagenDiagnostische centra
46Verzamelen Laboratoriumresultaten 2.0LAB-2.0-LRB-FHIR
25Verzamelen Afspraken (*) 1.1AfsprakenEA-1.1-AFB-FHIRLogistieke gegevensAlle zorgaanbieders
47Verzamelen Afspraken 2.0EA-2.0-AFB-FHIR
26Verzamelen Basisgegevens zorg (*) 2.1Basisgegevens zorgMM-2.1-BZB-FHIRBehandelgegevensMedisch-specialistische instellingen
48Verzamelen Basisgegevens zorg 3.0MM-3.0-BZB-FHIR
28Verzamelen Huisartsgegevens (*) 1.1HuisartsgegevensMM-1.1-HGB-FHIRBehandelgegevensHuisartspraktijken en -posten
49Verzamelen Huisartsgegevens 2.0MM-2.0-HGB-FHIR
32Verzamelen Basisgegevens GGZ (*) 1.1Basisgegevens GGZMM-1.1-GGB-FHIRBehandelgegevensGeestelijke 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) **

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) **

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-FHIR

Uitslagen (voor diagnostische centra) **

Behandelgegevens (voor de overige zorgaanbieders) **

Alle zorgaanbieders, behalve apotheken
52Verzamelen Meetwaarden vitale functies 2.0MM-2.0-MVB-FHIR
38Verzamelen Overgevoeligheden (*) 1.1OvergevoelighedenMM-1.1-AIB-FHIR

Medicatiegegevens (voor apotheken) **

Behandelgegevens (voor de overige zorgaanbieders) **

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


*) 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 betreffende gegevensdienst 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 dergelijke combi-gegevensdienst wordt gemaakt voor de 2019 standaard en voor de 2020 standaard.
  • Een DVA die is gekwalificeerd voor (systeemrollen van) 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 toestemmingscategorie3 - 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.

Ook mogelijk om meer fijnmazige toestemmingen te 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.

o

Reikwijdte van toestemming is in overeenstemming met 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 en GNL 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+3-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)


...