16 to 32 GB
RAM to serve the International edition, most of it Elasticsearch heap, plus a search cluster to run.
Discovery. No product code yet.
A pure-Rust FHIR terminology server for SNOMED CT, LOINC, and other clinical code systems, on ordinary hardware.
FerroTERM serves the HL7 FHIR terminology API for SNOMED CT, LOINC, and other clinical code systems from a memory-mapped index built once per edition. You run the full International edition in a few hundred megabytes on a laptop or a small box, with no JVM and no search cluster to operate.
Ferro for the Rust family FerroTERM shares with FerroEHR, TERM for terminology.
Why it exists
The same edition, on hardware you already have
SNOMED CT terminology servers today are almost all Java, and the reference server runs on Elasticsearch. That stack wants 16 to 32 GB of RAM to serve the International edition, more than a laptop or a small box has.
a few hundred MB
One Rust binary and a memory-mapped index. Small enough to run beside other services on a modest box.
The data itself is small: about 360,000 concepts, 1.2 million descriptions, and 1.5 million relationships. FerroTERM treats SNOMED as a graph, materializes the answers a terminology server is asked for once per release, and serves them from precomputed structures. These are the design targets recorded in the architecture, not measurements of a running server.
What it is
The decisions already taken
The architecture is recorded in full, with citations, in the documentation. Here is the shape of it.
Machine-generated FHIR
HL7 publishes the type system and every operation as machine-readable resources. A generator emits per-version Rust from them, so the operation surface is correct per version by construction. Planned across R4B, R5, R4, and R6.
An index-materialized graph store
SNOMED is stored as a graph, natively, as integer-keyed adjacency arrays and roaring bitmaps for the transitive closure. Subsumption is a bitmap test, a descendant set is a bitmap returned directly. This is a graph model with a materialized store, not a graph database and not live traversal.
Value sets driven by ECL
Value-set expansion follows SNOMED's Expression Constraint Language. The evaluator compiles ECL to set algebra over the descendant bitmaps and typed adjacency, tested against the published ECL grammar as its own layer.
One self-contained binary
A single static binary over a pure-Rust, memory-mapped embedded engine (redb). No JVM, no separate search service, no external database. The offline build turns an RF2 release into the store, graph, and text index once per edition.
The FHIR terminology API
$lookup, $subsumes, $validate-code, $expand, and $translate, served from one running server. Correctness is checked against Snowstorm as the reference server.
MIT licensed
The software is open source under the MIT license. Use it, embed it, run it. SNOMED CT content is licensed separately by SNOMED International and is never distributed here: you bring your own RF2 release.
Where the project is
FerroTERM is in discovery. This repository is being scoped before implementation, so it describes the intended architecture and the decisions already taken, not a finished server. There is no product code yet, and no benchmark to quote.
The most useful thing you can do right now is read the architecture and the ECL approach, then tell us where it is wrong. Issues and discussion are welcome.