SNOMED International develops and maintains two terminology servers, Snowstorm and Snowstorm Lite. This page sets them beside FerroTERM on the points you choose by: what each one serves, what each one needs to run, and what each one costs to licence. Every claim about a Snowstorm server links the sentence in that project's own documentation that carries it.
Every cell about Snowstorm or Snowstorm Lite comes from that project's own documentation, linked in the cell and listed again under Sources. A claim that could not be sourced was left off the page, so a row you expect and do not find means the evidence was missing, never that the feature is. Every cell about FerroTERM is checkable in the FerroTERM repository, and the cell says where.
The Snowstorm documentation was read on 12 September 2026, from the
master branch of each repository. The current release
on that date was
Snowstorm 11.0.0
(2 September 2026) and
Snowstorm Lite 2.6.0
(9 September 2026). SNOMED International's
terminology services page
was read the same day. The FerroTERM column describes release
0.1.3.
Snowstorm Lite serves SNOMED CT and nothing else, by design. Rows about other code systems read not in scope in its column. That is where the project drew its boundary, and reading it as a missing feature would misrepresent it.
This page compares features and carries no latency figure for any of the three. A latency number is worth reading when the servers ran on one machine over one release, and that run has not been made. The benchmarks page has FerroTERM's own measurements, each with the machine, the method, and the record it came from.
“An open source terminology server with special support for SNOMED CT”, built on Elasticsearch “with a focus on performance and enterprise scalability”. It runs the SNOMED International Browser for the International edition and around fourteen national editions, and it runs the Authoring Platform. SNOMED International states that it is not able to offer commercial support for the product, and that support comes from the community.
“A fast FHIR Terminology Server for SNOMED CT with a small memory footprint.” Its use cases are scaling architectures, responsive search behind data entry, and SNOMED CT offline in places with poor connectivity or in trusted research environments. The readme states plainly that it is “Not suitable as a national terminology server”.
A pure-Rust FHIR terminology server for SNOMED CT, LOINC, ICD-10,
ICD-11, RxNorm, UCUM, and any FHIR CodeSystem, served
from one binary over an index built once per release and read at
startup. No JVM, no Elasticsearch, no database to run. It checks
its own answers against Snowstorm, which is the behavioural
reference for the cases the specification leaves open.
| FerroTERM 0.1.3 | Snowstorm | Snowstorm Lite | |
|---|---|---|---|
| Code systems |
SNOMED CT, LOINC, UCUM, ICD-10 in the WHO, Dutch, and US
versions, ICD-11, RxNorm, ATC/DDD, ICPC-2, the Dutch national
code systems, the BCP and ISO registries, and any FHIR
CodeSystem, ValueSet, and
ConceptMap resource.
Code systems page
|
“Supports SNOMED CT, LOINC, ICD-10, ICD-10-CM and other code systems”. Anything else loads through a custom code system format that carries a single display term, a simple hierarchy, and properties. README, Using the FHIR API | SNOMED CT only: “A fast FHIR Terminology Server for SNOMED CT”. readme |
| SNOMED editions in one server | Each artifact directory is one code system version, and a server loads several. Resolving a default across several SNOMED editions through the Module Dependency Reference Set is still an open item on the checklist. implementation.md | “Hosting multiple extensions alongside the International Edition of SNOMED CT”. README | One: “Only supports one release of SNOMED CT Edition at this time”. Extension and derivative packages import on top of that edition. readme |
| FHIR version |
R4 (4.0.1) under /r4, R4B (4.3.0) under
/r4b, R5 (5.0.0) under /r5, and the
R6 ballot under /r6, each in its own version's
shapes, in JSON or XML.
FHIR versions
|
R4: “The Snowstorm HL7 FHIR API implements the
terminology module, version R4.” JSON or XML, by the
Accept header.
Using the FHIR API
|
R4: the readme's FHIR features cite the R4 implicit value sets and implicit maps, and no other version is documented. readme |
| Terminology operations |
CodeSystem/$lookup,
$validate-code, $subsumes,
ValueSet/$expand,
ValueSet/$validate-code,
ConceptMap/$translate,
ConceptMap/$closure, $versions,
metadata, and
metadata?mode=terminology.
The FHIR terminology API
|
CodeSystem lookup, validate-code, and subsumes;
ValueSet expand and validate-code, with search,
create, replace, update, and delete;
ConceptMap translate; metadata and
metadata?mode=terminology.
Using the FHIR API
|
CodeSystem lookup and
$validate-code; ValueSet
create, edit, delete, $expand, and
$validate-code; ConceptMap create,
edit, delete, and $translate.
CodeSystem $subsumes arrived in 2.3.0.
readme, changelog
|
| Client-authored value sets and maps |
A server reads and searches the ValueSet and
ConceptMap resources loaded with its artifacts,
and takes a client's resource inline in the request or through
$cache-control. A deployment that names a
database in FERROTERM_RESOURCES also serves
POST, PUT, GET,
DELETE, _history reads, and
?url= search of CodeSystem,
ValueSet, and ConceptMap, with
ETag and If-Match.
store.rs
|
ValueSet search, create, replace, update, and
delete over the FHIR API.
Using the FHIR API
|
ValueSet and ConceptMap create,
edit, and delete over the FHIR API.
readme
|
| SNOMED implicit value sets and maps |
?fhir_vs, ?fhir_vs=isa/[sctid],
?fhir_vs=ecl/[ecl],
?fhir_vs=refset,
?fhir_vs=refset/[sctid], and
?fhir_cm=[sctid].
Value sets and ECL
|
“The SNOMED CT URI, filters, properties, implicit value sets, and implicit concept maps”. Using the FHIR API |
SNOMED CT implicit value sets, with the isa and
ecl filters supported, and SNOMED CT implicit
maps.
readme
|
| ECL |
ECL 2.2, from a parser written to the official ANTLR
ECL.g4 grammar, vendored with its example corpus;
malformed ECL comes back as an OperationOutcome.
VERSIONS.md, implementation.md
|
“Fully ECL v2.0 compliant” in the README; SNOMED International's terminology services page says “Fully ECL v2.1 compliant”. README, terminology services | “ECL Core, a subset of ECL”, and “Full ECL support is not planned”: the readme says it covers the most used features without the complexity and memory demands of the full specification. readme |
| Languages |
Displays and designations per language from the language
reference set and RF2 acceptability, selected with
displayLanguage.
README
|
“Multi-lingual search and content retrieval”, with a documented guide to language-specific search behaviour. README | “Multiple language support with configurable character folding”, and a language-aware preferred term in the mini-browser. readme |
| SNOMED authoring, browser, history | None. The server is read-only over an index built offline from a release. README | Authoring of the International edition, nine national editions, and community extensions; the API behind the SNOMED International Browser; “Full history (depends on full RF2 import)”. README | “Does not support SNOMED CT authoring or the SNOMED CT Browser”. readme |
| A web UI in the box |
A viewer at /ui, served by the same binary and
nothing to deploy separately. It is a FHIR client over the
public API, so it runs $lookup,
$validate-code, $subsumes,
$expand, and $translate against
whatever this deployment publishes.
The viewer
|
Not claimed in the documentation. Snowstorm provides the terminology server API for the SNOMED International Browser, which is a separate application. README | A Dashboard at the server root, used to pull an edition through the syndication service and to administer the index. readme |
| FerroTERM 0.1.3 | Snowstorm | Snowstorm Lite | |
|---|---|---|---|
| Runtime dependencies | The binary and its artifact directory. No JVM, no Elasticsearch, no database. README | Java 17 and Elasticsearch 8, tested against 8.11.1; an HTTP proxy for SSL is recommended. Getting started | JDK 17. Apache Lucene runs inside the application, so there is “no need for Elasticsearch”. readme, terminology services |
| Memory each project asks for |
The sizing guide puts an edition on a 2 to 4 GB box with two
cores. The resident figure that belongs beside it is being
re-measured: the harness read it with ps, which does not
count the pages macOS compresses, so every published figure
understated what a served edition holds.
Hardware sizing, benchmarks
|
“At least 8G of memory”: as a minimum 2G for Snowstorm and 4G for Elasticsearch, with another 4G left free for disk caching. The Docker quickstart uses 8Gb across its three containers. Getting started, Using Docker | “After creating the index the app can run with just 500mb memory”, and the index for the International edition builds inside 1 GB. readme, running with Java |
| Deployment shape |
One binary or a distroless container image, over an
artifact directory built once per release by
ferroterm-build. Releases carry signed SLSA
Build Level 3 provenance and SBOMs.
Install and run
|
A Spring Boot jar on the JVM beside an Elasticsearch install,
or docker compose with a Snowstorm container, an
Elasticsearch container, and the browser.
Getting started, Using Docker
|
A “self-contained application”: the
snomedinternational/snowstorm-lite Docker image
over a Lucene index volume, or the jar on Java 17.
readme, running with Java
|
| Getting the content in | You bring the release you are licensed for and build it into an index offline, once per release. There is no syndication client. Loading code systems | RF2 import through the native SNOMED CT API, which is also the only way to create a SNOMED CT code system. Other systems load through the HAPI FHIR CLI or a FHIR package upload. Using the FHIR API | Upload an RF2 archive, or let the server download a release from SNOMED International's MLDS syndication service by itself. The import takes about five minutes. readme |
| Licence of the software | Business Source License 1.1: free outside production and for non-commercial production use, a commercial licence for other production use, Apache 2.0 four years after each version. LICENSE | Apache 2.0. LICENSE.md | Apache 2.0. LICENSE.md |
The memory row is what each project states for its own deployment on its own hardware, so the three figures were measured in different places under different loads. Read it as a sizing starting point. None of the three code systems' content is included with any of these servers: SNOMED CT stays licensed by SNOMED International, and you bring the release you hold a licence for.
ValueSet
resources in Snowstorm, and ValueSet and
ConceptMap resources in Snowstorm Lite. FerroTERM
serves the same interactions only where the deployment names a
database in FERROTERM_RESOURCES; a deployment that
names none refuses every write with a 422.
Read on 12 September 2026 from the master branch of
each repository.
CodeSystem $subsumes in 2.3.0, CodeSystem $validate-code and the syndication dashboard in 2.5.0.The book's How it compares page sets FerroTERM beside Ontoserver and Hermes as well. If a cell here is out of date, or a claim reads unfairly, open an issue and it gets corrected against the source.