Toelatingseisen voor de MedMij Catalogus

Versie 1.0.0, datum publicatie 14 May 2024

Met de introductie van het volwassenheidsniveau voor Gegevensdiensten in versie 2.2.0 van het MedMij Afsprakenstelsel zullen vanaf 14 May 2024 alle nieuwe Gegevensdiensten een volwassenheidsniveau hebben.

Reeds gepubliceerde Gegevensdiensten in de Catalogus zullen echter nog geen volwassenheidsniveau hebben. Er wordt stapsgewijs gewerkt aan het vaststellen van het volwassenheidsniveau voor deze Gegevensdiensten. Zodra het volwassenheidsniveau voor een Gegevensdienst is vastgesteld, zal deze in de Catalogus worden weergegeven.

Stichting MedMij is eigenaar van de MedMij Catalogus waarin de Gegevensdiensten zijn gepubliceerd. Deze Gegevensdiensten hebben een bepaald volwassenheidsniveau. Om het gewenste kwaliteits- en volwassenheidsniveau van de gepubliceerde Gegevensdiensten te borgen zijn er toelatingseisen opgesteld. Deze toelatingseisen bestaan uit negen beoordelingsthema’s en 31 toetsingscriteria, waaraan een Gegevensdienst dient te voldoen voordat toetreding tot de MedMij Catalogus wordt geaccordeerd.

Gegevensdiensten in ontwikkeling (degene met de volwassenheidsniveaus Alpha en Beta) hoeven niet aan alle toetsingscriteria te voldoen. In de laatst twee kolommen van de onderstaande tabel wordt weergegeven welke toetsingscriteria vereist zijn voor het volwassenheidsniveau Alpha en welke voor Beta. Gegevensdiensten met het volwassenheidsniveau Release candidate en General availability dienen te voldoen aan alle toetsingscriteria.

Beoordelingsthema’s en Toetsingscriteria

Om te worden toegelaten tot de MedMij Catalogus wordt een Gegevensdienst getoetst aan de hand van negen beoordelingsthema’s. Aan ieder beoordelingsthema is één of meer van de 31 toetsingscriteria voor toelating gekoppeld. Op deze pagina is informatie te vinden over de thema's waaraan deze criteria gekoppeld zijn, worden de toetsingscriteria toegelicht en wordt verder uitgelegd hoe een indiener van een toelatingsverzoek kan aantonen aan de diverse criteria te voldoen.

In totaal zijn er 9 beoordelingsthema’s:

1. Richtlijn/Zorgafspraken

2. Governance

3. Volwassenheidsniveau veld

4. Functioneel ontwerp

5. Technisch ontwerp

6. Dataset

7. Testmogelijkheden

8. Kwalificatie

9. Implementatieplan

Overzicht Toetsingscriteria

*Er moet minimaal een 0.1 versie van het implementatieplan aanwezig zijn.

Uitleg over hoe te voldoen aan de Toelatingscriteria

Hieronder is voor elk criterium een toelichting te vinden over hoe een indiener kan aantonen dat een Gegevensdienst voldoet aan de toelatingscriteria voor de MedMij Catalogus.

Thema 1: Richtlijn/Zorgafspraken

MedMij eist dat een Gegevensdienst toegevoegde waarde heeft voor MedMij. Een Gegevensdienst moet bijdragen aan het doel van MedMij: ‘Meer grip op gezondheidsgegevens voor mensen’. Als een partij een Gegevensdienst wil ontwikkelen dan zijn er afspraken nodig over welke informatie gedeeld wordt en hoe er in het zorgproces met de informatie om wordt gegaan. Een richtlijn beschrijft welke uitwisseling van informatie nodig is bij bepaalde zorgprocesstappen. De richtlijn wordt opgesteld door degene die de zorg levert (of vertegenwoordiging daarvan) in samenwerking met patiëntvertegenwoordiging. Zonder richtlijn bestaat het risico dat te veel of te weinig informatie op het verkeerde moment op de verkeerde plek terecht komt. 

Criteria.Toelating_1.1: De Gegevensdienst moet toegevoegde waarde hebben voor MedMij

a. Onderbouwing van de intentie en toegevoegde waarde van Gegevensdienst ten opzichte van huidige situatie, bijvoorbeeld over de toename van de kwaliteit van zorg, wetgeving etc.

b. Getekende intentieovereenkomsten van minimaal één DVP en minimaal één DVA/XIS.

c. Minimaal één use-case beschreven vanuit persoonsperspectief welke ook is onderschreven door een belangenorganisatie.

d. Evaluatie van de positie van de standaard ten opzichte van andere standaarden.

Criteria.Toelating_1.2: Er zijn richtlijnen & zorgafspraken opgesteld in samenspraak met de houder en/of belangenorganisatie

a. Minimaal één uitgewerkte use-case met een uiteenzetting van de situatieschets hoe gegevens tussen patiënt en zorgverlener worden uitgewisseld en hoe de patiëntinformatie door de zorgverlener wordt gebruikt.

b. Er wordt aangetoond door welke partij of in afstemming met welke partij(en) richtlijnen en zorgafspraken zijn opgesteld. Deze richtlijnen en zorgafspraken moeten aansluiten bij de uiteengezette governance structuur.

Criteria.Toelating_1.3: De Gegevensdienst moet passen binnen de gegeven functies in het MedMij afsprakenstelsel en de Gegevensdienst voldoet aan wettelijke richtlijnen

a. Met de ondertekende 202404 Houderschapsovereenkomst.docx wordt verklaard dat de Gegevensdienst past binnen de functies van het MedMij Afsprakenstelsel.

b. Met de ondertekende 202404 Houderschapsovereenkomst.docx wordt verklaard dat er wordt voldaan aan wettelijke eisen en richtlijnen.

Criteria.Toelating_1.4: De binnen de Gegevensdienstgebruikte informatiestandaard beschrijft hoe de uit te wisselen informatie semantisch juist getoond kan worden

a. Een beschrijving over hoe de informatie uitgewisseld dient te worden.

b. Een toelichting over op welke manier metagegevens zoals bron, auteur, datum en tijd herleidbaar zijn.

c. De Zelfverklaring Ontsluiting metagegevens Zelfverklaring_Ontsluiting Metagegevens.docx is ondertekend. Hierin wordt verklaard dat de ontsluiting van metagegevens de richtlijnen van het MedMij Afsprakenstelsel volgt en dat de links naar de metagegevens niet gewijzigd worden zolang de Gegevensdienst geldig is.

 Thema 2: Governance

De besluitvorming rondom een Gegevensdienst moet zijn georganiseerd, conform NEN 7522.

Volgens deze NEN-norm heeft iedere Gegevensdienst een houder nodig die de inhoudelijke besluitvorming en de daarbij behorende rollen en processen inricht. Denk hierbij aan het aanstellen van een autorisator en het samenstellen van expertgroepen. Verder wijst de houder functionele- en technische beheerders aan die wijzigingen doorvoeren op de Gegevensdienst en/ of standaard. Daarnaast stelt de houder ook de visie, het kwaliteitsbeleid en de meerjarenstrategie voor de Gegevensdienst op.

Criteria.Toelating_2.1: Er is een houder die vanuit deze geaccepteerde rol een Gegevensdienst aanbiedt die is gebaseerd op een uitgewerkte meerjarenstrategie.

a. Ondertekende 202404 Houderschapsovereenkomst.docx MedMij.

b. Ingevulde Houderschapschecklist-V1-2.pdf (opgesteld door Nictiz, brede toepasbaarheid). Deze checklist bevat onder andere de eis voor de aanwezigheid van een kwaliteitsbeleid, een meerjarenstrategie voor de Gegevensdienst, een plan voor het gebruik van stelselbeheerstandaarden en een ingerichte governance structuur.

 Thema 3: Volwassenheid veld

Om een Gegevensdienst te implementeren moeten bronsystemen de informatie beschikbaar kunnen stellen volgens de afgesproken standaarden. Dit betekent dat informatie aan de bron gestandaardiseerd geregistreerd moet worden of dat bronsystemen de informatie kunnen converteren naar de afgesproken standaarden. Zie Template_uiteenzetting_criterium_3.1.docx

Criteria.Toelating_3.1: Het ontwerp van de bronsystemen en processen sluit aan bij informatiestandaarden binnen de Gegevensdienst

a. Uiteenzetting over het netwerk van de Gegevensdienst, inclusief de bronsystemen en een toelichting over de aansluiting binnen het netwerk (direct of middels conversie).

b. Uiteenzetting over de processen rondom de inzet van de Gegevensdienst inclusief toelichting.

Criteria.Toelating_3.2 Validatie van de praktische werking van Gegevensdienst in het veld heeft plaatsgevonden

a. Er heeft een testtraject plaatsgevonden (PoC, hackathon, pilot).

Verslaglegging van het testtraject, waarbij de werkzaamheid van de standaard wordt aangetoond.

Verslaglegging van alle bevindingen van het testtraject en hoe high en medium bevindingen die betrekking hebben op de Gegevensdienst zijn opgelost. 

Thema’s 4, 5 en 6: Functioneel ontwerp, technisch ontwerp en dataset

Een functioneel ontwerp beschrijft de processtappen van een gegevensuitwisseling. Het beschrijft de actoren, de gebeurtenissen en de inhoud (concepten) van wat er uitgewisseld wordt. Zo staat in een functioneel ontwerp bijvoorbeeld welke zorginformatiebouwstenen gebruikt moeten worden in deze gegevensuitwisseling.

Een technisch ontwerp volgt op een functioneel ontwerp en beschrijft hoe de informatie van de ene naar de andere plek getransporteerd moet worden. Het beschrijft het technische format waar de informatie beschikbaar wordt gesteld.

Wanneer er een richtlijn is, dan wordt de dataset aan de hand daarvan gedefinieerd. Het beschrijft in detail welke gegevenselementen opgenomen moeten worden in de standaard en of deze elementen verplicht gevuld moeten zijn, of als optioneel worden opgenomen.

Criteria.Toelating_4.1, 5.1 en 6.1: Er zijn een functioneel ontwerp, technisch ontwerp en dataset opgesteld dat allen voldoen aan de voorschriften.

a. Uitwerking van het functioneel ontwerp, deze bevat minimaal een inleiding en een beschrijving van het doel en de doelgroep, beschrijving van de use-cases, beschrijving van de actoren, beschrijving van de gebeurtenissen, beschrijving van de concepten) en beschrijving van de scenario's (de uitwisseling inclusief transacties).

b. Uitwerking van het technisch ontwerp dat volgt uit het functioneel ontwerp. Het technisch ontwerp toont aan hoe informatie van de ene naar de andere plek gaat. Het ontwerp is gepubliceerd in Simplifier en bevat mapping, verwijzingen naar Simplifier profielen en voorbeeldmateriaal.

c. Uitwerking over de dataset, deze bevat de minimaal benodigde gegevenselementen (verplichtingen en optioneel gebruik), kardinaliteit, conformiteit, verwijzingen tussen concepten, codelijsten, terminologie inclusief onderbouwing van het gebruik, scenario’s en actoren.

Criteria.Toelating_4.2, 5.2 en 6.2: Het functioneel ontwerp, technisch ontwerp en de dataset sluiten aan op de versies van de generieke onderdelen (conform richtlijnen stelselbeheer).

a. In de Zelfverklaring aansluiting generieke onderdelen Zelfverklaring_Generieke onderdelen.docx wordt verklaard dat het functioneel ontwerp, technisch ontwerp en de dataset aansluiten op de versies van generieke onderdelen (bijvoorbeeld de richtlijnen omtrent FHIR).

b. De versiespecificatie van generieke onderdelen is opgenomen op een zichtbare plek in het functioneel ontwerp, het technisch ontwerp en de dataset.

Criteria.Toelating_4.3, 5.3 en 6.3: Het functioneel ontwerp, technisch ontwerp en de dataset zijn openbaar beschikbaar en publiekelijk toegankelijk gedurende de periode dat de standaard actief is

a. Met de Zelfverklaring Openbare beschikbaarheid Zelfverklaring_Openbare beschikbaarheid.docx verklaart de Beheerder van de informatiestandaard dat het functioneel ontwerp, het technisch ontwerp en de dataset openbaar beschikbaar zijn en publiekelijk toegankelijk blijven gedurende de periode dat de informatiestandaard gebruikt wordt binnen de Gegevensdienst.

b. Beheerder van informatiestandaard heeft een verklaring opgesteld en stemt hierin in met het opnemen van publicatie van links vanuit MedMij Catalogus en houdt deze doorlinkmogelijkheid actief gedurende het gebruik van de informatiestandaard in de Gegevensdienst.

Criteria.Toelating_4.4, 5.4 en 6.4: Een duidelijk beheerproces is ingericht rondom de afhandeling van wijzigingsverzoeken voor het functioneel ontwerp, technisch ontwerp en de dataset

a. Een uiteenzetting van het beheerproces voor wijzigingsverzoeken die aansluit bij governance structuur, wanneer mogelijk inclusief een publiek toegankelijke verzoekmogelijkheid.

 Criteria.Toelating_4.5: Het functioneel ontwerp laat zien aan te sluiten binnen de gegeven functies van het MedMij Afsprakenstelsel: Verzamelen of Delen

a. Het functioneel ontwerp benoemt functie Verzamelen of Delen expliciet.

b. Een toelichting van het functioneel ontwerp, namelijk hoe de functie Verzamelen of Delen aansluit bij de Gegevensdienst en informatie standaard.

Criteria.Toelating_5.5: Het technisch ontwerp dient unieke identifiers gespecificeerd te hebben voor de afzonderlijke gegevenselementen

a. Een beschrijving van hoe informatie uniek identificeerbaar is binnen het technisch ontwerp

Criteria.Toelating_6.5: De dataset is voorzien van patiëntvriendelijke termen

a. Er zijn afspraken over het weergeven van informatie in begrijpelijke taal.

b. Er zijn afspraken over wie verantwoordelijkheden draagt voor lagen van vertalingen.

Criteria.Toelating_4.6, 5.6 en 6.6: Het functioneel ontwerp, technisch ontwerp en de dataset volgen de versionering van de SemVer standaard.

a. Er is een Zelfverklaring Versionering volgens SemVer Zelfverklaring_Versionering volgens SemVer.docx waarin wordt verklaard dat de versionering van de ontwerpen en dataset verloopt via de SemVer - methodiek.

Criteria.Toelating_6.7: Er is een richtlijn over de de-duplicatie en reconciliatie van gegevens

a. Voor de dataset is een richtlijn opgesteld waarin de werkwijze voor reconciliatie en de-duplicatie van gegevens wordt toegelicht.

Thema 7: Testen

Er moeten testmogelijkheden zijn voor leveranciers, bijvoorbeeld in de vorm van testmateriaal. Zij kunnen met beschreven fictieve situaties en gegevens controleren of hun configuratie naar behoren werkt. Bij testmogelijkheden kan je ook denken aan hackathons, pilots, of een zandbak/ testomgeving om configuraties in uit te proberen.

Criteria.Toelating_7.1: Testmateriaal en testmogelijkheden moeten beschikbaar zijn voor deelnemers.

a. Aanleveren van uitgewerkte testscenario’s

b. Beschikbaar stellen van een testvoorziening

c. Beschikbaar stellen van testondersteuning

d. Toelichting geven op het beschikbaar stellen van testfaciliteiten.

Thema 8: Kwalificatie

Een kwalificatie wordt uitgevoerd op basis van kwalificatiemateriaal. Kwalificatie materiaal geeft een fictieve situatie van gegevensuitwisseling weer, aan de hand waarvan moet worden aangetoond dat informatie op de juiste manier wordt uitgewisseld.

Criteria.Toelating_8.1: De informatiestandaard waarop de Gegevensdienst is gebaseerd, is te kwalificeren, zowel technisch als functioneel

a. Verklaring door de kwalificerende partij waarin wordt verklaard dat de toetseisen en kaders van de standaard helder, eenduidig en als zodanig geverifieerd zijn.

b. Een verklaring die door een kwalificerende partij wordt afgegeven dat er toetsmateriaal beschikbaar is gesteld voor de kwalificerende partij in de vorm van aanleverformats, CCG, scripts en een informatiepagina voor kwalificatie.

Criteria.Toelating_8.2: Er is een toereikend (her)kwalificatieproces beschikbaar voor de informatiestandaard waarop de Gegevensdienst is gebaseerd

a. De kwalificatie verloopt via een door Stichting MedMij erkende partij.

b. Een verklaring afgegeven door de kwalificerende partij over de uitwerking & toelichting op het ingericht proces en dat deze is opgezet vanuit al bestaande processen.

c. Verklaring kwalificerende partij waarin wordt verklaard dat er een feedbackloop is ingericht voor bevindingen die naar voren komen uit de kwalificatie.

d. Verklaring kwalificerende partij dat de richtlijnen en werkwijze voor her-kwalificatie duidelijk zijn beschreven.

Thema 9: Implementatieplan

Een implementatieplan bepaalt het startniveau van de uitwisseling en geeft zekerheid aan de kwaliteit van de afspraken en standaard. Het creëert commitment en geeft een realistisch beeld van de doorlooptijd van het implementatietraject.

Criteria.Toelating_9.1: De Gegevensdienst moet beschikken over een implementatieplan (of migratieplan bij vervanging)

a. Een implementatieplan dat minimaal het volgende bevat:

Tijdspad voor ontwikkeling eerste implementatie

Tijdspad voor kwalificatie- en acceptatie traject

Introductiestrategie ten aanzien van GLG, Pilot of PoC

Toetsingscriteria voor beoordeling voor opschaling

Criteria.Toelating_9.2: De Gegevensdienst moet beschikken over een releasebeleid dat aansluit bij de meerjarenstrategie en het uitgewerkte implementatieplan

a. Uitwerking & toelichting Releasebeleid