Wegwijs in de EHDS: inzicht in de vereisten voor systemen voor elektronische patiëntendossiers

Author info

Voor het eerst heeft de Europese Unie een specifiek regelgevingskader voor elektronische patiëntendossiers (EHR) ingevoerd. Deze nieuwe vereisten zijn vastgelegd in de Verordening betreffende de Europese ruimte voor gezondheidsgegevens (EHDS), die op 26 mei 2025 in werking is getreden. In dit artikel geven we een overzicht van de belangrijkste wettelijke vereisten en bespreken we de juridische, technische en nalevingsaspecten waarmee fabrikanten al in de vroegste stadia van ontwerp, ontwikkeling en implementatie rekening moeten houden bij hun producten. 

Als u geïnteresseerd bent in andere onderwerpen met betrekking tot de EHDS, zie dan: European Health Data Space - Het potentieel van EU-gezondheidsgegevens benutten, European Health Data Space: Het debat gaat door, EHDS ontsluiten: De laatste loodjes en de impact op bedrijven. 

Noodzaak van regulering van EPD-systemen in de EU 

De regulering van EPD-systemen is een noodzakelijke stap om de al lang bestaande versnippering van de digitale gezondheidsinfrastructuur in de Europese Unie aan te pakken. Historisch gezien zijn EPD-systemen vaak gebaseerd op verschillende technische normen en gegevensformaten, wat belemmeringen opwerpt voor de naadloze uitwisseling van gezondheidsinformatie tussen zorgverleners, regio's en lidstaten. Dit gebrek aan interoperabiliteit kan de continuïteit van de zorg belemmeren, de mogelijkheden van patiënten om toegang te krijgen tot hun gezondheidsgegevens en deze te delen beperken, en de ontwikkeling van grensoverschrijdende digitale gezondheidsdiensten in de weg staan. De Europese Commissie heeft interoperabiliteit consequent aangemerkt als een essentiële voorwaarde voor effectieve digitale gezondheidsdiensten en grensoverschrijdende gezondheidszorg. 

De reden voor de invoering van specifieke productwetgeving met betrekking tot EPD-systemen in het EHDS was dan ook het leggen van de technische basis die nodig is voor de effectieve implementatie van de EHDS-vereisten met betrekking tot zowel het primaire als het secundaire gebruik van elektronische gezondheidsgegevens (EHD) en daarmee het mogelijk maken van de naadloze en veilige uitwisseling van EHD in de hele Europese Unie. Een van de minder expliciete maar commercieel belangrijke doelstellingen van het EHDS is het terugdringen van vendor lock-in-praktijken die soms gepaard gaan met IT-systemen in de gezondheidszorg. 

De definitie van een EPD-systeem ontrafeld 

De EHDS definieert een EHR-systeem als ‘elk systeem waarbij de software, of een combinatie van de hardware en de software van dat systeem, het mogelijk maakt dat persoonlijke elektronische gezondheidsgegevens die behoren tot de prioritaire categorieën van persoonlijke elektronische gezondheidsgegevens zoals vastgesteld in de EHDS, worden opgeslagen, doorgegeven, geëxporteerd, geïmporteerd, geconverteerd, bewerkt of bekeken, en dat door de fabrikant is bedoeld om te worden gebruikt door zorgverleners bij het verlenen van patiëntenzorg of door patiënten bij het raadplegen van hun elektronische gezondheidsgegevens’. 

De definitie is opzettelijk in brede bewoordingen opgesteld om interoperabiliteit te waarborgen in het gehele ecosysteem van verbonden systemen. Bijgevolg omvat deze niet alleen systemen die informatie verzamelen en beheren, zoals ziekenhuisinformatiesystemen, maar ook de systemen die gegevens aan deze systemen leveren (deze systemen “voeden”). 

De onderstaande tabel combineert de relevante bepalingen van de EHDS, de overwegingen en de toelichtingen van de Commissie met aanvullende praktische interpretaties die bedoeld zijn om fabrikanten te ondersteunen bij het beoordelen of een bepaalde oplossing in aanmerking komt als EHR-systeem in het kader van de EHDS.

 

Element van de definitie van het EHR-systeem

Interpretatie/praktische richtsnoeren

‘elk systeem waarbij de software, of een combinatie van de hardware en de software van dat  systeem’

Een EHR-systeem kan deel uitmaken van een fysiek apparaat of een op zichzelf staand softwareprogramma zijn.

„het mogelijk maakt dat persoonlijke elektronische gezondheidsgegevens die behoren tot de prioritaire categorieën van persoonlijke elektronische gezondheidsgegevens die in het kader van de EHDS zijn vastgesteld, worden opgeslagen, doorgegeven, geëxporteerd, geïmporteerd, geconverteerd, bewerkt of bekeken”

Een EHR-systeem hoeft niet al deze functies (gegevens opslaan, doorgeven, exporteren, importeren, converteren, bewerken of bekijken) tegelijkertijd uit te voeren. Daarom kan de aanwezigheid van slechts één of enkele van deze functionaliteiten het systeem al binnen het toepassingsgebied van de EHDS-definitie brengen.

 

Volgens artikel 14, lid 1, van de EHDS omvatten de prioritaire categorieën van persoonlijke EHD patiëntendossiers, elektronische recepten, elektronische afleveringen, medische beeldvormingsonderzoeken en bijbehorende beeldvormingsrapporten, medische testresultaten, met inbegrip van laboratorium- en andere diagnostische resultaten en bijbehorende rapporten, en ontslagrapporten, waarvan de belangrijkste kenmerken zijn vastgelegd in bijlage I bij de EHDS. 

 

Een dergelijk systeem moet door de fabrikant specifiek bedoeld zijn voor de verwerking van een of meer prioritaire categorieën van elektronische gezondheidsgegevens. Het is daarom niet noodzakelijk dat het systeem alle prioritaire categorieën van EHD verwerkt; de verwerking van één enkele prioritaire categorie kan voldoende zijn om het systeem onder de definitie van een EHR-systeem te laten vallen (overwegingen 36 en 38 van de EHDS). 

 

„door de fabrikant bedoeld om te worden gebruikt door zorgverleners bij het verlenen van patiëntenzorg of door patiënten bij het raadplegen van hun elektronische gezondheidsgegevens”

Software for general puNet als bij de verordening inzake medische hulpmiddelen (MDR) legt de EHDS sterk de nadruk op het door de fabrikant beoogde doel. Of een bepaalde oplossing als EHR-systeem kwalificeert, hangt niet alleen af van de technische functionaliteiten ervan, maar ook van de manier waarop de fabrikant het systeem bedoeld heeft te worden gebruikt. Het beoogde doel moet duidelijk tot uiting komen in de technische documentatie overeenkomstig bijlage III van de EHDS.

Het klassieke voorbeeld van een EHR-systeem dat door de fabrikant bedoeld is om door zorgverleners te worden gebruikt bij het verlenen van patiëntenzorg, zijn systemen die door clinici worden gebruikt voor het vastleggen van aantekeningen en testresultaten en die bredere functionaliteiten voor patiëntenbeheer ondersteunen.

Software voor algemene doeleinden mag niet als een EHR-systeem worden beschouwd, zelfs niet wanneer deze in een zorgomgeving wordt gebruikt. Dit omvat gevallen zoals tekstverwerkingssoftware die wordt gebruikt voor het schrijven van rapporten die vervolgens deel gaan uitmaken van schriftelijke elektronische patiëntendossiers, middleware voor algemene doeleinden of databasebeheersoftware die wordt gebruikt als onderdeel van oplossingen voor gegevensopslag (overweging 38 van de EHDS).

Een EHR-systeem dat door de fabrikant bedoeld is om door patiënten te worden gebruikt bij het raadplegen van hun EHD, kan bijvoorbeeld een app omvatten die verbinding maakt met de EHD-toegangsdienst. Een smartwatch waarmee gebruikers hun EHD kunnen bekijken, zou daarentegen niet als een EHR-systeem worden aangemerkt, omdat deze buiten de context van de gezondheidszorg functioneert, met name buiten situaties waarin een patiënt actief medische zorg zoekt of ontvangt.rposes should not be considered to be an EHR system, even when used in a healthcare setting. That covers cases such as text-processing software used for writing reports that would then become part of written electronic health records, general-purpose middleware, or database management software that is used as part of data storage solutions (recital 38 of EHDS)

De EHDS vervangt de bestaande productwetgeving niet. Artikel 1, lid 5, bepaalt uitdrukkelijk dat de EHDS van toepassing is onverminderd de wetgeving inzake medische hulpmiddelen (MDR, IVDR) en kunstmatige intelligentie (AI-wet). Bijgevolg kan software tegelijkertijd onderworpen zijn aan verplichtingen uit hoofde van verschillende wettelijke kaders.

De onlangs bijgewerkte richtsnoeren van de MDCG inzake de kwalificatie en classificatie van software bevestigen dat EHR-systemen waarvan het primaire doel de opslag, het beheer en de uitwisseling van patiëntendossiers is, over het algemeen niet als medische hulpmiddelen worden aangemerkt. Afhankelijk van de functionaliteiten en het beoogde doel van de software kunnen zich echter drie scenario's voordoen: 

  • EHR-systeem als medisch hulpmiddel of in-vitrodiagnostisch hulpmiddel (IVD) – wanneer het EHR-systeem zelf voldoet aan de definitie van een medisch hulpmiddel of IVD volgens de MDR/IVDR; 
  • Module van een EHR-systeem als medisch hulpmiddel of IVD – wanneer afzonderlijke modules binnen het EHR-systeem voldoen aan de criteria om als medisch hulpmiddel/IVD te worden aangemerkt; 
  • Medisch hulpmiddel of IVD dat interoperabiliteit met een EPD-systeem claimt: wanneer software voor medische hulpmiddelen (MDSW) interoperabiliteit met een EPD-systeem claimt, moet aan zowel de MDR/IVDR- als de EHDS-vereisten worden voldaan. 

Er ontstaat een extra laag van complexiteit wanneer dergelijke software ook kwalificeert als een AI-systeem met een hoog risico onder de AI-wet, waardoor deze onderworpen wordt aan de aanvullende vereisten en nalevingsverplichtingen die daarin zijn vastgelegd. 

Vereisten voor EPD-systemen: interoperabiliteit en logboekcomponenten

Om de EHDS-doelstellingen van naadloze gegevensuitwisseling, toegankelijkheid en verantwoordingsplicht te verwezenlijken, moeten EHR-systemen voldoen aan verplichte eisen die specifieke functionele mogelijkheden van ge e EHR-systemen beschrijven. Centraal in dit kader staan twee geharmoniseerde softwarecomponenten die de consistente werking van EHR-systemen in de hele EU ondersteunen, namelijk:

  • de interoperabiliteitscomponent – maakt het importeren en exporteren van prioritaire categorieën van persoonlijke EHD mogelijk met behulp van het European Electronic Health Record Exchange Format (EEHRxF) 
  • de logboekcomponent – maakt het genereren van toegangslogboeken mogelijk die de transparantie en traceerbaarheid binnen diensten voor toegang tot gezondheidsgegevens ondersteunen. 

Bijlage II bij de EHDS-verordening bevat de essentiële eisen voor geharmoniseerde softwarecomponenten van EHR-systemen waarvoor interoperabiliteit met EHR-systemen wordt geclaimd. Naast specifieke eisen inzake interoperabiliteit en logboekregistratie stelt bijlage II een aantal algemene eisen vast die van toepassing zijn op beide geharmoniseerde softwarecomponenten. In het bijzonder moeten fabrikanten deze componenten zo ontwerpen en ontwikkelen dat ze veilig en beveiligd functioneren, hun beoogde doel vervullen en hun prestaties en functionaliteit behouden wanneer ze worden geïnstalleerd, gebruikt en onderhouden in overeenstemming met de instructies van de fabrikant. Die essentiële eisen zullen, waar relevant, ook van toepassing zijn op medische hulpmiddelen, medische hulpmiddelen voor in-vitrodiagnostiek, AI-systemen en wellness-toepassingen die interoperabiliteit met EHR-systemen claimen. 

De gedetailleerde technische specificaties die van toepassing zijn op deze geharmoniseerde softwarecomponenten moeten door de Europese Commissie worden vastgesteld via uitvoeringshandelingen in de vorm van gemeenschappelijke specificaties, die naar verwachting uiterlijk op 26 maart 2027 zullen worden aangenomen. Deze uitvoeringshandelingen zullen een centrale rol spelen bij het vormgeven van het praktische nalevingskader voor EPD-systemen, aangezien zij naar verwachting onder meer interoperabiliteitsnormen, beveiligingseisen, logboekfuncties en technische eisen met betrekking tot de EEHRxF nader zullen definiëren. 

Bijgevolg moeten fabrikanten de ontwikkeling ervan nauwlettend volgen, aangezien deze uiteindelijk wettelijke verplichtingen op hoog niveau zullen vertalen naar concrete technische vereisten die fabrikanten kunnen implementeren. De vaststelling van die uitvoeringshandelingen zal ook directe praktische gevolgen hebben voor fabrikanten, met name in de context van conformiteitsbeoordeling en nalevingsactiviteiten vóór het in de handel brengen. 

EHR-systemen op de EU-markt brengen 

Alvorens een EHR-systeem op de EU-markt te brengen, zullen fabrikanten de geharmoniseerde softwarecomponenten moeten testen binnen speciale Europese digitale testomgevingen. De Europese Commissie zal de software ontwikkelen die ten grondslag ligt aan die testomgevingen en deze op open-sourcebasis beschikbaar stellen. De resultaten van de tests en de conformiteitsbeoordeling moeten vervolgens worden opgenomen in de technische documentatie van het EHR-systeem. 

Fabrikanten van EHR-systemen moeten ook aan de volgende eisen voldoen: 

  • Technische documentatie – technische documentatie opstellen, bijhouden en regelmatig bijwerken waaruit blijkt dat de geharmoniseerde softwarecomponenten voldoen aan de essentiële eisen, met inbegrip van de resultaten van de tests die in de Europese digitale testomgeving zijn uitgevoerd;
  • Informatieblad – gebruikers kosteloos voorzien van een informatieblad met beknopte, volledige, nauwkeurige, duidelijke en toegankelijke informatie die relevant is voor hun gebruik van het EHR-systeem; 
  • EU-conformiteitsverklaring – de EU-conformiteitsverklaring opstellen en de CE-markering aanbrengen; 
  • Registratie in de EU-databank – EHR-systemen registreren in de EU-databank; 
  • Identificatie en contactgegevens van de fabrikant – de naam, contactgegevens en het centrale contactpunt binnen het EHR-systeem vermelden; 
  • Beheer van naleving gedurende de levenscyclus – procedures handhaven om voortdurende naleving gedurende de gehele levenscyclus van het EPD-systeem te waarborgen, met inbegrip van updates, wijzigingen en aanpassingen in de implementatie; 
  • Bewaarplicht – bewaar de technische documentatie en de EU-conformiteitsverklaring gedurende ten minste 10 jaar nadat het EHR-systeem in de handel is gebracht; 
  • Toegang tot broncode en programmeerlogica – verleen bevoegde autoriteiten toegang tot de broncode of programmeerlogica indien dit noodzakelijk en gerechtvaardigd is voor nalevingscontroles; 
  • Klachtenafhandeling en registers van non-conformiteit – stel procedures voor klachtenafhandeling vast en houd registers bij van klachten en non-conforme EHR-systemen. 
  • Correctieve maatregelen en terugroepacties – controleer de naleving en neem correctieve maatregelen, waaronder terugroepacties of uit de handel nemen, wanneer niet-naleving wordt vastgesteld;
  • Melding van non-conformiteiten en onderhoudsmaatregelen – distributeurs, importeurs, gemachtigde vertegenwoordigers, gebruikers en bevoegde autoriteiten informeren over non-conformiteiten, corrigerende maatregelen, terugroepacties, uit de handel nemen of verplichte preventieve onderhoudsmaatregelen; 
  • Samenwerking met autoriteiten – samenwerken met markttoezichtautoriteiten en alle informatie en documentatie verstrekken die nodig is om aan te tonen dat aan de EHDS-vereisten wordt voldaan. 

Gemachtigde vertegenwoordigers, importeurs en distributeurs van EHR-systemen zijn eveneens onderworpen aan specifieke verplichtingen in het kader van de EHDS. Deze omvatten taken met betrekking tot nalevingscontrole, het bewaren van nalevingsdocumentatie, samenwerking met bevoegde autoriteiten en markttoezichtautoriteiten, traceerbaarheid van marktdeelnemers, het nemen van corrigerende maatregelen in geval van niet-naleving en deelname aan markttoezichtactiviteiten. 

Hoe kunnen fabrikanten van EHR-systemen zich voorbereiden? 

De EHDS-vereisten voor EHR-systemen worden in twee fasen ingevoerd. De regels zullen eerst vanaf 26 maart 2029 van toepassing zijn op EHR-systemen die patiëntendossiers, elektronische recepten en elektronische afleveringen omvatten. De vereisten worden vervolgens vanaf 26 maart 2031 uitgebreid naar EHR-systemen die medische beeldvormingsonderzoeken, medische testresultaten en ontslagrapporten omvatten. 

Hoewel het nog enkele jaren duurt voordat de vereisten voor EHR-systemen van toepassing worden en veel van de technische vereisten nog onderworpen zijn aan toekomstige uitvoeringsbesluiten, duidt de EHDS nu al op een fundamentele transformatie in de manier waarop softwaresystemen voor de gezondheidszorg binnen de Europese Unie worden ontworpen, onderling verbonden, gedocumenteerd en gecontroleerd. 

Fabrikanten moeten naleving van de EHDS beschouwen als een voortdurende prioriteit in plaats van een taak die kort voor de toepasselijke deadlines kan worden afgehandeld. In de praktijk zal de EHDS waarschijnlijk de productarchitectuur, het cyberbeveiligingsbeleid, de aanbestedingspraktijken, de daarmee samenhangende contractuele verplichtingen en de commerciële langetermijnstrategie in de hele digitale gezondheidssector bepalen. Het is daarom van cruciaal belang dat fabrikanten al in een vroeg stadium van het productontwerp en de productontwikkeling beoordelen of hun oplossingen onder het EHDS-kader als EPD-systemen kunnen worden aangemerkt, of dat de door hen ontwikkelde medische hulpmiddelen en wellness-applicaties zo moeten worden ontworpen dat ze interoperabel zijn met dergelijke systemen. 

Vroegtijdige voorbereiding is essentieel. Fabrikanten moeten de productontwikkeling, de systeemarchitectuur en de technische documentatie afstemmen op de essentiële eisen die van toepassing zijn op geharmoniseerde softwarecomponenten van EHR-systemen. Zij moeten ook de uitvoeringsbesluiten die de Europese Commissie zal vaststellen nauwlettend volgen, aangezien deze de toepasselijke eisen op het gebied van techniek, interoperabiliteit, logboekregistratie, beveiliging en conformiteitsbeoordeling nader zullen specificeren.

Mocht u meer informatie nodig hebben over het EHDS-kader of hulp bij het beoordelen of uw softwareoplossing in aanmerking komt als EHR-systeem en welke wettelijke vereisten van toepassing zijn, dan staat ons team u graag bij – magdalena.kogut@timelex.eu; marta.wilinska@timelex.eu. 

Funded by the European Union under Horizon Europe Programme (Grant Agreement No. 101080756). Views and opinions expressed are however those of the AI4Lungs consortium author(s) only and do not necessarily reflect those of the European Union or the Health And Digital Executive Agency (HaDEA). Neither the European Union nor the granting authority can be held responsible for them.