FerroEHR
The openEHR CDR each member runs. The gateway reaches it over ITS-REST 1.1.0 like any other client, and the node profile is checked against FerroEHR and EHRbase.
Where else the record is.
FerroFED is an openEHR federation gateway, in pure Rust. A client sends it an ordinary AQL query with no federation syntax: the gateway resolves the patient outside the query, sends standard AQL to each CDR scoped to that node's own EHR id, and merges the answers with each node's provenance into one ordinary result set. It holds no clinical data of its own.
A gateway image and an operator console image on GHCR, a Kubernetes
package and the ferrofed binary for x86_64 and aarch64
Linux, built at SLSA Build Level 3.
What it does
One query in, one answer out, every node named
FerroFED follows the openEHR Federation Working Group's Federation Tier with AQL specification and reaches every node over openEHR ITS-REST 1.1.0. The conformance statement names the test that holds each conformance point.
Federation Tier with AQL 1.0.1
Transparent to the client
/v1/query/aql takes a conformant openEHR query and
answers one ordinary ITS-REST result set. Ordering, paging,
DISTINCT and the aggregates apply across nodes, and
what cannot be exact is refused with a reason.
No identifier in what a node receives
The patient resolves to each node's local EHR id outside AQL, through a patient index such as FerroPIX. The rewrite refuses a query that would leak an identifier, and an outbound gate checks every request again.
Federation metadataNever a silent partial answer
Every node in scope is reported with its status. A node that does not answer in its time budget fails the query, unless the client asks for flagged partial rows with every missing node named.
Follow-ups and writesEvery request reaches its owner
A request under an EHR goes to the one node that holds it, a versioned write only to the CDR that created the version, and a stored query lives at the gateway as an immutable version it distributes to the members.
EHDS and MyHealth@EUThe European exchange format on FHIR
The patient summary, prescriptions and dispensations, laboratory, imaging and discharge reports in the HL7 Europe profiles, from a member's openEHR record or its own FHIR endpoint, and served to a national contact point.
OAuth 2.0, DPoP and EHDS loggingEvery caller verified, every access recorded
Each caller is authenticated at the gateway and each node reached with its own credential. Consent can be checked first, and every access to patient data is recorded with the verified caller and the categories of the data.
The operator console
The federation as the gateway sees it
The console shows the members, their reachability, the incidents and the stored queries, runs a federated query with every node's status, and keeps the configuration as revisions an operator saves, applies and rolls back.
Run it
From a laptop to a Kubernetes cluster
The gateway is one static binary on a distroless base, in front of the CDRs you already run and beside a patient index. The console is its own image and keeps no patient data.
Compose
The quickstart
docker compose up --wait from a checkout starts the
gateway beside four FerroEHR nodes and FerroPIX; a seed script
adds synthetic patients, and you send one federated query.
The container images
ghcr.io/ferrohealth/ferrofed and
ghcr.io/ferrohealth/ferrofed-console, for amd64 and
arm64, each with SLSA provenance and an SBOM you verify before
you run it.
The Kubernetes package
A kustomize package, deploy/kubernetes/, attached to
every release with each image pinned by digest: the gateway's
StatefulSet, its network policy and its disruption budget.
In the family
The product that connects records across organisations
The FerroHEALTH products reach each other only over published protocols. FerroFED sits in front of the CDRs and asks the patient index where a patient's records are.
FerroPIX
The patient index the gateway resolves through. FerroFED keeps no table of patients: it asks a PIXm Manager as a client, and the quickstart runs FerroPIX.
FerroBRIDGE
The eehrxf crate builds the European exchange
documents the FHIR face serves from a member's openEHR record.
The documentation
Four questions, four parts of the book
Does it fit my problem?
How a federated query works, what the Federation Tier asks and what FerroFED claims, the conformance statement, and the status under the EHDS Regulation.
What does a client send and get?
An ordinary AQL request in, an ordinary result set out, the federation metadata that says which nodes answered, and the European exchange format on the FHIR face.
What does running it involve?
A production deployment step by step, every configuration key, admitting a node, the console, and hardening.
How is the work organised?
The tracker is the worklist, every check is a committed script you can run, and a change cites the specification section it implements.