PEC Healthcare Insights

EHDS: Why the next EHR procurement becomes an identity-and-access-trail decision

The EHDS does not make every hospital system immediately subject to full conformity requirements in 2026. Yet it already poses a concrete security question for a new EHR procurement: can the supplier evidence a credible path to authenticated clinical access, analysable access trails and future EU conformity evidence?

Not general cyber resilience, but a clinical access trail

The EHDS EHR rules target qualifying electronic health record systems. These are software or appliances that store, intermediate, import, export, convert, edit or view priority categories of electronic health data and are intended for use by healthcare providers in patient care or by patients. Not every hospital application is therefore automatically within scope; the Commission gives an appointment-booking-only system as a counter-example.

The EHDS's distinct cyber contribution is consequently not a general requirement for the whole hospital operation. It concerns evidence of access to patient data in harmonised EHR components. That differs from NIS2, which addresses the risk-management and incident governance of a covered organisation, and from the Cyber Resilience Act (CRA), which establishes horizontal cybersecurity and vulnerability requirements for products with digital elements. Recital 36 distinguishes EHR-specific security elements from more general product properties that may, for example, be supported by the CRA.

The five fields: turning an audit log into an access chain

For EHR systems used by health professionals, Annex II provides for reliable mechanisms to identify and authenticate them. For systems enabling access to personal electronic health data, the European logging component is to record each access event or group of events: the actor, the patient or data subject, the data category, the date and time, and the data origin.

This is more than an abstract “audit-log” tick box. The harmonised component must permit the review or analysis of logs, or connect to external tools. It must also support retention periods and access rights that take data origin and category into account. Procurement teams should therefore ask for more than a log export and require a demonstration of the chain: how is a professional reliably identified and authenticated? Can the five fields be searched and filtered in a realistic case, then passed to a SIEM or another analysis tool? Do origin, category and authorisation logic remain visible across interfaces and middleware?

Interoperability is also a provenance question

Annex II links interoperability, security and the rights of natural persons. Connected products are to be reliably and securely interoperable; the requirements also cover import, export and access capabilities in the European Electronic Health Record exchange format (EEHRxF). For procurement, that creates a practical test case: importing or exporting must not simply deliver a record. Its origin and category, the applicable rights and the logging of access along the interface need to remain traceable.

This matters especially where an installed estate is retained through an upgrade, translation or intermediary layer. The EHDS does not automatically demand a simplistic replacement of the whole estate. The Commission explains that import and export can be achieved by upgrading an existing EHR system or by using a translating or intermediary system. In either case, the auditability of that layer belongs in the operational and contractual evidence.

From a marketing promise to supplier evidence

The EHDS moves part of the evidence burden upstream into the EHR supply chain. Manufacturers must ensure that the EHR system and its harmonised components conform to Annex II and the common specifications under Article 36. The framework provides, when the respective requirements apply, for technical documentation, an EU declaration of conformity, digital testing, CE marking and registration in the EU database.

This is not a reason to promise a non-existent “full EHDS conformity” in 2026. The detailed common specifications and other key implementing acts have a 26 March 2027 adoption deadline. A dated evidence path is therefore more useful than a label: a supplier roadmap for the specifications, intended Article 40 digital-test evidence, Article 37 technical documentation, Article 39 declaration of conformity, and a plan for CE marking and registration. Change control, release timing, budget, supplier participation and remedies or upgrade rights if the path fails are equally important.

The phases create a preparation window – not a basis for false assurances

EHR application is phased. Article 105 identifies 26 March 2029 for patient summaries, ePrescriptions and eDispensations, and 26 March 2031 for imaging studies and reports, test results and reports, and discharge reports. Those dates make 2026 an architecture and procurement window, rather than a deadline for blanket EHDS obligations in every hospital app.

A tender should therefore distinguish the material scope, the priority data categories and the planned go-live. This permits current security requirements, national rules and the EHDS-roadmap element to be separated clearly now – and brought together traceably later.

Six questions for procurement, IT and information security

  1. Does the product fall within the EHR-system definition, and which priority data categories does it process?
  2. Can it produce the five fields of the Annex II § 3.2 access trail and support log review or analysis?
  3. How are health professionals identified and authenticated, including across connected systems?
  4. How are data origin, category-specific rights and retention maintained through interfaces and middleware?
  5. What is the dated plan for Article 36 specifications, Article 40 testing, documentation, declaration, CE marking and registration?
  6. Who bears specification-driven changes, and which upgrade, remedy or exit rights apply if the plan fails?

Conclusion: procure an evidence path, not an empty formula

The EHDS replaces neither NIS2 organisational cyber governance nor the CRA's horizontal product law. Its EHR-specific value lies in a future regulated access trail for clinical data and a harmonised conformity path. Anyone procuring an EHR, HIS or major integration layer today should therefore require robust evidence on identity, logging, analysis, origin and supplier delivery – without claiming blanket 2026 compliance for every application.

Next step

Assess digitalisation, information security and procurement together

A structured inventory of systems, interfaces, roles and supplier dependencies creates a robust basis for the next digitalisation decision – without replacing legal advice or an assurance of outcomes.

Assess digitalisation and AI in healthcare

Official primary sources and scope of validity

As at: 3 September 2026. This article is for orientation only and does not constitute legal advice. Regulation (EU) 2025/327 is controlling; the specific assessment depends on the system, data categories, use case, national rules, and future implementing acts and guidance.