SNOMED CT vs ICD-10: when to use which

New engineers in healthcare data ask the same question after a week on the job: "if SNOMED already covers diagnoses, why do we also need ICD-10?" The answer is that the two systems were built for different jobs, and the right answer for production is usually to store both and translate between them. This post explains the difference, the design implications, and how AutoICD bridges them.

The two systems, briefly

SNOMED CT is a clinical terminology. It is owned by SNOMED International, distributed under license through national release centres (NLM in the US), and structured as a polyhierarchy of concepts with formally defined relationships. The international edition has more than 350,000 active concepts; the US Edition adds a country-specific extension. Concepts cover findings, disorders, procedures, body structures, organisms, substances, situations, and events; it is a vocabulary intended to capture what was observed and done.

ICD-10 is a classification. The WHO publishes a base ICD-10 for global mortality and morbidity reporting; the US clinical modification, ICD-10-CM, is governed by CMS and NCHS for billing and statistics, with roughly 74,000 codes in the FY2025 release. Codes are arranged in a strict hierarchy of chapters, blocks, three-character categories, and billable subcategories. The structure is optimised for grouping conditions into reimbursement bundles, not for representing fine-grained clinical truth.

What that difference means

The mismatch shows up in everything from API design to UX:

• Granularity: SNOMED has many concepts that map to one ICD-10 code. "Acute exacerbation of chronic obstructive bronchitis" and "acute exacerbation of asthmatic bronchitis" are distinct SNOMED concepts that both crosswalk to J44.1 in ICD-10-CM.
• Polyhierarchy: a SNOMED concept can have multiple parents (a clinical-finding view and an immune-mediated view, say). ICD-10 codes have exactly one parent.
• Composability: SNOMED supports post-coordination, where you compose a concept by attaching qualifiers to a base concept. ICD-10 captures detail by enumerating codes; you cannot mint a new code at runtime.
• Update cadence: SNOMED CT international ships twice a year; ICD-10-CM ships annually with an October 1 effective date. Mid-year ICD-10-CM addenda are rare, so most teams treat the file as static for nine months out of twelve.
• Licensing: SNOMED CT requires a license from SNOMED International (free in member countries via the affiliate program). ICD-10-CM is in the public domain in the US.

When to use which, in practice

Use SNOMED CT for

• Storing the clinical truth of an encounter at the level of granularity the clinician documented. If the note says "acute febrile illness with cervical lymphadenitis" you want a SNOMED concept that says exactly that, not a billing bucket.
• Driving clinical decision support, allergy checking, and problem-list semantics. SNOMED's relationship model lets a CDS rule say "any concept that is a descendant of penicillin allergy" and have it actually work.
• Cross-institutional interop where the receiving system needs to reason about clinical meaning, not bill against it.

Use ICD-10-CM for

• Anything that touches a claim, an encounter summary that flows downstream to billing, or a CMS-mandated quality report.
• Statistical reporting where the recipient expects classification-grade groupings (CDC NCHS data, Medicaid reporting, public-health surveillance).
• Risk-adjustment workflows. HCC v22 and v28 are defined over ICD-10-CM, and the SNOMED-to-HCC path runs through ICD-10 anyway.

In short: SNOMED captures what happened, ICD-10 captures what gets billed for. A patient record that has both is a patient record that survives every downstream consumer.

Bridging them with AutoICD

AutoICD treats both as first-class data and ships a precomputed cross-map between them. Three patterns cover almost every integration:

Pattern 1: code clinical text directly in ICD-10

If your input is free-text and you need ICD-10-CM at the output, call /v1/code with default options. The two-pass strategy uses SNOMED CT internally as part of the term index but returns ICD-10-CM codes:

import { AutoICD } from "autoicd-js";

const client = new AutoICD({ apiKey: "sk_..." });

const result = await client.code(
  "Patient with type 2 diabetes mellitus and chronic kidney disease stage 3.",
  { includeSnomed: true },
);

for (const entity of result.entities) {
  const top = entity.codes[0];
  const snomed = entity.cross_references?.snomed?.[0];
  console.log(`${entity.entity_text} -> ${top?.code} (SNOMED ${snomed})`);
}

Pattern 2: translate a known SNOMED code to ICD-10

If you already have a SNOMED concept ID (from an EHR problem list, for example) and need the ICD-10 equivalent for billing, /v1/translate is the right call:

const result = await client.translate({
  from: { code: "44054006", system: "snomed" }, // type 2 diabetes
  to: ["icd10"],
});
console.log(result.mappings.icd10);
//   [{ code: "E11.9", description: "Type 2 diabetes mellitus without complications", confidence: 1.0 }]

Pattern 3: read both representations of one code

If a user lands on an ICD-10 code page and you want to surface the SNOMED equivalents and synonyms inline, the unified reference lookup gives you all of it in a single call. See /reference/snomed-ct and /reference/icd-10 for the directory pages, or hit the API directly:

const detail = await client.reference.lookup("icd-10-cm", "E11.9");
if (detail.system === "icd-10-cm") {
  console.log(detail.record.long_description);
  console.log(detail.record.cross_references.snomed);
  // ["44054006", ...]
}

What about UMLS

UMLS sits on top of both. A UMLS Concept Unique Identifier (CUI) is the meta-concept that groups SNOMED, ICD-10, ICD-11, RxNorm, MeSH, and other source-vocabulary atoms together. If your application has to talk to multiple terminology suppliers, UMLS is the bridge; if you only ship one or two systems, you can usually skip it. AutoICD's /reference/umls directory and unified lookup expose CUIs alongside the source codes when you need them.