Om via MedMij gezondheidsgegevens uit te wisselen, moeten zorginstellingen beschikken over een DigiD-aansluiting. Zonder deze aansluiting is gegevensuitwisseling niet mogelijk.

MedMij adviseert zorgaanbieders om aan te sluiten op de Toegangsverleningservice (TVS). Meer informatie hierover is te vinden op de website van DICTU.

In sommige gevallen kan een bestaande DigiD-aansluiting worden hergebruikt. Zowel zorgaanbieders als leveranciers vinden daarover uitgebreide informatie via bovengenoemde bronnen.

Het begint met een kennismakings- en intentiegesprek met onze leveranciersmanager. Je kunt vragen stellen en je krijgt advies of MedMij-deelnemer worden voor jouw organisatie inderdaad de juiste stap is. Ook stellen we gezamenlijk vast of je een goed beeld hebt van het aanmeldtraject.

Daarna volgt een administratieve toets. Dit betekent dat je alle benodigde formulieren digitaal invult en samen met de gevraagde documenten verstuurt aan het MedMij Loket. Daarna ben je officieel kandidaat-deelnemer.

Bekijk onder factsheets het Factsheet Hoe word je deelnemer. Daarin lees je meer over het complete aanmeldproces.

* Een afgerond kwalificatietraject voor een gegevensdienst
* Een afgerond acceptatietraject voor één van de use cases
* Een geldige NEN 7510-certificering, inclusief audit op het aanvullend normenkader MedMij en pentest
* Een verplichte kwaliteitstraining gevolgd hebben

Voldoe je als kandidaat-deelnemer aan alle voorwaarden? Dan ontvang je het MedMij-label en ben je MedMij-deelnemer.

Vragen over Kwalificatie en Acceptatie kun je wel rechtstreeks sturen.

ISO-certificering is géén vervanging voor NEN 7510.

Deze naam moet duidelijk en herkenbaar zijn. Daarom gelden er vaste naamgevingsregels, zodat zorgaanbieders goed te onderscheiden zijn—ook als ze (bijna) dezelfde naam hebben als een andere organisatie.

Sommige zorgverleners kiezen er ook voor om hun officiële MedMij-naam actief te communiceren naar hun patiënten, bijvoorbeeld via hun website of in gesprekken. Zo weet een gebruiker zeker dat ze in hun PGO met de juiste organisatie te maken hebt.

Je organisatienaam blijft hetzelfde, de naam van je PGO of applicatie verandert

Elke MedMij-deelnemer mag de naam van de PGO en/of de applicatie wijzigen als de nieuwe naam van de PGO en/of de applicatie onder de statutair rechtspersoon (en de eventuele daaronder vallende handelsnamen) valt én de MedMij-gekwalificeerde gegevensdiensten aanbiedt. De MedMij-deelnemer (dienstverlener in het persoonsdomein - DVP en/of dienstverlener in het zorgaanbiedersdomein - DVA) toont aan dat de nieuwe naam is geregistreerd in een handelsregister onder de organisatienaam. De deelnemer stuurt een gewaarmerkt kopie van het handelsregister naar het MedMij-loket. Een medewerker van het loket controleert dit en voert de naamswijziging administratief door en raadpleegt - indien nodig - onze jurist.

Je organisatienaam verandert, je gegevensdienst blijft hetzelfde

Een MedMij-deelnemer verkoopt de PGO en/of applicatie. Het product blijft gelijk en krijgt een andere eigenaar. De nieuwe organisatie stuurt een ondertekende verklaring dat deze organisatie alle verplichtingen uit het MedMij Afsprakenstelsel op zich neemt. Een medewerker van het loket controleert dit, voert de naamswijziging administratief door en raadpleegt - indien nodig - onze jurist.

Je organisatienaam én je gegevensdienst veranderen

De MedMij-deelnemer draagt de PGO en/of applicatie over. Het product krijgt een andere eigenaar die een andere gegevensdienst aanbiedt dan de gegevensdienst waarvoor het MedMij-label is verkregen. Het ‘recht’ op voering van het MedMij-label zou kunnen vervallen. Inschakeling van onze jurist is noodzakelijk.

Hier vind je het MedMij Afsprakenstelsel.

Samen met ICT-leveranciers van PGO’s en zorginformatiesystemen én met patiëntenvertegenwoordigers werden informatiestandaarden ontwikkeld die voldoen aan de MedMij-spelregels. Daarbij is zoveel mogelijk gebruikgemaakt van bestaande standaarden. Om uitwisseling met PGO’s mogelijk te maken, zijn aan deze standaarden MedMij-specificaties toegevoegd. Deze noemen we gegevensdiensten. Ze zijn gebaseerd op HL7 FHIR en vertaald naar FHIR-profielen: technische richtlijnen die ontwikkelaars van PGO’s, zorginformatiesystemen en apps kunnen gebruiken om hun systemen op elkaar aan te laten sluiten.

Om via MedMij gezondheidsgegevens uit te wisselen, moeten zorginstellingen beschikken over een DigiD-aansluiting. Zonder deze aansluiting is gegevensuitwisseling niet mogelijk.

MedMij adviseert zorgaanbieders om aan te sluiten op de Toegangsverleningservice (TVS). Meer informatie hierover is te vinden op de website van DICTU.

In sommige gevallen kan een bestaande DigiD-aansluiting worden hergebruikt. Zowel zorgaanbieders als leveranciers vinden daarover uitgebreide informatie via bovengenoemde bronnen.

Is er voor een nieuwe gegevensdienst een aanvullende usecase nodig? Dan moet die eerst worden toegevoegd via het formele wijzigings- en releaseproces van het Afsprakenstelsel. Pas daarna kan de gegevensdienst worden opgenomen in de Catalogus.

Besluiten over het creëren, wijzigen of beëindigen van gegevensdiensten – en over opname in de catalogus – worden genomen door het bestuur van Stichting MedMij. (Kandidaat-)deelnemers worden hierover tijdig en duidelijk geïnformeerd via de reguliere communicatiekanalen van MedMij.

Tijdens de kwalificatie kijken we naar de berichten die het systeem van de gegevensaanbieder (DVA) verstuurt en naar schermprints van het systeem waar de gegevens oorspronkelijk zijn ingevoerd (het bronsysteem).

Het is wél belangrijk dat alle gegevens die in de bijlagen (addenda) van de gegevensdienst worden genoemd, ergens beschikbaar zijn (bijvoorbeeld door ze in te voeren in een testomgeving). Zo kunnen we beoordelen of de berichten juist en volledig zijn opgebouwd.

Het request dat een PGO-server hiervoor verstuurt is een standaard HTTP GET-verzoek, maar MedMij stelt aanvullende eisen: het verzoek moet worden verzonden via een mutual TLS-verbinding (mTLS). Dit zorgt voor een veilige en betrouwbare communicatie tussen systemen.

Een voorbeeld van zo'n (vereenvoudigd) HTTP-request is:

GET /stelselnode/zorgaanbiederslijst?api=1.1.2 HTTP/1.1
Host: api.provesproject.nl
Connection: keep-alive
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml; …
Let op: omdat dit over een beveiligde mTLS-verbinding loopt en afhankelijk is van specifieke certificaten en netwerkconfiguraties, is het lastig om één generiek voorbeeld te geven.

Meer informatie over deze verzoeken vind je in de technische documentatie van het MedMij Afsprakenstelsel en bij de betreffende interfacebeschrijvingen.

Wanneer een release niet backwards compatibel is, communiceren we dit duidelijk richting deelnemers. Planning is dan een belangrijk onderdeel van de afstemming. In overleg met het MedMij Afsprakenstelsel stellen we per gegevensdienst een geldigheidsperiode vast.

* Het functioneel ontwerp beschrijft de functionele eisen per gegevensdienst, inclusief welke zibs worden ondersteund. Voor sommige gegevensdiensten gelden daarnaast extra kwalificatievoorwaarden.
* Het kwalificatiescript licht per gegevensdienst toe wat de doelen zijn en welke uitkomsten van de kwalificatie worden verwacht.
* Het addendum bevat een overzicht van de exacte data en informatie die moeten worden opgeleverd, waaronder de schermprints.

Kortom: de combinatie van FO, script en addendum vormt de leidraad voor het aanleveren van de juiste en volledige schermprints.

Door inhoud (de data) én vorm (de manier waarop deze in het XIS worden geregistreerd) te combineren, kan MedMij een goed onderbouwde uitspraak doen over de interoperabiliteit. Zo waarborgen we dat gegevens correct, volledig en op eenduidige wijze worden uitgewisseld.

Als dit het geval is, moet dit voorafgaand aan de kwalificatie worden gemeld.

Zien we tijdens de kwalificatie afwijkingen in de FHIR-berichten? Dan kan MedMij – ter controle – vragen om een schermprint van de geïmporteerde gegevens in het XIS.

Een succesvolle ontsluiting met XIS A garandeert namelijk niet dat dit ook zonder meer geldt voor XIS B. Elke combinatie van DVA en XIS wordt afzonderlijk beoordeeld op interoperabiliteit en correctheid van de gegevensuitwisseling.

Voor de BgGGZ-gegevensdienst geldt dat minstens 90% van de 23 zibs beschikbaar moet zijn (dus ten minste 21 zibs). Daarom vervult de DVA de regierol binnen de zorginstelling: hij moet de gegevens samenbrengen vanuit meerdere bronsystemen. Dit maakt het vullen van de set een complexe, maar cruciale taak.

Een update van een zib kan impact hebben op de informatiestandaarden én daarmee op de kwalificatie van deelnemers. Eventuele wijzigingen worden zorgvuldig afgewogen en tijdig gecommuniceerd.

Bij deze gegevensdiensten ligt de focus van de kwalificatie uitsluitend op de correcte implementatie van de FHIR-berichten. Tijdens de kwalificatie moeten ook de originele berichten vanuit het bronsysteem worden aangeleverd, die via een andere communicatiestandaard zijn verzonden. Nictiz beoordeelt vervolgens of de vertaling naar FHIR technisch inhoudelijk juist is en geschikt voor uitwisseling richting de DVP (Dienstverlener in het persoonsdomein - oftewel de PGO-leverancier).

Let op: deze uitzonderingsroute is alleen van toepassing als het gebruikte bronsysteem al beschikt over een geldige AORTA-kwalificatie.

Zie ook het Testbeleid van de verplichte release van het MedMij Afsprakenstelsel. Naast het reguliere kwalificatietraject biedt Nictiz de mogelijkheid om vrijblijvend te testen op de testomgeving. Dit helpt PGO-leveranciers en DVA’s beoordelen of een applicatie nog aan de eisen voldoet.

Een DVA kan ervoor kiezen om te testen bij wijzigingen die een hoog risico vormen voor de interoperabiliteit of de kwaliteit van gegevensuitwisseling. Blijken de tests niet succesvol, dan is het mogelijk om de gegevensdienst opnieuw te kwalificeren met een nieuwe versie of systeemcombinatie.

Wanneer testen (en mogelijk opnieuw kwalificeren)?

We adviseren DVA’s te testen in de volgende situaties:

* Er is een versie-update van het bronsysteem of een andere betrokken partij.
* De DVA zelf voert een update of wijziging door.

Let op: Je kunt alvast starten met je NEN 7510-certificering, een belangrijke voorwaarde voor deelname.
Meer hierover lees je in de het factsheet over het MedMij Normenkader Informatiebeveiliging.

Voorbeelden van deze bouwstenen zijn:

* Autorisatie in de use case verzamelen
* Het opvragen van de whitelist
* De zorgaanbiederslijst (ZAL)
* De OAuth Client List (OCL)

Door gebruik te maken van deze bouwstenen kun je sneller ontwikkelen en testen. Let op: MedMij is niet de eigenaar van deze bouwstenen.

De bouwstenen zijn beschikbaar onder een AGPLv3-licentie. Dit betekent dat je ze vrij mag gebruiken en verwerken in je eigen product, mits je eventuele doorontwikkeling van de bouwsteen deelt met de community.

Je vindt de bouwstenen hier.

Om die reden is het nodig om alle combinaties van DVA en XIS'en te kwalificeren. Dat vraagt een flinke inzet van DVA’s, maar MedMij doet geen concessies aan de kwaliteit van het kwalificatieproces. Alleen zo zorgen we dat burgers hun gezondheidsgegevens correct en bruikbaar in hun PGO ontvangen.

Tegelijk blijven we samen met betrokken partijen kijken naar mogelijke verbeteringen in het proces, mét behoud van de hoge kwaliteitsstandaard.

Een succesvolle ontsluiting met XIS A garandeert namelijk niet dat dit ook zonder meer geldt voor XIS B. Elke combinatie van DVA en XIS wordt afzonderlijk beoordeeld op interoperabiliteit en correctheid van de gegevensuitwisseling.

Het zelfstandig aanleveren van schermprints zonder toestemming kan leiden tot juridische risico’s. Stem dit dus altijd af met je XIS-leverancier.

Voor de BgGGZ-gegevensdienst geldt dat minstens 90% van de 23 zibs beschikbaar moet zijn (dus ten minste 21 zibs). Daarom vervult de DVA de regierol binnen de zorginstelling: hij moet de gegevens samenbrengen vanuit meerdere bronsystemen. Dit maakt het vullen van de set een complexe, maar cruciale taak.

De deelnemer moet zelf beoordelen wat de aard en impact van wijzigingen zijn op implementaties en de ondersteuning van gegevensdiensten. Om dit goed in te schatten, kan de deelnemer gebruikmaken van zelftests om de gevolgen van wijzigingen tijdig te detecteren en beheersen.

*Alle partijen die deelnemen aan het MedMij-netwerk – dus ook XIS'en – moeten zich houden aan de eisen van het PKIoverheidstelsel. Dit garandeert een veilige en betrouwbare verbinding.*

In de netwerklaag zijn drie beveiligingsfuncties essentieel:

1. Beveiliging: De verbinding moet versleuteld zijn en voldoen aan de PKIoverheid-normen.
2. Authenticatie: Iedere partij moet zich op een betrouwbare manier kunnen identificeren.
3. Autorisatie: Het systeem moet controleren of een partij bevoegd is om gegevens te ontvangen of te versturen.
Voor de autorisatie maakt MedMij onderscheid tussen inkomend en uitgaand verkeer, omdat de manier waarop de andere Node wordt herkend en gecontroleerd in beide gevallen verschilt.

Om die reden is het nodig om alle combinaties van DVA en XIS'en te kwalificeren. Dat vraagt een flinke inzet van DVA’s, maar MedMij doet geen concessies aan de kwaliteit van het kwalificatieproces. Alleen zo zorgen we dat burgers hun gezondheidsgegevens correct en bruikbaar in hun PGO ontvangen.

Tegelijk blijven we samen met betrokken partijen kijken naar mogelijke verbeteringen in het proces, mét behoud van de hoge kwaliteitsstandaard.

Een succesvolle ontsluiting met XIS A garandeert namelijk niet dat dit ook zonder meer geldt voor XIS B. Elke combinatie van DVA en XIS wordt afzonderlijk beoordeeld op interoperabiliteit en correctheid van de gegevensuitwisseling.

Door inhoud (de data) én vorm (de manier waarop deze in het XIS worden geregistreerd) te combineren, kan MedMij een goed onderbouwde uitspraak doen over de interoperabiliteit. Zo waarborgen we dat gegevens correct, volledig en op eenduidige wijze worden uitgewisseld.

* Het functioneel ontwerp beschrijft de functionele eisen per gegevensdienst, inclusief welke zibs worden ondersteund. Voor sommige gegevensdiensten gelden daarnaast extra kwalificatievoorwaarden.
* Het kwalificatiescript licht per gegevensdienst toe wat de doelen zijn en welke uitkomsten van de kwalificatie worden verwacht.
* Het addendum bevat een overzicht van de exacte data en informatie die moeten worden opgeleverd, waaronder de schermprints.

Kortom: de combinatie van FO, script en addendum vormt de leidraad voor het aanleveren van de juiste en volledige schermprints.

Het zelfstandig aanleveren van schermprints zonder toestemming kan leiden tot juridische risico’s. Stem dit dus altijd af met je XIS-leverancier.

Als dit het geval is, moet dit voorafgaand aan de kwalificatie worden gemeld.

Zien we tijdens de kwalificatie afwijkingen in de FHIR-berichten? Dan kan MedMij – ter controle – vragen om een schermprint van de geïmporteerde gegevens in het XIS.

De deelnemer moet zelf beoordelen wat de aard en impact van wijzigingen zijn op implementaties en de ondersteuning van gegevensdiensten. Om dit goed in te schatten, kan de deelnemer gebruikmaken van zelftests om de gevolgen van wijzigingen tijdig te detecteren en beheersen.