EHDS EHR Certification: The Real Timeline, and Why It Is a Data-Model Problem

The date you have probably been given for EHDS certification is wrong. The real one is later — and the work that has to happen before it is not a compliance form. It is a data model, and that is where most healthcare organisations will lose the time they think they have.

The European Health Data Space Regulation is in force, and the summaries have not been kind to the truth. I have seen it written that healthcare providers and EHR vendors must certify their systems by January 2026. That is simply incorrect, and it matters, because a wrong date drives either false panic or false comfort. Here is the timetable that the regulation actually sets.

The real timeline

Regulation (EU) 2025/327 entered into force on 26 March 2025, opening a transition phase rather than switching anything on. The general date of application is 26 March 2027, by which the Commission must have adopted the key implementing acts and certain secondary-use provisions begin — the templates for data-access applications and permits, secure processing environment requirements, and the data quality and utility label. The first major operational milestone is 26 March 2029: cross-border exchange of the first priority categories — patient summaries, ePrescriptions and eDispensations — and the point at which commercial EHR systems handling those categories placed on the market must meet the regulation’s interoperability, logging and security requirements. In-house EHR systems built and used by providers themselves get until 26 March 2031, alongside the second priority categories — medical images, laboratory results, discharge reports. A later milestone in 2035 opens the secondary-use infrastructure to third countries.

So the EHR certification gate is 2029 for commercial systems and 2031 for in-house ones, not 2026. But — and this is the part the corrected date should not soften — the preparation window is not generous. Migrations of clinical systems run six to eighteen months, the exchange format’s implementing act is not final yet, and vendor decisions realistically have to be locked by 2027 to hit 2029 on an orderly budget rather than an emergency one.

What certification actually requires

EHDS regulates EHR systems as a product. Two harmonised software components are mandatory: a European interoperability component, so the system can send and receive the priority data categories in the common European exchange format, and a European logging component, so every access to the data is recorded. Manufacturers self-certify conformity for interoperability and security within a pre- and post-market framework that also reaches authorised representatives, importers and distributors. Wellness apps and high-risk AI systems that claim interoperability with those components are pulled in too.

The word “self-certify” tempts organisations to treat this as paperwork. It is not, because the thing being certified is whether your data actually conforms — and for most providers, it does not yet.

Why this is a data-model problem, not a compliance one

A patient summary exchanged across borders in 2029 is only useful if it is complete, structured consistently, and mapped to clinical practice at the far end. The hard truth about European health records is that they are digitised in form but fragmented in practice: different systems in primary care, hospitals and specialist services, with limited interoperability even inside a single country, let alone across one. Connecting national gateways to a cross-border platform does not fix that. What fixes it is the unglamorous work underneath — a coherent information model, consistent clinical terminology and coding, and a classification discipline that makes one system’s “discharge summary” mean the same thing as another’s.

That is a taxonomy problem, and it is the lens I would bring to EHDS readiness. The certification is the visible deadline; the data model is the actual project, and it is the part that takes years rather than months. It is also the same discipline I write about across the information-architecture work on this site — because a health record, a parts catalogue and a regulatory register are all, underneath, classification problems.

The legacy estate, and the cascade

Healthcare carries one of the heaviest legacy burdens of any sector. Hospitals acquire technology slowly, through decades of procurement, mergers and donated equipment, and critical — sometimes life-critical — systems routinely run on unsupported operating systems, because a certified medical device cannot be casually re-patched without risking its regulatory approval. Layer EHDS interoperability onto that estate and every new API endpoint becomes a remotely reachable service that used to be an internal one. Where those systems are products with digital elements, they also fall under the Cyber Resilience Act‘s reporting duty, and the EHDS work forces exactly the kind of re-platforming decisions that turn deferred technical debt into a dated, funded programme. The organisations that wait until 2029 will be doing full system replacement under time pressure; the ones that start the data and vendor analysis in 2026 will be doing a managed migration.

EHDS also sits alongside, not instead of, the GDPR, and intersects the AI Act wherever health data trains or validates a model. The evidence discipline that answers those regimes is the same one that answers EHDS — obligations mapped to controls, controls traced to records, set out on the evidence and assurance page.

If EHDS is on your horizon, the useful question in 2026 is not “are we certified” — it is “does our clinical data mean what the exchange format needs it to mean.” A technology control assessment answers it before the migration path narrows; as a fractional CTO I run the programme that closes the gap. See how engagements are scoped.