The European Health Data Space Regulation turns electronic health record software into a regulated product with mandatory security and logging components, and turns hospitals and other health data holders into suppliers of data for secondary use through secure processing environments. Regulation (EU) 2025/327 entered into force on 26 March 2025, and its main obligations for EHR systems and data holders start on 26 March 2029. This guide covers what EHR system manufacturers, healthcare providers and health data holders must build, the conformity steps, the timeline and the enforcement model, with a security and identity lens. It is for product security teams at EHR vendors, hospital CISOs and data governance leads. Status checked on 27 October 2026 against EUR-Lex and the European Commission (DG SANTE) pages. For the wider sector picture see the Healthcare Cyber Regulation Map.
Key takeaways
- EHR systems become CE-marked products that must contain two harmonised software components, the European interoperability component and the European logging component, under a mandatory conformity self-assessment scheme.
- Logging is a patient right, not only a control: the logging component feeds access services so people can see who has accessed their health data.
- The CRA steps aside for EHR conformity: Regulation 2025/327 amends Regulation (EU) 2024/2847, and where a product is both, the Commission says the EHDS conformity procedure applies instead of the CRA procedure.
- Secondary use runs only through secure processing environments, under a data permit from a health data access body, with personal data never downloaded and re-identification prohibited.
- Dates are staggered: implementing acts by 26 March 2027, first priority categories and most data holder duties from 26 March 2029, the rest from 26 March 2031.
Scope: who and what is covered
The Regulation has two halves. Chapter II gives individuals rights over their electronic health data for primary use (care), Chapter III regulates EHR systems as products, and Chapter IV governs secondary use (research, innovation, policy, statistics) through health data access bodies (HDABs).
| Actor | Definition point | Main security-relevant duties |
|---|---|---|
| EHR system manufacturer | EHR systems, Art. 2(2)(k); general-purpose software excluded, Art. 25(2) | Harmonised components, testing, technical documentation, EU declaration, CE marking, EU database registration |
| Manufacturer of a medical device, IVD or high-risk AI system claiming interoperability | Art. 30 | Prove compliance with Annex II interoperability and logging requirements; product certified under its own regulation |
| Wellness application manufacturer claiming interoperability | Arts. 47 to 49 | Meet common specifications and essential requirements, register and label, export only with user consent and control |
| Health data holder | Art. 2(2)(t); micro-enterprises and natural persons generally excluded, Art. 50 | Make Art. 51 data categories available to HDABs, describe datasets, review descriptions at least annually |
| Health data access body | Chapter IV | Issue data permits, operate or oversee secure processing environments, handle complaints (Art. 81) |
| Health data user | Chapter IV | Process only in the SPE for permitted purposes; no re-identification, no unauthorised third-party access |
A holder of personal electronic health data is always a controller under the GDPR, according to the Commission's FAQ. Organisations that process health data only as processors for others are not holders. See the GDPR Compliance Guide for Security Teams.
Key obligations
EHR system manufacturers
Recital 36 explains the design: a mandatory conformity self-assessment scheme for EHR systems that process the priority categories of data, built around two harmonised software components whose technical specifications come from implementing acts based on the European electronic health record exchange format. The Commission's FAQ (Q25) lists the pre-market steps:
- Provide the two harmonised components: the European interoperability software component and the European logging software component (Arts. 25, 26 and 29).
- Pass testing in the digital testing environment (Art. 40). A system that fails testing may not be placed on the market; only the final successful test report needs to be made available.
- Draw up technical documentation (Art. 37) and an information sheet (Art. 38).
- Draw up the EU declaration of conformity (Art. 39).
- Affix the CE marking (Art. 41).
- Register the system in the EU database (Art. 49).
Updates need a fresh assessment only where they amount to a substantial change; the FAQ (Q27) says all three conditions in the Regulation must be met, the first being a change to the intended functions, type or performance that the initial risk assessment did not foresee. Treat this as a release gate question for every major version.
Relationship with the CRA: recital 36 says the EHDS security requirements cover elements specific to EHR systems, while more general security properties are handled by other mechanisms, including the Cyber Resilience Act. The Commission's FAQ (Q66) adds that where a product is both an EHR system and a product with digital elements, the EHDS conformity procedure applies instead of the CRA procedure, so a manufacturer does not run two cybersecurity conformity assessments. The CRA essential requirements still need to be met. See the EU CRA Product Classes Guide.
What the logging component means in practice
The European logging component "provides the capability to generate logs that can be used in the health data access service", so that individuals can see who accessed their data (FAQ Q7 and Q23). For an EHR vendor this changes logging from a forensic aid to a functional, user-facing feature with interoperability requirements. Expect access events to need a reliable actor identity (clinician, role, organisation), the data category, time and purpose.
| Logging design question | Why it matters under EHDS | Practical control |
|---|---|---|
| Who is the actor? | Patients see access by person and organisation | Named user accounts, no shared ward logins; service accounts labelled as systems |
| Is the log complete? | Missing entries mislead the patient and the regulator | Log at the data layer, including API and integration engine access |
| Is the log tamper-evident? | Logs support complaints and enforcement | Append-only storage, hash chaining or WORM retention, restricted admin roles |
| Is it exchangeable? | Logs must work with national access services | Follow the implementing act specifications when published; avoid proprietary-only formats |
See the CIS Control 8 Audit Log Management Guide for the general logging baseline.
Health data holders and secondary use
- Make data available: holders must provide the Art. 51 categories they control to HDABs when a permit is granted, and describe their datasets (Art. 60(3)), reviewing the descriptions at least annually.
- Secure processing environments: secondary use access happens only through an SPE (recital 77); only non-personal data may be downloaded from it. Art. 73(5) requires an implementing act with SPE security requirements.
- Prohibitions: re-identification or attempts at it, and giving access to third parties not named in the data permit, are prohibited (recital 62). See the Anonymisation and Re-identification Risk Guide.
- Opt-out: individuals may opt out of secondary use (Art. 71); an opt-out applies to new permits and requests after the opt-out, not to data already used.
- Trade secrets: under Art. 52 an HDAB can refuse a permit where no protective measures are sufficient.
Timeline and current status
Status as checked on 27 October 2026. Implementing acts setting the technical detail were still due when checked; dates below are from the Commission's EHDS page and FAQ.
| Date | Milestone |
|---|---|
| 11 Feb 2025 | Regulation (EU) 2025/327 adopted, amending Directive 2011/24/EU and Regulation (EU) 2024/2847 |
| 5 Mar 2025 | Published in the Official Journal |
| 26 Mar 2025 | Entry into force; transition phase begins |
| 26 Mar 2027 | Deadline for key implementing acts, including common specifications for the harmonised EHR components (Art. 36(1)) and SPE security requirements (Art. 73(5)); EHDS Board provisions apply |
| 26 Mar 2029 | EHR systems placed on the market must meet common specifications for the first priority categories (patient summaries, ePrescriptions and eDispensations); most Art. 51 secondary use categories apply |
| 26 Mar 2031 | Second priority categories (medical images, laboratory results, hospital discharge reports); remaining secondary use categories such as genomic data |
| Mar 2035 | Third countries and international organisations may apply to join HealthData@EU |
In-house EHR systems get an extended transitional period (recital 44). Check the implementing acts as they are adopted: the security detail of both the logging component and SPEs depends on them.
Enforcement and penalties
Enforcement is split. Market surveillance authorities designated by Member States police EHR systems under Chapter III. Health data access bodies supervise secondary use, and GDPR supervisory authorities monitor the new individual access rights. Recital 102 says penalties, including administrative fines, should be imposed for any infringement, and recital 103 identifies serious infringements such as re-identification, prohibited or unauthorised uses and downloading personal electronic health data outside the SPE. Recital 23 says supervisory authorities should be able to impose administrative fines that are effective, proportionate and dissuasive, with Danish courts able to impose them as criminal penalties. This guide does not restate maximum amounts: read the penalty articles in the Regulation and the national implementing law that applies to you.
What it means for AI agents and non-human identities
- System actors in the log: integration engines, interface services, RPA bots and AI assistants read EHR data constantly. If they access data through shared or unlabelled service accounts, the patient-facing log becomes either noise or a gap. Give each a distinct, named workload identity. See the Non-Human Identity (NHI) Guide.
- AI functions inside EHR systems: an EHR system with AI functions such as emergency triage can be subject to both the AI Act high-risk requirements and the EHDS EHR requirements (FAQ Q65). See the EU AI Act High-Risk AI Systems Guide.
- Agents in secure processing environments: research teams increasingly run automated pipelines and AI agents inside SPEs. Their credentials must be scoped to the permit, logged to the principal investigator, and unable to export personal data.
- API credentials for data holders: holders sending datasets to HDABs need short-lived, scoped machine credentials rather than static keys. See the API Key Management Guide.
Compliance steps
- Classify your role for each product and dataset: EHR manufacturer, Art. 30 manufacturer, wellness app, holder, user or a mix.
- Map products to priority categories to know whether 2029 or 2031 applies to each EHR system.
- Gap-assess logging against the patient access use case now: actor identity, completeness across APIs, integrity and retention.
- Remove shared accounts for clinicians and systems so every access event names a person or a labelled system.
- Track the implementing acts due by 26 March 2027 and plan engineering for the harmonised components.
- Set up the conformity file: testing evidence, technical documentation, information sheet, declaration, CE marking and Art. 49 registration.
- Prepare dataset descriptions as a holder and assign an owner for the annual review.
- Design SPE access with permit-scoped identities, no-download controls and output checking, ready for the Art. 73(5) requirements.
Decision guidance
- Product versus in-house system: a hospital that builds its own EHR system benefits from the extended transition, but it still needs the harmonised components eventually; buying a certified product moves the conformity burden to the vendor.
- Claim interoperability or not: medical device and wellness app manufacturers only take on the EHR requirements when they claim interoperability; decide deliberately, because the claim brings registration and logging duties.
- Small organisations: micro-enterprises are generally outside the holder duties, unless national law extends them.
Common failure patterns
- Shared ward logins: access logs that show "ward3" instead of a clinician cannot serve the patient access right.
- Integration blind spots: HL7 or FHIR interfaces reading data without writing access events, so logs show less than happened.
- Treating CE marking as paperwork: placing a system on the market without passing the Art. 40 testing.
- Static research credentials: long-lived keys into an SPE shared by a whole project team.
- Waiting for 2029: logging redesign and identity clean-up take years in hospitals; the implementing acts arrive only two years before the first deadline.
Detection and measurement
- Named access ratio: share of EHR access events attributed to a named person or labelled system identity.
- Interface coverage: integrations and APIs that write access events, as a share of all integrations.
- Log integrity checks: scheduled verification of tamper evidence, with failures investigated.
- SPE export attempts: blocked download or export attempts per month, reviewed by the HDAB or SPE operator.
- Conformity readiness: EHR products with a complete technical file against the 2029 or 2031 date.
Framework mapping
| EHDS duty | NIST SP 800-53 r5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| European logging component, access transparency | AU-2 Event Logging, AU-9 Protection of Audit Information | DE.CM (Continuous Monitoring) | A.8.15 Logging |
| Named access for people and systems | IA-2, IA-9 Service Identification and Authentication | PR.AA (Identity Management, Authentication, and Access Control) | A.5.16 Identity management |
| SPE no-download and permit scope | AC-3 Access Enforcement, AC-4 Information Flow Enforcement | PR.DS (Data Security) | A.8.12 Data leakage prevention |
| Testing and technical documentation | SA-11 Developer Testing and Evaluation | ID.IM (Improvement) | A.8.29 Security testing in development and acceptance |
Practitioner checklist
- Each EHR product is mapped to its priority categories and to the 2029 or 2031 date.
- The implementing acts on harmonised components and SPE security are tracked with an owner.
- All clinician and system access to health records uses individual, named identities.
- Access logging covers user interfaces, APIs and integration engines.
- Logs are tamper-evident and retained for the access service and complaints.
- The conformity file covers testing, documentation, information sheet, declaration, CE marking and registration.
- Dataset descriptions exist and are reviewed at least annually.
- SPE access uses permit-scoped, short-lived credentials and blocks personal data export.
Standards and references
- EUR-Lex: Regulation (EU) 2025/327 on the European Health Data Space
- European Commission: European Health Data Space Regulation (EHDS)
- European Commission: Frequently Asked Questions on the European Health Data Space
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Healthcare Cyber Regulation Map · Healthcare Identity Security Guide · EU CRA Product Classes Guide · GDPR Compliance Guide for Security Teams. This guide summarises the security-relevant duties of Regulation (EU) 2025/327 and is not legal advice.