EHDS readiness
The European Health Data Space regulation puts obligations on EHR systems in its Chapter III: an EHR system must include two harmonised software components, meet the essential requirements of Annex II, and carry technical documentation and an EU declaration of conformity before it is placed on the market or put into service.
This page states, requirement by requirement, what FerroEHR provides today. It exists so an evaluator can see the real position rather than infer one, and so the project has a checklist rather than an intention.
Warning
No conformity assessment has been carried out. No technical documentation has been drawn up under Article 37, no EU declaration of conformity exists under Article 39, and FerroEHR is not registered under Article 49. A status of “Shipped” below means the software provides the capability — it is not a claim of conformity, and nothing on this page is one.
The regulation, and how to check this page against 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.
Every requirement identifier, heading and date on this page was read from that published text on 2026-09-10. The wording in the “Requirement” column is this project’s own paraphrase for navigation; the regulation is the authority and its text governs. Where the two differ, the regulation is right and this page is a defect worth reporting.
When it applies
- 26 March 2027 — The Regulation applies from this date.
- 26 March 2029 — Articles 25, 26, 27, 47, 48 and 49 apply to the priority categories of personal electronic health data in Article 14(1)(a), (b) and (c), and to EHR systems the manufacturer intends to process them.
- 26 March 2031 — The same articles apply to the categories in Article 14(1)(d), (e) and (f), and Chapter III applies to EHR systems put into service in the Union as described in Article 26(2).
The last of those matters most here: a deployment that a health institution runs for itself, or that is offered as a service, is put into service under Article 26(2) rather than placed on the market.
The two harmonised software components
Article 25(1) requires an EHR system to include both.
| Component | Status | Where it stands |
|---|---|---|
| European interoperability software component for EHR systems | Planned (#3171) | The requirements this component carries are Annex II 2.1 to 2.3: an interface that provides and receives personal electronic health data in the European electronic health record exchange format. FerroEHR serves the openEHR ITS-REST surface and an optional FHIR façade; neither is that format, and the format’s own content is set by implementing acts under Article 36. |
| European logging software component for EHR systems | Partial (#3170) | Annex II 3.2 lists five things every access event must record. The access-event model records the agent, the subject, the object and its domain, the outcome, the purpose and the time, and the audit trail is retrievable. Whether each of the five maps onto a field without a gap is the mapping #3170 exists to establish. |
Annex II — the essential requirements
The identifiers are the Annex’s own. “Evidence” links what a reader can check for themselves; “Gap” says what is missing when a row is not complete.
1. General requirements
| # | Requirement (our paraphrase) | Status | Evidence | Notes |
|---|---|---|---|---|
| 1.1 | The components achieve the performance the manufacturer intended and are suitable for their intended purpose in normal use, without putting patient safety at risk. | Open question | — | Question: The requirement is a claim by a manufacturer about an intended purpose. FerroEHR is source-available software rather than a placed product, so who the manufacturer is depends on who puts a deployment into service — the question #3168 has to answer before this can be a status rather than a question. Tracked in #3168 |
| 1.2 | The components can be supplied and installed following the manufacturer’s instructions without adversely affecting their characteristics and performance. | Partial | Deployment artifacts and their documented installation | Gap: The artifacts and their instructions exist and a deployment probe reads the running stack back. What does not exist is the manufacturer’s declared intended purpose those characteristics would be measured against. |
| 1.3 | Interoperability, safety and security features uphold the rights of natural persons in line with the intended purpose, as set out in Chapter II. | Partial | The rights the software can serve, and who must serve the rest | Gap: Chapter II rights are largely a deployment’s duty rather than a product’s. The shared-responsibility page states which side each one falls on; the patient-facing access route is not built. |
| 1.4 | Components intended to operate with other products, including medical devices, are designed so interoperability and compatibility are reliable and secure and data can be shared with the device. | Open question | — | Question: FerroEHR claims no interoperability with a medical device. If a deployment claims it, Article 27 puts that claim’s requirements on the party making it. |
2. Requirements for interoperability
| # | Requirement (our paraphrase) | Status | Evidence | Notes |
|---|---|---|---|---|
| 2.1 | A system that stores or intermediates personal electronic health data provides an interface giving access to it in the European electronic health record exchange format, through the European interoperability software component. | Planned | Which priority categories round-trip through the FHIR façade | Tracked in #3171, #3206 |
| 2.2 | Such a system can receive personal electronic health data in that format, through the same component. | Planned | — | Tracked in #3171 |
| 2.3 | A system designed to provide access to personal electronic health data can receive it in that format, through the same component. | Planned | — | Tracked in #3171 |
| 2.4 | A system that lets a user enter structured personal electronic health data allows entry with enough granularity to provide it in the exchange format. | Partial | Templates and the archetype-constrained entry model | Gap: openEHR templates constrain entry to the archetype’s granularity, which is finer than any exchange format is likely to require. That the granularity SUFFICES for the European format cannot be shown until the format is set by implementing act. |
| 2.5 | The components include no feature that prohibits, restricts or unduly burdens authorised access, sharing or permitted use. | Shipped | The query surface over the whole stored record; Authorisation refuses or permits; it adds no commercial gate | — |
| 2.6 | The components include no feature that prohibits, restricts or unduly burdens exporting the data in order to replace the system with another product. | Shipped | Whole-repository dump and load; EHR-Extract export | — |
3. Requirements for security and logging
| # | Requirement (our paraphrase) | Status | Evidence | Notes |
|---|---|---|---|---|
| 3.1 | A system used by health professionals provides reliable identification and authentication of them. | Shipped | Basic and OAuth2/OIDC authentication | — |
| 3.2 | The European logging software component records, for every access event or group of events, at least the healthcare provider or other individuals who accessed the data, the specific natural person or persons who accessed it, the categories of data, the time and date, and the origin of the data. | Partial | The five elements mapped onto fields, gaps included | Gap: Points (b) and (d) are recorded and reach both renderings. Point (c) is partial, because the record names an openEHR resource class and a pseudonymisation domain rather than an Annex I priority category. Points (a), the accessing organisation, and (e), the origin of the data, have no field at all, and the declared purpose of use reaches neither export. Each gap is asserted by a test that fails when it closes. Tracked in #3170 |
| 3.3 | The components include tools or mechanisms to review and analyse the log data, or support connecting external software that does. | Shipped | Audit retrieval (IHE ATNA ITI-81) and the syslog and FHIR feeds | — |
| 3.4 | Components that store personal electronic health data support different retention periods and access rights that take the origin and category of the data into account. | Partial | Per-EHR access control and the audit retention setting | Gap: Access rights are per EHR, per role and per attribute, and audit retention is configurable. Retention that varies by the ORIGIN or CATEGORY of clinical data is not implemented; the archival tier moves records without expiring them. |
Open questions
These decide whether Chapter III applies to a given deployment at all, and to whom. They are questions this project has not answered, stated as questions.
- Who is the manufacturer of a FerroEHR deployment? FerroEHR is source-available software, not a product placed on the market. Article 26(2) treats an EHR system manufactured and used within a health institution, and one offered as a service, as put into service — which puts the manufacturer’s duties on the party doing that rather than on the project. Tracked in #3168.
- Article 25(2) excludes general purpose software used in a healthcare environment from Chapter III. A clinical data repository is not general purpose software, so the exclusion is unlikely to apply, but the line has not been drawn by guidance yet. Tracked in #3168.
- The European electronic health record exchange format is set by implementing acts under Article 36 that have not been adopted. Until they are, requirements 2.1 to 2.3 name a format with no content, and what the interoperability component must emit cannot be built to a specification. Tracked in #3171.
Related
- Technical documentation readiness — the Annex III elements, and what exists for each.
- Shared responsibility — which duties the software can carry and which belong to the deployment.
- Control matrix — the legal controls the tracker declares, generated from the tracker.