--- { "title": "Introducing Termbox", "description": "We're announcing Termbox, our FHIR terminology server built for performance and scale. Ranked first on the FHIR TX Benchmark, with support for all major terminology operations and fast content loading. Community Edition is free.", "date": "2026-04-20", "author": "Orlando Osorio", "tags": ["Terminology", "Termbox", "Announcement"] } --- We're excited to announce Termbox: a FHIR terminology server. Built from the ground up with performance in mind. Designed to scale and adapt to any terminology, regardless of complexity. ## Why We Built Termbox After 20+ years in healthcare and over 10 years working with FHIR, we've noticed a pattern: organizations build a solution, it often contains user interfaces, storage layers, integration pipelines, validation, etc. They adopt FHIR at multiple levels so different components can interact easily. At some point they need to pull data from external sources: drug information, clinical knowledge, laboratory tests, disease classifications. They need to validate data, power a search input, translate local codes into standard ones. All of these are terminology problems. For the simpler cases, our recommendation has been to use the [Aidbox Terminology Module](docs/aidbox/terminology-module/aidbox-terminology-module) — a lightweight approach that covers common cases and gets teams moving quickly (a common approach in the industry, a lightweight implementation of the basics). But as requirements grow, the limits show up. Complex filtering, hierarchies, localization, complex value sets, syntax-based terminologies. And then there's the content itself: finding the sources, handling different formats, different release schedules, managing licenses, keeping everything up to date. The recommendation, then, is to use a terminology server. Implementers can easily see the value in separating terminology as its own server or component. Given the nature of the data — immutable, with its own origin and lifecycle, independent of tenant — it makes architectural sense. But there are concerns: a terminology server can become a bottleneck. User-facing requests need to return in milliseconds going over hundreds of thousands of terms; validation during data ingestion can slow down the entire system. There's also the operational side, a common worry: running another service, setting up the pipelines to keep the data current. We built Termbox to address all these concerns. ## Performance Termbox is fast, really fast. We knew performance was a critical requirement, so we set out to build a server that could handle any terminology, no matter how complex, and still return results in under 40ms for complex operations. Earlier this month we published the [FHIR TX Benchmark](fhir-tx-benchmark): an open benchmark comparing the main terminology servers on the market. Termbox ranked first, and it wasn't close: several times faster than competitors, up to 30x faster on the most complex operations.
# Server Score
1 termbox
100%
2 fhirsmith
38%
3 ontoserver
21%
4 snowstorm
7%
5 hades
6%
We'll be publishing a dedicated post on performance: how we built it, some of the challenges, and what the numbers mean in practice. ## Content One of the hidden costs of running a terminology server is getting the content ready. Finding the sources, understanding and negotiating licensing requirements, converting from different formats to FHIR, loading and indexing, setting up pipelines to keep the content up to date. It can take weeks before everything is set up. Termbox supports multiple ways of loading data: FHIR resources, bundles, packages, pre-indexed binaries, atom feeds. Loading is fast: going from zero to a fully indexed SNOMED takes around 1 minute. We're also working on the Termbox Gallery: a curated repository of FHIR terminologies built on years of work we've done with our clients: conversion scripts, data pipelines, licensing agreements, including distribution rights for some terminologies so you can get the content directly from us. More on this in a future post. ## Conformance Termbox covers the most commonly used FHIR terminology operations: `$lookup`, `$validate-code`, `$expand`, `$subsumes`, (`$translate` coming soon). The operations most systems are likely to depend on. We're working heavily on full conformance with the [FHIR TX Ecosystem IG](https://build.fhir.org/ig/HL7/fhir-tx-ecosystem-ig/) test suite and making good progress. Most of the failing tests today are surface-level details like error message formatting, metadata parameters, rather than gaps in core functionality. We expect to reach full compliance in the coming months. A dedicated post on conformance is coming. ## Try It You can get started with Termbox in just a few minutes: a `docker compose up` and you're running. The Community Edition is free for development, evaluation, and non-commercial use.
Get Started
## What's Next This is the first in a series of posts about Termbox. We'll be going deeper on performance, content management, and conformance. More posts coming soon. We're also currently working on a hosted SaaS option for teams that don't want to run their own instance. We'll also be working with the community on open-sourcing the conversion scripts we use to build the FHIR distribution of terminologies. Through our Professional Edition and integration consulting work, we're also working with enterprise customers on features that aren't yet standardized: knowledge base support, AI integration and skills, semantic search. We'll have more to share on this soon. We're just getting started. There's a roadmap of features we're excited to share, and we'll be publishing more as things take shape. If you have questions, want to share feedback, or just want to talk terminology — reach out. You can find us at the [Health Samurai Community Zulip](https://connect.health-samurai.io/) or through our [contact page](/contacts).