Every real FHIR deployment ends up with at least one local code system. A trust's internal specialty list, a research network's protocol-specific vocabulary, a private hospital group's billing categories: the international vocabularies cover most of the ground but never quite all of it. A terminology server that handles local code systems as a first-class concern is the one that saves the team from building a parallel internal registry. The five tools below have a credible track record on this specific requirement in 2026.
For broader context on FHIR terminology services and where local code systems fit within them, the rest of the FHIR coverage is the right entry point to the supporting material.
What Local Code System Support Actually Means
Three behaviours matter most:
- Loading custom CodeSystem resources without manual database editing, ideally through standard FHIR API calls.
- Honouring custom code systems in $expand, $validate-code, and $lookup operations on equal footing with LOINC and SNOMED CT.
- Supporting ConceptMaps that translate between local codes and the international vocabularies, so the rest of the stack can ingest a single coded view.
A tool that hits all three feels like the local code system was always part of the vocabulary mix. A tool that misses any of them tends to push the local content into a sibling service the application team then has to integrate with separately.
The 5 FHIR Terminology Tools That Handle Local Code System Extensions Well Worth Shortlisting
- HAPI FHIR Terminology Service. HAPI handles local code systems as a baseline capability. CustomCodeSystem resources load through the standard API, the four core operations honour them, and ConceptMap support for local-to-international translation is part of the design. The integration with the wider HAPI stack reduces friction further.
- Ontoserver. Ontoserver supports local code system extensions cleanly alongside its SNOMED CT focus. The fit is strongest when the local codes need to coexist with a heavy SNOMED CT workload and translate cleanly across, which is the common pattern in NHS trusts that need to retain a small internal vocabulary alongside the canonical one.
- Snowstorm with Sibling Service. Snowstorm itself is purpose-built for SNOMED CT, so local code systems usually live in a sibling service that exposes the same FHIR terminology API. Several open-source-first NHS deployments run Snowstorm for SNOMED CT and a lightweight HAPI instance for local codes, with both fronted by the same API layer.
- Smile CDR Terminology. Smile CDR's commercial managed terminology service handles local code systems under contract, with operational guarantees around custom CodeSystem loading and translation. Useful for organisations that want a single vendor responsible for the international vocabularies, the local extensions, and the mappings between them.
- Medplum Terminology Module. Medplum's bundled platform handles local code systems as part of the wider FHIR stack. The fit is strongest for organisations standardising on Medplum across storage, identity, forms, and terminology, where the local vocabulary lives in the same operational footprint as everything else.
Patterns That Make Local Code Systems Manageable
Three patterns tend to keep local code systems healthy over the long run. First, treat the local CodeSystem as a versioned, sourced artefact, with a clear owner and a release cadence even if the cadence is infrequent. Second, build ConceptMaps to the most relevant international vocabulary from day one, even if the mappings are partial, because the cost of building mappings retroactively is much higher than building them incrementally. Third, surface usage telemetry, so the team can spot when a local code starts taking on a clinical meaning that diverges from its definition.
A team that adopts these three habits tends to keep its local code systems tidy. A team that does not tends to discover, eighteen months in, that the local vocabulary has quietly grown into a thicket.
For broader strategic context on FHIR terminology server selection, the complete guide for healthcare teams in 2026 is the right back-reference. For the related topic of allergy and adverse reaction coding that often combines local and international vocabularies, the best terminology servers for allergy and adverse reaction coding in 2026 is the natural companion read.
Sources
- ConceptMap $translate operation specification - HTML spec, HL7, R5
- Mastering FHIR Terminology (Dion McMurtrie, CSIRO) - PDF slides, DevDays, 2023
- Ontoserver: a syndicated terminology server (foundational) - Article, PMC / JAMIA, 2018
