Every terminology conversation eventually lands on the same question. Should the record hold a SNOMED CT concept or an ICD-10 code? The two vocabularies solve different problems and the choice is rarely either-or. In practice most mature stacks carry both, in different fields, for different reasons.
For the broader context, the wider FHIR resource set has related notes. The site's SNOMED CT common-concepts browser sticks to SNOMED because that is where clinical documentation actually lives.
What Each Vocabulary Is Built To Do
SNOMED CT is the vocabulary for clinical documentation. It captures findings, procedures, situations with explicit context, and body structures with a level of granularity that matches how a clinician actually thinks. It supports post-coordination for the tail of concepts that need composition rather than lookup.
ICD-10 is the vocabulary for classification. It groups conditions into buckets that support reporting, billing, epidemiology, and administrative decisions. It is deliberately coarser than SNOMED for that job.
The short version: SNOMED describes what the clinician saw and did; ICD-10 describes how the case gets counted.
Use SNOMED For Anything That Feeds Clinical Decisions
- Problem list entries that drive downstream logic
- Reasons for encounter that route ordering rules
- Procedure documentation that flows into follow-up decisions
- Observation qualifiers that need composition
- Anything that a decision support module reads
Every one of those has to be granular enough that a rule can fire on it. ICD-10 is too coarse. Two ICD-10 codes can hide meaningfully different clinical situations that a rule needs to distinguish.
Use ICD-10 For Anything That Feeds Reporting
- Billing submissions where the payer expects ICD-10
- Population health rollups keyed to standard groupers
- Regulatory reports built against ICD-10 taxonomies
- Historical trend analysis where the corpus is ICD-10
- Case-mix calculations tied to ICD-10 categories
Trying to force SNOMED into these workflows is expensive and rarely accepted. Reporting infrastructure has ICD-10 baked in for decades.
Where They Cross: The Map Step
Some fields need both. A problem list stores SNOMED for granularity and derives ICD-10 for reporting. That derivation is a map operation, not a translation, and the map is not free. SNOMED-to-ICD-10 maps are lossy by design: multiple SNOMED concepts collapse to one ICD-10 code, and one SNOMED concept can map to several ICD-10 codes with context.
Maintain the map with a real terminology tool. Do not hand-roll it in a spreadsheet, and do not assume the map from the vendor is complete for your jurisdiction. It probably is not.
What Not To Do
Storing ICD-10 where clinical decisions read it makes decision support hunt for granularity that is not there. Storing SNOMED where reporting reads it makes the reporting layer do work it was not built for. Both mistakes are common and both produce workflows that look fine on demo day and drift into fragility over the next year.
For teams that need to figure out what to do when the incoming concept is ambiguous — one code coming in that maps to two clinically distinct facts — handling ambiguous SNOMED concepts in a downstream system is the deep dive.
The Reference Set Escape Hatch
Even when SNOMED is the right call, the raw vocabulary can be too broad. Reference sets narrow SNOMED to a curated subset for a specific domain, and that curation makes the "what do I show the user" question much easier. Reference sets: the SNOMED feature that shrinks your problem walks through the pattern.
And for teams that still need to get from a clinician's phrasing into a SNOMED concept in the first place, searching SNOMED CT when you only have a free-text symptom covers the search side.
Sources
- WHO official ICD-10 classification browser - WHO official ICD-10 classification browser, canonical reference
