Health-data infrastructure in Rust, built on open standards.

The frame is one FerroHEALTH instance serving one tenant: the eight inside are the family, and everything outside is a caller, a target or another organisation. Every product is single-tenant: one instance serves one organisation, and an organisation that serves several runs several instances. Left to right is the order data moves. An arrowhead points at what is called or written to, and the FHIR side carries one at both ends because the bridge reads openEHR out to FHIR and writes FHIR back in. The other three servers call a FHIR terminology server, for three different reasons: FerroFORMS, now paused, to expand the value set behind a coded field so the form can offer the codes it admits, FerroEHR to validate a coded value at commit time, with $expand configured in its place against a server that does not offer $validate-code, and FerroBRIDGE to resolve a display, translate a code and validate one. That seam is the FHIR terminology API, so FerroTERM fills it and so does any other implementation. The facade speaks the FHIR release FHIRconnect's mappings name, and FerroBRIDGE's site says which. HL7 Version 2 senders reach the bridge over MLLP, and it maps each message through HL7's Version 2 to FHIR guide into the CDR. OMOP is a database schema, so its edge names no protocol: the OMOCL mappings compile to SQL that writes typed rows into the CDM tables.

The dashed box is FerroTASK, the planned product, and the grey box is FerroFORMS, which is paused. No authorisation server is drawn: each server is its own SMART App Launch resource server, through FerroAUTH's ferrohealth-smart, and checks the access tokens it is handed against the deployment's own authorization server, because one central service would hold the signing key every server's access depends on. Identity and the IHE profiles are FerroPIX's alone, and FerroEHR implements none of them: it is to look the subject of an EHR up at FerroPIX as a client, over PIXm and PDQm, so the subject its EHR_STATUS carries can be the pseudonym FerroPIX mints. An application sends FerroFED an ordinary AQL query and never learns it was federated: the gateway asks FerroPIX where the record is, then sends standard AQL to each node, the local FerroEHR or another organisation's CDR, and merges what comes back. An application that opens a record asks FerroPIX the same question; FerroFORMS receives the EHR it is launched with and asks nobody. Every operator console is built on FerroUI and is reactive. FerroSYS sits with the other shared libraries: its crates carry the secrets, configuration, telemetry, health, HTTP stack and usage report of each product, inside that product. FerroTASK reads the record over AQL and commits the state of each plan back to it, like any other client of the CDR. The audit trail goes to an Audit Record Repository the deployment runs, through FerroAUDIT, which FerroEHR, FerroFED and FerroPIX use. Which release of each standard a product implements is on that product's site, rendered from its own pins.