The interoperability component

Regulation (EU) 2025/327, the European Health Data Space regulation (https://eur-lex.europa.eu/eli/reg/2025/327/oj), defines the European interoperability software component for EHR systems as “a software component of the EHR system which provides and receives personal electronic health data under a priority category … in the European electronic health record exchange format” (Art 2(2)(n)). An EHR system that claims compliance carries one (Art 25(1)), and Annex II, points 2.1 to 2.3, says what it must provide and receive.

FerroBRIDGE ships that component as the Rust crate eehrxf, published from this repository on the crate line (Crate versions). An EHR system or a gateway in front of several of them links the crate and serves the documents it builds on its own FHIR face; the crate holds no route, no store and no access record of its own.

Nothing on this page is a conformance claim. The Commission has not adopted the implementing act that lays down the exchange format (Art 15(1)), so the crate is built against its published proxies, listed under The pinned proxies, and is read again against the act when it is adopted.

• What the crate holds
• The profile checks
• The definitions it publishes
• The pinned proxies
• Where it stands

What the crate holds

The crate has one Cargo feature per priority category of Art 14(1) and one per serialisation, and no default feature:

Without a feature the crate is the format-neutral dataset model: dataset reads the Xt-EHR EHDS Logical Information Models package as data, every logical model on its canonical URL and every element on its element path, with what the obligations profiles ask of a producer and a consumer. No element is a Rust type of its own, so a new release of the models is a new package, never new code.

The crate authors no mapping language and no profile mapping: FHIRconnect files are its input. It depends on no logging component and on no application, so it and the European logging component stay independent of each other, as Art 2(2)(n) and (o) define them. The Rust documentation is on docs.rs.

The profile checks

The crate holds what it reads and what it writes to the pinned profiles in four ways:

• The crosswalks: a test per category holds every row to the packages it names, and fails when an element a producer must populate has no row, when a row names an element or slice the profile lacks, or when a row’s obligation differs from the obligations profile (The category crosswalks).
• The structural check of a received document: ReceivedDocument::check walks the document’s Bundle and Composition profiles: cardinalities, fixed[x] and pattern[x] values and slices, with every constraint it cannot evaluate listed (The structural check).
• The full validation of a received document: ReceivedDocument::validate hands the document to ferrobridge-validator, this repository’s FHIR R4 profile validator, over the category’s Bundle profile and its whole dependency closure (Full validation).
• HL7’s FHIR Validator over the documents it writes: the suites that write a patient summary document and hold it to the profiles also write it to the directory EEHRXF_EMIT_DIR names. The CI fhir-validator job runs HL7’s FHIR Validator over every one of them, offline, against hl7.fhir.eu.eps 1.0.0-ballot, hl7.fhir.eu.base 2.0.1 and the MyHealth@EU Master Value Sets Catalogue, with the jar and every package pinned by sha256 in docs/VERSIONS.md. It fails on an error, a fatal issue or a claimed profile the validator could not find. Its results, each document with the validator’s outcome and a summary, are the eehrxf-fhir-validation artifact of the run. They are the evidence for the documents the component writes.

The definitions it publishes

The component writes two things no specification defines, and FerroBRIDGE publishes both under its own domain:

• The archetype-local code systems: an archetype’s local codes are written under https://ferrobridge.eu/fhir/CodeSystem/archetype-local/ followed by the archetype id, one code system per archetype. The page at that base describes them.
• The remaining-dispensations extension: the number of dispensations a prescription item has left travels in https://ferrobridge.eu/fhir/StructureDefinition/remaining-dispensations on MedicationRequest.dispenseRequest, as a valueUnsignedInt. The site serves its StructureDefinition at that URL, and at the same URL with .json.

The pinned proxies

Each proxy is vendored by scripts/vendor/eehrxf.sh as the archive its publisher serves, pinned by URL and sha256 in docs/VERSIONS.md, and read by the crate’s tests:

Where it stands

The patient summary is the most complete category: the crosswalk, the document Bundle, its mapping from openEHR, the terminology rules and the receipt are built. The prescription and dispensation records are read and written in the MPD form. The laboratory, imaging and discharge reports have their crosswalks and their document assembly; building each report from openEHR content waits on the mapping contexts for their profiles. The open work is on the tracker. The profiles this repository’s own FHIR facade maps to, category by category, are on EHDS readiness.