European Health Data Space implementing acts 2027: what EHR vendors must build

Summary. The European Health Data Space (EHDS) Regulation, (EU) 2025/327, entered into force on 26 March 2025, and the Commission must adopt its key implementing acts by 26 March 2027. Two decide what EHR vendors build: the Article 15(1) act on the European electronic health record exchange format (EEHRxF) and the Article 36(1) act on common specifications for the mandatory interoperability and logging components. On 1 November 2026 neither draft had opened for public feedback, and Member States were still discussing Commission non-papers. From 26 March 2029, EHR systems intended to process patient summaries, ePrescriptions or eDispensations must comply when placed on the EU market. From 26 March 2031 the rule extends to medical images, test results and discharge reports, and to in-house and as-a-service systems. Compliance is self-declared behind a test gate, ending in CE marking and EU registration. Manufacturers outside the EU, including Indian vendors, need a jointly liable EU authorised representative. Our advice: start logging and data mapping now, and treat FHIR as likely but unconfirmed.

About this article. This is for product and compliance leads at EHR vendors. On 1 November 2026 we checked it against the Official Journal text of Regulation (EU) 2025/327 as published on 5 March 2025, the four EHDS implementing regulations adopted so far, the Commission's FAQ of 26 March 2026, the Have your say portal and EHDS committee records. This is not legal advice. The FAQ gives preliminary views of Commission services and the key acts are unwritten, so re-check before you commit a roadmap. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

What March 2027 means, and what it does not

March 2027 is a regulatory milestone, not a product deadline. The Regulation applies generally from 26 March 2027, but Article 105 defers the provisions that bind EHR systems to 2029 and 2031. By then the Commission must adopt the key acts, and Member States must have set up digital health authorities and national contact points and notified their penalty rules. Governance provisions also start to apply.

The dates below come from the Regulation and the Official Journal.

The nine implementing acts with the March 2027 deadline

The FAQ names nine acts. Status comes from the Have your say portal and committee records.

Two more matter to vendors. Testing environment specifications under Article 40(4) reached the committee as a non-paper in September, with adoption planned for the first quarter of 2027. A delegated act under Article 49(4) will set what manufacturers enter in the EU database.

Will the two key acts arrive on time?

The portal still lists adoption of both in the fourth quarter of 2026. That looks optimistic: on 30 September the committee was still discussing the timeline for Articles 15 and 36, and the record of its 22 October meeting was not yet public.

Earlier acts took 119 to 165 days from opening feedback to adoption: the EHDS Board took 119 (9 December 2025 to 7 April 2026) and identification took 165 (9 April to 21 September 2026). Counting back from 26 March 2027, feedback would need to open between 12 October and 27 November 2026. Only the fastest pace still fits. That is our arithmetic, not a Commission statement. The 2029 and 2031 dates sit in Article 105 itself, so a late act does not by itself move them, and we found no proposal to change them.

Who counts as an EHR system manufacturer

Article 2(2)(k) defines an EHR system as software, or hardware and software, that lets priority-category health data be stored, intermediated, exported, imported, converted, edited or viewed, and that the manufacturer intends for healthcare providers treating patients or for patients accessing their data. A system need not do all of these. A manufacturer is whoever makes a product, or has it made, and markets it under its own name or trademark.

Under Article 34, an importer, distributor or user also becomes a manufacturer if it sells a system under its own name, modifies it in a way that might affect conformity, or changes its intended purpose. That catches white-label deals and can catch hospitals that modify a product. The FAQ gives examples:

General-purpose software is excluded; recital 38 names text processors, middleware and database software. Medical devices, in vitro diagnostics and high-risk AI systems that claim interoperability must meet Annex II but need not use the testing environment. Wellness apps that claim interoperability must meet the common specifications, carry an Article 47 label, register in the Article 49 database and share data only with the user's consent.

What you must build: the two harmonised components

The FAQ describes capabilities, not architecture: systems need not use the format internally, but must speak it at their edges and log access.

The interoperability component

Section 2 of Annex II requires that:

• a system designed to store or intermediate personal health data offers an interface to that data in the EEHRxF, and can receive data in it;

• a system designed to provide access to the data can also receive it in the EEHRxF;

• structured data entry captures enough granularity to produce EEHRxF output;

• the components contain no features that prohibit, restrict or unduly burden authorised access, sharing or use; and

• the same applies to authorised export when a customer replaces the system with another product.

The last point is an anti-lock-in rule written into product law. If your EHR runs on a shared cloud pool, check whether the EU Data Act switching rules also apply to you.

Article 15 says the format covers datasets, coding systems and technical specifications, with regular coding updates. The FAQ expects it to build on the Xt-EHR Joint Action, which published logical models and FHIR mappings. A September 2026 IHE Catalyst briefing warns that these outputs are not the legal baseline and are being revised.

Will it be FHIR? The evidence points that way, but nothing is binding:

• Committee records show FHIR versioning under discussion in March and May 2026.

• The Commission's 2026 MyHealth@EU work plan includes a FHIR proof of concept for patient summaries and ePrescriptions.

• Ringholm, a health interoperability consultancy, expects the specifications to build on HL7 Europe's FHIR guides.

• Against that, Member States asked on 30 September for the text to state clearly that national infrastructures may use alternative formats.

So keep profile and version choices behind a mapping layer. In June the committee also discussed push and pull functions, so do not assume a pull-only API. The HL7 Europe portal, updated 16 October 2026, shows where the guides stand:

The logging component

Annex II requires the logging component to record, on every access event or group of events, at least:

1. the healthcare provider or other individuals that accessed the data;

1. the specific natural person or persons who accessed it;

1. the categories of data accessed;

1. the time and date of access; and

1. the origin or origins of the data.

The components must also offer log review tools, or support external ones, and those that store data must support retention periods and access rights by origin and category. Systems for health professionals must identify and authenticate them reliably.

These logs exist for patients. Article 9 gives people a right to know who accessed their data through the health professional access service, when and what, for at least three years from each access. Implementing Regulation (EU) 2026/2099 adds a floor for cross-border exchange: professionals authenticate at eIDAS level substantial, rising to high from 26 March 2032, and from 26 March 2029 requesters must accept patient attributes from an EU Digital Identity Wallet. Those duties fall on national entities and providers, but your customers will ask for them.

Build list

The first column follows Annex II; the others are our engineering reading.

Conformity: self-declaration with a test gate

No notified body assesses EHR systems: recital 38 calls the route mandatory self-certification. The Commission's summary has seven steps:

1. Conform to Annex II, the Article 36 specifications and the EEHRxF.

1. Test in the digital testing environment (Article 40).

1. Compile technical documentation (Article 37).

1. Provide the information sheet and instructions (Article 38).

1. Sign the EU declaration of conformity (Article 39).

1. Affix CE marking (Article 41), on accompanying documents for software.

1. Register in the EU database (Article 49).

The Commission will release the testing software as open source for Member States to deploy, and a system that fails may not be placed on the market. A third release of the environment and database was shown in March 2026, and its acceptance site was online on 1 November.

Articles 30 and 37 also require you to:

• keep the technical documentation and declaration for 10 years after placing on the market;

• on a reasoned request, show authorities source code or logic they need to check compliance;

• run complaint channels and registers of complaints and non-conforming systems;

• take corrective action, recall or withdraw non-conforming systems, and inform authorities, distributors and users; and

• hand over technical documentation within 30 days of a market surveillance authority's request.

An update needs a new conformity assessment only if it is a substantial change. The FAQ applies the general product test: the update alters functions, type or performance in a way the initial risk assessment did not foresee, it changes the hazard or raises the risk, and the product is made available. Write that risk assessment with your release roadmap in mind.

Penalties are national. Member States set them under Article 99 and notify them by 26 March 2027; criteria include annual turnover in the Union.

An EHR system that is also a product with digital elements must meet the essential requirements of the Cyber Resilience Act from 11 December 2027, showing conformity through the EHDS procedure; a recital places SaaS and in-house EHR systems outside that Act. An EHR with an AI triage function also falls under the AI Act's high-risk rules.

What happens to systems already on the market

Chapter III applies when systems are placed on the market or put into service after the relevant date. Ringholm reads this to mean that systems placed on the market earlier need not add the harmonised components unless a substantial change makes them new products. Do not stretch that to new sales of an old product: the Commission's Blue Guide says placing on the market applies to each individual product, not a product type, and we found no Commission statement on how that maps to a software licence sold in 2030. Take EU counsel's advice.

Two forces push installed systems towards compliance anyway.

Healthcare providers must exchange in the EEHRxF. They can upgrade or use a system that translates between their internal format and the EEHRxF, according to the FAQ. Such a converter is itself an in-scope EHR system, which creates a product opportunity for integration vendors.

Member States can demand more through procurement. Article 29 lets them set rules for procurement, reimbursement and financing, provided the harmonised components are not affected. A 2028 hospital tender may ask for EHDS conformity before the legal deadline.

SaaS and in-house systems get until 2031

Article 26(2) treats EHR systems built and used within EU health institutions, and EHR systems offered as a service to EU customers, as put into service. Article 105 applies Chapter III to these from 26 March 2031. A cloud-hosted EHR sold on subscription therefore has a later legal deadline than the same software sold as a licence, though tenders and national rules may pull it forward.

A 2027 to 2029 plan for EHR vendors

Build the logging component first. Its fields are already in Annex II, it touches identity and audit infrastructure that takes longest to change, and its content does not depend on the FHIR profile the act picks, though the Article 36 act may fix the format.

Worked example: one access event

Until the Article 36 act fixes a format, use a neutral record you can map to a FHIR AuditEvent. Values are illustrative:

            {
  "event_id": "7f3c2a1e-0b9d-4c55-9e21-5d8f0a6b4e10",
  "occurred_at": "2029-04-02T09:14:07Z",
  "healthcare_provider": { "id": "provider-registry-id", "name": "Example Hospital" },
  "accessor": { "id": "national-professional-id", "role": "physician" },
  "patient": { "id": "patient-identifier" },
  "data_categories": ["patient-summary"],
  "data_origin": ["source-system-or-provider-id"],
  "action": "read"
}
          

healthcare_provider, accessor, data_categories, occurred_at and data_origin cover Annex II section 3.2, points (a) to (e), in that order. The other fields are our additions. Make the store append-only, sign or hash-chain records, and give the patient-facing service a query path that does not expose other patients' data.

India angle: Indian EHR and health-tech vendors selling into the EU

As manufacturers. An Indian company marketing an EHR system under its own name in the EU is its manufacturer. Article 31 requires it first to appoint an authorised representative in the Union by written mandate. The representative is jointly and severally liable if the manufacturer fails its Article 30 obligations, so expect an audit before anyone signs.

As build partners. Where an EU vendor outsources engineering, legal obligations stay with it, but the work can be delivered from anywhere. Teams that have built FHIR R4 integrations for India's Ayushman Bharat Digital Mission will recognise much of the tooling, since the ABDM guide is also based on R4, though the profiles differ.

As data processors. Logs and exports hold EU patients' health data, so GDPR governs them. The EDPB treats remote access by a third-country processor as a transfer, and India has no EU adequacy decision, so you need a Chapter V safeguard such as standard contractual clauses. Article 90 lets Member States add conditions, and Article 86 allows national rules requiring EU storage for primary use. Section 17(1)(d) of India's DPDP Act disapplies most duties when an India-based firm processes data of people outside India under a foreign contract, but section 8(5) security safeguards remain. Our DPDP engineering playbook covers the domestic side.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our application development team can run an Annex II gap analysis, build FHIR import and export and access logging, and automate conformance tests for EHR products. Talk to us at /contact-us/.

Last updated: 1 November 2026.

References

1. Regulation (EU) 2025/327 on the European Health Data Space, Official Journal of 5 March 2025 — EUR-Lex

1. European Health Data Space: specifications for the European electronic health exchange format (EEHRxF), initiative 17512 — European Commission, Have your say

1. European Health Data Space: common specifications for the software components of electronic health record systems, initiative 18579 — European Commission, Have your say

1. Committee on the European Health Data Space, summary record of 30 September 2026 — Comitology Register, European Commission

1. Frequently asked questions on the European Health Data Space, version of 26 March 2026 — European Commission, DG SANTE

1. Commission Implementing Regulation (EU) 2026/771 on the EHDS Board, 7 April 2026 — EUR-Lex

1. Commission Implementing Regulation (EU) 2026/2083 on MyHealth@EU, 18 September 2026 — EUR-Lex

1. Commission Implementing Regulation (EU) 2026/2098 on dataset description metadata, 18 September 2026 — EUR-Lex

1. Commission Implementing Regulation (EU) 2026/2099 on cross-border identification and authentication, 21 September 2026 — EUR-Lex

1. European Health Data Space: templates for secondary use of electronic health data, initiative 16712 — European Commission, Have your say

1. European Health Data Space: technical requirements for HealthData@EU, initiative 16155 — European Commission, Have your say

1. Committee on the European Health Data Space, summary record of 23 and 24 June 2026 — Comitology Register, European Commission

1. Committee on the European Health Data Space, summary record of 28 May 2026 — Comitology Register, European Commission

1. European Health Data Space: common specifications for the European digital testing environment, initiative 17513 — European Commission, Have your say

1. European Health Data Space Board operations, initiative 14992 — European Commission, Have your say

1. European Health Data Space identification management, initiative 15353 — European Commission, Have your say

1. Certification of EHR systems — European Commission, DG SANTE

1. Xt-EHR Joint Action: Extended EHR@EU Data Space for Primary Use — Xt-EHR

1. The European Health Data Space, September 2026 briefing — IHE Catalyst, published by eHealth Suisse

1. Committee on the European Health Data Space, summary record of 23 March 2026 — Comitology Register, European Commission

1. European Health Data Space: state of play, IHE-Europe Experience Days, March 2026 — European Commission, Digital Health unit (via IHE-Europe)

1. 15(1) Implementing Act notes — Ringholm

1. HL7 Europe FHIR Implementation Guides portal, updated 16 October 2026 — HL7 Europe

1. EHR EU Database, acceptance environment — European Commission

1. Regulation (EU) 2024/2847, the Cyber Resilience Act — EUR-Lex

1. EHDS Article 105 with commentary — Ringholm

1. The Blue Guide on the implementation of EU product rules 2022, section 2.3 — EUR-Lex

1. AuditEvent, FHIR R4 — HL7

1. FHIR Implementation Guide for ABDM, version 6.5.0 — National Resource Centre for EHR Standards

1. Guidelines 05/2021 on Article 3 and Chapter V of the GDPR, version 2.0 — European Data Protection Board

1. Data protection adequacy for non-EU countries — European Commission

1. Digital Personal Data Protection Act, 2023 — Ministry of Electronics and Information Technology, India