Written for the integration architect and terminology-adjacent informatics lead who inherits the local-code reality rather than choosing it. The stance is deliberately anti-purist (govern, don't prohibit), and the technical spine stays FHIR-correct throughout: value sets as the unit of binding, concept maps scoped value set to value set, and only the four runtime operations named. Builds directly on the Terminology 101 and SNOMED CT explainers and hands forward to the ICS-wide mapping piece.
A data quality review finds the same screening test recorded four different ways across three departments: one SNOMED CT concept, two local codes created years apart, and one free-text convention that became a de facto code. The person who authored the older local codes left in a restructure. Nobody can say with confidence which downstream reports count which variants.
No one in that story did anything unreasonable. A service needed a code before anyone had time to find the right national one, a form needed a dropdown, a deadline arrived. The problem isn't that local codes exist. It's that they exist outside the machinery that keeps meaning stable.
In brief
Local codes are a permanent feature of every Trust's estate, created for legitimate reasons: new services, local pathways, fields the national terminology didn't yet cover. Drift begins the moment they live in spreadsheets and hard-coded dropdowns instead of governed infrastructure. The fix is structural: host local code systems in the same terminology machinery as SNOMED CT, with the same versioning; do all binding and validation at value set level; maintain concept maps (scoped value set to value set) as owned, versioned artefacts; and enforce the whole arrangement at runtime with the standard terminology operations. Add a named owner and a release-driven review cadence, and local codes stop being a liability and become a governed extension of the national standard.
Why local codes exist (and why that's fine)
The purist position ("SNOMED CT only, no local codes") fails on contact with operational reality. New services start before national coverage catches up. Local pathways carry distinctions that matter locally and nowhere else. Legacy systems arrive in mergers carrying decades of their own vocabulary. And sometimes a team simply needs a working dropdown this week.
So the goal of terminology governance is not zero local codes. It's zero ungoverned codes: every code in use, national or local, should be identifiable, versioned, owned, and reachable by the same tooling. Governance is a property of the machinery, not of the code's publisher.
Where drift actually comes from
Drift has a consistent anatomy, and none of it is mysterious. Local codes get authored in spreadsheets and embedded directly in form configurations, so there's no single source of truth, and the same need gets solved twice in different departments. There's no versioning, so a code's meaning shifts silently when someone "tidies" a label. There's no ownership, so retirement never happens and dead codes keep collecting data. Mappings to SNOMED CT get done once, for a project, and never maintained, so the bridge decays while everyone assumes it's load-bearing. And because none of this is visible to the integration layer, wrong codes travel: into shared records, into reports, into the ICS.
Each step is small. The compound effect is the review meeting in the opening paragraph.
The governance model: one machinery for every code
The structural fix is a single decision: local codes live in the same terminology infrastructure as the national standards, as first-class code systems. Same hosting, same versioning discipline, same operations, same governance surface.
Concretely, that means your terminology server holds SNOMED CT, ICD-10 and LOINC alongside a formally published code system for each local vocabulary: each local code with an identifier, a display, a status, and a version history, exactly like its national neighbours. This is the design conviction behind WeHub Term, which treats officially published and locally authored code systems identically; the moment local codes get second-class treatment, they migrate back to spreadsheets, and the drift cycle restarts. One machinery, every code, no exceptions: everything else in this guide builds on that.
Value sets: where the rules live
With all codes hosted, the unit of governance becomes the value set: the named, versioned shortlist of codes valid in one specific context. A form field, a message element, a report filter: each binds to a value set, never to "SNOMED CT" at large and never to a hard-coded list.
Two authoring styles cover every case. Explicit value sets enumerate their codes, which suits small, tightly controlled lists. Rule-based value sets define membership by expression (all descendants of a given SNOMED CT concept, for example), which stays current as the terminology evolves. And because everything is hosted in one place, a single value set can legitimately combine national concepts with local codes: the admission form's shortlist can carry SNOMED CT concepts alongside the Trust's local service codes, all governed identically. When someone asks "which codes are allowed here?", the answer becomes a named artefact with a version, not an archaeology project.
Concept maps: the bridge you maintain, not the one you hope for
Local codes earn their keep locally, but data crosses boundaries: into shared records, national datasets, analytics. That crossing runs on concept maps, and two disciplines keep them trustworthy.
First, scope. A concept map's source and target are value sets, not entire code systems. You are never mapping "our codes to SNOMED"; you are mapping the codes used in this context to the codes accepted in that one. That scoping is what makes each map finite, testable and ownable rather than an open-ended crosswalk programme. Second, honesty about relationship. Each mapping states whether the target is equivalent, broader or narrower than the source, because pretending a broader match is an exact one is how meaning quietly degrades in transit. A map with an owner, a version history and stated relationships is a bridge. A spreadsheet from a 2019 project is a hope.
The operations that enforce governance at runtime
Governance on paper is decoration; the terminology operations are what make it real at runtime, and four do the work. $expand materialises a value set into its current concrete list, which is how forms and interfaces render governed dropdowns instead of stale copies. $validate-code checks an inbound code against the value set bound to that context, which is how bad codes get caught at the boundary instead of discovered in a report. $translate applies a concept map when data crosses between contexts, local to national or between two local worlds. $lookup fetches a concept's display and details so humans read words while systems exchange identifiers.
Wire these into the integration layer (validation on ingest, translation at boundaries, expansion for interfaces) and the governance model stops being a policy document and becomes a property of the estate. A code that isn't in the machinery simply doesn't pass.
A working cadence: owners, reviews, retirements
The last ingredient is rhythm, and it's modest. Name one owner for terminology governance with real authority over local code creation: new local codes go through them, with a standing first question of "does national coverage already exist?". Tie reviews to releases: when a new SNOMED CT edition lands, rule-based value sets are re-expanded and checked, and concept maps touching affected concepts are reviewed on a defined timescale. Keep a change log per artefact, because "why is this code here?" deserves a recorded answer. And run retirements deliberately: when national coverage catches up with a local code, the local concept is deprecated with an effective date, a mapping to its successor is published, and historical data keeps its meaning through the map rather than being rewritten.
None of this is a programme. It's a habit attached to release cycles, and it's cheaper than any single drift incident it prevents.
The bottom line
Local codes are not a governance failure; ungoverned local codes are. Put every code in one machinery, bind every context to a named value set, maintain the maps as owned artefacts, and let the runtime operations enforce what the policy promises. The first step costs a week, not a quarter: inventory the local codes in one high-traffic form, and for each one write down its owner, its version and its map to the national standard. The blank cells in that table are your terminology governance backlog, in priority order.
