The `$translate` operation is one of those FHIR features that everyone references and few teams stress-test until production exposes the gaps. ICD-10-CM workflows in US healthcare lean on it heavily: SNOMED CT problem lists need to map to ICD-10-CM for billing, encounter diagnoses need to translate cleanly across systems, and quality measures depend on consistent code mapping behavior across releases.
This piece compares seven implementations of `$translate` for ICD-10 workflows. The wider terminology framing is in the buyer's guide for US healthcare; the SNOMED-side context is in top 6 FHIR terminology servers for SNOMED-heavy workloads in 2026. The wider series sits at the digital health FHIR primer.
What $translate Has to Do for ICD-10
The operation takes a source code, a target code system, and an optional ConceptMap, and returns one or more mapping results with equivalence values. For ICD-10-CM workflows, the source is almost always SNOMED CT, and the ConceptMap is the SNOMED-to-ICD-10-CM map that SNOMED International ships and updates twice yearly.
The implementation has to load that ConceptMap, return all valid target codes for a source (including the equivalence classifier), handle one-to-many and many-to-one mappings, and stay current across releases.
The Seven Implementations
The shortlist below covers what tends to come up in real ICD-10 deployments. The order reflects which implementation fits which workload, not a hard ranking.
- Snowstorm. Handles the SNOMED-to-ICD-10-CM ConceptMap as part of the standard SNOMED release content. Translation results include the equivalence relationship and the map advice strings, which is what downstream billing logic actually needs.
- OntoServer. Treats ConceptMap as a first-class object, with strong support for translating in both directions and respecting the equivalence classifier. For organizations that need bidirectional translation as part of clinical decision support, this is the most capable option.
- HAPI FHIR Terminology. Implements `$translate` against any uploaded ConceptMap. The SNOMED-to-ICD-10-CM map can be loaded as a resource and queried like any other. The translation logic is straightforward and predictable, with the usual HAPI ergonomics.
- Smile Digital Health. Builds on HAPI's ConceptMap support and adds operational tooling for managing map versions across releases. For teams that need a contracted vendor to keep the SNOMED-to-ICD-10-CM map current, this is the most direct path.
- Termbox. Ships the SNOMED-to-ICD-10-CM ConceptMap as managed content and updates it with each SNOMED release. The operational story is the differentiator: the team running it does not have to think about map ingestion.
- LHC Terminology Services. The Lister Hill tooling supports `$translate` against value sets and ConceptMaps relevant to NLM-curated content. For research and public health workflows where the upstream provenance matters, it is the natural fit.
- Bonsai. Handles `$translate` for SNOMED CT, ICD-10-CM, and the ConceptMap between them, with documented loading scripts for each. The developer ergonomics are explicit selling points: a team can stand up a working translation service in a day.
What Tends to Go Wrong
Three patterns recur across teams that have run `$translate` in production for ICD-10 workflows.
- The ConceptMap goes stale. SNOMED ships a new release, the map is not reloaded, and downstream billing pulls outdated codes for new diagnoses.
- One-to-many mappings are handled by returning a single result, which silently drops information the application needed.
- Equivalence classifiers are ignored in client code, so an inexact mapping is treated as if it were exact.
The fixes are not subtle. Automate the map reload on each SNOMED release. Always return all results from `$translate` and let the caller pick. Surface equivalence in the UI when the user is reviewing a translation.
How to Pick
For self-hosted SNOMED deployments, Snowstorm with the standard ConceptMap is the path of least resistance. For OntoServer-class deployments where ECL and bidirectional translation matter, OntoServer is the front-runner. For managed-service deployments, Termbox and Smile both handle the operational side cleanly.
The right `$translate` implementation is mostly the same vendor as your `$expand` implementation, which is the same vendor as your terminology server overall. Splitting them adds operational friction that rarely pays back.
Sources
- ConceptMap $translate operation specification (canonical, evergreen) - HL7 FHIR R5
- ConceptMap resource specification (equivalence semantics, evergreen) - HL7 FHIR R5
- JPA terminology module including $translate implementation notes (evergreen) - HAPI FHIR project docs