EHR

Electronic Health Record

In short: EHDS defines the term EHR (formally: EHR System) in a much wider sense than how this term is genereally used in the industry. Effectively all software applications that deal with patient data are defined to be an EHR, unless the application meets certain criteria.

From article 2:

• (j) 'electronic health record' or 'EHR' means a collection of electronic health data related to a natural person and collected in the health system, processed for the purpose of the provision of healthcare;
• (k) 'electronic health record system' or 'EHR system' means 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 of personal electronic health data established under this Regulation 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;

From the EU FAQ, March 2025:

The EHR definition has the following elements:

• EHR systems can be a combination of hardware of software or just software: an EHR system can be integrated as part of a physical device or be software on its own;
• They allow the storage, intermediation, export, import, conversion, editing, or viewing of priority categories of electronic health data: a system that only processes other kinds of data (such as a system for patients to book appointments) is not an EHR system;
• Systems do not need to provide all of storage, intermediation, export, import, conversion, editing, or viewing functionalities to be considered as an EHR system;
• They are intended by their manufacturer to be used:
  • By healthcare providers when providing patient care: the classic example would be systems used by clinicians for recording notes, test results etc, up to a patient management system; or
  • By patients when accessing their electronic health data: this means that for example an app that connects to the electronic health data access service for patient will count as an EHR system.

Exclusions from the EHR definition

The comission has informally indicated that the determination of whether a system is an 'EHR' is based on the wider intent of the definition, and that edge use cases can always be found where the formal definition may not directly apply. For example:

• One could argue that a Laboratory Information System (LIS) isn't a an EHR, given that it's not 'intended by the manufacturer to be used by healthcare providers when providing patient care'. A LIS should be considered to be an EHR however.
• One could also argue that a 'smart thermometer' is an EHR given the current definition, whereas that's not the intent of the definition (this was clarified as part of the article 15 implementing act, see discussion related to Feeder Systems below).

As such: be aware of edge use cases, and take the intent of the definition into account.

There are various statements in implementing acts and the FAQ which elaborate the circumstances when the above generic wording doesn't apply, i.e. when something should not be regarded as an EHR under the EHDS:

1. When general purpose software is used it does not count as an EHR system: standard text processing software can be used to edit any kind of textual information, including for example patient summaries, but it is not specifically intended by the manufacturer for use in providing patient care and so does not count as an EHR system (Source: Article 25(2) and recital 38)
   Example: if I purchase SAP and customize it to be an EHR, it's not an 'EHR' ? The vendor SAP won't have to do self-assessment. The organization that turns SAP or Excel into a useful healthcare product will have to do so. Otherwise one could state that 'Python' as a product is not an EHR, and that anything based on that tool can't be an EHR. That's obviously false.
2. Articles 27 and 48 document that AI Systems and Medical Devices could be EHRs, but only if they choose to interoperate data with EHRs via the harmonized interoperability component. In that case vendors of such systems shall claim interoperability with the harmonised software components of EHR systems, and shall prove compliance with the essential requirements on the harmonized components. (And not compliance regarding the other requirements on EHR systems).

Being an EHR versus having to support the EEHRxF

Note that a system being an EHR (according to the above definition) does not automatically imply that an EHR has to support the EEHRxF data format nor the harmonized components. A sub-category of EHRs (see Article 105) will have to do so. [We use the term EHR(+) for such systems in our EHDS-on-FHIR training course]. All EHRs have to support the patient rights, but they may do so using some other data format and exchange mechanism than the one defined for use by the harmonized components.

The (currently: draft) article 15 Implementing Act specifies that support for the EEHRxF data format and the harmonized interoperability component is also NOT applicable for the folowing categories of applications:

• EHRs where the patient summary is limited to patient demographics and insurance information;
• National Contact Points (NCPeH);
• Feeder Systems, defined as EHRs that perform automatic generation of data, where such data is not retained by the generating EHRs, except for temporary buffering of such data prior to transmission. For example: a smart thermometer, some lab devices. Such systems to feed data to downstream systems and do not store, present or manage the data themselves.

Mixture of applicable legislation

Products may have parts that fall under different certification systems such as under the Medical Devices Regulation, the Artificial Intelligence Act or the EHDS. In such case, each part of the product needs to comply with the applicable certification framework.

Comments/Discussion

Please find some illustrative examples below:

In scope:

• An information system used in a pharmacy to read electronic prescriptions, process dispensations at the pharmacy and to issue an electronic dispensation.
• A patient information portal allowing a patient access electronically health data documents produced in the provision of healthcare services that are included in the priority categories under the EHDS Regulation, e.g. electronic prescriptions, medical images and reports such as X-ray or MRI scans, laboratory results of blood or urine tests.
• A system converting the output of legacy EHR systems into the EEHRxF.

Out of scope:

• Scheduling system for appointments in a general practitioner's practice;
• Administrative billing system, unless it processes diagnosis, medication or other patient data from priority categories for preparing the bills;
• A wellness application processing non-medical data, e.g. sleep information or measuring intensity and duration of physical activity.

This includes systems intended for placing on the market, EHR systems offered as a service as defined in Article 1(1), point (b), of Directive (EU) 2015/1535 (EHR systems offered through the SaaS licensing) and EHR systems that are developed and used in-house (e.g. by healthcare providers themselves)

---

Feedback

Please e-mail ehds@ringholm.com should the information on this page be incorrect or incomplete; we welcome your suggestions to improve its content.

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.