Clinical Architecture Blog

Medication Concepts - Engineering Primer [Part One]

Part One - The Medication Domain
As we enter the second decade of the 21st century, we have been given a mandate to evolve our simplistic, episodic and transient patient records into the robust, longitudinal, and precise paragons of technology that has been promised in board meetings, speeches and science fiction movies.  This can be accomplished.  Like all good architecture, achieving this objective will require an evolution over time that starts with stable foundational concepts that support the goal.  There are a number of domains of clinical terminology: problems, procedures, laboratory tests, nursing orders, etc.  One of the most pervasive and complicated of these is medications.

The purpose of this series on medication concepts for engineers is to provide a overview of the moving parts of medications, how they exist in terminologies today, how they are used in systems today and how they could be used in the future to the betterment of healthcare IT.

Medication concepts are used throughout applications in healthcare information technology in various ways.  They are used to order medications, record allergies, track inventory, manage purchase pricing, identify insurance coverage, transmit prescriptions, trigger alerts and workflow rules, and the list goes on.  It should not be a surprise that the ways that medications are represented in the various standard, proprietary and homegrown terminologies have become quite complicated over the years.

How is the Medication Domain Different?

The medication domain is different from other clinical domains in a few ways.

General functional variability and the resulting ‘Fuzziness'

Unlike a laboratory test or condition, for example, a medication concept can be used to represent something the patient is taking, something I want them to take, something they cannot take (an allergy), something I want to bill for, something I have to pay for and something I have in inventory.  This usage variability, and the overleveraging of existing terminologies to accommodate it, has led to some drug concepts becoming ‘fuzzy' or indistinct as they have been evolved in multiple directions to serve multiple purposes.  This ‘fuzziness' results in many of the "why is it set up like this?' questions that are encountered when an engineer is introduced to the medication domain for the first time.  For example, why do several of the medication terminologies have ‘route' as an attribute of the medication?  To my knowledge there are no medications that have a rectum, so why would a medication have a rectal route?  Why do so few medication terminologies represent bioavailability, when it can have such a significant impact on identifying the right dose? The answers to many of these questions lie in the origins and design drivers behind those concepts.  Medication concepts were used for business transactions before they were used in the clinical setting.  If you do not consider this it is very easy to embrace medication concepts with as number of incorrect assumptions.

Multiple clinical uses and the required attributes

The other difference with the medication domain is the number of clinical decision support functions that can be driven by medication concepts in the delivery of patient care.  Using medication concepts you can check for allergies, check for drug interactions, avoid medication contraindications and verify appropriate dosage levels, just to name a few.   These different uses of medication concepts have different requirements of what characteristics a medication concept must possess in order to drive them correctly.  If you try to drive a particular clinical function with a concept from the wrong level of granularity the result can range from too much clinical advice to no advice or worse, bad advice. 

Multiple levels of granularity

The medication domain is likely the most widely implemented clinical terminology domain in healthcare today.  However, when you take a closer look at how they have been implemented you see that different levels of medication terminologies have been implemented in different ways in these systems.  Medication concepts have been modeled as ingredients, classes, drug and route abstractions, dispensable medications and specific drug products.  In other words, if two applications have implemented medication allergies there is a fairly good chance that they did not do so in the same way or with the same types of medication concepts.

Multiple third party sources

Medication concepts have been around for awhile and were the first concepts used to really drive clinical decision support.  As a result a number of companies have developed stable, updated proprietary medication terminologies and associated clinical content.  This is good as it has provided end user systems with the freedom to stop managing local terminologies and focus on developing sophisticated applications and focus on patient care.  The downside, however, is that these vendors have each created terminologies that are slightly different.  These differences are obvious in some cases and subtle in others.  A misplaced assumption, especially with the subtle differences, can mean the difference in getting a allergy hit or not (or getting a thousand extra allergy hits...)
So... what is a medication concept?  In the next article we will start to examine the characteristics of a medication concepts and how they drive different functionality in healthcare applications.
Posted: 1/3/2010 11:13:48 PM by Global Administrator | with 0 comments

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

When I saw this in the ICD9CM, I assumed it was a 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, and Coding Clinic advice 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?


(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


  • 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: 

  • Hypertensive heart and renal disease, unspecified, with renal failure (404.92)

The rule would not fire and 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] ...

CODE Term Description
404.1 Hypertensive heart and renal disease, benign
404.11 Hypertensive heart and renal disease, benign, with heart failure
404.13 Hypertensive heart and renal disease, benign, with heart failure and renal failure
404.12 Hypertensive heart and renal disease, benign, with renal failure
404.10 Hypertensive heart and renal disease, benign, without mention of heart failure or renal failure
404.9 Hypertensive heart and renal disease, unspecified
404.91 Hypertensive heart and renal disease, unspecified, with heart failure
404.93 Hypertensive heart and renal disease, unspecified, with heart failure and renal failure
404.92 Hypertensive heart and renal disease, unspecified, with renal failure
404.90 Hypertensive heart and renal disease, unspecified, without mention of heart failure or renal failure
402 Hypertensive heart disease

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 (click here for 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.

As an added bonus, if this type of relationship is created it can serve to identify which terms are concatenated. 
This could be done within the existing SNOMED-CT structure by creating a new relationahip type like the 'is a' relationship but based purely on compositional relationships.

If this type of information was available, it could be used when processing clinical decision support to automatically include all concatenated terms that the included term is a component of. 

I am not suggesting this is a simple thing to do, especially when you have terms like the following:

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

What I am suggesting is that in order to create targeted, effective clinical decision support there has to be an effective strategy to deal with concatenated terms.  Without that you place a significant burden on the content authors to accurately cover related concatenated terms with a specific rule.  If you decide to rely on the ontological relationships, in the case of SNOMED-CT, you run the risk of generating significant noise as it can't tell where to stop.

My suggestion, in the short term, for those of you looking into using ICD-9, ICD10 CM or SNOMED-CT to drive diagnosis, problem or procedure codes is to create policies that avoid adding concatenated terms into the subset you are providing to users for selection.  This will help you to avoid the problem and prepare your application for a easier road when, in the future, you begin to try to use those codes to drive clinical decision support.
Posted: 9/12/2009 1:09:20 AM by Global Administrator | with 0 comments

Rule of Thumb – Drug Allergy Alerts

One of the most often implemented clinical decision support modules, across the spectrum of healthcare applications, is drug allergy checking.  In drug allergy checking a patient's allergies, or prior adverse reactions, are noted. When a drug is prescribed, it is checked against the noted allergies to see if there is a possibility that the drug could induce a reaction in the patient.

Straight forward, right?

There are some good rules of thumb from and implementation perspective, when it comes to allergy.  Things that can be missed and not seem important until it is too late.

What is the general pattern for allergy checking?

Computerized drug allergy checking follows the same pattern a provider would if they were checking a free text allergy manually. 

A drug has ingredients, the ingredients may be listed in an allergy class and that class may or may not be in a broader classification that indicates a cross sensitivity between classes.  If I am allergic to ibuprofen and my doctor prescribes ‘ubercough syrup', the allergy checking process simply breaks the prospective drug into its ingredients, checks to see if any of those ingredients are ibuprofen.  If not it begins to walk through the allergy class hierarchies (if available) for each ingredients in the prospective drug to see if there is any overlap between them and the allergy classes related to the ingredient I am allergic to.  Now, it should be noted that the different drug information content vendors have different features and differentiators in their content, but this general pattern is pretty ubiquitous.  To understand how your drug vendor's content specifically works, you should contact them and ask.
When is an allergy not an allergy?
While we speak about ‘allergy checking', there is actually what you might consider the silent partner to allergy checking, prior adverse reaction checking.  An allergy is the result of the body's immune system reacting to a substance that the body views as an invader. The body releases an overload of histamines in response to the attacker substance, which can create symptoms such as a runny nose, itchy eyes, hives, general swelling, vomiting, diarrhea, trouble breathing, quickened heart rate and finally loss of consciousness because of a drop in the person's blood pressure. This is called anaphylaxis.  I point this out just as an FYI.  If a patient has experienced a drug side effect in the past, that is not an allergy.  It is a thin line, but it leads me to my next point.

Ingredient is the best allergen to record, then drug, then class (if you have to).

When noting an allergy in the patient record it is always best to try to get your user to select an ingredient and here are the reasons why.

1.            The actual ingredient always gives you the highest fidelity checking result. 
Saying you are allergic to Acetaminophen relates you allergy to one ingredient... Acetaminophen.  If you say you are allergic to ‘Nyquil' you are telling the allergy checking module you are allergic to Acetaminophen, Dextromethorphan, Doxylamine succinate, Citric acid and Alcohol.  That's a lot of alerts and for someone allergic to Acetaminophen.  If you say you are allergic to a class you are considered as being allergic to all ingredients in that class. (Which may not even be relevant if what you experienced was a adverse reaction and not a true allergy.)

2.            When considering interoperability, ingredients are much better concepts.  Many content vendors share their ingredients in RxNorm.  No content vendor, that I know of, currently shares their allergy classes.   This means that your Patient's allergy, if expressed as a class, will most likely end up as free text in your partner's record.

The bottom line is the patient may not know the ingredient so you can't force it.  However, you may be able to make it easier to select and ingredient as a first choice, since it improve the result for the patient and decreases noise for the provider.

Allergy checking and severity

You shouldn't filter allergy alerts.  But let's say you want to attenuate how annoying you are to the user based on the severity of the potential allergic reaction.  There is something important you need to know.  Unlike other alerting venues, like drug interactions for instance, drug allergy alerts do not have an inherent severity.  The severity of the drug interaction alert is based on the reaction to the allergen the patient reported.  I can be allergic to amoxicillin and my reaction is hives.  You may be allergic to amoxicillin and your reaction is anaphylaxis.  My allergy is mild and yours is life threatening.  (assuming my hives are not life threatening giant hives) The severity comes not from the content, but from the patient.  

Many drug allergy patterns will report the place where the ‘hit' occurred (Ex: it was an ‘ingredient overlap' or a ‘class overlap').  Some will be tempted to treat this overlap-level like a severity and filter out a cross sensitivity or class hit in favor of a ingredient hit.  This would be a mistake, as a cross sensitivity that results in anaphylaxis is likely more relevant that an ingredient hit that results in a rash.  In your application allow the person noting the patient allergies to select a reaction (like ‘Hives') and a severity (like Mild, Moderate, Severe and Life Threatening).    Later you can use this severity to determine how you interact with your user.

In short allergy checking is a great way to prevent a serious problem for a patient.   The drug content vendors have good content supporting it, if you are diligent in implementing it correctly.

Posted: 3/26/2009 10:51:38 PM by Global Administrator | with 0 comments

Subscribe to our blog

Unsubscribe from blog


Clinical Architecture Healthcare IT BlogRSS