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

The EHDS EHR system: readiness

Revised 2026-10-29.

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 release of FerroEHR and of FerroBRIDGE, and the EHR system it declares is the two together: FerroEHR ships the European logging software component, FerroBRIDGE the European interoperability software component. This page states, requirement by requirement, what the two provide in their latest releases, and names the product that carries each requirement. The intended purpose and the shared responsibility pages cover the system as a whole. FerroBRIDGE’s EHDS readiness page lists the mappings it proves, profile by profile.

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 the EHR system 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 March 2025.

Every requirement identifier, heading and date on this page was read from the Official Journal text, vendored in the FerroEHR 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 unmodified releases for itself puts Cadasto B.V.’s products into service and does not become the manufacturer. Where Cadasto B.V. hosts them 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, as its published crate eehrxf, which FerroBRIDGE builds and publishes and every product that needs the component pins exactly: the dataset model read from the Xt-EHR logical models, the crosswalk of each Art. 14(1) category to the HL7 Europe profiles, the exchange format in FHIR, the receipt of a document and the mapping between openEHR and that format (the component’s pages). FerroBRIDGE reads FerroEHR over ITS-REST. The format itself is set by implementing acts under Article 15(1) that have not been adopted, so the component is built against their published proxies and no component can claim it yet. FerroEHR itself carries no FHIR mapping.
European logging software component for EHR systemsPartialShipped by FerroEHR on the FerroHEALTH products’ shared logging crate ehds-logging and audit crate ihe-atna (FerroAUDIT), which FerroEHR pins exactly in its root Cargo.toml: ehds-logging holds the Annex II 3.2 access record, the Art. 14(1) categories and the classification, the retention floor of Art. 9(2) and the emergency mark, and ihe-atna writes the BALP and DICOM renderings and sends the ATNA trail. FerroEHR ships the access-event model, the audit store with its hash chain and the scheduled verification of that chain, the sinks, the middleware that records and classifies every API access from its own data, 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. FerroEHR ships the whole component: the recording, the store, the review, the retention and the retrieval of the log.

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 component; The logging component’s stated performance, and the test that measures itGap: 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 access role and the emergency mark on its record. The logging component’s intended performance is stated as claims a test checks: every composition create and read recorded exactly once and every AQL execution at least once, no access succeeding without its record, a bounded cost in latency and throughput against the same workload with the log off, and a bounded ITI-81 retrieval time. scripts/perf/audit.sh measures them on every release candidate; a claim not met refuses the release, and the summary is attached to the release as its performance evaluation (Annex III point 2). The interoperability component’s assessment is FerroBRIDGE’s. The Regulation names no method or figure for showing performance or safety, so the claims and the method are Cadasto B.V.’s own, and no conformity assessment has examined either.
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. The Kubernetes deployment probe (scripts/deploy-probe-k8s.sh, probes P-K8S-PROD-BOOT and P-K8S-PROD-SHARED) installs the overlay against four PostgreSQL clusters, one per storage domain. Its first run, on 2026-10-14 against the release image of that day, observed the four-cluster layout refuse to start. A second run the same day, against an image built from the fix, observed the chart’s migration Job prepare all four clusters on their own migration credentials, the server boot under production with plaintext_listener its only gap, and the boot refuse all four domains on one cluster by naming shared_cluster. A run on 2026-10-20, against the main image after the move to the shared authentication crate (#3872), gave the four clusters certificates from one CA and made each refuse a connection without encryption, and the overlay mounts that CA (database.caConfigMap): it observed the migration Job and the server reach all four clusters with sslmode=verify-full (P-K8S-PROD-TLS-REFUSE, P-K8S-PROD-TLS), the boot under production, and the shared_cluster refusal. It ran on a kind cluster in a podman VM, whose node cannot create user-namespaced pods: a pod with hostUsers: false fails at sandbox creation, because runc may not mount sysfs in the new user namespace (“operation not permitted”). That run therefore set hostUsers: true, and its record names hostUsers: false as not exercised; observing it needs a cluster whose node runtime can create user-namespaced pods. Tried again on 2026-10-28 with the newest kind, Kubernetes, containerd and runc on a rootful podman machine, the pod failed the same way: a kind node is itself a container, so the run needs a VM or bare-metal node. The chart has no default posture: it refuses to render until config.deployment_profile names sandbox or production, so an installation that follows a quickstart does not run the sandbox posture by omission. The Compose files, the single-host evaluation stacks, declare sandbox explicitly and say it must not hold real personal data.
1.3Interoperability, safety and security features uphold the rights of natural persons in line with the intended purpose, as set out in Chapter II.PartialChapter II right by right, and who serves each part; One patient’s access log, through a subject-scoped grantGap: The shared-responsibility page of the FerroHEALTH book takes the Chapter II rights one by one: the part the EHR system has to provide for the Member State’s access service or the health professional access service to serve each right, what FerroEHR provides, and what stays with the deployer or the Member State. FerroEHR provides that part for access (Art. 3(1)), proxy access through a token that names the person (Art. 4(2)), rectification (Art. 6), portability (Art. 7), the restriction of access with its emergency override (Art. 8, Art. 11(5)), the information on access with its three-year floor (Art. 9), and an opt-out through the whole-EHR restriction (Art. 10). Two parts are not provided yet: marking what a person inserts and refusing a patient-context change to what a professional committed (Art. 5, FerroEHR#4350), and withholding newly registered data from the person until a professional releases it where a Member State delays access (Art. 3(3), FerroEHR#4351). The copy in the European exchange format (Art. 3(2)) is FerroBRIDGE’s interoperability component and waits on the Art. 15(1) implementing acts.
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; The run against independent ATNA implementations; 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 sends over RFC 5425 TLS only, through ihe-atna, and the FHIR feed is outbox-driven, so a record survives a repository outage; the instructions for use name both. scripts/interop/atna.sh runs the transactions against independent implementations from published images. Its first run, on 2026-10-28, found two defects on FerroEHR’s side, both fixed: the shared ehds-logging crate named an openEHR object by an opaque what.reference, which HAPI FHIR refused (FerroAUDIT#127), and one unclassified record lacked the BALP entity:data slice (FerroEHR#4353). The run of 2026-10-29, on FerroEHR’s main build with the FerroAUDIT release that fixes the first (FerroEHR#4365), found no disagreement: HAPI FHIR, from the image the script pins, accepted all 71 records of the window and its validator, with IHE BALP loaded, found no error; syslog-ng received all 72 syslog messages over RFC 5425 TLS, each a well-formed DICOM PS3.15 AuditMessage; and ten ITI-81 searches answered the same records on FerroEHR and on HAPI FHIR. The fixes ship in FerroEHR’s next release; a released version before it still writes the reference HAPI FHIR refuses. 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 system; The interoperability component, FerroBRIDGE’s eehrxf crateQuestion: 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 questionReceiving a document, in FerroBRIDGE’s eehrxf crateQuestion: 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 questionReceiving a document, in FerroBRIDGE’s eehrxf crateQuestion: 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 gatenone
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 exportnone

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 datanone
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 shipped category map, and the one a deployment declares; How a deployment declares the natural person behind a tokenGap: 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; the instructions for use say how to declare it. Point (c) is recorded through a category map from templates and archetypes to the Art. 14(1) categories, classified by ehds-logging. FerroEHR ships a map for the published CKM templates and COMPOSITION archetypes whose data sit in one priority category, which applies until the deployment declares its own; the production profile refuses to start while no map applies. An access to data the map in force does not name is recorded unclassified, never guessed: the shipped map leaves out the generic report containers, which carry laboratory, imaging and other reports alike, and CKM publishes no composition for an electronic dispensation, so a deployment declares its own templates. 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 feedsnone
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; Retention periods keyed on a registered origin; The access-log horizon in calendar years, and its floors; Access rights per EHR, per role, per template, category and originGap: A retention period can be keyed on the category of clinical content, through the category map in force, and on the origin of the data, through the [origins] register of the origins a deployment recognises: each by the id its data carry, with the clients whose direct commits come from it, so data committed directly carries the committing client’s origin. 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, the category and the origin: the ABAC request carries all three as resource attributes a Cedar policy or a remote decision point can name. 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 FerroEHR’s repository, and which FHIR resource a mapping for it would target.

Annex ICategoryCommitted templateA profile mapping would target
1Patient summariesinternational-patient-summary.optBundle (IPS-shaped) over Patient, Condition, AllergyIntolerance, MedicationStatement
2Electronic prescriptionseprescription-fhir.optMedicationRequest
3Electronic dispensationsNo committed templateMedicationDispense
4Medical imaging studies and related imaging reportsccta-report.optDiagnosticReport (+ ImagingStudy for the study itself)
5Medical test results, including laboratory and other diagnostic resultsgeneric-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 in FerroEHR’s repository, so nothing there demonstrates it end to end.

The rightmost column says what a mapping for the category would target. FerroEHR carries no FHIR mapping: mapping openEHR content to FHIR is the job of FerroBRIDGE, the other product of the EHR system, which reads FerroEHR over ITS-REST. Which HL7 Europe profiles FerroBRIDGE maps today, with the committed template and the round-trip test that proves each transform, is on its EHDS readiness page.

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 FerroEHR#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. (FerroEHR#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. (FerroEHR#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. (FerroEHR#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. (FerroEHR#3606)

Questions for counsel

Nothing in this book or in either product’s 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 FerroEHR#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

Each product 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 the manufacturer’s position and each product’s route.