Termbox now runs on Databricks Lakebase
Termbox, the FHIR terminology server, can now run on Databricks Lakebase PostgreSQL. The SNOMED, LOINC and RxNorm content, and the value sets you use, now live in the same platform as your other products and the same place your data teams already work.
The code list problem
Most of the interesting questions in healthcare analytics are, underneath, terminology questions. Data teams solve this using lists of codes. Sometimes exported from a terminology tool months ago. Sometimes typed by hand. Sometimes with complex ELT-like processes for keeping up with terminology sources. Meanwhile, the operational terminology server holds the definition of the concepts, the ones used to validate data, to power the search box in the UI and to map concepts between vocabularies. That creates a gap that affects architectural decisions and entails additional costs.
Terminology data is different
The reason that pipeline feels wasteful is that terminology behaves nothing like clinical data. It has four properties that, taken together, change where it belongs.
It's immutable and versioned. A terminology release is a snapshot, not a mutable dataset. SNOMED CT 20260301 is what it is, permanently; the next release is a new snapshot. This is what lets Termbox be as fast as it is. Content is loaded once and indexed aggressively. There's no write contention, almost no cache invalidation, no reconciliation logic. That's the foundation of the response times we published in the FHIR TX Benchmark.
It's read-mostly, and bursty. A terminology server has idle times, and enormous burst times: a nightly cohort build that executes thousands of expands, a bulk validation run over a backlog. Lakebase's autoscaling is a good fit for that kind of system, with scale-to-zero suspending it entirely when the server is idle.
Its lifecycle is owned by someone else. You don't decide when SNOMED CT changes, or LOINC, or RxNorm, or ICD-10. The publishers do, on their own schedules, and those schedules are frequent enough that analytics are at risk of running on a stale terminology release. If terminology sits outside your data platform, every one of those releases has to be propagated across a boundary. Keeping it inside means the refresh loop stays in one place.
It's a shared dependency, not one tenant's data. Clinical data belongs to a patient, an encounter, an organization. Terminology belongs to everyone. The same LOINC serves ingestion validation, the clinical search box, the cohort builder, and the agent answering questions about lab results.
There's a pattern in those four properties. In transactional systems, terminology use is diffuse and unpredictable, anything might need to validate a code at any moment. In analytics, it's different: narrow, contextualized, repeated. The same handful of value sets, expanded over and over, against the same tables. Which is exactly the case for putting terminology next to the data.
From the FHIR API to the SQL surface
Right now, everything in Termbox is exposed through the FHIR terminology API: $lookup, $validate-code, $expand, $subsumes, and $translate. For analytical workloads, the API is the right interface for some jobs and the wrong one for others. Expanding a value set once and joining the result against a billion-row table is not something you want to do over HTTP.
Part of that foundation is already in place. Termbox is powered by a comprehensive relational schema, built around concepts borrowed from RDF and heavily inspired by the FHIR terminology model: concepts, properties and designations are just rows. That schema is stable, and running on Lakebase makes it reachable from the platform where analytics happens.
A schema on its own isn't enough, though. A value set is a definition: includes and excludes, filters, hierarchy traversal, references to other value sets. Turning that definition into the set of codes it actually denotes is a computation, and a heavy one. That's the work $expand does on every call. For a value set to be usable from a SQL JOIN, that expansion has to be materialized, and kept current as new releases land.
That's the piece we're building: expansions materialized into the lakehouse, documented and stable enough to build pipelines on. One authoritative definition, reachable two ways: $expand from the application, a JOIN from the notebook. Running on Lakebase is the prerequisite.
How to run it
Termbox connects to Lakebase as a Databricks service principal, using short-lived OAuth-issued database credentials. Termbox resolves the credential, caches it, and refreshes it transparently before it expires. There's no long-lived database password sitting in your terminology service's configuration.
Full setup is in the Termbox documentation. To try it, you can get a free Development License in a couple of clicks.
