Your EHDS deadline is not 2029
The European Health Data Space regulation has been in force since March 2025. The date everyone repeats is 26 March 2029 — when patient summaries, ePrescriptions and eDispensations have to be exchangeable across all member states, and when EHR systems handling those categories fall under the regulation’s obligations.
Three years sounds comfortable. It is not, and the reason has nothing to do with the regulation.
The dates, briefly
- 26 March 2027 — general application. National digital health authorities, national contact points, health data access bodies, the obligation to join MyHealth@EU, and the Commission’s technical specifications for the European EHR exchange format.
- 26 March 2029 — priority category one. Patient summaries, ePrescriptions, eDispensations. Plus most of the secondary-use rules.
- 26 March 2031 — priority category two. Medical images, lab results, discharge reports.
Read that ordering again. The specifications land in 2027. The obligation lands in 2029. Which means the actual build window is two years, and it starts when the specification exists — not when you first heard about the deadline.
Why compliance projects are not really compliance projects
I spent two years building software for a private hospital group. Not a greenfield build — we took over from a previous supplier and had to make self-service check-in work against record systems that predated the project by a long way.
That work taught me something that no regulatory timeline accounts for: a hospital’s data does not sit behind an interface. It sits inside systems that were built for one job, extended for another, and are now load-bearing in ways nobody has written down. The people who made the original decisions have moved on. The documentation, where it exists, describes what was intended rather than what runs.
Getting a patient summary out of that is not a mapping exercise. It is an archaeology exercise, and archaeology is slow in a way that project plans are consistently optimistic about.
Then there is the part that makes healthcare specifically hard: you cannot pause a hospital. Every change happens to a live system with patients in it. There is no migration weekend. Everything is incremental, everything is reversible, and everything is tested more carefully than it would be anywhere else — correctly so.
What actually eats the time
Not the standard. The format is published, it is documented, and any competent team can read it.
What eats the time is everything underneath:
- Finding where a piece of clinical information actually lives, when it lives in four places that disagree.
- Deciding which of those is authoritative, which is a question for clinicians rather than engineers.
- Discovering that a field means something different in one department than in another, and that both are right locally.
- Getting a system that has no API to produce structured output without destabilising the thing it was actually built to do.
- Proving all of it, to people whose professional risk is real.
None of that is EHDS-specific work. It is the work of making an old system explain itself, and it is the same work whether the deadline is a regulation, an acquisition, or a supplier you finally want to replace.
The uncomfortable implication
If your organisation’s plan is to start in 2028, the plan is to fail — not because your team is slow, but because the discovery phase alone will consume more calendar than anybody’s estimate, and it is the phase that cannot be parallelised by adding people.
The organisations that will be fine in 2029 are the ones treating 2026 and 2027 as the years for the unglamorous part: working out what they actually have, where the meaning lives, and which of their systems can be made to answer questions at all.
That work has no deadline pressure attached yet, which is exactly why it does not get funded. It also happens to be the work that determines whether the rest is possible.
If you are a vendor rather than a provider
The commercial position is sharper. Interoperability has quietly become a buying criterion: a system that cannot exchange data is becoming a system that cannot win contracts, regardless of how good it is at its own job. That shift is already visible in procurement, and it will accelerate as providers start asking suppliers to prove readiness rather than promise it.
What I would do now
Not a compliance programme. A survey.
Pick one priority category — patient summaries are the obvious start — and try to produce one, end to end, from your real systems. Not a pilot with clean data. A real one, with the awkward cases in it.
You will learn more in six weeks of that than in six months of gap analysis, because the question is not what does the regulation require. That part is written down. The question is what is actually in our systems, and can it answer — and the only way to find out is to ask them.
I work on exactly this kind of problem: making systems built in a different decade answer questions they were never designed for, without breaking what already depends on them. If you are looking at 2029 and wondering where to start, I am happy to talk it through.