March 2029 Is an Engineering Deadline, Not a Policy Date: What the European Health Data Space Actually Makes You Build

Why Does a 2029 Deadline Belong on a 2026 Roadmap?

Health tech roadmaps are full of dates that quietly slip. This one has a different shape, and it is worth understanding why before deciding where it sits in your backlog.

The European Health Data Space Regulation was published in the Official Journal on 5 March 2025 and entered into force later that month. The European Commission's own timeline for the regulation then stages the obligations across three milestones: March 2027, when the Commission must adopt the implementing acts carrying the detailed operational rules; March 2029, when primary use of patient summaries and ePrescriptions or eDispensations becomes live across all Member States and most secondary use rules apply; and March 2031, when medical images, laboratory results and hospital discharge reports become operational alongside the remaining data categories, genomic data included.

Read that as an engineering calendar rather than a legal one and the shape changes. The 2029 date is not when you start; it is when the thing has to already be working in production, in the field, at customer sites, having survived whatever conformity documentation and testing the regulation demands. For a hospital information system on an eighteen-month release cadence with a customer base that upgrades on its own schedule, shipping a feature in time for March 2029 means having it generally available considerably earlier, and having it designed well before that.

The more subtle problem is the 2027 dependency. The precise exchange profiles, security requirements and logging schemas arrive as implementing acts, which means a load-bearing input to your design lands roughly eighteen months before the first hard deadline. Teams that wait for total certainty before starting will spend that eighteen months doing discovery, hiring and rearchitecting simultaneously, in a market where every competitor is doing the same thing and bidding for the same integration specialists.

What Exactly Does the Regulation Require You to Ship?

This is the part that catches product teams off guard, because it is not a policy obligation that a compliance function can absorb. It is a feature list.

An EHR system placed on the EU market has to incorporate two harmonised software components. The first is a European interoperability component, which imports and exports electronic health data in the European Electronic Health Record exchange format. The second is a European logging component, which generates access logs supporting transparency and traceability. Both have to satisfy the essential requirements set out in Annex II of the regulation, covering safe and secure operation and maintained performance in line with the manufacturer's instructions.

Conformity is self-declared. As Timelex sets out in its walkthrough of the EHR system requirements, the manufacturer prepares and maintains technical documentation demonstrating compliance, draws up an EU declaration of conformity, affixes the CE marking, registers the system in an EU database and supplies users with an information sheet free of charge. Technical documentation has to be retained for at least ten years after the system is placed on the market, with lifecycle compliance procedures maintained throughout.

There is no notified body in this path. One vendor-facing breakdown of the regime puts it plainly: you test through a European digital testing environment and affix the marking yourself. That sounds like a relief and is actually the opposite. Self-certification moves the entire evidentiary burden inside your engineering organisation. Nobody external is going to tell you your FHIR profiles are wrong before you ship. You will find out during market surveillance, or when a customer's national authority asks, and by then the CE mark is already on the box and the documentation is already ten years' worth of your problem.

For an engineering leader, the practical translation is that EHDS creates a permanent compliance artefact attached to your product, not a project with an end date. Technical documentation that must survive a decade and track every release is a sustained capacity commitment, and it is the kind of work that fits a stable, long-lived team far better than a sequence of short contracts.

Who Is In Scope, and Who Is Wrong About Being Out of It?

The scope question generates more false comfort than any other part of the regulation, mostly because the phrase EHR system sounds like it means a hospital records suite and nothing else.

Manufacturers of EHR systems are the obvious population. Less obvious is the second one. The Johner Institute's overview of the regulation lists medical device and in vitro diagnostic manufacturers whose devices exchange data with EHR systems, wellness application developers claiming interoperability with EHR systems, and importers, authorised representatives and distributors of those products, alongside healthcare providers and authorities.

For a medical device claiming EHR interoperability, the obligations stack rather than substitute. You meet your MDR or IVDR duties and the EHDS interoperability and logging requirements on top. That is two regulatory regimes over one codebase, with two sets of documentation, two change-control processes and two audiences who can ask you to prove something about a release you shipped four years ago.

Wellness apps sit in a genuinely voluntary tier, but the escape hatch has a hinge on it. Certification is optional, and the label applies only if you claim interoperability with the EHR harmonised components. Claim it and you are in. This deserves a specific internal conversation, because the decision to make that claim is usually taken by a marketing or partnerships function that has no idea it is committing an engineering team to a conformity regime. Put the claim under change control before someone puts it on a landing page.

The corollary worth stating: if you sell health software into Europe, the question is not whether EHDS touches you. It is which of the three tiers you land in, and whether anyone in your organisation has actually checked rather than assumed.

The Starting Position Is Worse Than Most Roadmaps Assume

Planning a compliance build requires an honest answer to a question most organisations answer optimistically: how interoperable are we actually, today, measured rather than asserted?

The sector-level answer is not encouraging. In a Q4 2025 survey of 482 hospital CIOs, CMIOs, interoperability architects and national eHealth leaders across eight European countries, Black Book Research found that 27% of European hospitals achieved full cross-border patient data exchange, up from 18% in 2023. Another 42% demonstrated partial interoperability within domestic systems, and 31% were still running isolated systems reliant on legacy messaging.

The stated obstacles map directly onto engineering work rather than policy work. In the same survey, 54% named the lack of standardised FHIR-based APIs as their primary constraint and 49% identified regulatory fragmentation as a barrier, while 68% planned major infrastructure investments during 2026. The regional spread is stark too: Nordic and Benelux respondents averaged 47% cross-border connectivity against 14% in Southern Europe.

Two things follow for a vendor. First, a large share of your installed base is sitting on legacy messaging, which means your EHDS work is not only building a new export path but also normalising whatever your customers actually have. Second, and more commercially interesting, that 68% investment intention is a buying window. Vendors who can demonstrate a credible EHDS roadmap during 2026 and 2027 procurement cycles are selling into budget that has already been allocated. Vendors who wait until 2028 are selling remediation into budget that has already been spent.

This is the pattern behind most regulatory deadlines in European software, and we have written about the same dynamic playing out around the Cyber Resilience Act's reporting obligations and the 2027 S/4HANA custom code deadline. The deadline itself is never the expensive part. The synchronised scramble of an entire market toward the same scarce skills in the final eighteen months is.

FHIR Is the Substrate. The Profiles Are the Actual Work.

There is a comforting version of this project that circulates in planning meetings: we already speak FHIR, so we are most of the way there. It is half true, and the half that is false is where the budget goes.

The European exchange format is expressed using HL7 FHIR resources, IHE profiles and SNOMED CT terminology. A team already building against FHIR is working in the right substrate, and that genuinely matters. But the gap is rarely the protocol. It is the specific profiles, value sets and terminology bindings, which is a different discipline from knowing how to serve a FHIR endpoint.

Concretely, the work that eats quarters looks like this. Mapping legacy HL7 v2 message content into structured FHIR resources without silently losing clinical meaning. Binding local code systems to SNOMED CT, which surfaces every place where a clinician typed free text into a field that was supposed to be coded. Reconciling the fact that your patient identifier scheme, your national identifier scheme and the cross-border scheme are three different things. Handling the data quality problems that have been invisible for fifteen years because nothing ever tried to export the data to a stranger's system before.

Terminology work in particular is badly underestimated because it does not look like engineering. It looks like a spreadsheet. It is nonetheless the single most common place these projects stall, because it requires someone who understands both the clinical semantics and the data model, cannot be meaningfully parallelised by adding generalist developers, and produces no demo until it is nearly finished.

This is exactly the profile of work that suits a dedicated nearshore team over a project-based engagement. It runs for years rather than months, it compounds domain knowledge that is expensive to rebuild, and the worst possible structure for it is a rotating cast of contractors each of whom has to relearn why your discharge summary mapping has that one strange exception. We have laid out the structural difference between the two models in more detail in dedicated team versus project-based outsourcing.

The Logging Component Is a Product Feature, Not an Audit Checkbox

Of the two mandatory components, the logging one attracts the least attention in planning and causes a disproportionate share of the eventual rework. The reason is a category error: teams file it under audit logging, which they believe they already have.

They usually do not, at least not in the form required. Application audit logs are typically built for operators, retained for as long as the storage budget allows, schema-unstable because nobody ever promised otherwise, and full of internal identifiers that mean nothing outside the system. A regulatory logging component supporting transparency and traceability for health data access is a different artefact. It is evidence, it is subject to essential requirements, and its consumers include people who are not your operators.

Design it accordingly and several consequences fall out. The schema becomes a compatibility surface you cannot casually change, which means it needs versioning and a migration story from the first release. The retention and integrity properties become requirements rather than configuration. Access to the logs is itself sensitive personal data governance, so the logging system inherits the same access controls, data protection duties and residency constraints as the clinical data it describes, and you cannot solve it by piping everything into whatever observability vendor happens to be cheapest this year.

That last point is where two of our other pieces intersect with this one: what your development partners can and cannot see in production environments, which we covered in whether outsourced developers should have production data access, and the wider set of European data residency and sovereignty obligations we examined in what Europe's sovereignty rules demand from engineering teams. Health data raises the stakes on both, and a logging component that captures every access event raises them again.

Secondary Use Changes Your Data Architecture, Not Just Your Paperwork

The primary use obligations get most of the engineering attention because they map onto visible product features. The secondary use regime, covering research, innovation, algorithm development and policy-making, has arguably deeper architectural consequences and gets planned later, if at all.

The governing design decision is that secondary use operates on a default opt-out basis. The kdevlabs breakdown cited above is explicit that patients may withdraw their data from secondary-use pools simply and reversibly, with narrow exceptions for overriding public interest, and that this is not an opt-in regime: data is available unless a patient declines.

Read that as a systems requirement and it is substantial. A reversible, per-patient, potentially per-purpose preference has to be honoured across every downstream dataset your organisation produces. That means the preference cannot live in one table consulted at one point in one pipeline. It has to propagate: to extracts, to derived datasets, to whatever feeds your analytics environment, and to any model training corpus built from clinical data. Reversibility makes it harder still, because a patient who opts back in, or out again, creates a state change that every downstream consumer has to be able to act on.

Most clinical data platforms built over the last decade were not designed for this. They were designed for a world where consent was captured once, at the edge, and everything downstream inherited it implicitly. Retrofitting revocable, propagating consent into an existing lake is a genuine architectural project, and the organisations that discover this in 2028 will discover it at the same moment they are trying to certify their interoperability component.

The scheduling implication is the useful one: secondary use readiness and primary use conformity are not sequential projects you can run one after the other. They overlap, they compete for the same data engineers, and the second one is invisible until someone deliberately looks for it.

How Do You Sequence and Staff This Between Now and 2027?

The specs are not final, which is a reason to sequence carefully rather than a reason to wait. A large fraction of the work is independent of whatever the implementing acts eventually say, and that fraction is precisely what you should be doing during the window where engineers are still available at sane prices.

Start with what does not depend on the final profiles. Inventory every place clinical data enters, leaves or is transformed in your systems, including the integrations you inherited and nobody owns. Audit data quality against the categories you already know are in group one, because patient summaries and prescriptions are named in the regulation and will not change. Get your terminology mapping underway, since binding local codes to SNOMED CT is largely profile-independent groundwork. Separate your logging concerns from your operational telemetry now, while it is a refactor rather than a rewrite. Establish the technical documentation practice, because a ten-year artefact assembled retroactively is always worse and more expensive than one maintained as you go.

Then plan the profile-dependent work as a fast follower for 2027, with the team already in place, already familiar with your codebase, and waiting on a specification rather than on a hiring process. The difference between those two positions is roughly a year of calendar time, and it is entirely a staffing decision made in 2026.

This is where the delivery model matters more than usual. EHDS work is multi-year, domain-heavy and documentation-bound, which makes it close to the worst possible fit for project-based agency engagements or contractor churn: the knowledge you need is the accumulated understanding of your own data, and it evaporates every time the team turns over. A dedicated nearshore team, employed rather than assembled per project, in a European time zone where the interoperability specialist can join the same call as your clinical informaticist, is the structure that actually matches the shape of the work.

That is the model StepTo is built around. Our engineers are Serbian employees working as a stable, dedicated extension of the client's team in overlapping European hours, which for a compliance build means the domain knowledge accumulated mapping your discharge summaries in 2026 is still in the room in 2029 when a national authority asks how the export path works. For health software specifically, that continuity is not a nice-to-have; it is the thing that makes a ten-year documentation obligation survivable.