The system plumbing every FerroHEALTH server shares, as Rust libraries: secrets, configuration, logging and telemetry, health checks and the HTTP server.
Family site · What ships today · Milestones · Licensing
Project
Quality and security
Every FerroHEALTH server has to do the same handful of things before it can do its real job. It writes a log that a person or a log pipeline can read. It sends traces and measurements to the monitoring system a hospital already runs. It tells the container platform whether it is alive and ready for work. It stops cleanly when asked to, without dropping a request halfway. It reads its settings from a file and the environment, and keeps passwords out of every log line.
Today each server has its own copy of that code, and the copies have drifted apart: one setting has a different name in two products, and a log line looks different from one server to the next. FerroSYS is where that code moves, so every server behaves the same way and an operator learns it once.
The libraries touch no clinical content. They carry how a server runs, never what it stores or translates.
- Hospital IT and operations teams, who run several FerroHEALTH servers and want one log format, one set of health checks and one way to configure each of them.
- Developers of the FerroHEALTH servers, who take these libraries instead of writing the plumbing again.
The source is public, and the design is recorded on the tracker of this repository, where you can follow every decision. There is no paid edition with extra features. This README describes only what exists; what is planned is on the milestones.
FerroHEALTH is five servers, each its own product, that reach each other only over published standards: FerroEHR stores the record, FerroBRIDGE translates it to FHIR and the OMOP research model, FerroFED connects records across organisations and borders, FerroPIX matches patient identities, and FerroTERM serves the code systems (the shared lists of medical terms). No server is built into another.
Work that every server needs lives in shared libraries, so it is written once: FerroAUTH for sign-in and access control, FerroAUDIT for the audit trail, FerroUI for the web consoles, and FerroSYS for the system plumbing (logging, OpenTelemetry, health checks, the HTTP server stack and configuration). The family rule is that nothing is hand-written that a shared library provides; when a library lacks something, it is added there and released.
FerroSYS is a repository of shared crates, like FerroAUTH and FerroAUDIT: the crates run inside each server and take no call of their own. It distributes no configuration, deploys nothing and runs no service.
Nothing yet: FerroSYS has no released crate and no code. The repository
holds the licence, the brand, the tracker tooling and the plan in
docs/architecture.md. What is built, and in which
order, is on the
milestones.
- The FerroHEALTH family site and the family book
- The architecture, the milestones and the tracker
- Security policy
- Contributing and maintainers
- Brand
Business Source License 1.1 (LICENSE), with Apache License 2.0 as the Change License four years after each version; the licensing page says when you need a commercial licence from Cadasto B.V.