ICD-10 to ICD-11 migration: what changes for billing systems

ICD-11 has been the WHO's official global classification since January 2022. Adoption by member states is uneven and on a much longer clock than the protocol announcement; in the United States the regulator-mandated billing classification is still ICD-10-CM, with no published transition date. That gap is exactly where engineering teams land: build for the standard you bill against today, but make the data layer survive an eventual cutover and any near-term dual-coding requirements (research datasets, international subsidiaries, WHO reporting).

This post covers the structural differences that actually move bytes around in your system, and shows how to use AutoICD's /v1/translate endpoint to bridge the two during a dual-coding period.

Five differences that affect your schema

1. Code shape

ICD-10-CM codes are a letter, two digits, and an optional dotted suffix of up to four characters (J44.1, T81.4XXA). ICD-11 MMS uses a four-character stem starting with a letter and three digits, optionally extended with a dotted suffix and post-coordinated extensions (CA22.1, 1A00.0). Treat the column as wider, alphanumeric throughout, and case-sensitive.

2. Stem codes and post-coordination

ICD-10 captures detail by lengthening the code; ICD-11 captures it by attaching extension codes to a stem with an ampersand or slash separator, an approach the WHO calls post-coordination. A single billable expression in ICD-11 can therefore be a cluster of codes rather than a single string. Storage layers should accept the cluster, not just the stem, and string-equality comparisons need to canonicalise extension order before treating two codes as equal.

3. Extension codes

Extensions cover dimensions that used to live in separate ICD-10 chapters or in the seventh-character convention: severity, temporality, anatomy, agent, histopathology, consciousness, dimensional ratings. They are real codes drawn from chapter X (the extension chapter) and they post-coordinate onto stem codes. The AutoICD reference index has every extension code and lists the stems that accept it: /reference/icd-11.

4. Hierarchy and chapter shape

ICD-11 has 26 main chapters; ICD-10 has 22. New chapters cover sleep-wake disorders, conditions related to sexual health, and traditional medicine modules. Some content has migrated; for example, immune system disorders now have their own chapter rather than living inside the endocrine chapter. If you cache chapter membership, expect a one-time refresh.

5. Multiple parenting

ICD-10 is a strict tree: every code has exactly one parent. ICD-11 allows multiple parenting, which means a single code can appear under more than one ancestor depending on the clinical view (for example, an inflammatory eye condition can sit under both the eye chapter and the immune-system chapter). Tree walks that assume a unique parent will need adjusting; reach for a graph traversal instead.

What about the timeline

WHO endorsed ICD-11 in May 2019 and brought it into effect on January 1, 2022. Country adoption is set per member state. In the US the billing classification is ICD-10-CM, governed by CMS and NCHS; CMS has not published a deadline for an ICD-11 cutover. International subsidiaries, mortality reporting, and global research consortia are already producing ICD-11-coded data, so you are likely to see ICD-11 in inputs long before you bill in it. Designing for both, with a translation layer between them, is the durable position.

Translating with /v1/translate

AutoICD's translate endpoint maps a code in one classification to its equivalents in others. The TypeScript SDK exposes it as a single method:

import { AutoICD } from "autoicd-js";

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

const result = await client.translate({
  from: { code: "J44.1", system: "icd10" },
  to: ["icd11", "snomed"],
});

console.log(result.mappings.icd11);
//   [{ code: "CA22.0", description: "Chronic obstructive pulmonary disease with acute exacerbation", confidence: 0.94 }]
console.log(result.mappings.snomed);
//   [{ code: "195951007", description: "Acute exacerbation of chronic obstructive airways disease (disorder)", confidence: 0.97 }]

The mapping data is built from the WHO ICD-10/ICD-11 reference tables, the SNOMED CT international refset, and a manually curated overlay for the codes where the WHO mapping is one-to-many. Confidence scores reflect how clean the mapping is: a 1.0 means a documented one-to-one in the WHO tables, a sub-0.9 score means there is fan-out and you should expect to disambiguate.

A dual-coding pattern that works

When teams ask how to handle dual-coding without doubling their LLM bill, the pattern that holds up is:

1. Code the clinical note once, in your billing classification (ICD-10-CM in the US).
2. On a per-record basis, call /v1/translate to derive the ICD-11 equivalent for storage and reporting.
3. Cache the translation. The mapping is stable across the WHO release, so a simple key-value cache keyed on (source_system, source_code, target_system) cuts almost all repeat calls.
4. When ICD-11 is the primary billing target (most likely in non-US deployments), invert the pattern: code in ICD-11, translate to ICD-10-CM only for legacy claims or research linkage.

If you ever need to round-trip, do it explicitly and store both. The mapping is not symmetric for codes that live under different parents in the two classifications, so going A → B → A can give you back a slightly different code, especially in chapters that were restructured.