Today we are releasing Termbox 1.0, after two years building a high-performance FHIR Terminology Server, designed to support large-scale terminology workloads.
Deciding when to call a terminology server “1.0” is not straightforward.
- Is it when it supports every operation in the FHIR specification?
- When it passes every test in the FHIR Terminology Ecosystem IG?
- When it can serve SNOMED CT, LOINC, RxNorm, and ICD?
- Or when it supports advanced features such as the full SNOMED CT ECL?
All of these are valuable milestones. None of them, on its own, defines whether a product is ready for production.
For Termbox, the deciding test was replacing a terminology server already serving real customers, and running the entire production workload reliably.
Replacing a real system
Before Termbox, requests to tx.health-samurai.io were served by an Ontoserver deployment. Replacing it gave us a much more concrete definition of readiness than a feature checklist could provide.
The migration took six months. We first reproduced the terminology content available in the existing service. The goal was to ensure that replacing Ontoserver with Termbox would not disrupt the applications already relying on the existing terminology service.
During the migration, we captured real requests made by clients of tx.health-samurai.io. This produced a corpus of more than 250,000 unique requests, dominated by the operations that terminology clients actually use: ValueSet/$validate-code, ValueSet/$expand, CodeSystem/$lookup, CodeSystem/$subsumes, and CodeSystem/$validate-code.
We replayed that corpus against Termbox and compared each response with the original Ontoserver response. Differences were classified, investigated, and either accepted when both behaviors were valid or turned into implementation work when they exposed a missing capability or an incorrect result.
The goal was parity where it mattered: the requests, content, and behavior our customers relied on.
Evidence from production
The migration proceeded as a gradual production rollout until it reached 100% of the traffic, and Termbox became the system serving those requests at tx.health-samurai.io.
That cutover was the decisive milestone for 1.0.
Production numbers from the first month after completing the rollout:
- Requests served: 2M+
- Median response time: 2 ms
- p95: 6 ms
- p99: 36 ms
Alongside production observation, we built a dedicated performance suite, the TX Benchmark, to measure latency, throughput, and resource consumption across representative terminology workloads. Performance was treated as part of production readiness.
Stable, not finished
Termbox 1.0 supports CodeSystem, ValueSet, and ConceptMap, together with the core operations used to look up and validate codes, expand, test subsumption, and translate concepts. It supports large terminology distributions and includes a growing subset of SNOMED CT ECL.
There is still work ahead. Not every FHIR terminology operation and parameter is supported, and some capabilities remain under development. The current boundaries are documented on the Termbox capabilities page.
We are also validating Termbox through the FHIR Terminology Ecosystem test suite. Termbox currently passes more than 90% of the tests in the general category, and we are continuing the work across the terminology-specific categories.
The test suite measures standardized interoperability and conformance across a defined matrix. The migration demonstrated that Termbox could serve a diverse, existing production workload reliably. We want both forms of evidence.
What 1.0 means
For Termbox, 1.0 communicates that the product is stable and ready to support production workloads. It is the version we are prepared to stand behind, whether Termbox is consumed as a managed SaaS service or deployed on premises.
The roadmap continues: broader conformance, deeper support for individual terminologies, more ECL, Natural Language Processing features, a broader SQL surface and improved content distribution. We will build these additions on a production-proven foundation.
Termbox is 1.0 because it is already doing the job, under real production traffic. Try it as SaaS, or start playing with it in the sandbox.
