European UnionEuropean Health Data Space Regulation, Essential Requirements for the Harmonised Software Components of EHR Systems
Regulation (EU) 2025/327, Art. 30(1)(a) and Annex II
A product security requirements rule binding public and private bodies.
- Private right of action
- Yes
- Obligation class
- Security, Governance
As of .
What it requires
- This duty takes effect on for EHR systems intended by the manufacturer to process the priority categories of personal electronic health data in Article 14(1), points (a), (b) and (c), and on for those intended to process points (d), (e) and (f) and for EHR systems put into service under Article 26(2): Article 105 applies the Regulation from but applies Articles 25 to 27, which govern placing an EHR system on the market, and Chapter III for Article 26(2) systems from those later dates, and the manufacturer's Article 30 duty attaches to a system placed on the market under them.
- It reaches you if you are the manufacturer of an EHR system, meaning software, or hardware and software together, that stores, intermediates, exports, imports, converts, edits or views personal electronic health data of the priority categories and is intended for use by healthcare providers giving patient care or by patients accessing their own data, including a system manufactured and used within a health institution and a system offered as a service (Article 2, point (k), and Article 26(2)); general purpose software used in a healthcare environment is outside Chapter III (Article 25(2)). Ensure that the harmonised software components of your EHR systems, the European interoperability software component and the European logging software component, and the EHR systems themselves to the extent Chapter III sets requirements for them, conform with the essential requirements in Annex II and with the common specifications adopted under Article 36 (Article 30(1), point (a)).
- Design and develop your EHR system so that its interoperability, safety and security features uphold the rights of natural persons, and so that, where it is operated together with other products including medical devices, the harmonised software components make interoperability and compatibility reliable and secure (Annex II, points 1.3 and 1.4).
- Provide reliable mechanisms for the identification and authentication of health professionals in an EHR system designed to be used by health professionals (Annex II, point 3.1).
- Have the European logging software component of an EHR system designed to enable access to personal electronic health data record at least, on every access event or group of events, the identification of the healthcare provider or other individuals who accessed the data, the identification of the specific natural person or persons who accessed it, the categories of data accessed, the time and date of access and the origin or origins of the data (Annex II, point 3.2).
- Include in the harmonised software components tools or mechanisms to review and analyze the log data, or support the connection and use of external software for the same purposes, and support different retention periods and access rights that take into account the origins and categories of electronic health data (Annex II, points 3.3 and 3.4).
- Provide, where the EHR system is designed to store or intermediate personal electronic health data, an interface enabling access to that data in the European electronic health record exchange format and the ability to receive it in that format; where it is designed to provide access to such data, be able to receive it in that format; and where it includes a functionality for entering structured data, enable entry with sufficient granularity to provide the entered data in that format (Annex II, points 2.1 to 2.4).
- Do not include in the harmonised software components features that prohibit, restrict or place an undue burden on authorized access, sharing or use of personal electronic health data for permitted purposes, or on authorized export of that data for the purpose of replacing the EHR system by another product (Annex II, points 2.5 and 2.6).
- If you make a wellness application, a medical device, an in vitro diagnostic medical device or an AI system and claim interoperability with EHR systems, meet the Annex II essential requirements mutatis mutandis (Annex II, introductory sentence).
Who enforces it
Enforcement body
The market surveillance authority or authorities that each Member State designates under Article 43(2), which apply Regulation (EU) 2019/1020 to EHR systems (Article 43(1)) and are empowered to take the market surveillance measures in Article 16 of that Regulation (Article 43(2)); for medical devices, in vitro diagnostic medical devices and high-risk AI systems that claim interoperability, the authorities named in Article 43(7).
Settledness
- As of
- Open questions
- Which common specifications under Article 36(1) of Regulation (EU) 2025/327 apply to the essential requirements in Annex II, and from which dates by category of data?
What this law does
Article 30(1), point (a), of Regulation (EU) 2025/327 requires a manufacturer of an EHR system to ensure that the harmonised software components of its EHR systems and the EHR systems themselves, to the extent that Chapter III establishes requirements for them, are in conformity with the essential requirements in Annex II and with the common specifications adopted under Article 36.
Article 2, point (k), defines an EHR system as any system whereby the software, or a combination of the hardware and the software of that system, allows personal electronic health data that belong to the priority categories to be stored, intermediated, exported, imported, converted, edited or viewed, and intended by the manufacturer to be used by healthcare providers when providing patient care or by patients when accessing their electronic health data.
Article 25(1) provides that EHR systems shall include a European interoperability software component for EHR systems and a European logging software component for EHR systems, which together are the harmonised software components of EHR systems. Article 25(2) provides that Chapter III does not apply to general purpose software used in a healthcare environment.
Article 26(2) treats an EHR system manufactured and used within a health institution established in the Union, and an EHR system offered as a service to a person established in the Union, as put into service. Annex II applies its essential requirements mutatis mutandis to medical devices, in vitro diagnostic medical devices, AI systems and wellness applications claiming interoperability with EHR systems.
Annex II, point 1.3, requires an EHR system to be designed and developed in such a way that its interoperability, safety and security features uphold the rights of natural persons. Annex II, point 2.1, requires an EHR system designed to store or intermediate personal electronic health data to provide an interface enabling access to that data in the European electronic health record exchange format.
Annex II, point 2.2, requires an EHR system designed to store or intermediate personal electronic health data to be able to receive that data in the European electronic health record exchange format. Annex II, point 3.1, requires an EHR system designed to be used by health professionals to provide reliable mechanisms for the identification and authentication of health professionals.
Annex II, point 3.2, requires the logging component of an EHR system designed to enable access to personal electronic health data to record at least, on every access event or group of events, the identification of the healthcare provider or other individuals who accessed the data, the identification of the specific natural person or persons who accessed it, the categories of data accessed, the time and date of access and the origin or origins of the data.
Annex II, point 3.3, requires the harmonised software components to include tools or mechanisms to review and analyze the log data, or to support the connection and use of external software for the same purposes. Annex II, point 3.4, requires the harmonised software components that store personal electronic health data to support different retention periods and access rights that take into account the origins and categories of electronic health data.
The recitals state that the security requirements of the harmonised software components should cover elements specific to EHR systems, as more general security properties should be supported by other mechanisms such as those under Regulation (EU) 2024/2847.
Article 104 inserts Article 32(5a) into Regulation (EU) 2024/2847, under which a manufacturer of a product with digital elements that is classified as an EHR system demonstrates conformity with the essential requirements in Annex I to that Regulation using the conformity assessment procedure in Chapter III of Regulation (EU) 2025/327.
Article 36(1) requires the Commission to adopt, by , common specifications in respect of the essential requirements in Annex II by means of implementing acts. Article 105 applies Regulation (EU) 2025/327 from .
Article 105 applies Articles 25, 26 and 27 from to EHR systems intended by the manufacturer to process the priority categories of personal electronic health data in Article 14(1), points (a), (b) and (c), and from to those intended to process points (d), (e) and (f). Article 105 applies Chapter III to EHR systems put into service in the Union under Article 26(2) from .
Article 105 applies the implementing acts referred to in Article 36(1) from the dates that depend on the category of personal electronic health data. Article 43(2) requires each Member State to designate the market surveillance authority or authorities responsible for the implementation of Chapter III. Article 99 requires Member States to lay down the rules on penalties applicable to infringements of Regulation (EU) 2025/327, which must be effective, proportionate and dissuasive.
Article 100 gives any natural or legal person that has suffered material or non-material damage as a result of an infringement the right to receive compensation in accordance with Union and national law.
When LexLint raises it
When your app profile says your app distributes a software product or ships a mobile app.