Latest release: v0.0.8, 2026-10-18.
FerroBRIDGE reads FHIRconnect and OMOCL mapping files and runs them against any openEHR CDR it reaches over the ITS-REST API. Mappings are specification-conformant YAML validated against published schemas, so nothing is hand-coded per FHIR resource or per OMOP table.
Each release ships the ferrobridge binary for Linux, the
container image ghcr.io/ferrohealth/ferrobridge, the
operator console image, and library crates on crates.io. The
repository's compose.yaml starts the bridge with one
command.
Each one is recorded with its ground in the architecture document, including the places where no specification governs the choice and FerroBRIDGE makes its own.
FerroBRIDGE is its own process and its own image. It is not a crate inside a CDR, not a plugin, and not a library a CDR links. It reaches the CDR over ITS-REST like any other client, which is what lets it work against a CDR it did not build.
FHIRconnect files are validated against the two published draft-07 JSON schemas. OMOCL publishes none, so FerroBRIDGE authors one from the grammar tables and the published library, and validates every file against it.
FHIRconnect and OMOCL share a header and nothing else. The header model, the YAML loader, the mapping registry, and the RM-path model are shared; each language keeps its own parser, validator, and interpreter.
The FHIR side is a REST facade over the CDR that stores no clinical data. The OMOP side is a batch ETL over AQL that writes typed rows into a CDM v5.4 database, with concept resolution as SQL over the loaded OHDSI vocabulary.
The design as decided, the two mapping languages it reads, the version pins and why each one is what it is, and what gets built next.
An openEHR CDR over ITS-REST, a FHIR terminology server, and for the OMOP side a CDM v5.4 database with the OHDSI vocabulary loaded. Plus the failure behaviour you should know before you run it.
A FHIR R4 facade on one side, a batch ETL into the CDM on the other, and the mapping files that drive both, including where the specifications leave a decision open.
The tracker is the worklist and the checks are committed scripts you can run yourself. Code against an open issue and cited evidence are both welcome.
FerroBRIDGE has shipped eight releases on the 0.0.x line, the latest v0.0.8 on 2026-10-18. Every issue carries its acceptance criteria, and a release is cut when its milestone has no open issue left.
