Problem Lists: The Cacophony of Concatenation

I have spent some time recently looking into terminologies that are used to represent problem lists. Specifically the terminologies in question are the current de facto standard ICD-9, its successor ICD-10CM and the big Kahuna SNOMED-CT.

This is a good time to be looking at these, as the healthcare IT industry is starting to evolve electronic patient records (regardless of what acronym you use for it) to be a more useful and accurate picture of the patient's state. Until recently the patient's problems were (a) not represented in their electronic records, (b) represented using a home grown code that, aside from providing a display name, provided little support for leveragable decision support or (c) represented using an ICD-9CM code.

As I reviewed these terminologies, I ran across something that concerned me. The concern is with regard to concatenated terms in these terminologies.

What is a Concatenated Term?

A concatenated or combination term is a term that is, in actuality, multiple terms combined together under a single concept identifier.

Here is an example in ICD9CM:

404 - Hypertensive heart and chronic kidney disease

As opposed to the individual single terms:

402 - Hypertensive heart disease
585 - Chronic kidney disease (CKD)

In some cases it can be even more interesting:

404.00 - Hypertensive heart and chronic kidney disease, malignant, without mention of heart failure and with chronic kidney disease stage I through stage IV, or unspecified

当我看到这个ICD9CM,我认为这是一个legacy issue and existed because ICD9CM has been around for awhile. So I looked in ICD10-CM...

I132 - Hypertensive heart and chronic kidney disease with heart failure and with stage V chronic kidney disease, or end stage renal disease

And then I looked at SNOMED-CT...

194779001 - Hypertensive heart and renal disease with (congestive) heart failure

So, as it turns out, it is still an ongoing practice to create concatenated terms. This is not a legacy thing, or it is a legacy thing that has found its way into the terminologies we are supposed to use as we move forward.

I want to stop at this point and remind the reader that I am not a clinical person. I am a simple country programmer and guerilla informaticist. So there might be a reason for this I am not seeing. If there is, I want to know and I will post it here as a follow up.

Here is what was said on the American Health Insurance Management Association (AHIMA) website in an article about ICD10-CM enhancements regarding combination codes.

"ICD-10-CM includes combination codes for conditions and common symptoms or manifestations. A single code may be used to classify two diagnoses, a diagnosis with an associated sign or symptom, or a diagnosis with an associated complication. This allows one code to be assigned, resulting in fewer cases requiring more than one code and reducing sequencing problems.

Coding professionals have encountered sequencing dilemmas when coding conditions such as unstable angina with arteriosclerotic heart disease or diabetes mellitus with a complication/manifestation such as diabetic nephropathy. Manifestation/etiology conditions require two codes with sequencing mandated by ICD-9-CM. Brackets in the index identified that the etiology (diabetes mellitus) code was sequenced before the manifestation (diabetic nephropathy).

In cases when ICD-9-CM did not indicate correct sequencing, coding was not clear-cut, andCoding Clinicadvice was needed to sequence conditions appropriately. The ICD-10-CM use of combination codes has greatly simplified this process."

My concern is how we are using terminology and the compromises we need to make to drive a specific purpose.
In the case of patient problem terminologies, it can boil down to:

(a) Are we trying to solve a sequencing problem to support re-imbursement?

or

(b) Are we trying to allow the computer to assist with the heavy lifting by providing terms that can drive decision support?

Concatenated terms can assist with providing a refined display, with a single click of the patient's complex problem and, apparently, assist with sequencing for coding purposes. However, this can come at the expense of accurate and fast decision support.

Why do I say this?

When you create a decision support rule in healthcare, very often the rule fires based on the juxtaposition of elements of the patients clinical context. For example, a drug-drug interaction is an overlap of two drugs that are currently, or about to be, prescribed on a patient's medical record. Similarly, a contraindication is the overlap of a medication and a patient problem that is known to create a patient safety risk.

By way of example, let's take a fictional medication ‘Nancycillin' and say that it is absolutely contraindicated in patients with Hypertensive heart disease. If we use ICD9CM, in order to support that rule in our engine, we may setup the following rule:

Nancycillin[is absolutely contraindicated in patients with] (402)Hypertensive heart disease

If I set the above simple rule and the patient has the following in their EMR

Fred Flintstone

Problems:

• Hypertensive Heart Disease (402)
• Hypertensive renal disease, unspecified (403.9)
• Renal Failure (586)

The rule would fire just fine.

However, If I had added instead:

• 高血压心脏和肾脏疾病,未指定的,with renal failure (404.92)

The rule wouldnot fireand my patient might have a problem.

To handle the concatenated term we need to setup a collection of rules to cover the potential concatenated terms as follows:

Nancycillin[is absolutely contraindicated in patients with] ...

This is a potential issue, as the people setting up rules are not always in control of the terminology and I would imagine that next week a new concatenated term with ‘hypertensive heart disease' could be added to the terminology and there would still be a terminological gap.

Relationships to the rescue?

This is a problem in ICD9-CM and ICD10-CM, what about SNOMED-CT? SNOMED-CT, as I mentioned, has concatenated terms, but it also has something else...relationships. Can the relationships in SNOMED-CT bridge this issue?

In the SNOMED-CT relationships table, if you use a concatenated term there is a way to break it into its antecedents through the relationships table using the 'is a' relationship type.

Let's take our SNOMED-CT example of:

Hypertensive heart and renal disease with (congestive) heart failure

It has the following related terms in the SNOMED_CT Relationships Table:

It breaks down the term into parent terms using the ‘Is a' relationship type. But if you look at the second one, you see that it is also a concatenated term. When we break that one down we get the following:

It is worth noting that each of these terms also breaks down (or breaks UP) to a parent or parents. Using the relationship structure when I am done the term ‘Hypertensive heart and renal disease with (congestive) heart failure' results in 72 ‘Is a' antecedents (clickherefor the full list).

In order to accurately process my rules using the relationship table, I need to traverse the SNOMED-CT relationships across 72 antecedents, for this one term alone. Keep in mind, this has to be done for every term because I have no way of knowing which terms are concatenated and which ones are single.

So what's missing?

In order to deal with the issues, there are a few things that would come in handy.

Concatenated Term Indicator

A flag on a term that indicates that it is comprised of more than a single concept would provide the savvy terminology consumer with the ability to apply special processing or avoid concatenated terms altogether.

Concatenated Term to Components Relationship

If these terminologies provided relationships to their component terms that would be even better. This would not be like the ‘is a' relationships in SNOMED-CT. The ‘Is a' relationship is an ontological relationship that relates concepts into the conceptual framework of SNOMED-CT. This would be a compositional link relating a concatenated term to the single conceptual terms that, when combined, are the conceptual equal of the concatenated term. In this relationship structure a concatenated term would never link to another concatenated term.