Clinical Architecture Blog

The Medication Concept Continuum
In order to understand how a medication concept can be appropriately leveraged, you need to understand its characteristics and which are required to support a particular activity.
For the purposes of this primer, the term ‘medication concept' covers any entity that represents a medication from the ingredient to the physical packaged product.  This excludes therapeutic classes, allergy classes and other taxonomies that may be used to group or relate medication concepts.  This also excludes a medication order, which is an orchestration of a medication concept with other contextual information (we will talk more about this in a later post...).
The following diagram depicts the Medication Concepts Continuum.  It is intended to provide a ‘cheat sheet' that can be referred to throughout the rest of this lesson.  The characteristic breakdown in this diagram are generalizations and, as such, do not represent the actual structure of any existing drug vocabulary vendor.  To interpret how a particular vendors structure fits into this model, please refer to your vocabulary vendor's documentation.



A medication concept falls into one of three generalizations: Abstract, Dispensable or Actual.
The concepts in the Actual generalization represent things that physically exist in the real world.  You can actually put your hands on one.  A tablet or bottle of tablets, for example, is an actual medication concept.
The concepts in the Dispensable generalization represent things that can be conceptually dispensed and administered to a patient.  Another way to think of them is that they represent a completed notion of a medication.  In other words, if I have a dispensable concept I have sufficient information to select a specific actual concept off of the shelf.
The concepts in the Abstract generalization (which is most of them) represent primitive characteristic concepts or an incomplete combination of characteristics.  This type of concept is typically created to function as a navigation pivot OR a an anchor for additional information.  An example of a multi-characteristic abstract concept would be ‘warfarin sodium tablet' (Ingredient + dose form), which is not sufficient to identify an actual physical entity, but it conveys and idea of an ingredient and whether or not it will affect the patient systemically.
The Davinci Code(s)
When you look at the continuum you will also notice that there is the central inverted pyramid (not unlike the La Pyramide Inversée in front of the Louvre) that represents the continuum of medication concepts.  These are the codes that drive order entry, prescribing, alert checking and med-reconciliation. 
On the right side there is a collection of other concepts.  These other concepts are primitives.
You can think of the primitives as the raw building blocks that, when combined, establish the medication concepts that we find in the continuum.  Examples of a primitive would be ‘route of administration', ‘dosage form' and ‘unit of measure'.   For obvious reasons, these are critical to the meaning and stability of the medication concepts.  We cover them in more detail in a future post.
When you examine a drug concept it is important to note where it plugs into the continuum.  In many ways, that will give you an idea as to what you can actually do with it:

• To dispense a medication you need a dispensable
• To determine if a medication systemically affects the patient you need dose form and/or implied route
• To properly validate the dose you need to know the period of release
• To determine the inactive ingredients in a medication you need to know who manufactured it
• To be able to scan it with a bar code reader you may need to know its packaging details.

You may think it sound straight forward, but I have seen attempts to use the wrong concept for the wrong purpose and, like trying to make fruit smoothie with a chipper shredder... it did not end well.
The next topic will be how medication ingredients are typically represented and why it is not always as straightforward as it seems.

Part One - The Medication Domain
As we enter the second decade of the 21^st 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.