When you are trying to implement a terminology in a software application, the intent of the terminology can have a significant impact on how easy or difficult that process will be.  A terminology that was designed for software tends to elegantly support the patterns of use.  This type of terminology, if you are a data nerd like I am, is a delight to work with and makes the life of the integrator much easier.

Unfortunately, ICD-10-CM is not that kind of terminology.  ICD-10-CM is clunky, unstable and requires significant manual intervention to leverage the information in the format provided by CMS.  if you are wondering why this would be the case, you just have to remember that ICD-10-CM is first and foremost… a book.

To understand a terminology, you need to know its history, purpose and drivers.  When you examine the ICD-10-CM terminology, it is easy to see that it has been, and still is, meant to be a book.  Not the kind of book you want to curl up with and read in a Naugahyde chair by the fireplace. It is the book you use to find codes and perhaps kill a large spider with when you are not wearing shoes.

You might be asking “Charlie, how can you say it is a book?  What evidence do you have to support this outlandish claim?”  I will back up my claim with irrefutable evidence.

The Evidence

Exhibit A – Loosely coupled and unstable hierarchy

The codes are organized first into chapters, twenty-one to be exact.

These chapters divide the codes into groupings based on a combination of etiology, body system and code purpose.  These chapters do not have stale identifiers, but are typically correlated to numbers based on the chapter sequence.

Each chapter is divided into sections.

These sections logically group the rubrics (three digit codes) into a code range.  The sections do not have stable identifiers but are typically associated with the code ranges.  For example, in chapter 11, “Diseases of the digestive system,” there is a section called ‘Diseases of appendix’ that covers rubrics from K35 to K38.

In a true terminology, the organizational hierarchy would have stable identifiers that are unambiguously linked to the rubrics.  In this case, the chapters and sections would be classes and subclasses used to organize and navigate the rubrics they contain.

Chapters and sections are artifacts typically found in a…what do you call it?  Oh yeah… a book.

Exhibit B – Alpha Indexes instead of synonyms

ICD-10-CM has three “Alpha Indexes”.  The Alphabetic Index consists of the following parts: the Index of Diseases and Injury, the Index of External Causes of Injury, the Table of Neoplasms and the Table of Drugs and Chemicals.

The idea is that the user goes to the appropriate alpha index and finds the words they are looking for and that listing either directs them to the appropriate code OR redirects them to another word in the alpha index.

For example:

Let’s say you were looking for the code for “Abdominalgia”…

You would go to the “Index of Diseases and Injury” and run your finger down the list until you find it.  Next to it you would see the following:

See Pain, Abdominal

You would then flip the index to the P’s and run your finger down the list to “Pain, Abdominal” and you would see 16 codes and in that list you find the one you want “Pain, abdominal, rebound” and next to it you see the following:

See Tenderness, abdominal, rebound

So we flip the index again to the T’s and find what we are looking for “Tenderness, abdominal, rebound” and next to it you see eight codes and you pick the basic one: R10.829

The external cause index works in a similar fashion to this.

The drug and neoplasm tables are used to establish lookup grids for pre-coordinated scenarios.
In the Table of Neoplasms, the alpha index items are anatomic locations for each row and each column represents the nature of the neoplasm (Benign, In Situ, Uncertain, Unspecified, Malignant Primary, Malignant Secondary) with additional “manifestation” codes and “see also” codes listed when appropriate.

In the table of Drugs, the alpha index items are the drug formulations for each row and each column represents a drug-related event (Adverse Effect, Underdosing, Intentional Poisoning, Accidental Poisoning, Assault Poisoning and undetermined poisoning) with “see also” codes listed when appropriate.
Alphabetic indexes are something you find in the back of (wait for it) … a book.

Exhibit C – Important relationships and associations conveyed as unstructured text

ICD-10-CM codes have relationships to other codes.  They might be designated as ‘Code Also’, ‘Code Additional’, ‘Code First’, ‘Excludes1 (does not include)’, ‘Excludes2 (Should not be coded with)’ and ‘Includes’ (which is actually more synonyms).  How are these relationships provided?  As wild carded text in the chapter, section or code header associated with the codes in the book.

Here is an example of this from the XML provided by CMS:

E09 – Drug or chemical induced diabetes mellitus

Code First

poisoning due to drug or toxin, if applicable (T36-T65 with fifth or sixth character 1-4 or 6)

Use additional

code for adverse effect, if applicable, to identify drug (T36-T50 with fifth or sixth character 5) code to identify any insulin use (Z79.4)

Excludes1:

diabetes mellitus due to underlying condition (E08.-)
gestational diabetes (O24.4-)
neonatal diabetes mellitus (P70.2)
postpancreatectomy diabetes mellitus (E13.-)
postprocedural diabetes mellitus (E13.-)
secondary diabetes mellitus NEC (E13.-)
type 1 diabetes mellitus (E10.-)
type 2 diabetes mellitus (E11.-)

As humans reading a book, we can see the above information and sort out the details.  If ICD-10-CM were meant to be a terminology, this ontological information would be conveyed via concrete relationships between terms.  This would make it easier for the software to assist the human in understanding how the codes should be used together to fulfill their objective.

Terminologies provide relationships as defined links between terms (a structure typically referred to as triples (code->relationship type->code). This makes it easier for the software to consume so that it can provide concrete assistance.

Exhibit D – Um… it’s a BOOK!

Ladies and gentlemen – photographic evidence that the defendant is in fact a book.   This information format being its primary delivery system be it in electronic or hard back form.  The prosecution rests.

(Sorry – watched a Matlock marathon last weekend and got a little carried away…)

What does it all mean?

As I said at the beginning of this post, to understand a terminology, its capabilities and limitations, it is always best to understand its origins, code structure and intent.  In the case if ICD-10-CM, the fact that it is designed to be first and foremost a book just means that we need to lower our expectations of its capabilities as a terminology.

In the case of ICD-10-CM, what this means is that in its “natural” form (for example, if you get the XML from CMS like we do), the content has the following limitations:

1. It is challenging to search for a term – in its natural state, all synonymy is trapped in the indexes.  The indexes are not structured in a way that makes them easy to implement.  This makes ICD-10-CM difficult to integrate into an application unless you do some work to build or license an interface terminology.

2. It is challenging to browse the hierarchy – while the rubric-based hierarchy is logical, it is not provided as an actual hierarchy with relationships.  Also, since the chapters and sections lack stable identifiers, it is up to the implementer to stabilize them and synthesize the implied hierarchy for the chapter, section and rubric.

3. It is challenging to traverse relationships – because the relationships like “code-first,” “code also,”  “excludes,” etc. are not managed as triples, but rather as ranged free text expressions.  There is no practical way to navigate them without human or advanced algorithmic interpretation.

In healthcare, we are still in transition, still evolving away from a model in which humans in back rooms are mapping and coding.  ICD-10-CM is a remnant of that old model.  In the domain of “modern” informatics, the latest and greatest terminology we are being mandated to use is an anachronism, the equivalent to a View-Master in a world full of Virtual Reality headsets.

What can we do about it?

We can finds ways to cope with it.  ICD-10-CM is moving ahead and, despite the issues it represents, I think it is the right decision.  Mostly because as an industry, we have put too much time and money into making it happen. If we don’t do it now, how much credibility will we be able to salvage?  At this point, it is a moral imperative.

The Silver Lining

Sometimes you have to get to a tipping point, a point where you say to yourself, “Wow, that was not a good idea.”  This tipping point forces you to reconsider the direction, perhaps even to question everything.   It is how we gain experience.  I believe that ICD-10-CM is that tipping point for pre-coordinated terminologies in healthcare that could help us to change how we think in the future.

In the meantime, at Clinical Architecture, we have created a version of ICD-10-CM in which we have transformed what we found in the ICD-10-CM XML from CMS into an actual stable ontology.  We provide this at no additional charge to our Symedical® clients (along with over 400 other content assets).  We will also be making this available as a flat file data offering in our Content Cloud, which will be available at the end of July.  Feel free to contact us if you would like to learn more.

I am going to take a break from ICD-10-CM for a while.  If you have any question or additional thoughts, please leave them in the comments and I will be happy to share and address them.