Free guide · updated 2026-08-30
The EHDS Vendor Roadmap
Everything a manufacturer of health software has to do to keep selling it in Europe after March 2029 — what the law asks for, in what order, and what each step actually costs you. No email required, nothing held back.
Written against Regulation (EU) 2025/327 as published in the Official Journal. Every claim traces to a source, and the parts nobody has decided yet are marked as such rather than smoothed over. Annexbase sells software for this; the guide works whether or not you buy it.
Five things to know before you read anything else
Most of what is written about the European Health Data Space is either a law-firm summary of the text or a vendor scaring you. These five facts change how big the problem looks, and they are all verifiable.
You almost certainly do not have to rewrite your product.
The European format is a boundary format. The Commission's own FAQ states there is no requirement for EHR systems to use it internally. You keep your database, your data model and your product, and you translate at the edge — in and out. This is the single most reassuring fact in the whole regulation and the least known.
Only two parts of your product are regulated.
A European interoperability component and a European logging component. Nothing else in your system is harmonised by this regulation. The catch: the law requires the two to be independent of each other, which is an architectural constraint you have to be able to demonstrate, not just assert.
There is no auditor. You certify yourself.
No notified body, no certification body, no external assessment anywhere in the regulation's chapter on EHR systems. You assess your own product, write your own file, sign your own declaration and affix your own CE mark. That sounds easier than a third-party audit. It is not: with an auditor, someone tells you when you have enough evidence. Here nobody does.
One date matters more than the others.
2029-03-26 — patient summaries, electronic prescriptions and dispensations. If your system touches any of those three, that is your date. Imaging, test results and discharge reports follow on 2031-03-26, along with systems built in-house by health institutions.
Your own industry says this takes four to five years.
In a joint submission to the Commission, COCIR and MedTech Europe put their members' cycle at roughly two years to build a change of this kind and a further two to three to deploy it. Measured against 2029-03-26, that window is already narrower than the calendar. This is the argument for starting now rather than in 2028.
Are you in scope?
Work through these in order. If you answer yes to the first and yes to any part of the second, you are a manufacturer of an EHR system under this regulation and the whole obligation set applies to you.
Does your software handle any of these data categories?
| 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 it do any of these things 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
Four ways people wrongly conclude they are out of scope
- “We are not established in the EU.” Software offered as a service to anyone established in the Union is treated as put into service there, wherever you sit. You will also need to appoint an EU authorised representative, who becomes jointly and severally liable alongside you.
- “We built it for ourselves, we do not sell it.” Systems built and used inside a health institution are deemed put into service. The institution is the manufacturer, on the 2031-03-26 timeline.
- “We are a medical device, we are covered by MDR.” Partly. If you claim interoperability with EHR systems you must additionally prove conformity with the interoperability requirements. You keep your own regime otherwise.
- “We only convert data, we are not an EHR.” A converter that handles priority-category data and is intended for healthcare use is itself an EHR system, and needs its own CE mark.
Check your exact requirements free →
What you have to produce, and what happens if you cannot
Six artefacts. Five of them are documents; one is a test result you cannot generate yourself.
| What | Where it comes from | The teeth |
|---|
| Technical documentation (Annex III) | You write it. Ten prescribed sections. | 30 days to produce on request. Fail and the authority may require a test by an independent body at your expense. |
| A testing environment result | A free, state-run digital testing environment. Not you. | Mandatory before market. Your declaration cannot lawfully be completed without it. |
| Information sheet (Art 38) | You write it, for professional users. | Overstating functions or hiding interoperability limits is an infringement — and it binds your advertising too. |
| EU declaration of conformity (Annex IV) | You sign it, on your sole responsibility. | Not drawn up correctly is an enumerated non-compliance finding. |
| EU database registration | Commission portal, before you go to market. | Also an enumerated finding if missed. |
| CE marking | You affix it, to the accompanying documents. | Affixed in breach, or not affixed, is a finding. There is no notified body number. |
The obligations that never end
- Ten years of retention for the file and declaration after the last unit is placed on the market — plus source code or programming logic to authorities on a reasoned request.
- Three days to report a serious incident, to every Member State where you sell, counted from when you became aware. “Serious incident” includes serious prejudice to a person's rights, so an access-control defect can qualify.
- Every release needs a judgement on whether the change is significant enough to require re-testing and re-declaration — defensible years later, with a dated trail.
- Documented procedures keeping design, development and deployment in continuing compliance. For SaaS that reaches your production change control.
The eleven steps
This is the conformity assessment workflow proposed by Xt-EHR deliverable D8.2, the joint action of Member State authorities that has published the most concrete picture of how self-certification will run. It is a recommendation feeding the Commission's process, not binding law — but it is the best forward indicator available, and the shape is unlikely to change much.
1Determine 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.
2Prepare 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.
3Run the automated tests
Art 40(1)–(3) · presumption of conformity Art 40(3) and Art 36(4)
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.
4Evidence 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.
5Compile 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.
6Produce 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.
7Draw 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.
8Register in the EU database
Art 49(1)–(2) · Art 31
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.
9Affix 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.
10Keep 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.
11Reassess 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.
Working backwards from 2029-03-26
If patient summaries or prescriptions are in your product, here is the schedule that actually fits. It assumes you are not starting from a standing start on FHIR, and that you have one engineer who can be given to this part-time.
- Now — end 2026Determine scope and stop guessing. Get one example patient summary out of your system in the European format, however ugly, and validate it. You are looking for the size of the gap, not a finished product.
- 2027, first halfThe Commission's common specifications are due 2027-03-26. Re-scope against them when they land. Start the architecture work that separates your interoperability and logging components — this is the long pole and it is not a documentation task.
- 2027, second halfBuild the boundary layer properly. Begin recording evidence with pinned tool versions from the first run, not retrospectively. Stand up your quality procedures — D8.2 recommends ISO 9001, or ISO 13485 if you are already an MDR manufacturer.
- 2028First real engagement with a digital testing environment. Failed tests are private and only successful reports have to be disclosed, so iterate freely. Begin the technical file in parallel — not after.
- 2028, second halfDeploy to your installed base. This is the part vendors underestimate: clinics upgrade slowly, and a conforming version nobody has installed does not help you.
- By 2029-03-26Testing environment result in hand, technical file complete, information sheet supplied, declaration signed, registered in the EU database, CE mark affixed.
What to do in the next ninety days
Five things, none of which need a budget approval.
- Establish scope in writing. Which categories, which roles, which deadline. One page. Everything else depends on it and it takes an afternoon.
- Name an owner. Not a committee. One person who will still be there in 2029 and can be asked what the current state is.
- Get one artefact through a validator. One patient summary, structurally valid. It converts an abstract obligation into a known engineering distance.
- Check the independence constraint. Look at your architecture and ask honestly whether your logging could be described as independent of your interoperability layer. If not, that is your longest lead item, and it is better to know now.
- Start dating things. Every decision you make about what a requirement means, write down with the date and the reasoning. In 2029 this trail is the difference between a defensible file and an assertion.
What nobody knows yet
Anyone who tells you this is all settled has not read it carefully. These are open, and we publish them because a guide that hides its own uncertainty is worth less than one that does not.
Art 36 common specifications adopteddue 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 datano 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 documentationno 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 specificationsno 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.
There is one more, and it is the biggest: no market surveillance authority has yet examined an EHDS technical file, because enforcement has not started. Nobody — us included — can tell you with certainty what a sufficient file looks like. What we can tell you is that a reproducible, version-pinned, dated file is a better position than a folder of PDFs, and that the trail of decisions matters as much as the conclusions.
Where Annexbase fits, stated plainly
Step 3 runs in a free, state-run testing environment and step 8 in the Commission's portal. We do not compete with either. The other nine steps have no tooling in existence, and that is what we sell: scope determination, the guided workflow, reproducible evidence with pinned tool versions, and the generated technical file, information sheet and declaration — kept current as the regulation moves.
We are not a testing environment and issue no conformity result. We are not legal advice. We never store patient data. And the requirements corpus this guide is built from is published in full, with sources and a confidence tag on every interpretation, so you can audit the reading before you trust it.
Corrections welcome — if you think we have read something wrong, we would rather know. Article numbering for this regulation is reproduced inconsistently across secondary sources; verify against consolidated EUR-Lex before relying on any citation, including ours.