Een onderzoeksgroep vraagt gegevens op uit jullie systeem, en iemand stelt de levering met de hand samen uit drie tabellen en een spreadsheet. Die route loopt de komende jaren vast.
De European Health Data Space (EHDS) is Verordening (EU) 2025/327 en is op 26 maart 2025 in werking getreden. De verordening regelt twee dingen: hoe zorggegevens bij de patiënt en de behandelaar komen, en hoe dezelfde gegevens beschikbaar komen voor onderzoek, beleid en productontwikkeling. Dat tweede spoor heet secundair gebruik. Voor wie software laat bouwen of aanpassen, vertaalt de EHDS zich vooral naar een lijst met dingen die het systeem moet kunnen. Hieronder staat welke standaarden, exportpaden, kwaliteitseisen, logging en afscherming daarbij horen, en hoe je ze in een bestaand systeem inbouwt.
Wat de EHDS van je software vraagt en vanaf wanneer
De EHDS is op 5 maart 2025 gepubliceerd in het Publicatieblad van de Europese Unie en drie weken later van kracht geworden. De verordening werkt daarna gefaseerd door. Uiterlijk 26 maart 2027 stelt de Europese Commissie de uitvoeringshandelingen vast met de technische specificaties. Vanaf 26 maart 2029 gelden de regels voor secundair gebruik voor de meeste gegevenscategorieën, en moeten patiëntsamenvattingen, elektronische recepten en verstrekkingen tussen lidstaten uitwisselbaar zijn. Vanaf 26 maart 2031 komen daar beeldvormend onderzoek met verslag, uitslagen van laboratorium en andere diagnostiek en ontslagbrieven bij, plus genetische gegevens, gegevens uit klinisch onderzoek en gegevens uit biobanken.
2029 lijkt ver weg. Voor software is dat het niet. Een systeem dat volgend jaar in productie gaat, draait in 2029 nog steeds, en het datamodel dat je nu kiest bepaalt hoeveel werk een levering dan kost. De verordening raakt twee partijen tegelijk: de leverancier die de software bouwt en de zorginstelling die de gegevens houdt.
Dit artikel blijft aan de bouwkant. Wat de EHDS van een systeem vraagt, komt neer op vijf punten: de juiste standaarden spreken, leveren zonder handwerk, meetbare kwaliteit, herleidbare leveringen en afscherming per persoon. Hoe wij naar software in de zorg kijken, staat op onze pagina over healthcare.
De datastandaarden: HL7 FHIR, zibs en de Europese uitwisselvorm
Voor uitwisseling schrijft de EHDS een Europese uitwisselvorm voor, het European electronic health record exchange format. De Commissie legt de inhoud daarvan vast in uitvoeringshandelingen. De technische invulling loopt via HL7 FHIR. HL7 Europe publiceert implementatiegidsen op basis van FHIR R4, onder meer voor de Europese patiëntsamenvatting en voor het laboratoriumverslag.
In Nederland komt daar een laag bij. De zibs van Nictiz beschrijven per zorginformatieconcept welke gegevens je vastlegt en hoe. Ze vormen de basis voor de Nederlandse HL7 FHIR profielen en voor generieke datasets zoals de Basisgegevensset Zorg. Nictiz werkt aan een volgende generatie, zibs 2.0, waarin de Nederlandse afspraken bovenop internationale standaarden komen te liggen.
Daarnaast telt de codering. Klinische begrippen horen in SNOMED CT, uitslagen en metingen in LOINC. Een vrij tekstveld met "bloeddruk normaal" is voor secundair gebruik waardeloos.
Voor de bouw betekent dat drie dingen:
- Leg de mapping vast in code. Welk veld uit jouw tabellen hoort bij welke zib en welk FHIR profiel, met tests die meelopen in de pipeline. Een mappingdocument in een gedeelde map loopt binnen een jaar achter op het schema.
- Valideer tegen het profiel. Laat een build falen zodra een resource niet door de profielvalidatie komt.
- Houd rekening met versies. Profielen en codelijsten krijgen nieuwe versies. Leg per levering vast welke versie is gebruikt.
De techniek achter zulke koppelvlakken staat in ons artikel over de API koppeling; onze werkwijze op de pagina over API development.
Het exportpad voor secundair gebruik
Secundair gebruik loopt niet rechtstreeks van jouw database naar een onderzoeker. Elke lidstaat richt een toegangsinstantie in, de health data access body. Die beoordeelt aanvragen, geeft vergunningen af en beheert een beveiligde verwerkomgeving. In Nederland wordt die toegangsinstantie voorbereid in opdracht van het ministerie van VWS, samen met onder meer het RIVM en het CBS.
Jouw systeem zit aan de andere kant van die keten, als houder van gegevens. Artikel 60 van de verordening geeft de houder drie maanden na een verzoek om de gevraagde gegevens bij de toegangsinstantie aan te leveren, met in gerechtvaardigde gevallen een verlenging van maximaal drie maanden. Daarnaast lever je een beschrijving van je datasets aan voor de nationale catalogus, en controleer je jaarlijks of die nog klopt.
De gegevens gaan vervolgens naar een beveiligde verwerkomgeving. Gebruikers werken daarbinnen en nemen er alleen geanonimiseerde uitkomsten uit mee.
Wat je daarvoor inbouwt:
- Een exportpad naast het primaire proces. Een levering mag het dagelijkse werk in het systeem niet vertragen. Een leesreplica of een aparte analyseschil houdt beide gescheiden.
- Reproduceerbare selecties. Dezelfde vraag over dezelfde periode hoort later dezelfde set op te leveren. Dat vraagt om versiebeheer op je selectielogica en om peildatums in plaats van "nu".
- Bulklevering in een gestructureerd formaat, in plaats van een rapportage die iemand met de hand samenstelt.
- Een machineleesbare beschrijving per dataset: bron, bereik, periode, aantallen en kenmerken, gegenereerd uit het systeem zelf.
Het koppelvlak richting een toegangsinstantie is een integratievraagstuk met dezelfde aandachtspunten als andere systeemkoppelingen: formaat, frequentie, foutafhandeling en eigenaarschap.
Datakwaliteit en codering bepalen of je export bruikbaar is
De verordening koppelt een label voor datakwaliteit en bruikbaarheid aan datasets. Artikel 78 groepeert dat label in zes onderwerpen: documentatie van de data, technische kwaliteit, processen voor kwaliteitsbeheer, beoordeling van de dekking, informatie over toegang en levering, en informatie over wijzigingen in de data. Draagt een dataset zo'n label, dan levert de houder genoeg documentatie om het te laten controleren.
Exports lopen zelden stuk op de techniek. Ze lopen stuk op de inhoud:
- vrije tekst waar een code hoort
- metingen zonder eenheid of zonder tijdzone
- lokale codelijsten die nergens anders bestaan
- lege velden die soms "onbekend" en soms "niet van toepassing" betekenen
- dezelfde persoon die twee keer in het systeem staat
Die problemen los je op aan de invoerkant: gecodeerde velden met codelijsten uit SNOMED CT of LOINC in plaats van eigen tabellen, validatie op het moment van vastleggen, eenheden en tijdstempels expliciet opgeslagen, en kwaliteitscijfers die je kunt laten zien. Volledigheid per veld en dekking per periode zijn meetbaar; toon ze in een dashboard voordat iemand erom vraagt.
Die discipline is niet nieuw voor software in gereguleerde sectoren. In MRO software voor de luchtvaart, die wij bouwen, moet van elk onderdeel vastliggen wat ermee is gebeurd en wanneer. Dezelfde aanpak maakt zorgdata bruikbaar voor onderzoek.
Logging, herleidbaarheid en afscherming
Voor primair gebruik schrijft de EHDS twee verplichte softwarecomponenten voor in systemen die met de prioritaire gegevenscategorieën werken. De ene verzorgt import en export in de Europese uitwisselvorm. De andere legt vast wie welke gegevens heeft ingezien.
Voor secundair gebruik komt daar een tweede laag bij. Mensen mogen zich op elk moment en zonder opgaaf van reden afmelden voor secundair gebruik van hun gegevens. Dat is een veld in je datamodel en een filter in je exportpad, inclusief afgeleide tabellen, caches en eerder klaargezette bestanden.
Ook de mate van afscherming ligt vast. Gepseudonimiseerde gegevens komen alleen in beeld wanneer geanonimiseerde gegevens niet volstaan voor het doel, en dat moet in de aanvraag onderbouwd zijn en in de vergunning staan. Voor de bouw betekent dat vier dingen:
- Sleutelbeheer buiten de dataset. De koppeling tussen pseudoniem en persoon hoort in een aparte omgeving met eigen toegangsrechten.
- Een eigen pseudoniem per levering. Zo zijn twee leveringen niet zomaar aan elkaar te plakken.
- Herkomst per record. Welk bronsysteem, welke profielversie, welk moment van vastleggen.
- Een logboek waaruit niets verdwijnt. Wie heeft wat geleverd, aan wie, op grond van welke vergunning en met welke selectie.
Herleidbaarheid van dit type bouwen we ook buiten de zorg. In RFID toepassingen in de supply chain is elke scan een gebeurtenis die jaren later nog terug te vinden moet zijn, met bron, moment en plaats.
De EHDS inbouwen in een bestaand systeem
Weinig leveranciers beginnen met een leeg scherm. De praktijk is een systeem dat al jaren draait, met een datamodel dat ooit voor iets anders is bedacht. Een werkbare volgorde:
- Inventariseer wat je houdt. Welke gegevens staan erin, uit welke bron, en onder welke categorie van de verordening vallen ze. Artikel 51 noemt zeventien categorieën, van gegevens uit dossiers tot gegevens uit medische hulpmiddelen, registraties en biobanken.
- Maak de mapping. Van jouw velden naar zib en FHIR profiel, met een lijst van alles wat niet past. Die lijst is je echte backlog.
- Meet eerst de kwaliteit. Volledigheid, codering en dubbelingen, voordat je een termijn toezegt.
- Bouw het exportpad apart. Een leeslaag of replica met een eigen schema, zodat het primaire proces ongemoeid blijft.
- Zet afscherming in het pad zelf. Afmeldingen, pseudonimisering en selectie horen in de exportlaag, niet in een handmatige controle achteraf.
- Log elke levering en bewaar de definitie van de selectie erbij.
- Test met een echte levering, voordat er een termijn van drie maanden loopt.
Bij een systeem dat tegen zijn grenzen aanloopt, valt deze stap vaak samen met modernisering. De exportlaag is dan meestal het eerste stuk dat je lostrekt, zonder het hele systeem open te breken.
Wij bouwen en moderniseren al ruim dertig jaar software voor sectoren waar herleidbaarheid meetelt, met 30+ engineers in Nijmegen en Sarajevo, 100+ projecten en certificering volgens ISO 9001 en ISO 27001. De mensen die het systeem bouwen, houden het daarna draaiend. Loop je tegen deze vraag aan, plan dan een gesprek en we kijken mee naar je datamodel en je exportpad.
Veelgestelde vragen
Wat is de EHDS?
De EHDS is de European Health Data Space, vastgelegd in Verordening (EU) 2025/327. De verordening regelt hoe zorggegevens binnen Europa beschikbaar komen voor de zorg zelf en voor secundair gebruik: onderzoek, beleid, innovatie en productontwikkeling. Ze is op 26 maart 2025 in werking getreden en wordt gefaseerd van toepassing, met belangrijke momenten in 2027, 2029 en 2031.
Vanaf wanneer moet mijn software hieraan voldoen?
Uiterlijk 26 maart 2027 stelt de Europese Commissie de technische uitvoeringshandelingen vast. Vanaf 26 maart 2029 gelden de regels voor secundair gebruik voor de meeste gegevenscategorieën en zijn de eerste categorieën uitwisselbaar. Vanaf 26 maart 2031 volgen onder meer beeldvorming, uitslagen, ontslagbrieven en genetische gegevens. Systemen die nu gebouwd worden, draaien op die momenten nog.
Moeten we alles omzetten naar HL7 FHIR?
Nee. Je interne datamodel mag blijven zoals het is. Wat erbij komt, is een laag die jouw model vertaalt naar de Europese uitwisselvorm en de bijbehorende FHIR profielen, plus codering in SNOMED CT en LOINC. Leg die vertaling vast in code, met tests, zodat ze niet achterloopt op het schema.
Wat verandert er voor bestaande maatwerksoftware?
Meestal drie dingen: een exportpad naast het primaire proces, meetbare datakwaliteit en een logboek per levering. Daar komt afscherming bij, zodat afmeldingen en pseudonimisering in het exportpad zelf zitten. De rest van de applicatie blijft vaak ongewijzigd.
