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

Samenvatting

Waarom is deze RFC nodig?

Er zijn drie redenen om een nieuw fundament te geven aan de rol van de (Zorg)aanbieder in het MedMij Afsprakenstelsel.

  1. MedMij wil Personen regie geven op hun gezondheid. De zorgsector speelt daarin een weliswaar uitermate wezenlijke rol als Aanbieder, maar niet de enige. Naast Aanbieders uit de zorgsector, zijn ook Aanbieders uit verschillende publieke domeinen (zoals gemeenten en Rijks-uitvoerders) aan de orde, alsook bedrijven (zoals sportscholen, maar ook private aanbieders van apps of vragenlijsten). Het MedMij Afsprakenstelsel is qua opzet slechts voor een klein deel zorgsector-specifiek. De vraag komt dan op of de zorgsector-specifieke afspraken niet kunnen worden geïsoleerd van de afspraken die voor alle soorten Aanbieders gelden, zodat de weg vrijkomt voor ook andere soorten Aanbieders om hun Diensten aan te bieden op het MedMij-netwerk. Dit punt is een actueel item op de strategische roadmap van MedMij.
  2. Zorgaanbieders spelen een hoofdrol in het MedMij Afsprakenstelsel, als aanbieders en verwerkingsverantwoordelijken voor Gegevensdiensten. Omdat zij niettemin geen Deelnemers zijn, is die hoofdrol beperkt zichtbaar. Toch worden in het MedMij Afsprakenstelsel nu al verantwoordelijkheden verbonden aan de Zorgaanbieder-rol, ook al worden die dan geborgd via de Dienstverlener zorgaanbieder. Laatstgenoemde lijkt daardoor een grotere rol te spelen dan feitelijk het geval is. Dat blijkt bijvoorbeeld voor de juridische architectuur van het stelsel (RFC0018 Juridische architectuur (ter consultatie)) en voor de opzet van de kwalificatie op Gegevensdiensten, maar ook op andere aspecten. Er is een groeiende behoefte de rol van de (Zorg)aanbieder steviger juridisch te verankeren in het MedMij Afsprakenstelsel.
  3. Er is een stijgende vraag naar het omgaan, in MedMij-kader, met zogenaamde Modulediensten, die niet alleen uitwisselfunctionaliteit bieden, maar (ook) applicatiefunctionaliteit. Denk daarbij aan bijvoorbeeld e-health-modules of e-consult-applicaties. Hiervoor is RFC0026 geformuleerd, die tegelijk voor doorvoering wordt voorgesteld. Voor RFC0026 is het echter nodig om een type Aanbieders toe te laten op het MedMij-netwerk dat anders is dan de huidige (Zorg)aanbiedersRFC0026 heeft daarom deze RFC nodig.

Bij dit alles moge duidelijk blijven dat de inhoudelijke scope van MedMij zich tot gezondheid beperkt. Ook al is dat wezenlijk breder dan enkel zorg, dan nog beslaat het niet integraal alle andere aspecten van de leefwereld van een Persoon, zoals bijvoorbeeld financiën, werk, onderwijs, vervoer, et cetera.

Hoewel deze RFC een wezenlijke versterking van het stelsel betreft, verandert het niets aan de posities van de huidige Deelnemers en Zorgaanbieders. Het betreft enkel uitbreiding van de mogelijkheden en geen nieuwe of gewijzigde verplichtingen. Voor de Deelnemers betekent deze RFC bovendien geen implementatie-inspanningen, op de terminologiewijziging na.

Deze tekst is aangepast op de opmerkingen die gemaakt zijn in de consultatiesessie van 10 juli 2020.

Oplossingsrichting

De oplossingsrichting bestaat uit vier elementen:

  1. het generaliseren en hernoemen van rollen in het (Zorg)Aanbiedersdomein
  2. het isoleren van zorgsector-specifieke afspraken in het Aanbiedersdomein
  3. de omgang met meerdere Catalogi naast elkaar
  4. de kwalificatie op Diensten

1. Generaliseren en hernoemen

  • Het Zorgaanbiedersdomein gaat het Aanbiedersdomein heten.
  • Het niet-zorgsector-specifieke deel van de rol Zorgaanbieder gaat Aanbieder heten. Dat staat voor Aanbieder van Gegevensdiensten of, in de context van RFC0026, Modulediensten. Daarbovenop identificeert het MedMij Afsprakenstelsel een uitbreidbare set van Aanbieder-typen, waarvan Zorg het eerste is, en vooralsnog enige. Elke Aanbieder is van precies één nader geduid type. Een partij kan desgewenst de rol Aanbieder in meerdere typen spelen. Zoals ook nu al bij Zorgaanbieder, kan één partij ook de Aanbieders-rol van één type vaker naast elkaar spelen. Er is dus veel flexibiliteit, maar een partij kan geen generieke (type-loze) Aanbieder spelen.
  • Dienstverlener zorgaanbieder gaat Dienstverlener aanbieder (DVA) heten. Een Dienstverlener aanbieder kan tegelijkertijd verwerker zijn voor Aanbieders van meerdere typen, voor zover de DVA voor die typen is geaccepteerd. De DVA-rol heeft dus ook een verbijzondering in typen en wordt type-specifiek geaccepteerd. Een belangrijk verschil met de Aanbieder-rol is echter dat een Dienstverlener aanbieder ook van meerdere typen tegelijk kan zijn (minstens één). Alle huidige Dienstverleners zorgaanbieder worden dus Dienstverlener aanbieder, met een acceptatie op het type Zorg. Alleen als een DVA op een zeker type Aanbieder is geaccepteerd, mag hij als ontsluiter optreden van Diensten van een Aanbieder van dat type.
  • Er moet nog worden bepaald of het ook nodig is Dienstverleners persoon type-specifieke te accepteren. Mogelijk raken de type-specifieke aspecten (zie punt 2 hieronder) alleen de Aanbieders met hun Dienstverleners, en niet de Dienstverleners persoon, zodat de acceptatie van laatstgenoemden onafhankelijk kan blijven van het Aanbieder-type. Mocht dit toch anders blijken, continueren hoe dan ook de huidige Dienstverleners persoon hun MedMij-label, maar dan dus voor het type Zorg.
  • De term DVZA kan in zwang blijven, met als betekenis: een DVA die op het type Zorg is geaccepteerd. Analoog daaraan kan de invoering van andere typen Aanbieders, gepaard gaan met een nieuwe afkorting (DVxA) voor Dienstverleners die voor dit type Aanbieder werken. Hoe dan ook is een Aanbieder altijd van één type en een Dienstverlener aanbieder altijd van minstens één type.
  • Welke typen Aanbieder er op enig moment zijn, is onderdeel van het beheer van het MedMij Afsprakenstelsel. (Wijzigingen in de) openstelling van het MedMij-netwerk voor zekere typen Aanbieder geschiedt op basis van wet- en regelgeving (waaronder de op dat type toepasselijke wet- regelgeving) en de doelen en principes van MedMij.
  • De Zorgaanbiederslijst gaat Aanbod heten.
  • De Zorgaanbiedersnaam gaat Aanbiedersnaam heten.
  • Het termgebruik Zorgaanbieder en Dienstverlener zorgaanbieder is al danig ingeburgerd. Deze termen kunnen in gebruik blijven zodanig dat Zorgaanbieder staat voor Aanbieder van het type Zorg en Dienstverlener zorgaanbieder voor Dienstverlener aanbieder met als enige type: Zorg.

2. Isoleren 

  • Er spelen vier (zorg)sector-specifieke aspecten mee in de huidige rol Zorgaanbieder:
    • de eisen aan authenticatie van de Persoon, door de Aanbieder;
    • de legitimatie van het informatieverkeer door middel van een combinatie van behandelovereenkomsten en gespecificeerde toestemming;
    • de verplichte onderdelen in de toe te passen beschikbaarheids- en ontvankelijkheidsvoorwaarde (vooral nu: de leeftijdsvoorwaarde);
  • Deze aspecten worden weggehaald uit de generieke rol Aanbieder en ondergebracht, voor elke type Aanbieder, op een specifieke pagina voor dat type.
  • De Regie-fase in de use cases Verzamelen, Delen en Abonneren, moet geschikt gemaakt worden voor mogelijk andere grondslagen van het verkeer. Zo kan het zijn dat niet een gespecificeerde toestemming de grondslag vormt, maar een wettelijke verplichting. In dat geval hoeft de Persoon dus niet om toestemming gevraagd te worden, maar volstaat bijvoorbeeld een melding van het wetsartikel op grond waarvan het verkeer kan plaatsvinden. Een andere mogelijkheid is dat het verkeer plaatsvindt op basis van een al eerdere door de betreffende Persoon gegeven langdurige toestemming.

3. Meerdere Catalogi naast elkaar

  • In andere sectoren wordt met andere families van Informatiestandaarden gewerkt. Die zullen ook in Gegevensdiensten in een Catalogus moeten worden ondergebracht. Om redenen van beheer zullen dat andere Catalogi moeten kunnen zijn, elk met een eigen beheercyclus, los van elkaar en, zoals nu al, naast de rest van het MedMij Afsprakenstelsel.
  • Bovendien zullen ook Modulediensten (zie RFC0026) in een Catalogus moeten kunnen worden opgenomen, wellicht in Catalogi gescheiden van die voor Gegevensdiensten.
  • In het gebruik van de Diensten op het MedMij-netwerk kunnen alle Catalogi samen als één grote worden opgevat. Er blijft dus ook maar één Aanbod (v/h Zorgaanbiederslijst) en één OAuthClientlist. De federatie van Catalogi is er alleen om het beheer te kunnen organiseren. De Diensten die bijeenkomen in één Catalogus zijn die Diensten die door die ene beheerder van die Catalogus worden beheerd. Het is mogelijk, maar niet noodzakelijk, dat dat Diensten zijn die door verschillende typen Aanbieders kunnen worden aangeboden. Het is ook mogelijk, maar niet noodzakelijk, dat in dezelfde Catalogus zowel Gegevensdiensten als Modulediensten zijn opgenomen. En het is mogelijk, maar niet noodzakelijk, dat in dezelfde Catalogus Diensten voorkomen die met verschillende standaardenfamilies zijn gestandaardiseerd.
  • Het gebruik van Diensten die met verschillende standaardenfamilies zijn gestandaardiseerd introduceert mogelijk een integratievraagstuk voor Dienstverleners persoon. Het zij echter vermeld dat het kwalificeren op Diensten een vrije keus blijft voor Dienstverleners persoon. Voor geen enkele Dienst is kwalificatie verplicht. MedMij zal zich blijven inspannen voor optimale interoperabiliteit tussen Diensten, maar het is al decennia lang een utopie gebleken om een voor alle maatschappelijke en private sectoren geaccepteerde wijze van standaardiseren te creëren. MedMij moet geen partij kiezen in de blijvende worsteling die deze verzuiling oplevert, maar zo reëel zijn om specifieke sectoren hun specificiteiten toe te staan. Mocht een Dienstverlener persoon het in zijn businessmodel vinden passen om wel (enige) sector-overstijgende integratie ter hand te nemen, is hij daarin vrij. mogelijk biedt hij daarmee zijn gebruikers voordelen die anderen niet bieden.
  • Bij elke Dienst in een Catalogus staat benoemd welke typen Aanbieders de betreffende Dienst mogen aanbieden.
  • Het inhoudelijk beheer van elke Catalogus vindt plaats onder aansturing van de Stichting MedMij, eventueel in diens opdracht door een separate partij. Catalogi bevatten Diensten; aan de standaarden achter die Diensten wordt slechts gerefereerd, voor zover MedMij ze vindt passen (zie principe 19). Het inhoudelijk beheer van een Catalogus vindt altijd plaats door een partij die redelijkerwijs als inhoudelijke vertegenwoordiger kan optreden voor de eisen die aan de Diensten worden gesteld die in die specifieke Catalogus worden opgenomen. Het technisch beheer van alle Catalogi vindt centraal plaats in de MedMij Beheerorganisatie.
  • Op deze wijze kan MedMij dus ook sturen op de kwaliteit van bijvoorbeeld apps en vragenlijsten. Bij apps kan ook de medisch-inhoudelijke kwaliteit onderdeel uitmaken van het beheer van de betreffende Catalogus. In dat geval zal MedMij voor het beheer samenwerken met een partij die deze kwaliteit in de samenwerking inbrengt, omdat deze kwaliteit buiten de scope van MedMij valt (zie ook principe 1).
  • Elke Catalogus moet gestructureerd zijn volgens de daarvoor bedoelde (conceptuele, logische en technische) Informatiemodellen.

4. Kwalificatie op Diensten

  • De Aanbieder is verantwoordelijk voor de inhoud van de door hem aangeboden Gegevensdiensten en Modulediensten. Hij is ook de verwerkingsverantwoordelijke. Dat betekent ook dat het de Aanbieder is die een kwalificatie op een Dienst moet kunnen overleggen voordat deze in het Aanbod wordt opgenomen. Op dit moment wordt de Dienstverlener zorgaanbieder nog als de gekwalificeerde partij gezien.
  • Ten behoeve van de efficiëntie van het kwalificatieproces moet een Zorgaanbieder zijn kwalificatie op een Dienst kunnen gaan ontlenen aan het feit dat de Dienstverlener aanbieder die hij deze Dienst laat ontsluiten een basiskwalificatie heeft op deze Dienst, in een technische configuratie waarvan deze Zorgaanbieder gebruik maakt. Dat impliceert ook dat alle (ook de huidige) kwalificaties van Dienstverleners zorgaanbieder geldig blijven, zij het dat zij ook de basis gaan vormen voor een (geheel administratieve) toekenning van een kwalificatie aan individuele Zorgaanbieders.
  • De kwalificatie wordt de formele belichaming van de relatie van het MedMij Afsprakenstelsel met de Aanbieder. De Aanbieder hoeft niet (een nieuwe soort) Deelnemer te worden, omdat al haar verantwoordelijkheden bij haar rol als Aanbieder van specifieke Diensten horen. Deze zijn helemaal via de kwalificatie te borgen, per Dienst. Met zijn basiskwalificatie kan een Dienstverlener aanbieder de Aanbieder voor een belangrijk deel de lasten van het kwalificatieproces ontnemen, maar niet de eindverantwoordelijkheid. De basiskwalificaties blijven, net als de huidige kwalificaties, een middel voor Dienstverleners om zich te onderscheiden in hun markt.
  • Wanneer een Aanbieder, van een zeker type, Diensten aanbiedt op het MedMij-netwerk, verbindt deze zich aan alle afspraken die in het MedMij Afsprakenstelsel bij de Aanbieder-rol horen, inclusief de afspraken die horen bij het specifieke type Aanbieder.
  • Er komt één kwalificatiebeleid en -proces voor alle Catalogi, waarop de beheerder van een specifieke Catalogus kan aanvullen.
Aanpassing van
  • terminologie aanpassen, in hele afsprakenstelsel, inclusief de Begrippenlijst
  • nieuwe pagina's voor elk type Aanbieder, vooralsnog één: Zorg
  • onderscheid maken tussen meerdere Catalogi; metadata bij Catalogi voegen, zoals de inhoudelijk beheerder; mogelijk Gegevensdienst-identificatie generaliseren
  • kwalificatiebeleid aanpassen
Impact op rollen

Impact op de waarde van het MedMij-label voor Dienstverleners

Het valt te verwachten dat de waarde van het MedMij-label voor Dienstverleners persoon zal stijgen wanneer er meerdere soorten Aanbieders op het MedMij-netwerk hun Gegevensdiensten gaan aanbieden. Dienstverleners persoon kunnen hun klanten dan een rijker pakket van functionaliteit aanbieden, dat zich niet beperkt tot zorg alleen, maar ook verder tot gezondheid in den breedte. Daar staat geen extra inspanning voor de Dienstverleners persoon tegenover. Mogelijk spreekt deze verbreding wel nieuwe spelers op de markt aan, die dan echter ook een grotere markt zal zijn. MedMij zal de openheid van markten willen bevorderen en zich marktafscherming niet als doel stellen.

Dat laatste geldt ook voor Dienstverleners aanbieder. Omdat er meer typen Aanbieders in zicht komen van MedMij, wordt hun markt groter, maar kunnen er ook nieuwe spelers zich op de markt gaan bewegen. Bij Dienstverleners zorgaanbieder zijn er echter wel implicaties qua implementatie. Andere soorten Aanbieders kunnen andere, en ook lichtere eisen stellen aan bijvoorbeeld authenticatie. Dat maakt de waarde van het MedMij-label voor verschillende typen Aanbieders mogelijk verschillend. Om de markt op dit punt eerlijk te houden, lijkt het een goede overweging om het MedMij-label voor Dienstverleners zorgaanbieder te differentiëren per type Aanbieder. Er moet immers ook per type Aanbieder geaccepteerd worden. Binnen één type Aanbieder zijn de implementatie-inspanningen wel identiek. Over speelt dit pas als er ook feitelijk een tweede type Aanbieder zou worden geïntroduceerd. Daarvan is in deze voorbereidende RFC nog geen sprake.

Impact op governance

Zorgaanbieders hebben momenteel hun plaats in de governance van het MedMij Afsprakenstelsel via de koepels in de Eigenaarsraad. Wanneer een tweede type Aanbieder zou worden toegevoegd, waarvan in deze voorbereidende RFC nog geen sprake is, moet worden overwogen ook dit type Aanbieder, bij voorkeur via een koepel, deel te laten nemen in de Eigenaarsraad.

Impact op beheer

N.t.b.

Impact op RnA

Op het gebied van (meerdere) Catalogi en typering van Aanbieders.

Impact op Acceptatie
  • Op het gebied van terminologie.
  • Bovendien aparte acceptatie per type Aanbieder, maar dat speelt pas als er later feitelijk een tweede type Aanbieder zou worden toegevoegd.
Gerelateerd aan (Andere RFCs, PIM issues)
Eigenaar

Paul Oude Luttighuis

Implementatietermijn

1.3.0

Motivatie verkorte RFC procedure (patch)

n.v.t.

Compliance aan principes van MedMij

Principe
Principe

1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal

Positief

11 Stelselfuncties worden vanaf de start ingevuld

Neutraal

2 Dienstverleners zijn transparant over de gegevensdiensten 

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

Neutraal

Dienstverleners zijn aanspreekbaar door de gebruiker

Neutraal

14 Uitwisseling is een keuze

Neutraal

De persoon wisselt gegevens uit met de zorgaanbieder (Aanbieder)

Positief

15 Het MedMij-netwerk is gebruiksrechten-neutraal

Neutraal

MedMij spreekt alleen af wat nodig is

Positief

16 De burger regisseert zijn gezondheidsinformatie als uitgever

Positief

De persoon en de zorgaanbieder (Aanbieder) kiezen hun eigen dienstverlener

Neutraal

17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld

Neutraal

De dienstverleners zijn deelnemers van het afsprakenstelsel

Positief

18 Afspraken worden aantoonbaar nageleefd en gehandhaafd

Neutraal

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

N.t.b.

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.

DreigingKansImpactDreigingsID (intern)Maatregelen
Geen





  • No labels