Waarom is deze RFC nodig? | Er zijn redenen om een nieuw fundament te geven aan de rol van de (Zorg)aanbieder in het MedMij Afsprakenstelsel. - 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 uit verschillende . 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.
- Zorgaanbieders spelen een hoofdrol in het MedMij Afsprakenstelsel, als aanbieders en . 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.
- 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)aanbieders. RFC0026 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 . 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: - het generaliseren en hernoemen van rollen in het (Zorg)Aanbiedersdomein
- het isoleren van zorgsector-specifieke afspraken in het Aanbiedersdomein
- de omgang met meerdere Catalogi naast elkaar
1. Generaliseren en hernoemen- Het Zorgaanbiedersdomein gaat het Aanbiedersdomein heten.
- Het niet-zorgsector-specifieke deel van de rol Zorgaanbieder gaat heten. Dat staat voor Aanbieder van Gegevensdiensten of, in de context van RFC0026, Modulediensten. Daarbovenop identificeert het MedMij Afsprakenstelsel een uitbreidbare set van , 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.
- 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, . 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.
- , 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 heten.
- De Zorgaanbiedersnaam gaat Aanbiedersnaam heten.
- Het termgebruik 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 drie (zorg)sector-specifieke aspecten mee in de huidige rol Zorgaanbieder:
- de legitimatie van het informatieverkeer door middel van een combinatie van behandelovereenkomsten en
- Deze aspecten worden weggehaald uit de generieke rol Aanbieder en ondergebracht, voor elke type Aanbieder, op een specifieke pagina voor dat type.
- De in de use cases Verzamelen, Delen en Abonneren, moet geschikt gemaakt worden voor mogelijk andere grondslagen 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.
- In andere sectoren wordt met andere families van Informatiestandaarden gewerkt. Die zullen ook in Gegevensdiensten in een moeten worden ondergebracht. Om redenen van beheer zullen dat andere 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 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 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 . 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 Aanbieder 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 Aanbieder 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 .
- 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 , 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 DienstverlenersHet 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. Overigens 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 MedMij-organisatieDeze RFC heeft geen impact op de MedMij-organisatie, maar als er een nieuw type Aanbieder zou worden toegevoegd, heeft dat wel impact. - Zorgaanbieders hebben momenteel hun plaats in de governance van het MedMij Afsprakenstelsel via de koepels in de Eigenaarsraad. Wanneer echter een nieuw 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.
- Er moeten voor nieuwe types Aanbieder mogelijk beheerders van nieuwe Catalogi worden aangewezen en mogelijk nieuwe partijen die acceptatie en kwalificatie ter hand nemen.
Impact op PersoonDat een Persoon met diens PGO niet beperkt is tot uitwisseling met alleen Zorgaanbieders is een cruciaal aspect van diens regie op gezondheid. Gezondheid beperkt zich niet tot de grenzen die in de systeemwereld van het aanbod zijn aangebracht. Hoe belangrijk die systeemgrenzen ook zijn voor de kwaliteit en beheersing van dat aanbodssysteem, de leefwereld van de Persoon overschrijdt die grenzen onvermijdelijk en ruimschoots. De komst van PGO's geeft de Persoon de mogelijkheid zelf een rol te spelen in de overbrugging van de verzuiling die tussen de systeemzuilen maar moeizaam overbrugbaar is. Dat die overbrugging evengoed onder de hoede van een afsprakenstelsel komt te staan waarborgt de betrouwbaarheid en biedt ook een concreet startpunt voor bevordering van interoperabiliteit tussen die zuilen. Een zuilen-overstijgend afsprakenstelsel is effectiever en haalbaarder dan een zuilen-overstijgende standaard.
|
---|
Impact op beheer | |
---|
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 | |
---|
Implementatietermijn | |
---|
Motivatie verkorte RFC procedure (patch) | |
---|