Page tree
Skip to end of metadata
Go to start of metadata

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. Introductie van overkoepelende gegevensdienst(en).

Oplossingsrichting 2 is naar voren gekomen als de gewenste richting en wordt hier verder uitgewerkt.

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.

Aanpassing van


Impact op rollen


Impact op beheer


Impact op RnA


Impact op Acceptatie

Ja, vereist aanpassingen in acceptatiescripts.

Gerelateerd aan (Andere RFCs, PIM issues)

AF-1127

Eigenaar
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

Dienstverleners concurreren op de functionaliteiten

Positief

13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders

Positief

Dienstverleners zijn aanspreekbaar door de gebruiker

Positief

14 Uitwisseling is een keuze

Positief

De persoon wisselt gegevens uit met de aanbieder

Positief

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Positief

MedMij spreekt alleen af wat nodig is

Positief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Positief

De persoon en de aanbieder kiezen hun eigen dienstverlener

Positief

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Positief

De dienstverleners zijn deelnemers van het afsprakenstelsel

Positief

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Positief

10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling

Positief

19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat

Positief

Uitwerking


Risico's

Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.

Deze RFC introduceert geen nieuwe beveiligingsrisico's. De impact van een aanval op een PGO Server, waardoor access_tokens zouden kunnen worden misbruikt wordt wel groter, doordat de scope van het access_token nu meerdere gegevensdiensten kan omvatten. De scope blijft echter nog altijd beperkt tot 15 minuten toegang tot de gezondheidsgegevens van één Persoon. Om deze reden zijn geen extra maatregelen nodig.

Bijlagen

No files shared here yet.


  • No labels