FerroFED

Design phase. No release yet.

Where else the record is.

FerroFED is an openEHR federation gateway. A client sends it an ordinary AQL query and never learns it was federated: 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. It holds no clinical data of its own.

Read about the specification See what is decided

The repository, its gates and the vendored specification exist. The architecture is being written by a research program on the tracker, and there is no binary yet. This page says so rather than describing software you cannot download.

What the specification asks

Four properties a federation gateway has to keep

FerroFED follows the openEHR Federation Working Group's Federation Tier with AQL specification. Each of these is a normative requirement there, and each will be scored by a test here.

Transparent to the client

The gateway is a conformant openEHR Query API. A basic patient query needs no federation syntax, and the answer is an ordinary ITS-REST result set with the federation's additions in one metadata member.

No identifier reaches a node

The patient identifier is resolved to each node's local EHR id outside AQL and consumed at the gateway. Nothing the gateway sends to a node carries a directly identifying identifier.

Never a silent partial answer

Every node in scope is reported with a status. When a node that was asked does not answer, the default is to fail the query; flagged partial rows go only to a client that asks for them.

Follow-ups go to the owner

A read or a write after the query is routed to the CDR that created the record, on its system id. Consent stays with each node, enforced before it releases data.

Where to start

Four questions, four answers

Operate

What will it need around it?

Member CDRs over ITS-REST, an identifier cross-reference service, and optionally a locator and a directory, plus the failure behaviour to know before you run it.

Integrate

What does a client send and get?

An ordinary AQL request in, an ordinary result set out, and the federation metadata that says which nodes answered.

Contribute

How is the work organised?

The tracker is the worklist and the checks are committed scripts you can run yourself. While the design is open, cited evidence is worth more than speculative code.

Where the project is

The first milestone is the repository and the research program that writes the architecture; the second is the first federated query over two nodes. Every issue carries its acceptance criteria, and a release is cut when its milestone has no open issue left.

Read the documentation See the roadmap