EHDS readiness for EHR manufacturers: certification duties, EEHRxF, and what is not a notified-body audit
A decision page for EHR manufacturers under Regulation (EU) 2025/327 Chapter III — harmonised software components, EEHRxF, EU declaration of conformity, CE marking, and why this is not an MDR notified-body audit.
Ala Ben Aicha
Direct answer
This page is for EHR-system manufacturers under EHDS Chapter III. You ship interoperability and logging components, self-declare, CE-mark and register. That is not a notified-body audit. EEHRxF is the exchange format the implementing acts will lock.
Decision table: duties versus other regimes
Pin Regulation (EU) 2025/327 and the Commission page on certification of EHR systems. Dates for product teams (26 March 2025 in force; implementing acts by March 2027; category 1 March 2029; category 2 March 2031) and HL7 Europe Base/Core payloads sit on EU Core and EHDS implementation. Software that is a medical device is still MDR — a separate question.
An EHR system (Article 2(2)(k)) is software intended to store, intermediate, export, import, convert, edit or view priority-category personal electronic health data (patient summaries, ePrescriptions / eDispensations, imaging, test results, discharge reports) for healthcare providers or for patients accessing those data. Appointment-only tools are out of that definition.
| Duty | Where | What it is | What it is not |
|---|---|---|---|
| Two harmonised software components | Art. 25; Annex II | Interoperability component — import/export priority data in EEHRxF. Logging component — access logs for Art. 9 | Rewriting the whole EHR as a generic FHIR R4 server |
| Manufacturer obligations | Art. 30 | Conformity with Annex II + Art. 36 common specifications; technical documentation (Art. 37); information sheet (Art. 38); single contact point | A Commission “EHDS certified” badge on a slide |
| Common specifications | Art. 36 — by 26 March 2027 | Implementing acts that lock testable interoperability and logging requirements | An excuse to invent a private XML format in 2026 and call it EEHRxF |
| EU declaration of conformity | Art. 39 | Manufacturer self-declares that Annex II is met; assumes responsibility | Assessment by a notified body under this Chapter |
| Digital testing environments | Art. 40 | Member-state / European automated tests of the harmonised components; results go into technical documentation | A substitute for the 2027 acts, or a pass that expires like an ISO certificate |
| CE marking | Art. 41 | Affix CE for the EHR-system Chapter III obligations | MDR CE for SaMD. One product may need both regimes — they are not the same audit |
| EU database of EHR systems | Art. 49 | Register before placing on the market / putting into service, including assessment results | A marketing directory you can skip if you only sell in one Member State |
| Priority categories / EEHRxF | Arts 2, 26, 29; Commission EEHRxF notes | Harmonised datasets, coding systems, technical specs for the priority categories | Secondary-use HealthData@EU permits |
Xt-EHR and related work describe the EHDS conformity path as mandatory self-assessment feeding the Art. 39 declaration, with market surveillance (not a pre-market notified body) able to challenge a file. Article 39(5) is the legal hook: by drawing up the declaration, the manufacturer assumes responsibility for the harmonised components. If the same product is Class IIa+ medical device software, MDR still involves a notified body — that is the MDR article, not this page.
EEHRxF is the payload contract: datasets, terminology, and technical profiles. Until the 2027 implementing acts name the artefacts, treat HL7 Europe Base/Core as the implementable preview, not as a substitute for the acts.
Illustrative 4–8 week spike
Phases below are a readiness spike for a manufacturer’s product team, not a quote, not a notified-body programme, and not a date on which you may CE-mark.
| Week (illustrative) | Phase | Exit |
|---|---|---|
| 1 | Scope the product as an EHR system — which priority categories you actually store or view; in-house hospital build still counts as putting into service (Art. 26) | Written yes/no per category; MDR qualification parked with the regulatory owner |
| 2 | Component map — where import/export (interoperability) and access logging live in the architecture; what is not harmonised (Member States may still constrain the rest) | Diagram of the two components vs the rest of the EHR |
| 3–4 | EEHRxF rehearsal — pin HL7 Europe IG(s) for the categories you sell (Patient Summary, MPD, laboratory, HDR); round-trip one de-identified fixture | Fixture Bundle + gaps vs Annex II language |
| 5–6 | Evidence pack — technical documentation skeleton (Art. 37), log-review story (Annex II security), plan for Art. 40 testing when environments exist | Folder structure; no fake “passed EHDS” letter |
| 7–8 | Declaration rehearsal — who signs Art. 39, languages, 10-year availability, Art. 49 data you will need; rollback: do not CE-mark on a rehearsal | Named signatory; list of open legal questions for your counsel |
Category 1 obligations for in-scope systems are still aimed at March 2029, category 2 at March 2031, with common specifications due by March 2027. Shipping a Patient Summary FHIR document in 2026 is useful rehearsal. It is not early compliance with a 2029 duty.
What you will not get from this page (or from me as a stamp)
- A notified-body audit, NB number, or MDR certificate.
- An EHDS CE marking I affix, or an EU declaration I sign as manufacturer — you are the manufacturer (or you name one).
- A finding that your product is or is not an EHR system, or is or is not SaMD. Qualification is a legal act.
- A promise that HL7 Europe IG version x will be the named EEHRxF profile in the 2027 acts.
- Clinical advice.
I implement interoperability components, logging pipelines, and fixture-driven mapping against the IGs the acts (and your counsel) point at. Market surveillance, the EU database, and the signature on Annex IV remain yours.
If that manufacturer spike is what you need, use digital health interoperability or contact with project intent.