SNOMED CT mapping trust: when clinical terminology becomes a liability
SNOMED CT contains over 350,000 clinical concepts, but mapping errors between systems silently corrupt the data that health AI models train on. When a 'heart failure' concept maps to the wrong hierarchy or a retired code persists in a production system, clinical terminology stops being a foundation and starts being a liability.
SNOMED CT is the clinical terminology health systems use to record diagnoses, procedures, findings, and observations in structured form. It holds over 350,000 active concepts joined by more than 1.4 million relationships, maintained by SNOMED International with updates each January and July. Unlike ICD-10 billing codes, it captures clinical meaning. Mapping it across systems introduces errors that compound silently.
SNOMED CT is the most comprehensive clinical terminology system in healthcare, with over 350,000 active concepts and more than 1.4 million relationships connecting them. It is the backbone of structured clinical documentation in EHRs across 40 countries. And it is quietly breaking the health AI models that depend on it.
The problem is not SNOMED CT itself. The problem is what happens between SNOMED CT and every other system it touches. Mapping clinical terminology across coding systems, EHR platforms, research databases, and AI training pipelines introduces errors that compound silently. By the time a model trains on mapped SNOMED data, nobody can trace whether "Type 2 diabetes mellitus" in one system means exactly the same thing as "Type 2 diabetes mellitus" in another.
This is the SNOMED CT data trust problem. And it is one of the most underexamined liabilities in healthcare AI.
Is SNOMED CT used to support clinical documentation?
Yes. SNOMED CT is the primary clinical terminology system used to support clinical documentation in electronic health records worldwide. The International Health Terminology Standards Development Organisation (IHTSDO), operating as SNOMED International, manages the standard. Over 40 countries hold national licenses.
Clinicians use SNOMED CT concepts to record diagnoses, procedures, findings, and clinical observations in structured formats. Unlike ICD-10, which was designed for billing and statistical classification, SNOMED CT was purpose-built for clinical documentation. It captures clinical meaning at a level of granularity that billing codes cannot.
A single clinical encounter for chest pain might reference SNOMED concepts for the symptom itself (29857009: Chest pain), the anatomical site (51185008: Thoracic structure), and the clinical finding context (finding with explicit context). ICD-10 would compress all of this into a single billing code like R07.9.
This granularity is SNOMED CT's greatest strength. It is also the source of its greatest mapping vulnerability.
Do SNOMED codes change?
Yes, SNOMED codes change. SNOMED International releases updates twice per year, in January and July. Each release can introduce new concepts, retire existing ones, merge duplicate concepts, and restructure hierarchical relationships.
Between 2018 and 2023, SNOMED International retired over 12,000 concepts and introduced more than 30,000 new ones. Retired concepts do not disappear from production systems overnight. They persist in legacy EHR databases, in historical clinical records, and in the training datasets that health AI developers have already assembled.
When a concept is retired, SNOMED International provides a "historical association" that points to the replacement concept. But these associations are advisory, not enforced. An EHR system that mapped to concept 123456789 five years ago may still carry that concept in its database without any automated mechanism to update it. The clinical meaning encoded in that concept may have shifted, split into multiple concepts, or been absorbed into a different hierarchy entirely.
For AI training data, this creates a specific failure mode: temporal concept drift. A model trained on SNOMED-coded records from 2019 and 2024 may treat retired and replacement concepts as distinct clinical entities when they are the same thing, or worse, treat them as identical when the replacement concept carries a meaningfully different clinical scope.
What are the challenges of SNOMED CT?
The challenges of SNOMED CT cluster into four categories that directly affect clinical terminology mapping trust.
Mapping inconsistency across systems. SNOMED CT concepts must be mapped to ICD-10, CPT, LOINC, RxNorm, and local terminology systems. Each mapping layer introduces interpretation decisions. A single SNOMED concept for "chronic kidney disease, stage 3" may map to one ICD-10 code in Epic, a different one in Cerner, and a third in a research data warehouse. These discrepancies are rarely visible to the end user or the AI developer.
Granularity mismatch. SNOMED CT operates at a level of clinical detail that other systems do not support. When a highly specific SNOMED concept must map to a less granular billing code, clinical meaning is lost. This loss is irreversible. Once a SNOMED concept for "left anterior descending coronary artery stenosis, greater than 70 percent" maps to a generic ICD-10 code for coronary artery disease, the specificity that made the SNOMED concept valuable is gone.
Versioning chaos across institutions. Not every EHR system runs the same SNOMED CT release. A hospital using the July 2022 release and a clinic using the January 2024 release may encode the same clinical finding with different concept IDs because one concept was split or merged between releases. When records from both institutions feed into the same AI training pipeline, the model cannot distinguish version-driven differences from genuine clinical differences.
Local extension proliferation. SNOMED CT allows national and institutional extensions. The US Edition, managed by the National Library of Medicine, adds concepts specific to US clinical practice. Individual health systems add local codes. These extensions create data that is SNOMED-like but not SNOMED-standard, and the distinction matters enormously when data moves between systems.
Can SNOMED CT standardize clinical data?
SNOMED CT can standardize clinical data, but only when the mapping, versioning, and governance infrastructure supports it. The terminology itself is rigorous. The problem is that most health systems treat SNOMED CT as a static reference table rather than a living standard that requires active maintenance.
Standardization breaks down at three points.
First, at the point of entry. Clinicians selecting from a dropdown of SNOMED-mapped terms in an EHR are choosing from an interface layer, not from the SNOMED hierarchy directly. The interface term "heart failure" might map to SNOMED concept 84114007 (Heart failure) or to a more specific descendant concept like 441481004 (Chronic systolic heart failure). Which concept gets recorded depends on how the EHR vendor configured the mapping. Two clinicians documenting the same patient condition in two different EHR systems may produce different SNOMED concept codes.
Second, at the point of extraction. When SNOMED-coded data is pulled from an EHR for research, analytics, or AI training, the extraction query must account for concept hierarchies. A query for "diabetes" that only searches for exact matches to concept 73211009 (Diabetes mellitus) will miss the thousands of descendant concepts that represent specific types and stages of diabetes. Most extraction pipelines do not handle hierarchical subsumption correctly.
Third, at the point of integration. Merging SNOMED-coded data from multiple sources requires concept normalization, version alignment, and extension reconciliation. Without this work, standardization is nominal, not actual.
The mapping trust gap in health AI
Health AI developers typically inherit SNOMED-mapped data from upstream sources: EHR exports, claims databases, clinical data warehouses, and registry feeds. They rarely have visibility into how the mapping was performed, which SNOMED CT version was used, or whether local extensions were mixed into the standard terminology.
This creates a trust gap that is distinct from data quality in the traditional sense. The data may be complete, timely, and free of null values. It may pass every conventional quality check. But if the SNOMED mappings are inconsistent, outdated, or lossy, the clinical meaning encoded in the data is unreliable.
Consider a practical scenario. A pharma company building a real-world evidence model for a cardiovascular drug pulls SNOMED-coded patient records from six health systems. Each system used a different EHR vendor. Three used the US SNOMED Edition with local extensions. Two used the International Edition. One had not updated its SNOMED release in 18 months.
The resulting dataset contains records that look standardized. Every diagnosis has a SNOMED concept code. But the codes do not mean the same thing across systems. The model trains on this data and produces cohort estimates that are systematically biased by mapping inconsistency, not by clinical reality.
This is not a theoretical risk. It is a daily reality for organizations building health AI on multi-source clinical data. The same structural problem affects ICD-10 coding accuracy and CPT code integrity, but SNOMED CT mapping failures are harder to detect because the terminology's granularity makes errors less visible.
Key statistics
The scope of SNOMED CT mapping risk is quantifiable, and the numbers are large enough to matter for any organization using clinical terminology in AI pipelines.
Why concordance scoring matters for terminology trust
The Data Trust Index scores every health data record across eight dimensions. For SNOMED CT mapping trust, two dimensions carry outsized weight: Concordance (10%) and Provenance (25%).
Concordance measures whether the same clinical concept is represented consistently across sources and systems. For SNOMED-coded data, concordance scoring answers a specific question: does SNOMED concept 84114007 in System A refer to the same clinical entity as SNOMED concept 84114007 in System B, given that the two systems may use different SNOMED editions, different interface terminologies, and different mapping rules?
Provenance measures whether the origin and chain of custody of a data element can be verified. For SNOMED mappings, provenance scoring tracks which SNOMED edition was used, when the mapping was last updated, whether local extensions were applied, and whether historical concept associations were followed when codes were retired.
Without these two dimensions, a SNOMED-coded record can appear high-quality on every conventional metric while carrying mapping errors that corrupt downstream AI training. The DTI Engine catches what traditional quality checks miss: the gap between what a code says and what it means.
This same principle applies to HL7 message quality, where legacy data formats carry structural ambiguity that must be scored before any model touches the data.
The cost of unscored clinical terminology
The financial cost of SNOMED CT mapping failures is difficult to isolate from the broader cost of bad health data, which SuperTruth estimates at $3.5 trillion in system-wide waste. But the operational costs are specific and measurable.
Every time a health AI model produces a cohort estimate that is skewed by inconsistent SNOMED mappings, the downstream decisions built on that estimate carry the error forward. In clinical trials, this means recruiting patients who do not actually meet inclusion criteria. In real-world evidence studies, this means submitting data to the FDA that cannot withstand audit. In population health models, this means misallocating resources based on prevalence estimates that reflect mapping artifacts, not disease burden.
The alternative is scoring SNOMED-coded data before it enters any AI pipeline. This means checking concept validity against the current SNOMED release, verifying mapping consistency across sources, flagging retired concepts that have not been updated, and measuring concordance between SNOMED codes and their mapped ICD-10, CPT, and LOINC equivalents.
What fixing SNOMED CT mapping trust looks like
Fixing SNOMED CT mapping trust is not a one-time data cleaning project. It is an ongoing governance function that must operate at the point of data ingestion, not after the fact.
The process requires four capabilities.
Automated version detection. Every SNOMED-coded record must be tagged with the SNOMED edition and release version used at the time of encoding. Without this metadata, downstream systems cannot determine whether two identical concept codes were produced under the same mapping rules.
Concept lifecycle tracking. When SNOMED International retires, splits, or merges a concept, every downstream system that holds records with that concept must be notified and updated. This is not optional maintenance. It is a data integrity requirement.
Cross-map validation. SNOMED-to-ICD-10, SNOMED-to-LOINC, and SNOMED-to-RxNorm mappings must be validated against the current mapping tables published by the National Library of Medicine. Stale cross-maps are a primary source of concordance failure.
Trust scoring at ingestion. Every SNOMED-coded record entering an AI training pipeline, a research database, or a clinical decision support system must be scored for provenance, concordance, and recency before it is used. This is what the DTI Engine does. It does not clean the data. It tells you whether the data is trustworthy enough for your intended use.
The SNOMED CT problem is a data trust problem
SNOMED CT is not broken. It is one of the most carefully maintained clinical terminology systems in the world. But the infrastructure surrounding SNOMED CT, the mapping layers, the EHR configurations, the extraction pipelines, and the AI training workflows, does not maintain the same standard of rigor.
The result is a gap between what SNOMED CT can do and what organizations actually get from it. Closing that gap requires treating clinical terminology mapping as a trust dimension, not a technical detail.
Organizations that score SNOMED-coded data before it enters their AI systems will build models that reflect clinical reality. Organizations that do not will build models that reflect mapping artifacts. The difference between those two outcomes determines whether health AI helps patients or harms them.
The DTI Engine scores every health data record 0-100 across 8 trust dimensions before your AI model sees it. For organizations working with SNOMED-coded clinical data across multiple sources, concordance and provenance scoring are the difference between a training dataset you can defend and one you cannot. If your team is evaluating data for training, compliance, or clinical use, schedule a conversation with the SuperTruth commercial team or (215) 918-4140.
Further reading:
Jason Alan Snyder
Co-founder of SuperTruth and Artists & Robots, and an inventor on the Data Trust Index patents. Twenty-plus years building technology inside Interpublic Group. He writes here nearly every day on data trust, provenance, and what AI should be allowed to act on, and publishes essays on his Substack.
About SuperTruth · LinkedIn · Substack · jasonalansnyder.com
See it in practice
DTI scores the record, not the patient.
8 dimensions. 0 to 100. Travels with every record permanently.