Samenvatting

Waarom is deze RFC nodig?	Er is een stijgende vraag naar het omgaan met Diensten die verder gaan dan alleen gegevensuitwisseling met Verzamelen en Delen van gezondheidsgegevens, zoals het aanroepen en gebruiken van e-health-modules voor blended care (in de GGZ en elders), of een e-consultapplicatie. Functionaliteiten die gebruik die worden aangeboden in applicaties die buiten de PGO's staan, maar die wel gebruik kunnen maken van de standaarden voor gegevensuitwisseling. Daarmee kunnen Modules ook bouwen op het vertrouwen en de interoperabiliteit die MedMij borgt. Deze wensen zijn actuele items op de strategische roadmap van MedMij. Waar Gegevensdiensten gezondheidsgegevens laten Verzamelen of Delen, doen Modules ook iets met de gegevens. De functionaliteit van een Module kan geboden worden in de vorm van een een website, een app, of anderszins, zolang die functionaliteit maar elektronisch te benaderen is, in de vertrouwenscontext van MedMij. Het gebruik van een Module door een Persoon levert persoonlijke input- en outputgegevens op, die ook onder de regie van de Persoon moeten vallen. Daarom moet ook het Delen van die inputgegevens en Verzamelen van die outputgegevens door de Moduleaanbieder worden aangeboden. Hoewel deze RFC een wezenlijke versterking van het stelsel betreft, verandert het niets aan de posities van de huidige Deelnemers en Zorgaanbieders in het stelsel. Het betreft een wezenlijke uitbreiding van de mogelijkheden, maar geen nieuwe of gewijzigde verplichtingen. Voor de Deelnemers betekent deze RFC bovendien geen verplichte implementatie-inspanningen. Die zijn pas aan de orde wanneer een Deelnemer of een Aanbieder een zekere Module zou willen (laten) implementeren of gebruiken. Dat blijft geheel diens eigen keus.
Oplossingsrichting	Voor het mogelijk maken van Modules moet het allereerst mogelijk zijn Aanbieders van deze Modules in het stelsel op te nemen, ook als dit geen Zorgaanbieders zijn, en hen (waar nodig) te laten bijstaan door Dienstverleners. In RFC0046 wordt beschreven hoe in de MedMij Core gebruikgemaakt wordt van de rollen Aanbieder en Dienstverlener Aanbieder. In het onderwerp functionaliteiten worden specialisaties beschreven van deze rollen, die in deze RFC worden uitgewerkt. Typen modules Er wordt onderscheid gemaakt tussen drie verschillende typen modules. Het belangrijkste verschil tussen deze types is de verantwoordelijkheid voor gegevensverwerking. DVP modules De verantwoordelijkheid voor gegevensverwerking ligt bij de DVP. De module kan direct beschikken over de bij de DVP aanwezige gezondheidsgegevens en nieuwe gegevens worden meteen gedeeld met de DVP. De door de DVP geauthenticeerde identiteit van de gebruiker wordt, indien noodzakelijk, overgenomen door de module. Autorisatie voor het uitwisselen van de gegevens tussen DVP en module is niet nodig, de verantwoordelijkheid over de gegevens ligt volledig bij de DVP. Gegevensuitwisseling tussen Moduleaanbieders van dit type (DVP's) en andere Aanbieders verloopt via de bestaande usecases Verzamelen en Delen. Aanbiedermodules De verantwoordelijkheid voor gegevensverwerking ligt bij een bestaande Zorgaanbieder, welke wordt ondersteund door een Dienstverlener Aanbieder. De module kan direct beschikken over de in de systemen van de Aanbieder aanwezige gezondheidsgegevens en nieuwe gegevens worden meteen gedeeld met de systemen van de Aanbieder. Authenticatie van de gebruiker wordt, indien noodzakelijk, door de module zelf uitgevoerd. Autorisatie voor het uitwisselen van de gegevens tussen Aanbieder en module is niet nodig, de verantwoordelijkheid over de gegevens ligt volledig bij de Aanbieder. Gegevensuitwisseling tussen Moduleaanbieders van dit type (Aanbieders) en DVP's verloopt via de bestaande usecases Verzamelen en Delen. Externe modules De verantwoordelijkheid voor gegevensverwerking ligt bij de Moduleaanbieder. De module kan alleen via de bestaande usecases beschikken over benodigde gegevens en nieuwe gegevens beschikbaar stellen. Authenticatie van de gebruiker wordt, indien noodzakelijk, door de module zelf uitgevoerd. Rollen Op de proceslaag van het interoperabiliteitsniveau is Aanbieder als rol gedefinieerd, net als Dienstverlener Aanbieder. Als specialisaties van deze rollen, worden vanuit deze RFC Moduleaanbieder en Dienstverlener Moduleaanbieder gedefinieerd. Met bijbehorende rollen op de onderliggende lagen. Vanuit deze rollen worden functies en gegevens beschreven, alsmede de verantwoordelijkheden. Dienstverlener Moduleaanbieder is alleen van toepassing bij externe modules. Gebruik Voor het starten van de modules moeten nieuwe usecases worden toegevoegd. Hierbij wordt rekening gehouden met de verschillende typen modules. Voor gegevensuitwisseling wordt gekeken naar de verwerkingsverantwoordelijke. Alleen in het geval van externe modules is de Moduleaanbieder de verwerkingsverantwoordelijke en daarmee ook de verantwoordelijke voor het leveren van de gegevensdiensten. Het binnen MedMij geldende all-to-all-principe is ook voor Modules geldend. Als een Aanbieder een Module plaatst binnen het MedMij-netwerk, moet deze vanuit alle Dienstverleners Persoon kunnen worden aangeroepen. Coördinatie Modules worden op dezelfde manier als Gegevensdiensten gecoördineerd door MedMij. Dat wil zeggen dat zij worden opgenomen in (eventueel aparte) Catalogi, dat het gebruik gestandaardiseerd wordt, dat erop gekwalificeerd moet worden en dat modules integraal worden opgenomen in het Aanbod. De Catalogus-structuur moet geschikt gemaakt worden voor Modules. Een Catalogus van Modules kan gezien worden als een "Module store" voor Aanbieders van zekere typen. Net als bij Gegevensdiensten staat bij Modules in de Catalogus vermeld welke type Aanbieders hen mag aanbieden. Daarnaast staat in de Catalogus om welk type module het gaat. In het beheer van de betreffende Catalogi kan kwaliteitsbeleid worden toegepast op de in de Catalogus opgenomen Modules, ook op de medisch-inhoudelijke kwaliteit ervan. Dat is aan de beheerder van die Catalogus. Kwalificatie Bij externe modules biedt de moduleaanbieder zelf de benodigde gegevensdiensten aan. In dit geval moet de (Dienstverlener) Moduleaanbieder, net als andere (Dienstverleners) Aanbieders, gekwalificeerd worden voor de aangeboden gegevensdiensten. Bij de twee andere typen modules is niet de niet aan de orde. Daar zijn respectievelijke de DVP en (Dienstverlener) Zorgaanbieder de partij die gekwalificeerd moet worden. Acceptatie Modules worden aangeboden door een specifiek type Aanbieder, namelijk Moduleaanbieder. Een apart type Aanbieder vraagt om een aparte acceptatie op dat type. Als er voor het gebruik van zekere Modules een andere wijze van authenticeren en/of toestemmen nodig zou zijn, inclusief een aangepaste toestemmings- of bevestigingsverklaring, hoort dat dus bij het betreffende type Aanbieder, niet bij de Module zelf. Vragenlijsten De omgang met vragenlijsten kan naar believen ingericht worden met Modules of alleen met Gegevensdiensten (zoals momenteel). In het eerste geval betreft de Module applicatiefunctionaliteit voor het tonen en laten invullen van een vragenlijst, terwijl in het tweede geval in het Persoonsdomein moet worden voorzien in die functionaliteit, typisch door de PGO. Deze twee varianten kunnen naast elkaar actief zijn op het MedMij-netwerk. Het MedMij Afsprakenstelsel laat de betreffende Informatiestandaarden vrij in deze keuze. Verwijzen Typisch wordt naar Modules verwezen in de resultaten van een Gegevensdienst. Zo kan een Persoon bijvoorbeeld een Gegevensdienst gebruiken van een Aanbieder uit de GGZ, waarmee hij een taak verzamelt om een Module te gaan gebruiken. Maar ook verwijzingen naar vragenlijsten zijn gewenst. Verwijzingen kunnen ook naar Gegevensdiensten verwijzen. MedMij moet gaan voorzien in een standaardwijze waarop verwijzende Aanbieders kunnen verwijzen naar Diensten van zekere (andere) Aanbieders. Zie hiervoor RFC0028 Verwijzingen in Gegevensdiensten (ter consultatie). Ook zonder doorvoering van RFC0028 kan RFC0026 alvast worden doorgevoerd.
Aanpassing van	Op basis van de MedMij Core uit RFC0046 Herstructureren afsprakenstelsel wordt het onderwerp Modules toegevoegd, waarbinnen de onderverdeling naar drie typen wordt beschreven. De Catalogus-structuur moet geschikt worden voor Modules. Er moet een standaardpatroon voor verwijzingen worden ontwikkeld.
Impact op rollen	Impact op Dienstverleners en Aanbieders Voor de positie van Dienstverleners en Aanbieders in het MedMij Afsprakenstelsel biedt deze RFC nieuwe mogelijkheden en is er alleen sprake van nieuwe verplichtingen voor zover men deze mogelijkheden, naar geheel eigen keus, zou willen benutten. De winst daarvan is dat het aanbieden en afnemen van Modules valt onder de vertrouwen- en interoperabiliteitsborging van MedMij. Dat kan een substantiële impuls geven aan zowel het aanbod als het gebruik van kwalitatief hoogwaardige Modules. Dat komt het zorgproces ten goede, maar ook de propositie van Dienstverleners. Dat Modules onder het vertrouwen- en interoperabiliteitskader van MedMij vallen, betekent echter ook dat zij de functionaliteit ervan mogelijk ter beschikking komt voor meerdere Aanbieders en/of Dienstverleners. Dat kan een flinke impact hebben op de concurrentiepositie van een mogelijke Aanbieder of Dienstverlener die deze functionaliteit al inzet als een onderscheidend element. Vooral menig Dienstverlener persoon zal zich willen onderscheiden met specifieke functionaliteit voor de Persoon. Voor een goed ontwikkelperspectief voor de PGO-markt zal MedMij dergelijke competitie ook kunnen toejuichen. Anderzijds kan de ontwikkeling van deze markt ook stagneren als er vanuit vertrouwen- en interoperabiliteitsperspectief niet in wordt geïntervenieerd. MedMij zal dan dus, met alle betrokkenen, passend beleid moeten (laten) voeren aangaande de opname van specifieke Modules, gebaseerd op actueel inzicht in vertrouwens- en interoperabiliteitsobstakels in de markt. Dat beleid komt tot uiting in het beheer van de Catalogi en de daarin opgenomen Modules. Dat beleid moet voortdurend keuzes maken om: zekere functionaliteit al dan niet überhaupt op te nemen in een Catalogus, als Module, in plaats van het vrij te laten in de markt; in de achterliggende Modulestandaard ruimte te laten voor aspecten waarop alsnog geconcurreerd kan worden. Overigens vindt momenteel, maar dan via Gegevensdiensten, in MedMij al standaardisatie plaats inzake vragenlijsten. Ook deze raakt de bovengenoemde aspecten.
Impact op beheer	Catalogus-beheer wordt geraakt.
Impact op RnA	Geen
Impact op Acceptatie	Geen
Gerelateerd aan (Andere RFCs, PIM issues)	AF-539, AF-1091, AF-1118, AF-1165, AF-1169 RFC0021, RFC0028
Eigenaar	Casper van der Harst , Bouke de Boer \| MedMij
Implementatietermijn	1.5.0 of later
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
3 Dienstverleners concurreren op de functionaliteiten	Positief	13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders	Neutraal
4 Dienstverleners zijn aanspreekbaar door de gebruiker	Positief	14 Uitwisseling is een keuze	Positief
5 De persoon wisselt gegevens uit met de zorgaanbieder	Positief	15 Het MedMij-netwerk is gebruiksrechten-neutraal	Positief
6 MedMij spreekt alleen af wat nodig is	Positief	16 De burger regisseert zijn gezondheidsinformatie als uitgever	Positief
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener	Positief	17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld	Neutraal
9 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

Opmerking vooraf

Deze RFC bouwt voort op RFC0021, die gaat over het uitbreiden van de soorten Aanbieders die, naast Zorgaanbieders, actief kunnen zijn op het MedMij-netwerk. Voor Modulediensten, het onderwerp van deze RFC, geldt dat ook. Ook die moeten kunnen worden aangeboden op het MedMij-netwerk door niet alleen Zorgaanbieders, maar bijvoorbeeld ook door specifieke Module-aanbieders. Daarom maakt deze RFC alvast gebruik van de terminologiewijzigingen die door RFC0021 worden voorgesteld. Het gaat om bijvoorbeeld:

Aanbieder (in plaats van alleen Zorgaanbieder)
Dienstverlener aanbieder (in plaats van Dienstverlener zorgaanbieder)
Aanbiedersnaam (in plaats van alleen Zorgaanbiedersnaam)
Aanbiedersnamenbeleid (in plaats van alleen Zorgaanbiedersnamenbeleid)
Aanbod (in plaats van Zorgaanbiederslijst)
Diensten en Modulediensten (in plaats van alleen Gegevensdiensten)

Deze RFC bouwt ook voort op RFC0028, die gaat over verwijzingen in Gegevensdiensten. Dat komt doordat in veel gebruikscontexten van Modulediensten de Persoon van een (Zorg)aanbieder in het kader van een behandeling de taak zal krijgen (Verzamelen) om een Moduledienst te gebruiken. De Gegevensdienst waarmee die taak wordt Verzameld zal dan moeten verwijzen naar de Moduledienst.

Naar aanleiding van de lessen uit de consultatiesessie van 10 juli 2020, is besloten deze RFC niet in release 1.3.0 op te nemen, maar op een nader te bepalen later tijdstip te behandelen.

Ontvangen opmerkingen van Frank Ploeg, d.d. 2 juli 2020

Het aspect van gegevensintegriteit over domeinen heen en over aanbieders geen zou moeten worden beschouwd.
De RFC wint aan duidelijkheid als enige use cases, bijvoorbeeld uit Koppeltaal, worden toegevoegd ter illustratie.

Nog uit te werken vragen:

Hoe richten we track & trace cq logging in ?

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.

Dreiging	Kans	Impact	DreigingsID (intern)	Maatregelen
Geen

Browser not supported