The European Health Data Space reaches medical software through its interface

Teams developing medical software know the MDR. Those who now also want to exchange data with a hospital's health record have, since 2025, a further regulation to deal with: the European Health Data Space. It does not concern every medical device. It does concern every device whose manufacturer claims that it is interoperable with electronic health record systems — and in our experience that claim often appears in sales material before it has been settled in development.

The basis: a framework of its own for health record systems

Regulation (EU) 2025/327 on the European Health Data Space (EHDS) entered into force on 26 March 2025. Its Chapter III is addressed to manufacturers of EHR systems. Under Article 2(2)(k), this means any system whose software allows personal electronic health data in the so-called priority categories to be stored, intermediated, exported, imported, converted, edited or viewed, and which the manufacturer intends to be used by healthcare providers when providing patient care or by patients when accessing their electronic health data.

The priority categories are set out in Article 14(1): patient summaries, electronic prescriptions and electronic dispensations, followed later by medical imaging studies and related reports, medical test results including laboratory results, and discharge reports.

An EHR system must contain two harmonised components. The interoperability component can import and export these data in the European electronic health record exchange format (EEHRxF); according to the Commission's FAQ, the system is not required to use that format internally. The logging component generates logs that allow patients to see who has accessed their data.

What an interoperability claim triggers for medical devices

A medical device is not automatically an EHR system. Article 27 of the Regulation provides, however, that where the manufacturer of a medical device, an in vitro diagnostic medical device or a high-risk AI system claims interoperability with EHR systems, it must prove compliance with the essential requirements for both harmonised components. Those requirements are laid down in Annex II. The Commission's FAQ points out that the cross-reference in Article 27 names only Section 2 of the Annex, while both components are clearly meant.

The difference from an EHR manufacturer lies in the route to conformity. Before being placed on the market, EHR systems must pass the tests of a European digital testing environment; their manufacturers must draw up technical documentation and an information sheet, issue an EU declaration of conformity, affix the CE marking and register the system in an EU database (Articles 37 to 41 and 49). Manufacturers of medical devices that merely claim interoperability must provide the proof but, according to the FAQ, are not obliged to use the testing environment.

Where a product is both — a medical device and an EHR system — both regulations apply in full, including both registrations: EUDAMED under the MDR and the EHDS database under Regulation (EU) 2025/327. The Commission states that it will work to streamline the two registrations.

An example

Consider software that analyses laboratory values and suggests a change of therapy, certified as a medical device under the MDR. As long as it only displays its results itself, the EHDS does not touch it on this point. If the data sheet says “transfers findings to your hospital information system”, that is in our assessment an interoperability claim: the manufacturer must then demonstrate that the product meets the requirements for the interoperability and logging components. If the same software also displays patient summaries or laboratory reports for treatment purposes, it may itself be an EHR system, and the full Chapter III route is added.

Deadlines

The obligations in Chapter III apply in stages under Article 105. From 26 March 2029, EHR systems processing the first group of priority categories may only be placed on the market with the harmonised components. From 26 March 2031, the same applies to systems processing the remaining categories.

The technical details — the common specifications for the components under Article 36 — are to be set out by the Commission in implementing acts, due by 26 March 2027. Until then, the direction is known, not every detail.

How to proceed

1. Collect every place where you claim interoperability with health records or hospital information systems: intended purpose, instructions for use, data sheet, website, tender documents.
2. Establish whether the product is itself an EHR system, that is, whether it stores, displays or exchanges data in the priority categories for patient care.
3. Set the essential requirements of Annex II alongside the existing MDR documentation and close only the gap.
4. Follow the implementing acts under Article 36 and plan development time for EEHRxF export and logging before 2029.

Where this does not apply

Not every piece of healthcare software falls under Chapter III. The FAQ explicitly lists appointment scheduling, billing that does not process data in the priority categories, and wellness applications handling non-medical data such as sleep duration as examples outside the scope. General-purpose software such as a word processor does not become an EHR system because someone writes a discharge letter in it. Wellness applications that claim interoperability have their own labelling and registration obligations (Articles 47 to 49).

Three uncertainties remain. The Commission's FAQ is expressly not an authoritative interpretation. The specifications have not yet been fully laid down. And in 2025 the Commission proposed a targeted revision of the MDR and IVDR, after which the references in the EHDS may need to be adapted. Member States may also maintain their own rules on the procurement and reimbursement of EHR systems (Article 29). What counts is the current text of the Regulation.

Conclusion

The EHDS reaches medical software not through its risk class but through its interface. Claiming interoperability means taking on obligations of proof. Making that claim deliberately now and setting the requirements alongside the MDR documentation leaves enough time before 2029.