ICD-11 has no clean map from ICD-10
ยท 9 min read
Nobody wants to read about disease classification codes. I did not want to work on them either. Then I spent months on a cancer registry and came out convinced that coding is where most health data quality is silently won or lost, long before anybody trains a model on it.
This is the post I needed when I started.
The thing people assume
Most engineers approach an ICD-10 to ICD-11 migration the way they would approach any schema change. Find the mapping table, write the transform, run it, verify counts, done. Coding systems look like enums, so they get treated like enums.
The assumption underneath that is a one to one correspondence between old codes and new codes. For a large part of any real registry, that correspondence does not exist, and no amount of engineering rigour creates it.
Why the structure changed
ICD-10 is essentially a hierarchy of codes you pick from. One diagnosis, one code, walk the tree until you find the leaf that fits.
ICD-11 is built differently. Underneath it there is a foundation of entities, and what you actually code against is a linearisation drawn from that foundation. More importantly for anyone building a registry, it supports postcoordination. You combine a stem code with extension codes to express things that ICD-10 forced into either a single overloaded code or a free text note. Laterality, severity, histology, anatomical detail, all of these can attach as structured extensions rather than being baked into one string.
That is a genuine improvement in expressiveness. It is also exactly why the migration is not a lookup.
The four cases, and why three of them hurt
One to one. Fine. Automate it, move on. In our registry this covered a decent share of records and gave a false sense of how the whole job would go.
One to many. The old code splits into several new ones, distinguished by detail that ICD-11 can express and ICD-10 could not. If the original record contains that detail somewhere, in a pathology report, in free text, you can sometimes recover it. If it does not, you cannot. Choosing the most common subtype is tempting and it fabricates precision.
Many to one. Two old codes collapse into one new one. This looks harmless because nothing is lost at the record level. It is not harmless if anybody ever ran a time series on the difference between those two codes, which for a cancer registry is the entire point of having one.
No direct equivalent. The category was restructured, and there is a judgement to make about where a historical record now belongs. There is no algorithmic answer. There is a defensible answer and an indefensible one, and telling them apart requires knowing oncology.
Why oncology is worse than most
Cancer is a bad case for this because a tumour is not one fact. It is a site, a morphology, a behaviour, a grade, sometimes a laterality, sometimes a stage. Cancer registries have historically leaned on a separate oncology specific coding system for morphology and topography, alongside ICD for the diagnosis.
ICD-11 changes how some of that fits together. That means a migration is not just old code to new code. It is a question about which system owns which fact, and whether your registry's existing split between them still makes sense. We spent more time on that than on any code writing.
What we built instead of a transform
The decision that shaped the whole project was accepting that the coding step keeps a human in it permanently, not as a temporary measure during migration.
So the pipeline sorts rather than converts. Records that map cleanly go through automatically. Records that hit any of the other three cases get routed to a queue with the candidate targets, the evidence available from the source record, and the reason it was flagged. A person decides. The decision gets stored with the record, not just applied to it.
That last part is the piece I would argue hardest for. Storing the decision, the date and the basis means that in five years when somebody questions a trend, the registry can answer whether it is biology or bookkeeping. A migration that overwrites codes in place destroys the ability to ever ask that question again.
A registry that cannot tell you why a code changed cannot tell you whether an incidence trend is real.
The part that applies beyond ICD
I think the general lesson is about where automation belongs.
The instinct with a mapping problem is to push automation as far as possible and treat the leftovers as failures. Inverting that worked better. Automate only the provably unambiguous, then invest the effort in making the ambiguous cases fast and well presented for the person deciding. Our win was not a smarter mapper. It was a queue that showed a coder everything they needed in one screen so a decision took seconds instead of minutes.
That is a less exciting result than an automated migration. It is also the one that survives audit, which for a registry feeding national surveillance is the only property that matters.
If you are about to do this
Three things worth knowing before you start.
Count your cases before you plan. Run the mapping tables against your actual distribution and find out what fraction of your records fall into each of the four cases. That number decides whether this is a two month project or a year, and it is specific to your registry.
Decide the ambiguous policy with clinicians before writing code. Not during. Every ambiguous class needs a written rule and a named person who agreed to it.
Keep both codes. Storage is cheap and regret is not. Retain the original code alongside the new one indefinitely.
If you are working on registry infrastructure or ICD-11 adoption, I would like to compare notes. isararsiddique@gmail.com