Versions Compared

Key

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

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

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.

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)


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

Architectuur en technische specificaties

>> aanpassen plaat bovenaan pagina (toevoegen UC en UCI Opvragen ASL)

Coördinatie, regie en uitwisseling

Toevoegen UC Opvragen ASL, UCI Opvragen ASL en ASL interface op diverse plaatsen.

Processen en informatie

>> aanpassen plaat bovenaan pagina (toevoegen UC Opvragen ASL

...

Info
titleToelichting

De verantwoordelijkheden op deze laag zijn geordend in hoofdstukken en secties als volgt:

  • Dossier
    • Use cases
    • Gegevensdiensten
    • Authenticatie
    • Autorisatie
  • Lijsten
    • Zorgaanbiederslijst
    • Autorisatieserverlijst
    • OAuth Client List
    • Gegevensdienstnamenlijst
    • Whitelist
  • Logging en portabiliteit

Op meerdere plaatsen komen daarbij use cases (op deze laag) en use case-implementaties (op de Applicatie-laag) aan de orde. Een use case-implementatie is de implementatie van de use case met dezelfde naam. In deze release van het MedMij Afsprakenstelsel zijn er negen use cases, waarvan er zich zeven afspelen tussen het Persoons- en het Zorgaanbiedersdomein. Van deze zeven maken, om de interoperabiliteit in het MedMij-netwerk te borgen, stroomdiagrammen deel uit van het MedMij Afsprakenstelsel. De andere twee spelen zich helemaal binnen het Persoonsdomein af. Hiervan eist het MedMij Afsprakenstelsel wel dat erin moet worden voorzien, maar niet of slechts deels hoe; dat wordt aan de vrijheid van de MedMij-deelnemers gelaten.

Het gaat om de volgende use cases:

Use case

Stroomdiagram

Hoofdfunctie(s)

UC VerzamelenmetRegie en Uitwisseling
UC DelenmetRegie en Uitwisseling
UC Raadplegen dossierzonderRegie
UC PortabiliteitsrapportzonderRegie
UC AbonnerenmetRegie
UC NotificerenmetRegie en Uitwisseling
UC Opvragen ZALmetCoördinatie
UC Opvragen ASLmetCoördinatie
UC Opvragen OCLmetCoördinatie
UC Opvragen GNLmetCoördinatie

Voor registratie van Deelnemers en de vanwege hun deelname belangrijke gegevens zijn vooralsnog geen separate use cases geïdentificeerd, omdat registratie als een secundair proces wordt gezien. Zie hiervoor de pagina Operationele processen.


De interpretatie door een Zorggebruiker van zorg- en gezondheidsinformatie die hij heeft verzameld bij een Zorgaanbieder, en de interpretatie door een Zorgaanbieder van zulke informatie die met hem/haar gedeeld is door een Zorggebruiker, hangt niet alleen af van de inhoud van die informatie, maar ook van de partij die de betreffende informatie oorspronkelijk heeft geregistreerd. We gebruiken hiervoor niet zomaar de term Bron, omdat deze term in de zin van het MedMij Afsprakenstelsel niet per se de oorspronkelijke herkomst (de auteur) betekent, maar alleen de onmiddellijke herkomst, gezien vanuit de Uitgever. In het MedMij Afsprakenstelsel is de auteursrol geen juridische rol. Dat betekent niet alleen dat er binnen de grenzen van het MedMij Afsprakenstelsel momenteel geen basis is om auteursauthenticiteit (met bijvoorbeeld certificaten) te arrangeren, maar het brengt ook met zich mee dat informatie over de auteur, hoe wezenlijk ook, voor het MedMij Afsprakenstelsel een gegevens-inhoudelijke aangelegenheid is. Die informatie wordt immers ook gebruikt voor de interpretatie van de gedeelde zorg- en gezondheidsinformatie. Omdat, conform principe 1, het MedMij Afsprakenstelsel gegevensneutraal wil zijn, wordt de auteursinformatie een onderdeel geacht van de inhoud van een Gegevensdienst.


Gegevensdiensten

6. MedMij Beheer zal alleen in de Zorgaanbiederslijst en in de Autorisatieserverlijst opnemen dat een zekere Gegevensdienst door een zekere Zorgaanbieder via een zekere Bron, respectievelijk Lezer, wordt aangeboden, indien zij (Stichting MedMij) heeft vastgesteld dat de Dienstverlener zorgaanbieder die daarbij de Bron, respectievelijk Lezer, is, voldoet aan de specifiek op die Gegevensdienst toepas­selij­ke eisen.

7a. Voor elke Gegevensdienst waarvan de Zorgaanbiederslijst of de Autorisatieserverlijst aan­geeft dat een zekere Zorgaanbieder deze aanbiedt, zal Bron, respectievelijk Lezer, ervoor zorgdragen dat die Gegevensdienst ook geleverd wordt. Daarbij wordt geen enkel onderscheid gemaakt tussen Uitgevers, tenzij het MedMij Afsprakenstelsel daartoe uitdrukkelijk verplicht. Dit geldt ook voor de mogelijke andere Gegevensdienst(en) die in de Catalogus staan genoemd als Vereist bij eerstgenoemde Gegevensdienst.

7b. Het is verantwoordelijkheid 7a bepaalde is ook van toepassing zolang de geldigheid van de toepasselijke vermelding in de Zorgaanbiederslijst of in de Autorisatieserverlijst niet langer dan één uur (3600 seconden) geleden is verstreken.

Info
titleToelichting

Zo wordt ervoor ruimte geboden dat na-ijlende sessies, die nog gebruik maken van de verstrijkende versie van de Zorgaanbiederslijst of de Autorisatieserverlijst, nog kunnen worden afgemaakt.


Lijsten

Info
titleLijsten t.b.v. Coördinatie

In het MedMij Afsprakenstelsel worden, ten behoeven van de hoofdfunctie Coördinatie, een aantal lijsten gebruikt voor de interoperabiliteit en het vertrouwen tussen het Persoonsdomein en het Zorgaanbiedersdomein.

lijst

afkortingwordt opgehaald en gebruikt doorinformatie-inhoud
UitgeverBron/Lezer
ZorgaanbiederslijstZALX
welke Zorgaanbieders welke Gegevensdiensten aanbieden, en eventueel ook Abonnementen daarop, en op welke adressen zij die laten laten ontsluiten, gegeven een zekere Interfaceversie
AutorisatieserverlijstASLX
welke Autorisatieservers beschikbaar zijn in het MedMij netwerk en welke Aanbieders en Gegevensdiensten zij ondersteunen
OAuth Client ListOCL
Xde namen van PGO's, welke Gegevensdiensten zij mogen gebruiken en naar welke adressen mogelijk Notificaties in het kader van Abonnementen op die Gegevensdiensten kunnen worden gestuurd, gegeven een zekere Interfaceversie
GegevensdienstnamenlijstGNLXXde gebruiksvriendelijke namen van Gegevensdiensten
WhitelistWHLXXwelke Nodes actief mogen zijn op het MedMij-netwerk



Zorgaanbiederslijst en Autorisatieserverlijst

10. MedMij Beheer beheert en publiceert een Zorgaanbiederslijst en een Autorisatieserverlijst , namens de deelnemende Dienstverleners zorgaanbieder. De gepubliceerde lijsten bevatten steeds en slechts alle actuele entries, en beschrijven van elke Zorgaanbieder:

  • welke Gegevensdiensten deze momenteel aanbiedt via welke Bron en Lezer, en welke technische adressen daarvoor moeten worden aangesproken bij de Dienstverlener zorgaanbieder, gegeven een zekere Interfaceversie;
  • voor welke Gegevensdiensten het mogelijk is om Abonnementen aan te gaan en via welke technische adressen dit kan worden gedaan, gegeven een zekere InterfaceversieIn deze release van het MedMij Afsprakenstelsel staat de Catalogus alleen Abonnementen toe op Gegevensdiensten die zijn gebaseerd op de UC Verzamelen.


Info
titleToelichting

Deze afspraak wijst MedMij Beheer de verantwoordelijkheid toe om ten behoeve van alle Dienstverleners persoon de benodigde lijsten te verspreiden van Zorgaanbieders en de door hen aangeboden Gegevensdiensten en Abonnementen. Zonder deze functie zou het stelsel niet functioneren.

In de Catalogus staat bij elke Gegevensdienst de maximale duur van een Abonnement op (Notificaties van) die Gegevensdienst. Bij een Gegevensdienst gebaseerd op UC Delen zal hier vooralsnog altijd 0 als maximale duur staan, hetgeen betekent dat er geen Abonnementen mogelijk zijn op deze Gegevensdienst.

...

11. De Zorgaanbiederslijst en de Autorisatieserverlijst voldoen aan wat over hen is bepaald in de Informatiemodellen.

12. MedMij Beheer beheert en publiceert, in de Zorgaanbiederslijst en in de Autorisatieserverlijst, unieke en gebruikersvriendelijke namen van Zorgaanbieders, van het formaat <zorgaanbieder>@medmij. Daarop is naamgevingsbeleid van toepassing.

Info
titleToelichting
Zorgaanbieders kunnen in hun directe of indirecte contact met Zorggebruikers deze naam meegeven als hun "MedMij-naam". MedMij Beheer zorgt voor uniciteit en heeft het laatste woord bij het vaststellen ervan.

13a. MedMij Beheer biedt aan Uitgever een use case (UC Opvragen ZAL) om de actuele versie van die Zorgaanbiederslijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.

13b. MedMij Beheer biedt aan Uitgever een use case (UC Opvragen ASL) om de actuele versie van die Autorisatieserverlijst op te vragen. Betrokken rollen gebruiken hiertoe het betreffende stroomdiagram.

Processen en informatie - UC Verzamelen - Totaalperspectief

De totale procesgang van de UC Verzamelen kent de volgende stappen:

  • De Uitgever presenteert aan de Zorggebruiker de mogelijkheid om te verzamelen.
  • De Zorggebruiker kiest expliciet de zorgaanbieder waarbij hij de informatie wenst te verzamelen en de specifieke Gegevensdienst(en). Daarvoor kunnen desgewenst de Gegevensdienstnamen worden gebruikt uit de Gegevensdienstnamenlijst. Het verzoek gaat naar de passende Bron.
  • De Bron ontvangt de Zorggebruiker.
  • De Bron laat de Zorggebruiker zich authenticeren.
  • Wanneer de Zorggebruiker de authenticatie heeft afgebroken geeft de Bron de mogelijkheid alsnog te authenticeren of de flow af te breken.
  • Dan breekt het moment aan waarop de Bron op zijn vroegst ervoor instaat dat de Zorgaanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreekt. Het MedMij Afsprakenstelsel adviseert de beschikbaarheidsvoorwaarde op het vroegst aangegeven moment van kracht te laten zijn. In deze release staat het MedMij Afsprakenstelsel het toe die voorwaarde op een later moment van kracht te laten zijn, maar niet later dan het laatste in het figuur aangegeven moment.
  • De Bron vraagt aan de Zorggebruiker of hij toestemming geeft tot het verstrekken van de gevraagde informatie aan de UitgeverDeze vraag staat op de pagina Toestemmingsverklaring.
  • De Bron logt die toestemming en laat de Uitgever weten dat de toestemming gegeven is.
  • Nu kan de Uitgever de Bron vragen om de gezondheidsinformatie.
  • Uiterlijk na de ontvangst van het verzoek zal de Bron ervoor instaan dat de Zorgaanbieder voor de betreffende Gegevensdienst(en) überhaupt gezondheidsinformatie van die Persoon beschikbaar heeft, of anders de happy flow afbreken.
  • Bij ontvangst slaat de Uitgever die informatie op in het persoonlijke dossier. 
  • Mocht de afgegeven autorisatie meerdere Gegevensdiensten omvatten, of mocht een Gegevensdienst uit meerdere Transacties bestaan (zie hiervoor de Catalogus), dan bevraagt de Uitgever de Bron daarna mogelijk opnieuw voor de nog resterende Transacties, eventueel na nieuwe interactie met de Zorggebruiker.
  • Bij de informatie wordt ook de meta-informatie opgeslagen die wordt bedoeld in verantwoordelijkheid 19 van de Processen- en Informatielaag.

Processen en informatie - UC Verzamelen - Uitzonderingen (Totaalperspectief)

nr.uitzonderingactievervolg
UC Verzamelen 1Bron vindt het ontvangen verzoek ongeldig.Bron informeert Uitgever over deze uitzondering. Uitgever informeert daarop Zorggebruiker hierover.Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
UC Verzamelen 2Bron kan de identiteit van de Zorggebruiker niet vaststellen.Bron informeert Uitgever dat verzoek niet wordt ingewilligd.

Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.

UC Verzamelen 3

Bron stelt op enig moment vast dat van Persoon bij Zorgaanbieder geen gezondheidsinformatie voor geen van de gevraagde Gegevensdiensten beschikbaar is. Hiervan is in elk geval sprake indien hetzij:

  • er geen behandelrelatie is aan te wijzen als grondslag voor het verzamelen;
  • Zorggebruiker nog geen zestien jaar oud is.

Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

UC Verzamelen 4De voorgelegde Toestemmingsverklaring wordt niet afgegeven.
UC Verzamelen 5Bron kan het antwoord op de toestemmingsvraag niet vaststellen.Bron informeert Uitgever over deze uitzondering. Uitgever informeert daarop Zorggebruiker hierover.Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering.
UC Verzamelen 6Bron kan, zelfs na toestemming, de gezondheidsinformatie alsnog niet ter beschikking stellen aan de Uitgever.Bron informeert Uitgever over deze uitzondering. Uitgever informeert daarop Zorggebruiker hierover, met opgave van oorzaak.Mocht de gezondheidsinformatie deels wel (geautoriseerd) ter beschikking staan, dan kan de flow dat nog verzorgen.
UC Verzamelen 7Zorggebruiker annuleert het inloggen.Bron presenteert een annuleringspagina en biedt Zorggebruiker de optie om toch in te loggen.Indien Zorggebruiker kiest niet in te willen loggen, kan het scherm gesloten worden. Zorggebruiker kan er ook voor kiezen toch in te loggen. In dat geval vraagt Bron weer om credentials.

Processen en informatie - UC Opvragen ASL

Tekst en plaatje analoog aan UC Opvragen ZAL.

Applicatie

>> aanpassen plaat bovenaan pagina (toevoegen UCI Opvragen ASL)


Info
titleToelichting

Voor een overzicht over alle lagen van de architectuur, en voor een toelichting van de betekenis van de symbolen en lijntjes, zie de overzichtspagina.

De afkorting:

...

Info
titleToelichting

Van de meeste use cases (zie de laag Processen en Informatie) wordt op deze (Applicatie)laag een use case-implementatie (UCI) voorgeschreven. Het gaat om de volgende.

use case-implementatie

Stroomdiagram

Hoofdfunctie

UCI VerzamelenmetRegie en Uitwisseling
UCI DelenmetRegie en Uitwisseling
UCI AbonnerenmetRegie
UCI NotificerenmetRegie of Uitwisseling
UCI Opvragen ZALmetCoördinatie
UCI Opvragen ASLmetCoördinatie
UCI Opvragen OCLmetCoördinatie
UCI Opvragen GNLmetCoördinatie



Autorisatie en OAuth

...

10a. MedMij Registratie en elke PGO Server implementeren de use cases UC Opvragen ZAL en UC Opvragen ASL (optioneel voor PGO Server) met de use case-implementaties UCI Opvragen ZAL en UCI Opvragen ASL, door middel van het bepaalde inzake de interfacebeschrijvingen op ASL-, GNL-, OCL- en ZAL-interface. Zij gebruiken hiertoe de betreffende stroomdiagrammen.

...

10c. PGO Server valideert elke nieuw verkregen ZAL-implementatie en ASL-implementatie tegen de bijbehorende XML-schema. De XML-schema's zijn een technische implementatie van het MedMij-metamodel.


Beveiliging

13. In het gegevensverkeer voor alle, in het afsprakenstelsel beschreven, use case-implementaties maken betrokken rollen gebruik van de functies VersleutelingServer Authentication en Server Authorization, volgens het bepaalde op de Netwerk-laag.

Applicatie - Interfaces


Info
titleInterfaces en use cases

Op deze pagina's staan de verantwoordelijkheden die horen bij de interfaces in het MedMij Afsprakenstelsel. In elke use case-implementatie wordt gebruik gemaakt van één of meer van deze interfaces. Onderstaande tabel laat zien welke use case-implementaties welk interface gebruiken.


Verantwoordelijkheden over de adressering van deze interfaces komen hieronder aan de orde. Verantwoordelijkheden voor de specifieke interfaces zijn opgenomen in specifieke subpagina's, die klikbaar zijn in bovenstaande tabel.

...

3. MedMij Registratie wordt in UCI Opvragen ZAL, UCI Opvragen ASL, UCI Opvragen OCL en UCI Opvragen GNL geadresseerd met de hostname stelselnode.medmij.nl

Applicatie - Interfaces - User interface (Autorisatieserver)

2a. De vraag die aan de Zorggebruiker gesteld moet worden in de stap "autoriseer" in UCI Verzamelen staat gespecificeerd op de pagina Toestemmingsverklaring. Daarbij geldt dat:

  • de gebruikersvriendelijke weergave van de identiteit van de Zorgaanbieder (NaamZorgaanbieder) wordt bepaald door de betreffende Dienstverlener Zorgaanbieder, in haar dienstverleningsrelatie met de betreffende Zorgaanbieder;
  • de gebruikersvriendelijke weergave van de Gegevensdienst (NaamGegevensdienst) wordt betrokken uit de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen, die overeenkomt met de Weergavenaam die bij de betreffende Gegevensdienst in de Gegevensdienstnamenlijst is opgenomen;
  • de gebruikersvriendelijke weergave van de identiteit van de Uitgever (NaamLeverancierPGO) wordt betrokken uit de OAuth Client List, op basis van de redirect_uri (van OAuth) die in stap 1 is verkregen;
  • indien de scope die de Authorization Server in de allereerste stap van de flow heeft gekregen meer dan één Gegevensdienst bevat en de Zorgaanbieder tenminste één, maar niet alle gevraagde Gegevensdiensten beschikbaar stelt aan de Persoon, dan dient deze situatie te worden getoond aan de Persoon, op de wijze zoals staat gespecificeerd op de pagina Toestemmingsverklaring.

Applicatie - Interfaces - Authorization interface

1a. De parameters in de authorization request worden als volgt gevuld:

parameter

vulling

toelichting

parameter

vulling

toelichting

response_type

letterlijke waarde codeDit is het gevolg van verantwoordelijkheid 4 op de Applicatielaag.

client_id

de hostname, die in de OAuth Client List is opgenomen, van de Node van de OAuth Client die de authorization request doet

redirect_uri

  1. zodanig dat de erin opgenomen hostname gelijk is aan de client_id en er geen poortnummer is opgenomen
  2. de redirect_uri moet volledig zijn en verwijzen naar een https-beschermd endpoint

Zie verantwoordelijkheden 1 en 2a op de pagina Interfaces.

De tweede eis is een maatregel tegen beveiligingsrisico's 4.1.5, 4.2.4, 4.4.1.1, 4.4.1.5 en 4.4.1.6 in RFC 6819. Zie bovendien Token interface, de toelichting onder verantwoordelijkheid 4.

scope

abonnementsdeel:

  • de letterlijke waarde subscribe
  • gevolgd door een tilde ~
  • gevolgd door een niet-negatief geheel getal, aangevende de gevraagde maximale duur van het Abonnement
  • gevolgd door een forward slash /

gegevensdienstdeel:

  • de betreffende (één) Zorgaanbiedernaam, ontdaan van de suffix @medmij, gevolgd door
  • een tilde (~), gevolgd door
  • het GegevensdienstId van de betreffende (één) Gegevensdienst uit de Gegevensdienstnamenlijst.

De scope kan worden gevuld met:

  1. een abonnementsdeel gevolgd door een gegevensdienstdeel, of met
  2. één of meerdere, door spaties gescheiden, gegevensdienstdelen.

Indien de scope bestaat uit meerdere gegevensdienstdelen, dan dienen deze delen betrekking te hebben op dezelfde Zorgaanbieder.

Het abonnementsdeel wordt gebruikt voor het aangaan, verlengen of beëindigen van een Abonnement. Als de gevraagde duur van het Abonnement 0 is, betekent dit dat het een verzoek betreft voor het  beëindigen van het (mogelijk) geregistreerde Abonnement op die Gegevensdienst bij die Zorgaanbieder.

Een gegevensdienstdeel wordt gebruikt om aan te geven welke Gegevensdienst wordt aangevraagd bij welke Zorgaanbieder, of om aan te geven op welke Gegevensdienst en Zorgaanbieder het abonnementsdeel van de scope betrekking heeft.

De twee verplichte delen volgen op het eventuele optionele deel en bestaat zelf uit twee, gescheiden door een tilde. Er mag in deze versie van het MedMij Afsprakenstelsel slechts sprake zijn van één van elk. Bij interpretatie van de Zorgaanbiedernaam door de ontvanger zal deze de suffix @medmij weer moeten toevoegen.

Er worden geen andere scopes of onderdelen van scopes opgenomen dan de hier genoemde.

Voorbeelden van syntactisch juiste scopes zijn:

  • "eenofanderezorgaanbieder~42", voor het eenmalig afnemen van Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij;
  • "eenofanderezorgaanbieder~42 eenofanderezorgaanbieder~43", voor het eenmalig afnemen van Gegevensdiensten 42 en 43 bij eenofanderezorgaanbieder@medmij;
  • "subscribe~180/eenofanderezorgaanbieder~42", voor het aangaan van een Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij van maximaal 180 dagen, of voor het aanpassen van het Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij naar maximaal 180 dagen vanaf vandaag;
  • "subscribe~0/eenofanderezorgaanbieder~42", voor het beëindigen van het Abonnement op Gegevensdienst 42 bij eenofanderezorgaanbieder@medmij.

state

  1. conform sectie 4.1.1. van RFC 6749
  2. de waarde mag geen URI bevatten

Hiermee geeft de OAuth Client informatie mee aan de OAuth Authorization Server, waaraan eerstgenoemde later, bij de redirect, kan afleiden bij welk verzoek de authorization code hoort. Deze informatie is verder betekenisloos voor de OAuth Authorization Server.

De tweede eis is een maatregel tegen beveiligingsrisico 4.1.5. De state-parameter mag niet bedoeld zijn om te worden toegevoegd aan, of anderszins verwerkt in de redirect_uri.

...

  • deze GegevensdienstId voorkomt bij de betreffende client_id op de OAuth Client List;
  • optioneel: de gevraagde set van GegevensdienstId's voorkomt bij de betreffende client_id op de OAuth Client List;
  • zij namens deze Zorgaanbieder deze Gegevensdienst ontsluit, in overeenstemming met de gepubliceerde Zorgaanbiederslijst;
  • optioneel: zij namens deze Zorgaanbieder deze set van Gegevensdiensten ontsluit, in overeenstemming met de gepubliceerde Autorisatieserverslijst;
  • indien in de scope ook subscribe voorkomt:
    • bij de betreffende client_id en Gegevensdienst op de OAuth Client List ook een subscription notification endpoint en een resource notification endpoint voorkomen;
    • zij namens deze Zorgaanbieder ook Abonnementen op deze Gegevensdienst ontsluit;
    • >> inspringen >de waarde vande duur parameter in het request de waarde heeft van 0 of een waarde groter dan 0 die kleiner of gelijk is aan de maximale duur van het Abonnement zoals de betreffende Zorgaanbieder deze aanbiedt.

...

NummerImplementeert uitzonderingenUitzonderingActieMeldingVervolg
Authorization interface 1a

UC Verzamelen 1

UC Delen 1

UC Abonneren 1

Authorization Server ontvangt een authorization request zonder (geldige) redirect_uri en/of zonder een (geldige) client_id.Authorization Server informeert PGO Presenter over deze uitzondering. Authorization Server voert geen redirect naar de Client uit, ook niet met een foutmelding. conform OAuth 2.0-specificatie, par. 4.1.2.1Allen stoppen de flow van de UCI Verzamelen/UCI Delen onmiddellijk na geïnformeerd te zijn over de uitzondering.


Authorization interface 1b

Authorization Server ontvangt een ongeldige authorization request, anders dan uitzondering 1a.

Deze situatie kan ook optreden wanneer een PGO Server meerdere gegevensdienstdelen opneemt in de scope van een authorization request, terwijl de Authorization Server dit niet ondersteunt.

Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert Zorggebruiker daarover.

conform OAuth 2.0-specificatie, par. 4.1.2.1, met de daar genoemde, zo specifiek mogelijke, toepasselijke error code


Authorization interface 2

UC Verzamelen 2

UC Delen 2

UC Abonneren 2

Authorization Server kan de identiteit van de Zorggebruiker niet vaststellen.Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert Zorggebruiker dat diens verzoek geen voortgang kan vinden, maar laat de oorzaak daarvan helemaal in het midden.conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Access denied."
Authorization interface 3

UC Verzamelen 3

UC Delen 3

UC Abonneren 3

Authorization Server stelt tijdens de afhandeling van de authorization request vast dat:

  • in geval van UCI Verzamelen: van Persoon bij Zorgaanbieder geen gezondheidsinformatie voor geen van de gevraagde Gegevensdiensten beschikbaar is;
  • in geval van UCI Delen: Zorgaanbieder niet ontvankelijk is voor die Gegevensdienst van Persoon;
  • in geval van UCI Abonneren: Zorgaanbieder geen Notificaties beschikbaar maakt voor Persoon op die Gegevensdienst.

Zie de toelichting op Beschikbaarheids- en ontvankelijkheidsvoorwaarde.

Authorization interface 4

UC Verzamelen 4

UC Delen 4

UC Abonneren 4

De autorisatievraag wordt ontkennend beantwoord.
Authorization interface 5

UC Verzamelen 5

UC Delen 5

UC Abonneren 5

Authorization Server kan de autorisatie niet vaststellen.Authorization Server informeert PGO Server over deze uitzondering. PGO Server informeert daarop Zorggebruiker hierover.conform OAuth 2.0-specificatie, par. 4.1.2.1, error code access denied, met in de error description "Authorization failed."


Applicatie - Interfaces - Token interface

2. De parameters in de access token response worden als volgt gevuld:

parameter

vulling

toelichting

access_token

Het hiermee uitgegeven access token.
token_typeletterlijke waarde "Bearer"

expires_in

900Conform verantwoordelijkheid 7 op de Applicatie-laag.

refresh_token

niet gebruiktConform verantwoordelijkheid 7 op de Applicatie-laag.
scope

Conform sectie 5.1 van de OAuth 2.0-specificatie.

Er gelden hierop een aantal toevoegingen.

Verplicht indien het authorization request verzocht om het gebruik van meerdere Gegevensdiensten. In dat geval is de scope-parameter gelijk aan het door de Autorisatieserver daadwerkelijk toegekende deel van de gevraagde scope.

Verplicht indien het authorization request verzocht om een Abonnement. In dat geval is de scope-parameter gelijk aan die in de betreffende authorization request, maar met de Abonnements-einddatum gesteld op de door de Authorization Server toegekende, en dus mogelijk beperkte, waarde. De toegekende duur van het Abonnement is:

  • niet hoger dan de in de authorization request gevraagde duur van het Abonnement;
  • niet hoger dan de maximale abonnementsduur die de Zorgaanbieder in de Zorgaanbiederslijst had opgenomen bij die Gegevensdienst en die Interfaceversie;
  • bij een gevraagde beëindiging gelijk aan 0.


Applicatie - Interfaces - GNL-, OCL-, ASL- en ZAL-interface

1. De URI van de:

...

4. Ingeval MedMij Registratie in UCI Opvragen ZAL, UCI Opvragen ASL, UCI Opvragen OCL en/of UCI Opvragen GNL niet beschikbaar is, mogen betreffende opvragers gedurende maximaal 10 uur gebruik maken van het meest recente exemplaar van de betreffende lijst in de cache.

Applicatie - Use case-implementaties

Deze pagina groepeert de pagina's van de verschillende use case-implementaties.

Applicatie - Use case-implementaties - UCI Opvragen ZAL

Stroomdiagram

Info
titleToelichting

In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.

Beide interacties met MedMij Registratie zijn backchannel-verkeer.


>> Figuur toevoegen.

Informatiemodellen - Logische modellen

Lijsten

>> Toevoegen Autorisatieserverlijst

Informatiemodellen - XML-schema's

Schema's

>> Toevoegen Autorisatieserverlijst

Informatiemodellen - XML-bestanden voor lijsten

Info
titleToelichting
De XML-bestanden waarmee MedMij Beheer de Zorgaanbiederslijst, de Autorisatieserverslijst, de Whitelist, de OAuth Client List, de Gegevensdienstnamenlijst en de Catalogus ontsluit voldoen aan enkele eisen, zodat PGO Server, Authorization Server, MedMijNode en anderen weten waarop zij kunnen rekenen voor de goede verwerking van deze lijsten.

1. Het XML-bestand van de Zorgaanbiederslijst heet MedMij_Zorgaanbiederslijst.xml. Het XML-bestand van de Autorisatieserverslijst heet MedMij_Autorisatieserverslijst.xml. Het XML-bestand van de Whitelist heet MedMij_Whitelist.xml. Het XML-bestand van de OAuth Client List heet MedMij_OAuthclientlist.xml. Het XML-bestand van de Gegevensdienstnamen heet MedMij_Gegevensdienstnamenlijst.xml. Het XML-bestand van de Catalogus heet MedMij_Catalogus.xml.

Communicatie - Toestemmingsverklaring

De toestemmingsverklaring en de toelichting daarop zijn verplichte teksten die de Dienstverlener zorgaanbieder dient voor te leggen aan de Persoon bij het ophalen van gezondheidsgegevens bij de Zorgaanbieder. Deze toestemmingsverklaring heeft betrekking op die gegevensuitwisseling. De verplichte toestemmingsverklaring volgt uit de Wet geneeskundige behandelingsovereenkomst (WGBO). De Zorgaanbieder is verplicht ervoor te zorgen dat ‘anderen’ dan de patiënt geen inlichtingen hebben over, inzage hebben in of een afschrift hebben van het medisch dossier, tenzij hiervoor toestemming is verleend. Binnen de MedMij afspraken verstrekt de Zorgaanbieder via de Dienstverlener zorgaanbieder gegevens aan de Dienstverlener persoon. Aangezien dit een 'andere' is dan de Persoon zelf, moet de Zorgaanbieder weten dat de persoon hiervoor toestemming heeft verleend. Bij de UC Verzamelen en de UC Abonneren staat beschreven hoe het proces rondom het geven van toestemming eruit ziet. De Dienstverlener zorgaanbieder implementeert de toestemmingsverklaring en toont deze aan de Persoon.

...

>> Aanpassen HTML schermen.


Operationele processen

Registratieprocessen ZorgaanbiederslijstWhitelist en OAuthclientlist

  • Doel: De registratieprocessen voor de Zorgaanbiederslijst, Autorisatieserverslijst, Whitelist en OAuthclientlist hebben als doel de juiste informatie te verzamelen benodigd voor een goede operationele werking van het stelsel. 
  • Initiatie: 
    • Deelnemer dient een verzoek in bij Stichting MedMij om een entry in de Zorgaanbiederslijst, Autorisatieserverslijst, Whitelist of OAuthclientlist aan te maken, te wijzigen of te verwijderen. 
    • Triggers voor wijzigingen zijn per lijst verschillend:
      • Whitelist:
        • Deelnemer wil een node op het MedMij-netwerk gebruiken.
        • Deelnemer wil een van haar eigen nodes niet meer op het MedMij-netwerk gebruiken.
      • Zorgaanbiederslijst, Autorisatieserverslijst en Zorgaanbiederskoppellijst
        • Dienstverlener zorgaanbieder wil in het MedMij-netwerk kenbaar maken een Gegevensdienst namens een Zorgaanbieder te ontsluiten.
        • Dienstverlener zorgaanbieder wil in het MedMij-netwerk kenbaar maken een Gegevensdienst namens een Zorgaanbieder niet meer te ontsluiten.
      • Alleen Zorgaanbiederslijst en Autorisatieserverslijst:
        • Dienstverlener zorgaanbieder wil een of meerdere endpoints bij een ZorgaanbiederGegevensdienst wijzigen.
        • Dienstverlener zorgaanbieder wil een of meerdere Gegevensdiensten die namens een Zorgaanbieder worden ontsloten, richting Persoon kunnen combineren in één Toestemmingsverklaring.
      • OAuthclientlist:
        • Dienstverlener persoon wil een OAuthclient toevoegen.
        • Dienstverlener persoon wil een OAuthclient verwijderen.
  • Afspraken over het proces:
    • Deelnemer is verantwoordelijk voor het aanleveren van mutaties voor de Zorgaanbiederslijst, Autorisatieserverslijst, WhiteList en OAuthclientlist. Aanvullend, bovenop de gegevens die zijn vereist voor de Zorgaanbiederslijst, dient voor het samenstellen van een Autorisatieserverlijst door Stichting MedMij, door de Dienstverlener zorgaanbieder, per interfaceversie, te worden aangegeven welke Gegevensdiensten die namens een Zorgaanbieder worden ontsloten, richting Persoon mogen worden gecombineerd in één Toestemmingsverklaring.
    • Bij het kenbaar maken van het ontsluiten van een Gegevensdienst voor een Zorgaanbieder overlegt de Dienstverlener zorgaanbieder de volgende verklaring van de Zorgaanbieder:
      "Ik, [Zorgaanbieder], verklaar onder de Zorgaanbiedersnaam [Zorgaanbiedersnaaméén of meerdere Gegevensdiensten aan te willen bieden op het MedMij-netwerk, vanaf [ingangsdatum] en deze te laten ontsluiten door [Dienstverlener zorgaanbieder]. Tevens geef ik stichting MedMij toestemming de Gegevensdiensten die op enig moment onder Zorgaanbiedersnaam [Zorgaanbiedersnaamworden aangeboden openbaar te publiceren."
    • Mutaties zijn gebonden aan de verantwoordelijkheden en regels zoals gespecificeerd in de Architectuur en technische specificaties, het Zorgaanbiedersnamenbeleid en OAuthclient-namenbeleid.
    • Stichting MedMij neemt het verzoek in behandeling en is verantwoordelijk voor een check op integriteit.
    • Valide mutaties worden in 95 procent van de gevallen door Stichting MedMij binnen 2 werkdagen verwerkt. Urgente mutaties krijgen daarbij voorrang. De mutatietijd voor urgente mutaties wordt in overleg met Stichting MedMij bepaald. Bij verwachte overschrijding van de (overeengekomen) verwerkingstijd, informeert Stichting MedMij de deelnemer hierover.
  • Resultaat: Stichting MedMij heeft het betreffende register aangepast. De deelnemer wordt geïnformeerd over de doorgevoerde wijziging.
  • Uitzonderingen: Een van de verantwoordelijkheden en regels in de Architectuur en technische specificaties wordt overtreden. Stichting MedMij vraagt de deelnemer om het verzoek aan te passen.

Actualiseren van Zorgaanbiederslijst, Zorgaanbiederkoppellijst en de OauthClientList bij publicatie nieuwe release

  • Doel: Borgen dat in de Zorgaanbiederslijst, de Autorisatieserverslijst, de Zorgaanbiederkoppellijst en de OAuthclientlist alleen Interfaceversies voorkomen van actieve releases van het MedMij Afsprakenstelsel. 
  • Initiatie: 
    • Er komt een nieuwe release uit van het MedMij Afsprakenstelsel. Dat wil zeggen dat de tot dan toe verplichte release de status verouderd krijg.
  • Afspraken over het proces:
    • MedMij Beheer is verantwoordelijk voor het verwijderen van alle entries in de Zorgaanbiederslijst, de Autorisatieserverslijst, Zorgaanbiederkoppellijst en de OAuthClientList die horen bij een (zojuist) verouderde Interfaceversie.
  • Resultaat: Stichting MedMij heeft de betreffende lijsten aangepast.
  • Uitzonderingen: Geen.

Processen inzake gecontroleerde livegang

Toetreding tot een gecontroleerde livegang

  • Doel: Het in de gelegenheid stellen van een Zorgaanbieder (desgewenst met diens Dienstverlener zorgaanbieder) of Dienstverlener persoon toe te treden tot een bestaande gecontroleerde livegang conform Beleid inzake gecontroleerde livegang.
  • Initiatie: Een Zorgaanbieder (desgewenst met diens Dienstverlener zorgaanbieder) of Dienstverlener persoon wenst toe te treden tot een gecontroleerde livegang. De betreffende Dienstverlener moet gekwalificeerd zijn voor de origineel-Gegevensdienst van de gecontroleerde livegang. De Zorgaanbieder mag in de afgelopen drie maanden niet al betrokken zijn geweest bij een gecontroleerde livegang op deze origineel-Gegevensdienst.
  • Afspraken over het proces: 
    • De MedMij Beheerorganisatie erkent de betreffende Dienstverlener op de kopie-Gegevensdienst, indien deze is gekwalificeerd op de origineel-Gegevensdienst.
    • Betrokken Dienstverlener laat zich inzake de kopie-Gegevensdienst op gebruikelijke wijze registreren in de Zorgaanbiederslijst, de Autorisatieserverslijst, de OAuth Client List en de Whitelist.
  • Resultaat: De betreffende partij is operationeel in de gecontroleerde livegang, tenzij niet aan de toepasselijke eisen is voldaan.
  • Uitzonderingen: -

Uittreding uit een gecontroleerde livegang

  • Doel: Het in de gelegenheid stellen van een Zorgaanbieder (desgewenst met diens Dienstverlener zorgaanbieder) of Dienstverlener persoon uit te treden uit een bestaande gecontroleerde livegang conform Beleid inzake gecontroleerde livegang.
  • Initiatie: Een Zorgaanbieder (desgewenst met diens Dienstverlener zorgaanbieder) of Dienstverlener persoon wenst uit te treden uit een gecontroleerde livegang. Bij een Zorgaanbieder kan dat gepaard gaan met een wens tot promotie tot het gewone live MedMij-netwerk.
  • Afspraken over het proces: 
    • De MedMij Beheerorganisatie beëindigt de erkenning van betreffende Dienstverlener op de kopie-Gegevensdienst.
    • De MedMij Beheerorganisatie verwijdert de op de betreffende partij betrekking hebbende elementen uit de Zorgaanbiederslijst, de Autorisatieserverslijst, de OAuth Client List en de Whitelist.
    • Indien het een Zorgaanbieder betreft die wens te promoveren, start de MedMij Beheerorganisatie het proces 'Promotie uit een gecontroleerde livegang'.
    • Mocht de uitreder de laatste ZorgaanbiederDienstverlener zorgaanbieder of Dienstverlener persoon zijn in de gecontroleerde livegang, start hij het proces 'Beëindiging van een gecontroleerde livegang'.
  • Resultaat: De betreffende partij is niet meer operationeel in de gecontroleerde livegang.
  • Uitzonderingen: -

Promotie uit een gecontroleerde livegang

  • Doel: Het live gaan van een Zorgaanbieder, met diens Dienstverlener zorgaanbieder, in het MedMij-netwerk, vanuit een gecontroleerde livegang, conform Beleid inzake gecontroleerde livegang.
  • Initiatie: Een Zorgaanbieder (met diens Dienstverlener zorgaanbieder) geven bij uitreding uit de gecontroleerde livegang aan te willen promoveren.
  • Afspraken over het proces: 
    • De MedMij Beheerorganisatie vervangt in de Zorgaanbiederslijst en in de Autorisatieserverslijst die elementen die betrekking hebben op de betreffende Zorgaanbieder-kopie-Gegevensdienst-combinaties de kopie-Gegevensdienst door de origineel-Gegevensdienst.
  • Resultaat: De betreffende Zorgaanbieder is live met de betreffende Gegevensdienst.
  • Uitzonderingen: -

Beëindiging van een gecontroleerde livegang

  • Doel: Het beëindigen van de gelegenheid van een groep Deelnemers tot het uitvoeren van een gecontroleerde livegang conform Beleid inzake gecontroleerde livegang.
  • Initiatie: Wanneer één van de volgende gebeurtenissen zich voordoet:
    • de looptijd van de kopie-Gegevensdienst verstrijkt, al dan niet na een eenmalige verlenging;
    • de laatste Zorgaanbieder, Dienstverlener zorgaanbieder of Dienstverlener persoon treedt uit uit de gecontroleerde livegang;
    • Stichting MedMij oordeelt dat enige bij de gecontroleerde livegang betrokken partij voordelen ontleent of beoogt te ontlenen aan de gecontroleerde livegang die niet in overeenstemming zijn met de bedoeling van gecontroleerde livegangen.
  • Afspraken over het proces: 
    • De MedMij Beheerorganisatie beëindigt de geldigheid van de kopie-Gegevensdienst.
    • De MedMij Beheerorganisatie verwijdert de kopie-Gegevensdienst uit de Gegevensdienstnamenlijst. De kopie-Gegevensdienst wordt nooit meer opnieuw gebruikt.
    • De MedMij Beheerorganisatie verwijdert de erkenning van betrokken Dienstverleners op de kopie-Gegevensdienst.
    • De MedMij Beheerorganisatie verwijdert op betrokken kopie-Gegevensdienst betrekking hebbende elementen uit de Zorgaanbiederslijst, de Autorisatieserverslijst en de OAuth Client List.
    • Betrokken partijen verwijderen eventuele op hen betrekking hebbende elementen uit de Whitelist, voor zover zij die niet ook gebruiken buiten deze gecontroleerde livegang.
  • Resultaat: De gecontroleerde livegang is niet meer operationeel.
  • Uitzonderingen: -


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

Attachments