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.

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 die recht geeft op het gebruik van een Gegevensdienst. Een access_token wordt pas uitgegeven:

  1. wanneer Persoon toestemming heeft gegeven voor alle toestemmingscategorieën die zijn verbonden aan de systeemrollen waaruit een Gegevensdienst bestaat, en
  2. wanneer de Aanbieder instaat voor beschikbaarheid van deze Gegevensdienst voor deze Persoon.

De toestemmingscategorie is bewust gekoppeld aan de systeemrol en niet aan de Gegevensdienst, zodat een Gegevensdienst kan bestaan uit onderdelen die in verschillende categorieën vallen, bijvoorbeeld "logistiek" en "behandeling".


Nadere uitwerking:

  • In een nieuwe lijst, de TCL, worden alle toestemmingscategorieën opgenomen, inclusief weergavenamen. De inhoud voor TCL wordt, in samenspraak met MedMij Standaarden, bepaald door de Stichting MedMij.
  • 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 bij voorkeur de gegevenscategorieën gehanteerd die binnen Mitz worden gebruikt, indien noodzakelijk aangevuld met eigen categorieën, ofwel
    • <Mitz> Behandelgegevens

    • <Mitz> Medicatiegegevens

    • <Mitz> Uitslagen

    • <Mogelijke noodzakelijke aanvulling - ter overweging> Logistieke gegevens
  • Uitgangspunt is om de Persoon niet met meer categorieën te confronteren dan strikt noodzakelijk, waarbij ernaar wordt gestreefd om alle gegevens die een aanbieder beschikbaar stelt te kunnen verzamelen op basis van een toestemming voor slechts één toestemmingscategorie.
  • 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 wordt niet geconfronteerd met toestemmingscategorieën en kan de gebruikersinteractie vormgeven op basis van de eigen visie, daarbij gebruikmakend van de use cases die zijn uitgewerkt in de beschikbare gegevensdiensten/informatiestandaarden.
  • 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. Een DVP hoeft geen kennis te hebben van toestemmingscategorieën.
  • DVA geeft vervolgens 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 set van toestemmingscategorieën waarvoor daadwerkelijk toestemming is gegeven,
  • 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. Autorisatie wordt vooralsnog slechts door een Autorisatie Server afgegeven voor aanbieder-gegevensdienst-combinaties waarvoor de betreffende DVA ook de Resource Server rol vervult.
  • DVA toetst bij ontvangst van een resource request in de Resource Server of het request past binnen één van de toegekende gegevensdiensten. Een Resource Server wordt niet geconfronteerd met toestemmingscategorieën.
  • NB. wanneer DVP vervolgens een nieuw Authorization Request laat sturen, dan zal Persoon wel weer opnieuw moeten inloggen en toestemmen.

Structuur van de TCL:

  • ToestemmingsCategorieën
    • Toestemming Categorie
      • ToestemmingsCategorieId
      • ToestemmingsCategorieWeergave
      • ToestemmingsCategorieToelichting

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 en dient door de DVA te worden aangegeven. De DVA dient hierbij de algemene regels te hanteren die door MedMij standaarden worden opgesteld.

Aanpassing van

TCL (nieuwe lijst), ZAL, authorization flow, toestemmingsverklaring, UC(I) Verzamelen

Aangezien deze RFC een nieuwe MedMij lijst introduceert is ervoor gekozen om middels deze RFC direct ook een herstructurering door te voeren op de wijze waarop de omgang met de verschillende lijsten in het afsprakenstelsel is beschreven. Inhoudelijk wijzigt hierdoor echter niets.

Impact op rollen

DVP, DVA

Impact op beheer

Ja

Ook TCL samenstellen en algemene regels voor koppelen categorieën aan gegevensdiensten/systeemrollen.

Impact op RnA

Ja

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)


...