Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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.

Cadasto B.V. is the manufacturer of each tagged FerroEHR release, and the EHR system it declares is FerroEHR and FerroBRIDGE together: FerroEHR ships the European logging software component, FerroBRIDGE the European interoperability software component. This page states, requirement by requirement, what FerroEHR provides today, and names FerroBRIDGE where a requirement is its part. The documentation of the EHR system as a whole, its intended purpose and the split of duties with the deploying organisation, is in the FerroHEALTH book (intended purpose, shared responsibility).

Warning

No conformity assessment has been carried out. The technical documentation of Article 37 is being drawn up and still lacks elements (see Technical documentation), 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 the Official Journal text vendored in the repository at docs/law/eu/ehds/text.html on 2026-10-06. 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 reaches a deployment that a health institution runs for itself, or that is offered as a service: Article 26(2) treats both as put into service. An organisation that runs an unmodified FerroEHR release for itself puts Cadasto B.V.’s product into service and does not become the manufacturer. Where Cadasto B.V. hosts FerroEHR as a service for a customer, it is the manufacturer and the operator of that deployment.

The two harmonised software components

Article 25(1) requires an EHR system to include both. Each is shipped by one product of the EHR system Cadasto B.V. declares.

ComponentStatusWhere it stands
European interoperability software component for EHR systemsOpen questionShipped by FerroBRIDGE, the other product of the EHR system Cadasto B.V. declares, which holds the mappings from openEHR to the European electronic health record exchange format and reads FerroEHR over ITS-REST. The format itself is set by implementing acts under Article 15(1) that have not been adopted, so no component can emit it yet. FerroEHR itself carries no FHIR mapping.
European logging software component for EHR systemsPartialShipped by FerroEHR: the access-event model, the audit store with its hash chain and the scheduled verification of that chain, the DICOM and FHIR renderings and the sinks, the middleware that records and classifies every API access, the ITI-81 retrieval, and the retention register. All five Annex II 3.2 elements are recorded, and every access record outside the demographic domain carries a category; a token that names a client application is recorded as that client, together with the professional it acts for when the deployment declares the claim that names one. The central store and review of the log are planned to move to FerroSYS in a later release.

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, and the issue that closes it where one exists.

1. General requirements

#Requirement (our paraphrase)StatusEvidenceNotes
1.1The components achieve the performance the manufacturer intended and are suitable for their intended purpose in normal use, without putting patient safety at risk.PartialThe manufacturer’s intended-purpose statement for the EHR system; FerroEHR’s part of it; The hazard log of the logging componentGap: Cadasto B.V. states the intended purpose, and the hazard log assesses the logging component against it in normal conditions of use, each hazard with its control and the test that shows it. H9, an emergency access to data restricted under EHDS Art. 8, is controlled by the emergency mark; the Art. 8 restriction itself is planned. The interoperability component’s assessment is FerroBRIDGE’s. The Regulation names no method for showing performance or safety, and no conformity assessment has examined either. Tracked in #3682
1.2The components can be supplied and installed following the manufacturer’s instructions without adversely affecting their characteristics and performance.PartialThe instructions for use; Deployment artifacts and their documented installation; The chart’s production overlayGap: The instructions for use set the production profile, which refuses to start while a separation is missing, and point a Kubernetes installation at the chart’s values-production.yaml: it sets production, makes every separation a values file can make, and accepts plaintext_listener by name behind a TLS ingress. The chart’s validation renders it and asserts each separation, and its boot check has the server evaluate the posture from the rendered configuration. Separate database clusters, which the server measures over live connections, are judged by no check before the first boot against the operator’s databases. The chart and the Compose files still declare sandbox by default, so an installation that follows the quickstart instead of the instructions runs the sandbox posture, which must not hold real personal data; the server says so on every boot and on GET /ferroehr/rest/status. Tracked in #3692
1.3Interoperability, safety and security features uphold the rights of natural persons in line with the intended purpose, as set out in Chapter II.PartialThe rights the software can serve, and who must serve the rest; One patient’s access log, through a subject-scoped grantGap: Most Chapter II rights are served through the electronic health data access services Member States establish (Art. 4(1)) and through the deploying organisation; the shared-responsibility page of the FerroHEALTH book says which side each falls on. An access declared with an agreed emergency purpose code is marked in its access record and shown to the person through the subject-scoped retrieval, as Art. 11(5) asks (emergency access); the mark lifts no restriction. FerroEHR does not yet hold the Art. 8 restriction of access by health professionals, so a Member State access service or the deploying organisation enforces it. Tracked in #3682
1.4Components 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.PartialThe access log’s IHE ATNA transactions and mutual TLS; Medical device purposes are outside the intended purposeGap: The logging component works with other products through IHE ATNA: ITI-20 feeds, ITI-81 retrieval, ITI-19 mutual TLS. The syslog feed ships with UDP transport when switched on, which delivers no record reliably and encrypts none, so deployment_profile = "production" refuses it unless audit_syslog_udp is accepted by name; TLS syslog and the outbox-driven FHIR feed are the reliable choices, and the instructions for use name them. FerroEHR claims no interoperability with a medical device; a device manufacturer that claims it carries Art. 27(1).

2. Requirements for interoperability

#Requirement (our paraphrase)StatusEvidenceNotes
2.1A 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.Open questionThe interoperability component is FerroBRIDGE’s part of the systemQuestion: This requirement is carried by FerroBRIDGE, which ships the interoperability component of the EHR system and reads FerroEHR over ITS-REST. The exchange format is set by implementing acts under Art. 15(1) that have not been adopted; the two EHDS implementing acts adopted so far, 2026/2083 (Art. 23) and 2026/2099 (Art. 16), set neither the format nor the Art. 36 common specifications.
2.2Such a system can receive personal electronic health data in that format, through the same component.Open question—Question: Carried by FerroBRIDGE, and waiting on the same Art. 15(1) implementing acts as 2.1.
2.3A system designed to provide access to personal electronic health data can receive it in that format, through the same component.Open question—Question: Carried by FerroBRIDGE, and waiting on the same Art. 15(1) implementing acts as 2.1.
2.4A system that lets a user enter structured personal electronic health data allows entry with enough granularity to provide it in the exchange format.PartialTemplates and the archetype-constrained entry modelGap: Clinical applications enter structured data through the REST API against operational templates, which constrain it to the archetype’s granularity, finer than an exchange format is likely to need. That the granularity suffices cannot be shown until the Art. 15(1) implementing acts set the format’s datasets.
2.5The components include no feature that prohibits, restricts or unduly burdens authorised access, sharing or permitted use.ShippedThe re-assessment against the authorisation defaults; The query surface over the whole stored record; Authorisation refuses or permits; it adds no commercial gate—
2.6The components include no feature that prohibits, restricts or unduly burdens exporting the data in order to replace the system with another product.ShippedWhole-repository dump and load; EHR-Extract export—

3. Requirements for security and logging

#Requirement (our paraphrase)StatusEvidenceNotes
3.1A system used by health professionals provides reliable identification and authentication of them.ShippedBasic and OAuth2/OIDC authentication; The assurance level and the natural person on patient data—
3.2The 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.PartialThe five elements mapped onto fields, gaps included; The category map a deployment declaresGap: Points (a), (d) and (e) are recorded: the accessing organisation, the time, and the origins of the served data read from the FEEDER_AUDIT provenance openEHR stamps on content, with the true distinct count beside the capped set. Point (b) records the authenticated principal and, when the deployment declares how a token names the natural person, the acting mode and the professional a client application acts for. Point (c) is recorded through the [audit.categories] map the deployment declares from its templates and archetypes to the Art. 14(1) priority categories; FerroEHR ships no map, so until one is declared every access is recorded unclassified. Records in the demographic domain carry no category, because no priority category lives there. The FHIR rendering of a read or a query carries the origins of the served data. The DICOM rendering carries neither the organisation, the declared purpose, the origins nor the categories, because PS3.15 A.5 defines no element for them.
3.3The components include tools or mechanisms to review and analyse the log data, or support connecting external software that does.ShippedAudit retrieval (IHE ATNA ITI-81) and the syslog and FHIR feeds—
3.4Components that store personal electronic health data support different retention periods and access rights that take the origin and category of the data into account.PartialRetention periods keyed on a priority category; The access-log horizon in calendar years, and its floors; Access rights per EHR, per role and per templateGap: A retention period can be keyed on the priority category of clinical content, through the category map the deployment declares, and an unclassified object takes the longest period configured for its kind. The access log’s horizon is set in calendar years (retention_years), with a three-year floor in every EU Member State (Art. 9(2)) and a longer national floor where one applies. Access rights can be keyed on the template through ABAC; the category is not itself an authorisation attribute. Neither retention nor access rights are keyed on the ORIGIN of the data. The origins FerroEHR records are the FEEDER_AUDIT originating-system ids a sending system chooses, as free text, and data committed directly carries none, so a period keyed on an origin could neither be checked against a declared vocabulary, as a category is, nor reach the data without a feeder audit; keying on origin first needs a register of the origins a deployment recognises. The archival tier moves records without expiring them.

The priority categories

The six priority categories of personal electronic health data are Annex I of the regulation, and Annex II 2.1 to 2.3 require an EHR system to provide and receive them in the European electronic health record exchange format. That format is set by implementing acts under Article 15(1) that have not been adopted, so this table is not a conformance claim against it. What it says is narrower and checkable: which category has an operational template committed to this repository, and which FHIR resource a mapping for it would target.

Annex ICategoryCommitted templateA profile mapping would target
1Patient summariescorpus/templates/ckm/international-patient-summary.optBundle (IPS-shaped) over Patient, Condition, AllergyIntolerance, MedicationStatement
2Electronic prescriptionscorpus/templates/ckm/eprescription-fhir.optMedicationRequest
3Electronic dispensationsNo committed templateMedicationDispense
4Medical imaging studies and related imaging reportscorpus/templates/ckm/ccta-report.optDiagnosticReport (+ ImagingStudy for the study itself)
5Medical test results, including laboratory and other diagnostic resultscorpus/templates/ckm/generic-lab-test-result.optDiagnosticReport + Observation
6Discharge reportsNo committed templateComposition (discharge summary) + Encounter

A category without a committed template is not one FerroEHR cannot store: the CDR stores whatever an operational template defines. It is a category with no committed example, so nothing in this repository demonstrates it end to end.

The rightmost column says what a mapping for the category would target, not what exists. FerroEHR carries no FHIR mapping: mapping openEHR content to FHIR is the job of FerroBRIDGE (https://github.com/FerroHEALTH/FerroBRIDGE), the other product of the EHR system, which reads FerroEHR over ITS-REST. No mapping set for these categories ships with either product, and no test in this repository asserts a transform for them.

Two of the example compositions behind the committed templates, the patient summary and the imaging report, were patched by hand rather than regenerated against a running server, which their pack’s provenance records and #1724 tracks. They are real CKM templates either way.

The position this page rests on

Cadasto B.V. decided these on 2026-10-06. They answer the questions earlier versions of this page left open.

  • Cadasto B.V. is the manufacturer of each tagged release. Each tagged release (the binaries, the OCI images, the Helm chart and the source archive) is one product Cadasto B.V. places on the market. A deployment that an organisation runs for itself puts that product into service; it does not make the deploying organisation the manufacturer. Cadasto B.V. may also host FerroEHR as a service for another organisation; Art. 26(2) treats an EHR system “offered as a service” as put into service, and Cadasto B.V. is then both the manufacturer and the operator. (#3606)
  • The EHR system is FerroEHR and FerroBRIDGE together. FerroEHR ships the European logging software component (Annex II 3), FerroBRIDGE the European interoperability software component (Annex II 2.1 to 2.3). The two are independent of each other (Art. 2(2)(n) and (o), Art. 30(1)(b)) because they are separate products that meet only over ITS-REST. The technical documentation and the declaration of conformity name the pair; FerroBRIDGE declares the interoperability component’s requirements, FerroEHR the logging component’s and the system-level ones of Annex II 1. (#3606)
  • One documentation set for the EHDS and the CRA. From 11 December 2027 one technical documentation set, one EU declaration of conformity and one CE marking cover both acts: Article 104 of this Regulation inserts CRA Art. 32(5a), which routes the CRA’s Annex I conformity through the conformity assessment procedure of this Chapter, and replaces CRA Art. 31(3) with a single set of technical documentation. (#3616)
  • The general-purpose exclusion does not apply. Article 25(2) excludes general purpose software used in a healthcare environment from this Chapter. FerroEHR is intended to store the health records of a healthcare provider, which is the use Art. 2(2)(k) names, so Cadasto B.V. treats it as an EHR system. (#3606)

Questions for counsel

Nothing in this repository answers these. They are stated as questions until counsel has answered them.

  • Does a deployment that modifies the source and puts the result into service become a manufacturer itself (Art. 34 of this Regulation; CRA Art. 21 and 22)?
  • What is the scope of the Art. 35 register of economic operators supplied: does a download under the public licence supply an economic operator?
  • Does CRA Art. 13(10), which lets a manufacturer patch only the latest version when earlier versions’ users get it free of charge, hold for commercial licensees under BUSL-1.1? Tracked in #3647.
  • Is a deployment Cadasto B.V. hosts as a service remote data processing outside the CRA’s product scope (CRA recitals 11 and 12), and is Cadasto B.V. then an essential or important entity under NIS2, for example as a managed service provider?
  • Is FerroEHR an important product with digital elements under CRA Annex III and Implementing Regulation (EU) 2025/2392, which decides the conformity assessment route for the CRA requirements?

The Cyber Resilience Act

FerroEHR is also a product with digital elements under Regulation (EU) 2024/2847. Its reporting duties apply now, and from 11 December 2027 the CRA’s essential requirements are assessed through this Regulation’s Chapter III procedure, in one technical documentation set and one declaration. The Cyber Resilience Act page states FerroEHR’s position, and the FerroHEALTH book states the manufacturer’s (the CRA).