Mapping and Maintenance Pitfalls

Why mapping is necessary

The previous lessons treated each code system on its own terms. In practice, no single terminology serves every job, so the same clinical fact must be expressed in more than one system — and that means translating, or mapping, codes from one system to another. The need shows up constantly. A problem recorded on a clinical problem list in SNOMED CT has to be translated to ICD-10-CM so it can be billed and reported, because the reimbursement and statistical machinery speaks the classification, not the fine-grained clinical terminology. Legacy and local codes — the homegrown lists that predate any standard — must be normalized to standard ones before they can be shared. And data captured in one terminology often has to populate a value set expressed in another, so that a field bound to one system can still be fed from sources coded differently. Mapping is the seam that lets systems built for different purposes talk to one another ¹.

Why mapping is lossy

A map is not a translation in the dictionary sense; it is encoded human judgment about which target code is “close enough” for a stated purpose. It is therefore inherently lossy. The clearest reason is granularity. A clinical terminology like SNOMED CT captures fine distinctions — laterality, severity, causal agent — while a classification like ICD groups cases into broader buckets sized for billing and epidemiology. When the source is more detailed than the target, several distinct source concepts collapse onto one target: a many-to-one map. A SNOMED CT diabetes concept, for instance, may land in a broader ICD-10-CM diabetes category, with its finer detail simply not represented on the target side ¹. Occasionally one source concept legitimately corresponds to several targets — a one-to-many map — and sometimes there is no adequate target at all. Crossing between systems designed for different jobs always sacrifices something; expecting a clean mathematical identity is the first mistake.

Map types and direction

It helps to name the shapes a map can take: one-to-one, where a single source code has a single faithful target; one-to-many, where one source spreads across several targets; and no-match, where the honest answer is that nothing fits. A subtler trap is directionality. A map built to take problem-list concepts to billing codes is not guaranteed to work in reverse, because the collapsing that happened on the way down cannot be undone on the way back up. Treating a one-directional map as if it were bidirectional silently invents detail that was never there. Always ask which direction a given map was built and validated for ¹.

Versioning and maintenance

Terminologies are living artifacts, released on regular cycles. With each release, concepts are added, inactivated, or replaced. That movement means a map is never finished: the source or target underneath it can shift, so maps drift and must be re-validated on every release rather than assumed stable. Inactivated concepts need explicit historical handling so that records coded under the old concept remain interpretable, which is why SNOMED CT maintains relationships that link a retired concept to its replacement ². Ignore this and old data slowly becomes unreadable as the codes beneath it expire.

Governance: an unowned map rots

Because maps drift, someone must own them. Governance means a named party is responsible for each map: testing changes against new releases, recording the provenance of every mapping decision, and deciding when a target is good enough. An unowned map does not stay correct on its own — it silently rots as the systems on either side move beneath it, and the rot is invisible until a downstream report or claim comes out wrong ¹.

Concrete pitfalls

A handful of failure modes recur. Stale maps are the most common: a terminology release ships, the map is not re-validated, and translations quietly go wrong. Catch-all buckets — the “unmatched” or “other” target that absorbs anything without a clean home — are convenient but dangerous, because they hide data-quality problems behind a code that looks complete. Semantic drift is slower and harder to see: a code’s real-world usage changes over time even though the code itself does not, so a once-valid map gradually stops meaning what it used to. And over-trusting automation — accepting an algorithmically generated map without clinical review — is acceptable for low-stakes analytics but reckless where the result drives care or payment ¹.

Practical guidance

A few habits keep mapping honest. Prefer maintained, authoritative maps over ad hoc ones, since the maintenance burden is exactly what tends to be neglected. Re-validate on every terminology release, treating each new version as a trigger to retest rather than a non-event. Keep the source code alongside the mapped code so that no information is irreversibly lost; even when the target is coarser, the original remains available for reinterpretation later. And review high-risk maps clinically, reserving human judgment for the cases where a wrong translation harms a patient or misstates a claim. None of this makes mapping lossless — that is not achievable — but it keeps the losses visible, owned, and intentional rather than silent ¹.