The EHDS EHR system: technical documentation
Revised 2026-10-28.
Article 37 of the EHDS regulation requires a manufacturer to draw up technical documentation before an EHR system is placed on the market or put into service, and to keep it up to date. Article 37(2) says it must contain at least the elements of Annex III, and a reference to the results of the European digital testing environment of Article 40. From 11 December 2027 the same documentation carries the content of CRA Annex VII (CRA Art. 31(3) as EHDS Article 104 replaces it).
Cadasto B.V., the manufacturer of each tagged release of FerroEHR and of
FerroBRIDGE, keeps the Annex III elements in this book, one page per element,
each linking its evidence, and each product’s CRA Annex VII points in that
product’s repository (FerroEHR’s in
docs/technical-documentation/).
Each release pins the revision of these pages it relies on, by the date on the
page. This page maps each Annex III element to its page and to the published
material it cites. The element pages cover FerroEHR’s part of the EHR system,
the logging component and the system-level requirements; FerroBRIDGE
documents the interoperability component with its own releases.
Warning
The documentation is incomplete: element 3 and element 6 cannot be written yet, and element 4 lacks the testing-environment results. No EU declaration of conformity exists. An “Available” row below means the material the element asks for is written and cited from its page, not that any authority has examined it.
Regulation (EU) 2025/327 of the European Parliament and of the Council of 11 February 2025 on the European Health Data Space and amending Directive 2011/24/EU and Regulation (EU) 2024/2847, OJ L series, 2025/327, 5 March 2025. Read on 2026-10-06; the regulation governs and the summaries here are this project’s paraphrase.
Annex III, element by element
1. A detailed description of the EHR system
Documented in A detailed description of the EHR system.
| # | Element | State | Material | Notes |
|---|---|---|---|---|
| 1(a) | Intended purpose, date and version. | Available | what exists | FerroEHR’s part of the statement of intended purpose is versioned with the book, which is frozen per release; the version and release date are each release’s tag and changelog heading. The statement for the EHR system as a whole is in the FerroHEALTH book (https://ferrohealth.eu/docs/ehds/intended-purpose.html). |
| 1(b) | The categories of personal electronic health data it processes. | Available | what exists | none |
| 1(c) | How it interacts with hardware or software that is not part of it. | Available | what exists | none |
| 1(d) | Versions of relevant software or firmware, and update requirements. | Available | what exists | none |
| 1(e) | Every form in which it is placed on the market or put into service. | Available | what exists | none |
| 1(f) | The hardware it is intended to run on. | Partial | what exists | The instructions for use name the platforms, the chart’s resource defaults and the database; the measured deployment classes state the environment each ran on. No minimum hardware specification is published. |
| 1(g) | The system architecture, and how the components integrate. | Available | what exists | none |
| 1(h) | Technical specifications, variants, configurations. | Available | what exists | none |
| 1(i) | A description of every change through the lifecycle. | Available | what exists | The changelog of every release, and the revision table of the documentation tree. |
| 1(j) | Instructions for use and, where applicable, for installation. | Available | what exists | none |
2. The system in place to evaluate the EHR system’s performance
Documented in The system in place to evaluate the EHR system’s performance.
| # | Element | State | Material | Notes |
|---|---|---|---|---|
| 2 | Where applicable, how performance is evaluated. | Available | what exists | Performance is measured by an independent instrument in open-loop, coordinated-omission-free runs, and the records are committed. |
3. References to the common specifications used
Documented in References to the common specifications used.
| # | Element | State | Material | Notes |
|---|---|---|---|---|
| 3 | Common specifications under Article 36 against which conformity is declared. | Missing | none | The implementing acts that set the Article 36 common specifications have not been adopted. Nothing can reference them yet. |
4. Verification and validation results
Documented in Verification and validation results.
| # | Element | State | Material | Notes |
|---|---|---|---|---|
| 4 | Results and critical analyses of the tests demonstrating conformity. | Partial | what exists | The openEHR conformance record and the hazard log’s named tests are committed. They show conformity to the openEHR specifications and the controls of the logging component, which is a different claim from conformity to Annex II; the European digital testing environment of Article 40, whose results Article 37(2) asks for, is not published. |
5. A copy of the information sheet
Documented in A copy of the information sheet.
| # | Element | State | Material | Notes |
|---|---|---|---|---|
| 5 | The information sheet required by Article 38. | Available | what exists | Published with the book of each release and attached to each GitHub release. |
6. A copy of the EU declaration of conformity
Documented in A copy of the EU declaration of conformity.
| # | Element | State | Material | Notes |
|---|---|---|---|---|
| 6 | The declaration required by Article 39. | Missing | none | No declaration has been drawn up: the Article 36 common specifications and the Article 40 testing environment it would rest on are not available. A draft, unsigned and marked as declaring nothing, lays out the Annex IV and CRA Annex V points with the facts that exist and the statements that are not made. |
What CRA Annex VII adds
CRA Annex VII asks for four things Annex III does not, each with its own file in each product’s repository: the design, development and vulnerability-handling processes with the software bills of materials (point 2), the cybersecurity risk assessment (point 3, FerroEHR’s), the information taken into account to set the support period, the five-year commitment to publish security fixes (point 4), and the standards applied or the solutions adopted in their place (point 5). The hazard log is the EHDS-side assessment of the logging component, which CRA Art. 13(4), as EHDS Article 104 amends it, lets the cybersecurity risk assessment be part of.
Test evidence
Element 4 asks for the results of the verification and validation tests. What
exists is FerroEHR’s openEHR conformance record (an independent instrument’s
runs against a composed deployment, with the results, verdicts and the
statement committed under docs/conformance/ and published on its
conformance pages), the
tests the hazard log names for each control of the logging component, and the
round-trip tests FerroBRIDGE names for each mapping on its EHDS readiness
page.
The conformance record demonstrates conformity to the openEHR specifications. Conformity to Annex II is a different claim against a different yardstick. The European digital testing environment of Article 40, whose results Article 37(2) asks the documentation to reference, is not published; running it is tracked in FerroEHR#3620.
Declaration of conformity
Article 39 requires an EU declaration of conformity stating that the essential requirements of Annex II are met, and Annex IV sets out what it contains, including the common specifications applied and the result of the Article 40 testing environment. No declaration has been drawn up. The common specifications of Article 36 have not been adopted, the testing environment is not published, and the exchange format the interoperability component must carry waits on implementing acts under Article 15(1). Chapter III applies to EHR systems from 26 March 2029 (Article 105).
When a declaration is drawn up, Cadasto B.V. draws it up for the EHR system, FerroEHR and FerroBRIDGE together, as one declaration for the EHDS and the CRA. It is published online for each release it covers, for at least ten years (Article 39(4)), and kept with the documentation for ten years after the system covered is placed on the market (Article 30(3)).
Keeping it current, keeping it for ten years
- Change control (Article 30(2)). A FerroEHR release whose changes touch a module of the logging component updates its technical documentation, or the revision of these pages it pins, in the same release, and its release procedure refuses the release otherwise.
- Retention (Article 30(3)). Every revision of these pages stays in the history of this book, and a release names the revision it relies on by its date. Each product’s own documentation is part of its signed release tag, and its book is frozen with each release.
- Translation (Article 37(3) and (4)). The documentation is written in English. A market surveillance authority that asks, with reasons, for a translation of parts of it into an official language of its Member State writes to info@cadasto.com, and Cadasto B.V. provides the translation within 30 days of the request, or sooner where a serious and immediate risk justifies it.
Related
- Readiness: the status per Annex II requirement.
- The Cyber Resilience Act: the manufacturer’s CRA position.
- Shared responsibility: which duties belong to the deployment.