Why EHDS compliance changes what you build, and when

The European Health Data Space is already law. Regulation (EU) 2025/327 entered into force on 26 March 2025, and it sets fixed dates by which health-software companies have to change what they build. That combination is unusual: a long lead time paired with hard deadlines. It gives product teams room to plan, and it removes the excuse to wait.

This guide is for the people who have to act on it: product owners and engineers at companies that make electronic health record (EHR) systems, medical-device software, or wellness apps in the EU. It answers three questions. What do you actually have to build? Who is in scope? And by when?

Key takeaways

• The EHDS is Regulation (EU) 2025/327, in force since 26 March 2025. It applies generally from 26 March 2027, with the deadlines that force you to build something landing on 26 March 2029 (patient summaries, ePrescriptions) and 26 March 2031 (imaging, lab results, discharge reports).

• If you make an EHR system, you must ship two harmonised software components (one for interoperability, one for logging), self-certify, and affix the CE mark. No notified body reviews it.

• The required exchange format is the EEHRxF (Article 15). In practice it is expressed with HL7 FHIR, IHE profiles, and SNOMED CT.

• Wellness apps face only a voluntary label, and only if they claim interoperability with EHR systems.

• Secondary use of health data is opt-out for patients, not opt-in.

What is the EHDS, and is it already law?

Yes. The European Health Data Space is Regulation (EU) 2025/327, adopted on 11 February 2025, published in the Official Journal on 5 March 2025, and in force since 26 March 2025 (European Commission). Because it is a regulation, not a directive, it applies directly in every Member State without waiting for national transposition.

The EHDS governs two different things, and it helps to keep them separate from the start. The first is primary use: health data used to deliver care, including a patient's right to access their own records and share them across borders. The second is secondary use: reusing health data for research, innovation, policy-making, and regulation. Most of the vendor build work sits in the primary-use rules and in a specific chapter on EHR systems. The secondary-use rules matter more for how patient data can be reused, and they carry their own obligations.

One detail the early coverage tends to skip: the regulation also amends the cross-border healthcare directive (2011/24/EU) and the Cyber Resilience Act (Regulation (EU) 2024/2847). If you already track the Cyber Resilience Act for your product security work, the two now share a border.

When do the EHDS deadlines actually hit?

The regulation applies generally from 26 March 2027, but the obligations that require engineering work arrive in 2029 and 2031. The full sequence runs across six years and is set out in Article 105 of the regulation (EUR-Lex).

There is a real ambiguity here, and it is worth money to get right. The binding text of Article 105 places the EHR-system conformity regime (Chapter III) at 26 March 2031. The Commission's own plain-language page on EHR certification, on the other hand, describes the harmonised components as needed around early 2029 for the first data group. The legal text governs if the two ever conflict. But when the regulator signals an earlier date in its guidance, the safe engineering plan is to be ready for 2029, not to bet on 2031 and discover the components were expected two years sooner.

In practice, the load-bearing risk in this timeline is not the headline dates. It is the implementing acts due around 2027. The EEHRxF specification and the common specifications for EHR components both arrive as separate Commission acts, and the 2029 and 2031 obligations only become concrete once they land. If those acts slip, your build target moves with them. Track their adoption the way you would track a dependency you do not control, because that is what it is.

Are you an EHR system, a medical device, or a wellness app?

Your obligations depend entirely on which category your product falls into, and the definitions are in Article 2 of the regulation. Getting the classification wrong is the most expensive mistake available, because it decides whether you face a mandatory conformity regime, an optional label, or a separate framework you already know.

The stacking case is the one that catches teams out. If your product is a medical device under the MDR and you also let it exchange data with EHR systems, an MDR CE mark does not exempt you from the EHDS. Article 27 pulls the EHDS interoperability and logging requirements onto your device on top of your existing conformity work. For clinical AI and software-as-a-medical-device makers, this compounds further, because a third framework (the EU AI Act) can also apply. We cover that stack in a separate guide on the EU AI Act for medical devices.

What is the EEHRxF, and how does it map to FHIR?

The European Electronic Health Record Exchange Format, codified in Article 15, is the common format every EHR system must be able to import and export. It defines harmonised datasets and coding for the priority categories: patient summaries, ePrescriptions and eDispensations first, then imaging, lab results, and discharge reports.

The EEHRxF does not invent a new standard from scratch. It is built on work from recognised standards bodies, including HL7 International, HL7 Europe, IHE, and SNOMED International (EEHRxF). In the current implementation guides, that means the format is expressed with HL7 FHIR resources and profiles, IHE integration profiles, and SNOMED CT terminology. If your team already builds against FHIR, you are working in the right substrate. The gap is usually in the specific profiles and value sets the EEHRxF requires, not in the underlying technology.

One caution on certainty. The exact, binding EEHRxF specification arrives as a Commission implementing act under Article 15, expected around 2027. The direction is clear from the official EEHRxF materials and the draft guides. The final field-level detail is not frozen yet. The sensible move is to build your data model against the current guides now and treat the 2027 act as the point where you confirm the mapping. If you want the deeper engineering view, our guide to FHIR and EHR interoperability walks through how this maps onto real integration work.

How do you certify an EHR system?

EHR-system certification under the EHDS is self-certification. There is no notified body. You demonstrate conformity yourself, and the model is closer to CE marking for general product safety than to the notified-body assessment many teams associate with the MDR. The steps come from Chapter III and its annexes.

• Build the two mandatory harmonised software components: a European interoperability component (import and export data in the EEHRxF) and a European logging component (record access events per the regulation's requirements).

• Meet the essential requirements in Annex II, filled in by the common specifications the Commission sets under Article 36.

• Run the product through a European digital testing environment (Article 40). A positive test result creates a presumption of conformity.

• Compile the technical documentation (Article 37) and keep it current.

• Draw up the EU declaration of conformity (Article 39).

• Affix the CE marking (Article 41), including in the accompanying documents and, where relevant, the packaging.

If your team has been through an MDR conformity assessment, do not assume the same process. The EHDS route has no notified body in the loop. Instead, the digital testing environment gives you a presumption of conformity, and the burden of the technical file sits with you. That changes who you need on the project and when. It is a documentation and testing exercise you own end to end, not an external audit you schedule and wait on. Confirm the current status of the testing environments with the European Commission before you plan around them, since they are still being set up.

Primary vs secondary use: what is the difference, and what about patient opt-out?

Primary use is health data used to deliver care, including giving patients access to their own records and letting that data move across borders for treatment. Secondary use is the reuse of health data for research, innovation, policy-making, and regulatory activities, and it only happens under a data permit issued by a Health Data Access Body.

For secondary use, patients have a right to opt out, and the regulation requires that opt-out to be simple and reversible. This is the correction worth flagging, because a lot of summaries get it backwards: the default is that data can be made available for secondary use, and the patient can withdraw it, rather than an opt-in the patient has to grant. There are narrow carve-outs where certain overriding public-interest purposes (such as public health or specific regulatory uses) can proceed despite an opt-out, under strict safeguards.

Two pieces of infrastructure carry this in practice, and they are easy to confuse. MyHealth@EU (formerly eHDSI) is the primary-use, cross-border network that already moves patient summaries and ePrescriptions between countries today and will extend to the group-2 categories later. HealthData@EU is the separate secondary-use infrastructure that connects the Health Data Access Bodies. If your product touches cross-border care, MyHealth@EU is the one you integrate with.

How does EHDS stack with GDPR and the MDR?

The EHDS does not replace the GDPR. It builds on it and adds health-sector rules on top, so the GDPR stays the baseline for processing personal data while the EHDS layers on access rights, secondary-use permits, and the patient opt-out. If your data protection work is already GDPR-aligned, the EHDS extends it rather than restarting it.

For medical-device and SaMD makers, the interaction that matters is Article 27, which governs the relationship with the MDR, the IVDR, and the AI Act. The practical rule: if your device claims interoperability with EHR-system harmonised components, you must also prove compliance with the EHDS essential requirements, on top of your MDR or IVDR conformity. The regulation does not spell out a single combined assessment, so the pragmatic plan is to budget for parallel compliance rather than assume one process covers both. Clinical AI adds a third layer, which is why we treat the EU AI Act for medical AI as its own topic.

What should a product team do in the next 12 months?

Start with classification, because everything downstream depends on it. Once you know whether you are an EHR system, a device, or a wellness app, the rest of the plan follows.

1. Classify your product against the Article 2 definitions, and write down the reasoning. If you are close to the EHR-system line, treat yourself as in scope until you can prove otherwise.

2. Map your current data model to the priority categories and to the EEHRxF, using FHIR and SNOMED CT as the target. Note where you are missing profiles or value sets.

3. If you are an EHR system, scope the two harmonised components (interoperability and logging) and the technical documentation as real backlog items, not future work.

4. Put the 2027 implementing acts on your roadmap as a dependency to watch, and plan to confirm your EEHRxF mapping when they land.

5. If you make a wellness app, decide whether you will claim interoperability. That single decision is what triggers the voluntary label.

6. If you handle data that can be reused, build the secondary-use opt-out handling into your data model early, since retrofitting consent and opt-out logic is painful.

7. Bring compliance or legal counsel in now, not at the end. Scoping the regulatory line up front keeps it from blocking a release later.

This is where KDL tends to get pulled in. We build the product-engineering side of this work: mapping a data model to EEHRxF and FHIR, building the interoperability and logging components, and preparing the technical documentation that goes into a self-certification file. We scope compliance up front so it does not stall a release, and we leave the legal sign-off with your counsel, where it belongs. If that is the shape of your next 12 months, tell us about the project.

Frequently asked questions

Does the EHDS apply to vendors outside the EU?

If you place an EHR system on the EU market or put it into service in the Union, the Chapter III obligations apply regardless of where your company is based. Location of the vendor does not exempt the product. Non-EU organisations also gain access to the secondary-use infrastructure from 2035, under separate conditions.

Is the EHDS just GDPR for health data?

No. The GDPR remains the baseline for processing personal data, and the EHDS complements it with health-sector rules: patient access rights, cross-border exchange, secondary-use permits, and the opt-out. You comply with both, and EHDS work extends your existing GDPR program rather than replacing it.

Do wellness apps have to be certified under the EHDS?

No. Wellness applications face no mandatory certification. There is a voluntary label under Article 47, and it is only relevant if you claim your app is interoperable with EHR systems' harmonised components. Make no interoperability claim and the label regime does not apply to you.

What is the first hard deadline for my product?

It depends on your classification. Teams handling patient summaries or ePrescriptions should plan for the group-1 primary-use date of 26 March 2029. EHR-system manufacturers face the conformity regime by 26 March 2031 under the legal text, though the Commission's guidance points to group-1 components around 2029, so building for the earlier date is the safer plan.

Is the EEHRxF the same as FHIR?

No. The EEHRxF is the EU's required exchange format, defined under Article 15. It is expressed using HL7 FHIR, IHE profiles, and SNOMED CT, so FHIR is the technology it runs on rather than a synonym for it. The exact binding specification arrives as a Commission implementing act expected around 2027.

The short version

The EHDS is in force, the dates are fixed, and the work is knowable. Classify your product, map your data to the EEHRxF using FHIR, and, if you are an EHR system, start on the two components and the technical file now. Build for 26 March 2029 where the Commission signals it, even where the legal text says 2031, because the cost of being early is small and the cost of being late is a product you cannot sell in the EU.

If you want a partner for the engineering side of that, KDL builds compliance-aware healthcare software and scopes the regulatory work up front. For the next layer of the stack, read our companion guides on the EU AI Act for medical devices and FHIR and EHR interoperability.

This article is for general informational purposes only. It is not legal or regulatory advice, and it does not replace review of the regulation itself or consultation with qualified compliance or legal counsel. EHDS obligations depend on implementing and delegated acts that were still being adopted at the time of writing; confirm current dates and technical specifications against the primary sources before making compliance decisions.

Sources

• European Union (EUR-Lex). Regulation (EU) 2025/327 on the European Health Data Space (canonical text, incl. Articles 15, 27, 37, 39, 40, 41, 47, 105). https://eur-lex.europa.eu/eli/reg/2025/327/oj/eng (retrieved 2026-07-06)

• European Commission (DG SANTE). European Health Data Space Regulation (EHDS). https://health.ec.europa.eu/ehealth-digital-health-and-care/european-health-data-space-regulation-ehds_en (retrieved 2026-07-06)

• European Commission (DG SANTE). Certification of EHR systems. https://health.ec.europa.eu/ehealth-digital-health-and-care/certification-ehr-systems_en (retrieved 2026-07-06)

• European Commission (DG SANTE). Electronic cross-border health services (MyHealth@EU). https://health.ec.europa.eu/ehealth-digital-health-and-care/digital-health-and-care/electronic-cross-border-health-services_en (retrieved 2026-07-06)

• EEHRxF (official). What is the EHRxF? https://ehr-exchange-format.eu/what-is-ehrxf/ (retrieved 2026-07-06)