Technical documentation
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 FerroEHR release, keeps that
documentation in the repository, in
docs/technical-documentation/:
one file per Annex III element and per CRA Annex VII point that adds one, each
linking its evidence. The tree as it stands at a release tag is that release’s
documentation. This page maps each Annex III element to its file and to the
published material it cites. It covers FerroEHR’s part of the EHR system, the
logging component and the system-level requirements; FerroBRIDGE documents the
interoperability component.
- Annex III, element by element
- What CRA Annex VII adds
- Test evidence
- Declaration of conformity
- Keeping it current, keeping it for ten years
- Related
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 the tree, 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.3.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 annex-iii-1-description.md.
| # | 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 | — |
| 1(c) | How it interacts with hardware or software that is not part of it. | Available | what exists | — |
| 1(d) | Versions of relevant software or firmware, and update requirements. | Available | what exists | — |
| 1(e) | Every form in which it is placed on the market or put into service. | Available | what exists | — |
| 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 | — |
| 1(h) | Technical specifications, variants, configurations. | Available | what exists | — |
| 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 | — |
2. The system in place to evaluate the EHR system’s performance
Documented in annex-iii-2-performance-evaluation.md.
| # | 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 annex-iii-3-common-specifications.md.
| # | Element | State | Material | Notes |
|---|---|---|---|---|
| 3 | Common specifications under Article 36 against which conformity is declared. | Missing | — | 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 annex-iii-4-verification-and-validation.md.
| # | 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 annex-iii-5-information-sheet.md.
| # | 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 annex-iii-6-declaration-of-conformity.md.
| # | Element | State | Material | Notes |
|---|---|---|---|---|
| 6 | The declaration required by Article 39. | Missing | — | No declaration has been drawn up: the Article 36 common specifications and the Article 40 testing environment it would rest on are not available. |
What CRA Annex VII adds
CRA Annex VII asks for four things Annex III does not, each with its own file in the tree: the design, development and vulnerability-handling processes with the software bills of materials (point 2), the cybersecurity risk assessment (point 3), the information taken into account to set the support period (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 the 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 the
conformance pages) and the tests the hazard log names for
each control of the logging component.
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 #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 release whose changes touch a module of the logging component updates the documentation tree in the same release, and the release procedure refuses the release otherwise.
- Retention (Article 30(3)). The tree is part of the signed release tag,
which cannot be deleted or moved, and of the source archive each release
deposits with Zenodo; the book pages it cites are frozen with each release at
/docs/vX.Y.Z/. - 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
- EHDS readiness: the status per Annex II requirement.
- Cyber Resilience Act: FerroEHR’s CRA position.
- Shared responsibility, in the FerroHEALTH book: which duties belong to the deployment.