For years, "interoperability" in European healthcare was an aspiration. The European Health Data Space (EHDS) makes it law. If you build, sell, or operate healthcare software in the EU, EHDS reshapes the ground you stand on — from the data formats you support to the APIs you must expose and the cybersecurity you must prove. Here's the plain-language version, plus a readiness checklist.
What EHDS actually is
EHDS is an EU regulation that creates a common framework for using and sharing electronic health data. It has two halves:
- Primary use — giving patients and their clinicians access to health records, including across borders. Your data should travel with you when you seek care in another member state.
- Secondary use — a governed pathway to reuse health data for research, innovation, public health, and policy, with privacy safeguards and permit-based access.
The two standards that run the engine
EHDS leans on two complementary frameworks:
- HL7 FHIR — the web-based standard for real-time exchange of clinical data between live systems. This is the workhorse of primary use: retrieving and sharing a patient's records at the point of care.
- OMOP Common Data Model — a research-oriented model that harmonises disparate datasets into a unified structure, enabling the population-scale analytics and longitudinal studies that secondary use depends on.
If your architecture already treats FHIR as the starting point rather than an afterthought, you are ahead. If you still lean on HL7 v2, EDIFACT, or legacy terminologies like READ codes, those will need to be mapped or replaced.
What changes for EHR systems and vendors
The practical demands land in a few places:
- Certification. EHR systems are expected to be certified for interoperability and security against EHDS requirements.
- Standardized APIs. Systems must expose APIs that let external, authorized systems retrieve, transmit, and process patient data — turning closed products into open platforms.
- Terminology and metadata. New responsibilities around cataloguing, validation, and curation of data, plus standardized metadata.
- Cross-border gateways. National gateways enable exchange between member states, which your data model has to accommodate.
The security catch: many providers are moving from closed, local systems to open, API-exposed platforms — and cybersecurity often lags that shift. Exposing standardized APIs without hardening authentication, authorization, and monitoring is how EHDS readiness becomes a breach. Treat security as a first-class workstream, aligned with your NEN 7510 and GDPR obligations.
An EHDS readiness checklist
- Make FHIR native. Model your clinical data on FHIR resources rather than translating at the edges.
- Inventory legacy formats. Find every HL7 v2 feed, flat file, and proprietary schema, and plan the migration.
- Design an API layer for external access. Assume authorized third parties will read and write via your APIs.
- Separate primary and secondary paths. Real-time FHIR for care; OMOP-shaped exports for analytics.
- Harden security for openness. Strong identity, granular authorization, encryption, and audit logging on every endpoint.
- Get your metadata house in order. Catalogue datasets with the documentation secondary-use governance expects.
EHDS is a large lift for legacy estates — but for well-built software it is a tailwind. Interoperable, FHIR-native products slot into the new ecosystem and win procurement that closed systems can't touch.
Frequently asked questions
What is the EHDS? An EU regulation creating a common framework for using and sharing electronic health data across primary use (care) and secondary use (research and policy).
What standards does it rely on? HL7 FHIR for real-time clinical exchange and the OMOP Common Data Model for large-scale analytics, alongside standardized APIs and terminologies.
What do vendors need to do? Certify systems for interoperability and security, expose standardized FHIR APIs, migrate off legacy formats, and strengthen cybersecurity as systems become open.
Neurova AI builds interoperable medical software with FHIR at the core and security designed for an API-exposed world. Read our companion guides on SaMD under the MDR, the EU AI Act, and NEN 7510 & GDPR.