# The EHDS Vendor Roadmap

What manufacturers of health software must do to keep selling it in Europe after 2029-03-26.

Published by Annexbase · guide corpus 0.1.0 · reviewed 2026-08-30
Written against Regulation (EU) 2025/327 (OJ L 2025/327, 5.3.2025). Tooling, not legal advice.

---

## Are you in scope?

Your software is in scope if it handles any of these categories of personal electronic health data:

| Category | Deadline | Tested against |
|---|---|---|
| Patient summaries | 2029-03-26 | hl7.fhir.eu.eps |
| Electronic prescriptions | 2029-03-26 | hl7.fhir.eu.mpd |
| Electronic dispensations | 2029-03-26 | hl7.fhir.eu.mpd |
| Medical imaging studies and related imaging reports | 2031-03-26 | hl7.fhir.eu.imaging |
| Medical test results, including laboratory and other diagnostic results and related reports | 2031-03-26 | hl7.fhir.eu.laboratory |
| Discharge reports | 2031-03-26 | hl7.fhir.eu.hdr |

...and does any of the following with them:

- Stores personal electronic health data
- Intermediates personal electronic health data
- Provides access to personal electronic health data
- Has a functionality for entering structured personal electronic health data
- Designed to be used by health professionals
- Designed to enable access by healthcare providers or other individuals

Note the deeming provisions: software offered as a service to anyone established in the Union is
put into service there regardless of where you are, and systems built and used inside a health
institution are also caught, with the institution as manufacturer.

## What you must produce

1. Technical documentation (Annex III) — ten prescribed sections. 30 days to produce on request;
   fail and the authority may require a test by an independent body at your expense.
2. A result from a state-run digital testing environment. Free, mandatory, and your declaration
   cannot lawfully be completed without referencing it.
3. An information sheet for professional users (Art 38). Overstating functions or hiding
   interoperability limits is an infringement, and it binds your advertising too.
4. An EU declaration of conformity (Annex IV), signed on your sole responsibility.
5. Registration in the EU database, before placing on the market.
6. The CE marking, affixed to the accompanying documents. There is no notified body.

And then, continuously: ten years of retention, three days to report a serious incident to every
market you sell in, a significance judgement on every release, and documented procedures keeping
design, development and deployment in continuing compliance.

## The eleven steps

### 1. Determine the applicable requirements

*Xt-EHR D8.2 step 1 · Annex II · Art 14(1) · Art 25(1)*

Everything downstream derives from this declaration: which Annex II requirements bind you, which conformity deadline applies, which implementation guides you will be tested against, and how much of your technical file can be generated. Scope it wrong and you build evidence for the wrong obligation.

**What you do**

- Declare every priority data category the system processes — patient summaries, ePrescriptions, dispensations, imaging studies, test results, discharge reports (Art 14(1), characteristics in Annex I).
- Declare the functional roles the system plays for those categories. Under D8.2 conformance is declared per profile and role, not per product.
- State the intended purpose in the manufacturer's own words. It is Annex III point 1(a), and it also fixes the boundary of Art 28: your marketing may not exceed it.
- Check the deemed-in-scope cases before concluding you are out: EHR systems offered as a service to anyone established in the Union, and in-house builds inside health institutions, are put into service regardless of where you sit (Art 26(2)).

**Done when:** Categories, roles and intended purpose are recorded, and the scoped requirement set is non-empty.

**Where people go wrong**

- Declaring fewer categories than you actually process does not shrink the obligation — it only invalidates the evidence you build on top of it.
- The EEHRxF is a boundary format. Commission FAQ Q23: there is no requirement to use it internally. You keep your internal model and transform at the edge.

### 2. Prepare the test plan

*Xt-EHR D8.2 step 2 · Art 40(3)*

A digital testing environment tests what you point it at. The test plan is the bridge between the scoped requirements and the artefacts you will submit — and it is the first thing a market surveillance authority reads to judge whether your self-assessment was serious.

**What you do**

- For each scoped requirement, decide how it will be shown: automated test in a DTE, manual checklist with evidence, or design documentation. Annexbase has already sorted them into automatable, hybrid and manual.
- List the concrete artefacts per profile: example instances, CapabilityStatement, StructureDefinitions, terminology bindings. Attach them here as you produce them.
- Pin the toolchain now. D8.2 requires test tooling to be documented with versions; a result you cannot reproduce is not evidence. Every validation run Annexbase records carries its exact validator, IG package and terminology pin.
- Choose a testing environment. Any Member State's DTE may be used and its results must be accepted across all Member States (D8.2).

**Done when:** Every scoped requirement has an assigned evidence route and the artefacts named in the plan are attached.

**Where people go wrong**

- Do not wait for the DTE to be feature-complete before planning. Six EU DTE releases are planned through end-2027; industry's own stated build-and-deploy cycle is four to five years against a March 2029 deadline.
- Ship the SNOMED IPS Free Set unless you hold a SNOMED licence. Expanded SNOMED, ATC and EDQM value sets are licensed content.

### 3. Run the automated tests

*Art 40(1)–(3) · presumption of conformity Art 40(3) and Art 36(4)* · Tooling exists: EU and Member State digital testing environments — free, state-run

Article 40(3) is imperative: before placing an EHR system on the market, manufacturers shall use a digital testing environment, and the results shall be included in the technical documentation. Annex IV point 4 makes the declaration itself depend on that result. Elements that test positive are presumed to be in conformity.

**What you do**

- Validate your artefacts here first. Annexbase runs the same Apache-2.0 HL7 validator the environments build on, pinned to an exact version, so structural failures surface before you open a DTE ticket.
- Iterate until the run is clean. Failed DTE tests receive feedback and only the successful test report has to be made available (Commission FAQ Q26) — you may iterate privately.
- Submit the passing artefacts to your chosen DTE and keep the successful report.
- Attach the DTE report here. It is the object that Annex IV point 4 and Art 49(2) both point at.

**Done when:** At least one passing validation run is recorded and the DTE report is attached.

**Where people go wrong**

- Annexbase is not a digital testing environment and issues no conformity result. It gets you to the DTE with artefacts that already pass, and preserves the reproducible evidence trail around the result you get back.
- Never paste patient data. Use synthetic instances — Annexbase stores no PHI, ever, and a real record in a test artefact is a data-protection incident of your own making.

### 4. Evidence the manual checklist items

*Xt-EHR D8.2 step 4 · Annex II sections 1–3 · Art 30(2)*

D8.2 splits requirements into testable assertions and checklist items. The checklist half — variable log retention periods and user access rights, assurance that the harmonised components do not impair intended functionality or patient safety, quality management system implementation — is verified manually against evidence you produce.

**What you do**

- Work the requirement list for this system. For each manual and hybrid requirement, attest it with the specific basis: a document reference, a test identifier, a screen capture.
- Attach the artefact behind each attestation. Attested with no artefact is an assertion; with the artefact it is evidence.
- Cover Art 30(2) explicitly — the procedures that keep design, development and deployment in continuing compliance. D8.2 recommends ISO 9001, or ISO 13485 if you are also an MDR manufacturer.
- Remember the two components must be independent of each other (Art 2(2)(n) and (o)). That is an architectural claim you have to be able to show, not just assert.

**Done when:** Every manual and hybrid requirement in scope carries an attestation, and each attestation names its basis.

**Where people go wrong**

- Attesting everything on day one produces a file that reads as unserious. Attest what you can evidence; leave the rest open and visible.
- Annex II point 3.4 implies a per-category, per-origin policy engine for retention and access rights. That is an engineering item, not a configuration flag.

### 5. Compile the Annex III technical documentation

*Art 37(1)–(2) · Annex III · Art 30(3)*

Draw it up before placing on the market and keep it up to date. On request you have 30 days to produce it — and Art 37(4) provides that if you do not, the market surveillance authority may require a test by an independent body at your own expense. That is the only route by which third-party testing can be forced on an EHR system manufacturer.

**What you do**

- Review the generated Annex III draft. Everything Annexbase holds is filled in; everything else is marked with the Annex III point it belongs to.
- Write the parts only you can write: the general description, the design and development information, and the risk management file.
- Reference the digital testing environment result — Art 37(2) requires the documentation to contain it.
- Plan for Art 30(3): retain the file for 10 years after the last covered system was placed on the market, and be ready to make source code or programming logic available on reasoned request.

**Done when:** The Annex III draft carries no unresolved TODO markers and references a DTE result.

**Where people go wrong**

- The 30-day clock in Art 37(4) starts when the authority asks, not when you start writing. A file compiled reactively is a file compiled late.

### 6. Produce the Article 38 information sheet

*Art 38(1)–(3) · Art 28 · Art 30(1)(d)*

The sheet accompanies the system for professional users and must be concise, complete, correct and clear. Article 28 turns it into a liability surface: it may not ascribe functions the system does not have, nor fail to inform of likely limitations related to interoperability or security. The same rule binds your advertising.

**What you do**

- Review the generated sheet against the Art 38(2) items (a) to (e).
- State the limitations honestly. Omission is itself an Art 28 infringement, not merely a gap.
- Choose the delivery route: supply the sheet with the system, or enter the information into the Art 49 EU database instead (Art 38(3)).
- Supply it free of charge, together with clear and complete instructions for use, in accessible formats (Art 30(1)(d)).

**Done when:** The sheet is reviewed, limitations are stated, and a delivery route is chosen.

**Where people go wrong**

- Article 28 reaches your website and your sales deck, not only the manual. Marketing copy that overstates interoperability is an infringement in its own right.

### 7. Draw up the Annex IV declaration of conformity

*Art 39 · Annex IV · Art 30(3)*

The declaration is the act of self-certification: you state on your sole responsibility that the Annex II essential requirements are fulfilled. Annex IV point 4 hard-couples it to a testing-environment result — the declaration cannot lawfully be completed without one.

**What you do**

- Complete the manufacturer identity block from your company profile. It must be the legal identity, not the trading name alone.
- Enter the digital testing environment result reference. Annexbase keeps the draft marked DRAFT until it exists.
- Translate into the languages required by the Member States where the system is placed on the market.
- Sign, date, and retain for 10 years alongside the technical documentation (Art 30(3)).

**Done when:** A DTE result is referenced and the declaration is signed by someone able to bind the manufacturer.

**Where people go wrong**

- The DRAFT marker on a declaration with no DTE reference is a safety feature. Do not strip it to make a deadline — an unfounded declaration is an Art 45(1)(c) finding.

### 8. Register in the EU database

*Art 49(1)–(2) · Art 31* · Tooling exists: European Commission EU database for EHR systems and wellness applications

Before placing on the market or putting into service, the manufacturer or the authorised representative enters the required data into the public EU database — including, for EHR systems, the results of the Article 40 assessment.

**What you do**

- Export the submission set from Annexbase and reconcile it against the portal's fields.
- Register before placing on the market, not after. Failure to register is an enumerated Art 45(1)(e) non-compliance finding.
- If you are established outside the Union, appoint an authorised representative by written mandate first (Art 31) — they are jointly and severally liable under Art 31(4).
- Record the registration reference here so it flows into your technical file.

**Done when:** The registration is submitted and its reference is recorded.

**Where people go wrong**

- The exact data list is to be set by delegated act under Art 49(4) and is not yet published. Treat the export as a working set, not a final schema.

### 9. Affix the CE marking

*Art 30(1)(f) · Art 41(1)–(3) · Reg (EC) No 765/2008 Art 30*

For software the marking goes on the accompanying documents, and on the packaging where applicable — affixed visibly, legibly and indelibly, before the system is placed on the market. It is the manufacturer's own indication of conformity; there is no notified body anywhere in Chapter III.

**What you do**

- Affix the marking to the accompanying documents (Art 41(1)); a software-only product has no physical mark.
- Do it before placing on the market (Art 41(2)). The general principles in Art 30 of Regulation (EC) No 765/2008 apply (Art 41(3)).
- Record where the marking appears and attach the marked document.
- Do not affix it before steps 3 to 7 are complete — a marking affixed in breach of Art 41 is an Art 45(1)(d) finding.

**Done when:** The marked accompanying document is attached and the placing-on-market date is recorded.

**Where people go wrong**

- There is no notified body number under EHDS. A four-digit number beside the mark would be a claim you cannot support.

### 10. Keep the documentation current

*Art 37(1) · Art 30(2) · Art 30(3) · Art 30(1)(n)–(o) · Art 44(7)*

Article 30(2) requires procedures that keep design, development and deployment in continuing compliance, with every change to the harmonised components reflected in the technical documentation. It names deployment, not just development — for SaaS that reaches your production change control. This obligation never ends.

**What you do**

- Log every release here. The change log is Annex III point 1(i) and the raw material for step 11.
- Keep the technical documentation and the declaration for 10 years after the last covered system was placed on the market (Art 30(3)).
- Stand up the Art 44(7) incident path now: serious incidents are reportable within three days of becoming aware, to the market surveillance authorities of every Member State where the system is placed on the market.
- Keep the Art 30(1)(n) complaint channel open and the Art 30(1)(o) registers of complaints and non-conforming systems current.

**Done when:** Continuous. At least one change-log entry exists and an owner is named for retention and incident reporting.

**Where people go wrong**

- 'Serious incident' under Art 2(2)(r) includes serious prejudice to a natural person's rights. An access-control or data-rights bug can be reportable within three days — that is far broader than a safety defect.

### 11. Reassess on significant change

*Xt-EHR D8.2 step 11 · Commission FAQ Q27 · Art 30(2)*

Reassessment is required for a substantial change — one that modifies the original intended functions, type or performance in a way unforeseen in the initial risk assessment, changes the nature of a hazard, or increases the risk level. Bug fixes, security patches and user-interface changes are exempt. Somebody has to make and defend that judgement on every release, with a dated trail.

**What you do**

- Mark each logged change significant or not, and record the reasoning at the time — not in hindsight.
- On a significant change, re-run the scope, re-test in the DTE, update Annex III and re-issue the declaration.
- Keep the negative decisions too. The trail of releases judged not significant is what makes the ones judged significant credible.
- Note that Art 30(2) requires all changes to the harmonised components to be reflected in the technical documentation, whether or not they trigger reassessment.

**Done when:** Every logged change carries a significance decision with reasoning.

**Where people go wrong**

- The substantial-change boundary is undefined pending guidance. Document your reasoning against the FAQ Q27 criteria so that a defensible judgement exists even if the line later moves.

## What nobody knows yet

- **Art 36 common specifications adopted** (due 2027-03-26) — Large. Every provisional mapping becomes testable against a normative specification, and conformity with the common specifications carries a presumption of conformity under Art 36(4). Expect the assertion split between automatable and manual to move. The date is fixed by the Regulation; whether the Commission meets it is not.
- **Art 49(4) delegated act on registration data** (no published date) — Moderate. Fixes the field list for EU database registration, which today Annexbase can only approximate. No published timetable.
- **Commission uniform template for Annex III technical documentation** (no published date) — Moderate. Recital 36 says the Commission should prepare one. Our generator follows Annex III point by point, so adoption is a restructure, not a rewrite. Recital only — no obligation and no date.
- **Art 15 EEHRxF specifications** (no published date) — Large for sections 2.1 and 2.2. Fixes the normative exchange format that the HL7 Europe implementation guides currently stand in for. Implementing acts foreseen; no published date.

And the biggest one: no market surveillance authority has yet examined an EHDS technical file,
because enforcement has not started. Nobody can tell you with certainty what a sufficient file
looks like.

## Known limits of this guide

- Common specifications under Art 36 are NOT YET ADOPTED. Implementing acts due by 26 Mar 2027. Every mapping below is provisional until they land.
- Article numbering is inconsistent across secondary sources. Verify against consolidated EUR-Lex before customer-facing use.
- Annex II chapeau applies these requirements mutatis mutandis to medical devices, IVDs, AI systems and wellness applications claiming interoperability. Art 27 cross-references only Section 2 — there is genuine textual tension. Cautious manufacturers should design to the whole Annex.

---

Annexbase provides tooling for the nine of these eleven steps that have no tooling anywhere. It
is not a digital testing environment and issues no conformity result, it is not legal advice, and
it never stores patient data. The requirements corpus behind this guide is published in full at
https://www.annexbase.com/corpus with sources and a confidence tag on every interpretation.

Free scope check: https://www.annexbase.com/scope