When dealing with any terminology domain, to establish a
working understanding, you need to get a handle on the anatomy of a term within
the domain. For example, if you are
looking at a catalog of automobiles you quickly see a pattern that revolves
around the vehicle make, model, production year and other characteristics that
identify the vehicle to the required level of granularity. Regardless of the domain, the pattern
typically becomes broken down into primary characteristics, secondary
characteristics and modifiers. The
primary characteristic is the core of information that is absolutely essential
to the meaning of the term. In other
words, if you began stripping off characteristics the primary characteristics
is where you say ‘when’ so that the term is not rendered ambiguous in the
domain. In our automobile example there
are, arguably, a couple of primary characteristics: the make and model. If someone asks you what you drive you typically
tell them the make and model (unless the model strongly implies the make or you
like bragging about the options package…).
The model year, edition and options are secondary characteristics that
further define the vehicle and the color and other minutiae could be considered
modifiers (unless it is purple).
In the medication domain, the primary characteristic is the
list of ingredients, more specifically the list of active ingredients. Active ingredients drive the use of
medication concepts and, like with the car example, most people when asked
about their medications respond with the active ingredients or the brand name
synonym for the active ingredients. For
medications the implied route, dose form, strength are secondary
characteristics that are relevant but not always necessary.
The Inactive
Ingredients are Inactive… or ARE they?
Active and inactive ingredients typically both live together
in the domain of substances (or ingredients).
Whether an ingredient is active or inactive is, in most cases, a role
that the ingredient plays as opposed to what the ingredient is. This post is mostly about active ingredients,
but it is worth a few minutes to talk about inactive so that, and an
implementer, you understand the conceptual differences and the limitations of
the notion of an inactive ingredient when you encounter it in the wild.
The difference between an active and inactive ingredient is
subtle to the non-pharmacist. Typically
the active ingredients are the substances that define the medication, while the
inactive ingredients are excipients that are introduced in the manufacturing of
the drug product OR ubiquitous essence of life ingredients like ‘water’
that do not factor into the medications function. If you refer to the medication continuum in
the previous post, you will note that inactive ingredients do not participate
in the abstract or dispensable generalizations.
Since inactive ingredients are, for the most part, introduced by the
manufacturing process, any attempt to introduce them into higher level
generalizations is risky as it can create false alerts and worse missed alerts
(Which is the topic of another post and covered to a small degree in my ‘allergy
rule of thumb’ post).
Some may argue that if an inactive ingredient is present in
all manufactured forms of a drug you can represent is at a higher level
generalization for that particular situation.
I would argue that stretching rules of the composition of a terminology
to accommodate a few exceptions is not worth compromising the terminology’s
consistency. You need to know that
active ingredients are always active ingredients, diverging from that path
leads to the scary woods of unintended consequences.
You may encounter what looks like an inactive ingredient in
an active ingredient list. This is
either: (A) a valid active ingredient in that particular circumstance, (B)
introduced because it is clinically relevant and there is no other way for the
terminology to deal with this, or (C) it is junk DNA left over from a bygone
era. In any case, you must treat it like
an active ingredient: avoid eye contact and sudden movements. This is discussed more later in this post.
Let’s talk about active ingredients.
The Ingredient Set
Every valid medication concept (I am looking at YOU
medical devices…) has one or many active ingredients that make up its primary
characteristic. This may be referred to
as an ingredient set, ingredient list, generic drug or the formulation (ingredient
set in the medication concept continuum).
In fact, most every drug compendia has a concept that represents this
level. This is important as that defines
the set of valid active ingredient combinations. Most, if not all, drug
concepts in a medication hierarchy point back to this type of concept. These ingredient sets break down into a list
of individual ingredients.
Base ingredients
A single ingredient can represent a base ingredient or a
variation of a base ingredient. This is
significant because a variation of a base ingredient is related to the base
ingredient but can have significant differences (which I will not get into here…
ask you local pharmacist). To illustrate
this, consider the following table of
RxNorm ingredients that start with ‘Erythromycin’:
|
RXCUI
|
SAB
|
TTY
|
STR
|
|
4053
|
RXNORM
|
IN
|
Erythromycin
|
|
4055
|
RXNORM
|
IN
|
Erythromycin Estolate
|
|
4056
|
RXNORM
|
IN
|
Erythromycin Ethylsuccinate
|
|
24346
|
RXNORM
|
IN
|
Erythromycin Gluceptate
|
|
24347
|
RXNORM
|
IN
|
erythromycin lactobionate
|
|
24351
|
RXNORM
|
IN
|
erythromycin stearate
|
|
236847
|
RXNORM
|
IN
|
ERYTHROMYCIN STINOPRATE
|
In this list you can see the base ingredient of ‘Erythromycin’
and the variations (or different salt forms of Erithromycin in this example). In most cases the variations of a base
ingredient are clinical equivalent to the base ingredient and add not
additional clinical value other than accurately describing the variation of the
ingredient in a specific formulation.
Some compendia have only base ingredients, Some have base and variations
and some have defined relationships between the variation and the base.
This information can come into play when processing clinical
rules so you need to be aware of it. For
example a clinical rule may only be attached to the base ingredient so you need
to use the relationship from the variation to the base ingredient to activate the
rule.
In some situation a ingredient variation may represent
something other than a salt form of the base.
Here are some examples from RxNorm of non-salt variations:
|
RXCUI
|
SAB
|
TTY
|
STR
|
|
352374
|
RXNORM
|
IN
|
drotrecogin alfa
|
|
353106
|
RXNORM
|
IN
|
drotrecogin alfa (activated), lyophilized
|
|
RXCUI
|
SAB
|
TTY
|
STR
|
|
797550
|
RXNORM
|
IN
|
Immune Globulin (Human)
|
|
617615
|
RXNORM
|
IN
|
Immune Globulin Subcutaneous (Human)
|
In some cases there may be no base ingredient – only variations:
|
RXCUI
|
SAB
|
TTY
|
STR
|
|
17609
|
RXNORM
|
IN
|
aluminum acetate
|
|
89858
|
RXNORM
|
IN
|
Aluminum carbonate
|
|
17610
|
RXNORM
|
IN
|
aluminum chlorhydrate
|
|
46241
|
RXNORM
|
IN
|
aluminum chloride
|
|
17611
|
RXNORM
|
IN
|
Aluminum chloride hexahydrate
|
|
612
|
RXNORM
|
IN
|
Aluminum Hydroxide
|
|
81948
|
RXNORM
|
IN
|
Aluminum Hydroxide (Gel), Dried
|
|
613
|
RXNORM
|
IN
|
Aluminum Hydroxide Gel
|
|
46242
|
RXNORM
|
IN
|
aluminum magnesium hydroxide
|
|
615
|
RXNORM
|
IN
|
Aluminum Oxide
|
|
17618
|
RXNORM
|
IN
|
aluminum phosphate
|
|
54989
|
RXNORM
|
IN
|
aluminum potassium sulfate
|
|
543375
|
RXNORM
|
IN
|
Aluminum Sesquichlorohydrate
|
|
17621
|
RXNORM
|
IN
|
aluminum sulfate
|
As an implementer, an awareness of the nature of base ingredients
and there variations is useful as it can motivate you to look at the data in different
ways, both in terms of development and validation.
When is an Ingredient
not an Ingredient?
Every now and then you may encounter an ingredient that is
present in an ingredient set that is not an ingredient. You will recognize this because under certain
situations they will wreak havoc.
Sometimes it will be an inactive ingredient, as discussed earlier, and
other times it may be a clinical work-around.
An example could be an ingredient set that has ‘water’ and
an active ingredient. If the user
happens to select that drug (either by picking the ingredient set or the brand
name synonym) to represent an allergen, they have unwittingly indicated that
the patient is allergic to any ingredient set that includes ‘water’.
Another example of a clinical work-around is a ingredient
term that represents a concept like ‘sugar-free’, ‘alcohol-free’ or ‘Preservative-Free’. These were introduced to support firing significant
clinical alerts without requiring existing terminology users to re-program
their applications. In that respect they
are ingenious and likely saved patient’s lives.
The unintended consequence of this, like with the water example, is that
if a ingredient set with a ‘freeness’ ingredient is used as an allergen it
introduces the notion that the patient is allergic to everything else that is ‘sugar-free’. There are not many of these but if you
encounter one you should make sure that you have exceptions in your allergy
checking to ignore ‘free-ness’-based hits.
Finally, some ingredient terminologies may include the notion of a route of administration in an ingredient (see the above example of 'immune globulin' in RxNorm) this is less of an issue because the route is not typically represented as a distinct ingredient, so the net result is similar to a variation of a base ingredient. Sometimes in these cases the routed ingredient may be disconnected from the base ingredient for clinical reasons.
Ingredients Drive
Medication Terminologies
Every use model for medication terminologies is driven by
the ingredients. Take some time, with
whatever terminology you have chosen for your implementation, to understand how the ingredients work and
how they factor into the decision support modules. Understanding this facet of
you medication providers content will provide significant insight into how
everything else works.
In the next post of this series we will cover the secondary characteristics of a medication concept.
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 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.
I have completed a new screencast that provides a 17 minute 
overview on how to leverage the ICD9 cross map files in the SNOMED-CT optional download. Grab a sandwich, MS Access and curl up by the monitor and see how this great resource from the NLM can save you some time and effort mapping SNOMED-CT terms to ICD9.
Follow this link to the resource page to access the screencast.
I am always looking for new ideas for screencast. If you have one email me and let me know.
Have a great week!
For those of you evaluating the use of the SNOMED-CT Core Subset, you need to be aware that the NLM has made some non-trivial changes to the format and content of the subset file in the latest (second) release dated 200908 (July).
If you have developed a load program, as we have, that uses the subset file to identify concepts that are included in the subset, it is likely you will need to modify that program.
Here is a summary of the changes:
Term Changes:
- Nine terms were added and eleven terms were retired from the core subset.
New Terms:
SNOMED_CID | SNOMED_FSN | SNOMED_CONCEPT_STATUS |
208892001 | Closed traumatic dislocation of hip (disorder) | Current |
165468009 | Erythrocyte sedimentation rate (ESR) raised (finding) | Current |
197321007 | Steatosis of liver (disorder) | Current |
40733004 | Infectious disease (disorder) | Current |
165346000 | Laboratory test result abnormal (situation) | Current |
442234001 | Serum cholesterol borderline high (finding) | Current |
442438000 | Influenza due to Influenza A virus (disorder) | Current |
442551007 | Dental caries extending into dentine (disorder) | Current |
4557003 | Preinfarction syndrome (disorder) | Current |
Retired Terms:
SNOMED_CID | SNOMED_FSN | SNOMED_CONCEPT_STATUS |
41006004 | Depression (finding) | Ambiguous |
309158009 | Laboratory finding abnormal (navigational concept) | Current |
371330000 | Fatty liver (disorder) | Duplicate |
131016008 | Increased thyroid stimulating hormone level (finding) | Duplicate |
166829003 | Serum cholesterol borderline (finding) | Ambiguous |
191415002 | Communicable disease (navigational concept) | Current |
78431007 | Influenza due to Influenza virus, type A, human (disorder) | Ambiguous |
416103000 | Elevated erythrocyte sedimentation rate (finding) | Duplicate |
50047001 | Compound dental caries (disorder) | Ambiguous |
63079007 | Closed traumatic dislocation of hip joint (disorder) | Duplicate |
64333001 | Preinfarction angina (disorder) | Duplicate |
File Structure Changes:
June Subset | July Subset | Change |
SNOMED_CID | SNOMED_CID | - |
FSN | SNOMED_FSN | Name Change |
CONCEPT_STATUS | SNOMED_CONCEPT_STATUS | Name Change Now uses Description instead of Code!!! |
UMLS_CUI | UMLS_CUI | - |
OCCURRENCE | OCCURRENCE | - |
USAGE | USAGE | - |
- | FIRST_IN_SUBSET | New Field (YYYYMM) |
IS_RETIRED | IS_RETIRED_FROM_SUBSET | Name Change |
- | LAST_IN_SUBSET | New Field (YYYYMM) |
- | REPLACED_BY | New Field (SNOMED-CT Concept ID) |
New Fields:
New Field | What is it? |
FIRST_IN_SUBSET | This is the issue year and month when the concept first appeared in the subset. |
LAST_IN_SUBSET | This is the issue year and month when the concept last appeared in the subset as a non-retired concept. |
REPLACED_BY | Concept ID of the concept replacing a retired concept. |
OUCH!
If you developed a program that loads the core subset file this update likely broke it.
If you are using a text ODBC/OLEDB driver to load the file the name changes to the columns broke it.
If you are accessing the fields using sequential access and splitting the fields using the pipe delimiter, the insertion of the FIRST_IN_SUBSET before the IS_RETIRED fields will break your load program.
If you created a function that uses the coded values in the CONCEPT_STATUS field to support your load logic, that is now broken by the switch to the text value. (I don't understand this change at all. It seems to run contrary to the move away from free text. I would change it back...)
Needless to say, this update was a painful one for the early adopter. But, if you have already created logic based on the inaugural release of the core subset data... and early adopter is what you are and it is not without risks.
Along with the painful changes that left our load program writhing on the ground, clutching its face and yelling "You broke my nose!" are some new useful additions.
The FIRST_IN_SUBSET, LAST_IN_SUBSET and REPLACED_BY_SNOMED_CID are useful lifecycle management fields that will help with the management of term availability.
Patience is a Virtue
If this update frustrated you, I would ask that you focus on the positive and consider that the Core subset is another in a growing line of great, "FREE" work products from our friends at the NLM.
It is also worth noting that as we in the HIT industry leverage SNOMED-CT, RxNorm and LOINC the bar will continue to be raised in terms of update frequency and format stability. From the interactions I have had with the NLM, I expect that they are paying attention and will be responsive as we evolve and leverage them more.
Free Advice
As someone who worked at a commercial content provider, I would encourage the following with respect to all data products.
1.) Do not change field/column names lightly if they are included in the file, as developers will leverage that with a text driver to load the information.
2.) Avoid inserting fields into a record, as some load programs will operate based on field order. If you append new fields to the end of the record you will be less likely to disrupt the load.
3.) Coded fields are better than text fields...always.
Regardless of the constructive criticism...this is good stuff. If we at Clinical Architecture can help you better take advantage of it, give us a call!
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?
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:
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.
I had a request to do a screen cast on the new SNOMED-CT CORE subset. In order to do it justice, I decided to provide an overview of the SNOMED-CT Essentials terminology and the CORE subset together to provide context for people that are new to both.
Follow this link to check it out. It is also available on the Resources page.
It is about 20 minutes and I tried a new approach. I hope you find it useful.
Please do not hesitate to contact me if you have any feedback or suggestions for future screen casts.
I recevied an email from the NLM UMLS Users listserv today with the following subject 'CORE Problem List Subset of SNOMED CT Now Available'. Being a UMLS enthusiast, I quickly downloaded the data and scoped it out. I thought I would share what I found out with you.
CORE Problem List Subset, What is it?
It is a subset of the complete SNOMED CT terminology that is design to help implementers by acting as a starter set of codes.
There are 5182 terms in the core data released today as opposed to the roughly 386,000 terms in the complete SNOMED CT terminology.
Where did it come from?
The data released today is based on the datasets submitted by the following institutions:
- Beth Israel Deaconess Medical Center
- Intermountain Healthcare
- Kaiser Permanente
- Mayo Clinic
- Nebraska University Medical Center
- Regenstrief Institute
- Hong Kong Hospital Authority
Why was it created?
This new core subset can provide a vendor or institution with a starter set of common terms that are used to record clinical observations (in fact CORE stands for Clinical Observations Recording and Encoding).
What is in the file that you can download?
The terms that were selected are available in a pipe ‘|' delimited file with the following record format.
|
Position |
Field name |
Description |
|
1 |
SNOMED_CID |
This is the concept identifier for the term. (If you are a regular SNOMED enthusiast, this is the same ID that you would find in the SCT_CONCEPTS_yyyymmdd.txt file.) |
|
2 |
FSN |
Fully Specified Name (the term description) |
|
3 |
CONCEPT_STATUS |
This is the concept status of the concept ID in the SCT_CONCEPT file. According to the extractions rules for the core this should always be zero, which means ‘current'. (Which also means you can probably ignore this field). |
|
4 |
UMLS_CUI |
Concept Unique Identifier for this SNOMED CT concept in the UMLS Metathesaurus MRCONSO table. |
|
5 |
OCCURRENCE |
The number of contributing institutions that have the concept in their problem list (currently from 1-7). |
|
6 |
USAGE |
The sum of the usage of this term divided by the 7. (I wonder if this would be better if it was the sum of the usage divided by the occurrence?? - I will follow up with NLM.) |
|
7 |
IS_RETIRED |
This is a field for the future to support when terms are retired. I would assume that the CONCEPT_STATUS field would also reflect that the SNOMED CT concept is no longer current as well. |
Note: I went back and forth on the USAGE field. I thought it was interesting that the sum of the usage was divided by the full count of seven and not the OCCURRENCE value. When you take the USAGE number, multiply it by seven and divide by the OCCURRENCE number the result is, in most cases, a much higher value that reflects the usage of the term within the institutions that are actually using the term. If you are a big data nerd (like me) the variance in how the terms are ranked depending on which way you look at the usage is interesting. I am also interested on how the original institutional average was calculated. (once again... nerd).
A Quick Look at the Data
When you take the supplied terms and sort them in order based on the USAGE number, here are the top 25 terms.
When I see this list it seems reasonable to me that these would have a higher usage in a problem or finding list. All of the terms are at a fairly high level and are the types of things you would expect to have a higher volume of occurances.
Impressions
If you are just getting started with SNOMED CT and thinking about using it as a reference terminology for tracking findings and problems in your electronic medical record, this new CORE subset is a great starting point. Kudos to the NLM and the constributing institutions for providing this information - it should facilitate the implementation of SNOMED CT by providing a place to start.
For more information checkout the full write up on the NLM website at:
http://www.nlm.nih.gov/research/umls/Snomed/core_subset.html
As we here at Clinical Architecture have been developing our Symedical product, I have had the pleasure of spending some quality time with UMLS Metathesaurus and RxNorm. As I was going through this journey of discovery, I thought to myself that it might be a good idea to share my findings and experiences with others who might also be looking into using RxNorm and UMLS to enhance or improve their clinical interoperability.
So, to that end, I have created the first of, in what I hope will be, a series of Screen Casts that provide some insight into UMLS and RxNorm.
(Video should work in all browsers but requires the Quicktime plug-in)
Basic Clinical Interoperability with RxNorm - Screencast
Special thanks Jan Willis and the other folks at NLM for their feedback.
When looking into what makes a good terminology, I would be remiss if I did not mention Dr. James Cimino's ‘Desiderata for Controlled Medical Vocabularies in the 21st Century'. Dr. Cimino's body of work is very enlightening and this particular publication started me on my personal journey into medical informatics.
The characteristics represented in this post stem from what I learned from Dr. Cimino and other mentors that I have had the privilege of working with directly (you know who you are) as well as my personal experience, ideas and pragmatic tendencies.
For the purpose of this post, a terminology is a set of terms with identifiers. The terms collectively are designed to model some facet of a particular domain. This could be a terminology of medications, ingredients, routes of administration, lab tests, units of measure, species, electronic parts, legumes or even Pokemon.
Basics
There are some basic characteristics that you should always look for in a terminology:
Characteristic #1 - Unique Identifiers
The identifier for a given term should be unique. The same identifier should never represent two different concepts in the terminology, ever.
Characteristic #2 - Stable Identifiers
The identifier for a given term should be persistent. Regardless of the status of the term the identifier should stick around and never be re-used to represent another term. (see Rule #1 - and YES, I am looking at you National Drug Code...)
Note: Rule #1 and #2 are important because identifiers get stored in electronic records and when that data is accessed later, the electronic record is invalid if the identifier is gone or the meaning has changed.
Characteristic #3 - Dumb Identifiers
An identifier itself should not have meaning. If an identifier is comprised of other identifiers that have been combined, then the composite identifier is inherently unstable. If the circumstances that related the composite identifiers together in the first place change, the resulting identifier must also change. For example, drug identifiers with smart numbers based on therapeutic classes become unstable when a class splits or the drug is assigned to another class. This also can become a problem if part of the composite key outgrows its original bounds and effectively breaks the parse-able nature of the composite keys.
The term ‘dumb number' was created as a counterpoint to ‘smart numbers' or numbers with built-in meaning. I change number to identifier, because I am not convinced that identifiers need to be numbers. Dr. Cimino's has a great name for them: ‘non-semantic identifiers'.
Characteristic #4 - Coverage
The terminology should adequately cover the domain it is meant to model. If the terminology does not have enough terms the consumer will find themselves wanting or worse... free texting.
Well Managed Terms
There are several things that you should look for to determine if the terms are well managed or have junk DNA that can pollute the terminology.
Characteristic #5 - Concept Orientation
This is a notion that is described in Dr. Cimino's Desiderata very well. It means that "terms must correspond to at least one meaning ("nonvagueness") and no more than one meaning ("nonambiguity"), and that meanings correspond to no more than one term ("nonredundancy")". In other words, a term should represent a concept and that concept should only be represented once as an active term in the terminology. If you lose concept orientation, you end up with a pick list where a term is repeated or a term that represents a concept broader than the scope of the terminology. If the concept orientation is not well managed in a terminology, it will look a mess. There will be repetition of terms, or worse, terms that don't make sense (for example, an ingredient terminology with the term ‘Powder')
Characteristic #6 - The Controlled Terminology should be controlled.
This states that a terminology should have a focus, and it should stay true to that focus. All too often the keepers of a terminology may be tempted to introduce a term into the set that is not an appropriate concept for the terminologies domain, but it serves some other purpose. On Sesame Street there was a segment called ‘One of these things (is not like the others)'. This is the way you feel when working with a vocabulary that is not well controlled. You come across terms that don't quite fit. This is especially prevalent in older terminologies and hopefully they have some indicator, or classification, that can help you navigate around them (because it can be hard even for a monster - click the link...).
Characteristic #7 - Consistent Term Structure
The terms themselves should have a consistent structure. When dealing with a term that describes a granular concept, like a dispensable medication. The lexical components that make up a term should have the same ordinal pattern from term to term. You should not see for example ‘ibuprofen 200 mg oral tablet' and later ‘warfarin 200 mg tablet oral'.
Bringing the terminology to life
Making the terminologies more robust, or three dimensional, allows the terminology consumer to leverage the resulting metadata and maximize the utility of the terminology. The following characteristics help breath life into a terminology.
Rule #8 - The Terminology should have a lifecycle
Terminologies evolve. New terms are created, existing terms are split, become obsolete or are replaced. A good terminology provides the user information on the status of a term that allows the terminology consumer to take action when a something happens to a terms. This can be as simple as a term status that indicates whether it is active or obsolete, or as complex as replacement pointers that help the terminology consumer decide how to transform the obsolete term they are referencing. This is especially true if the terminology is stable. Since an identifier never gets removed from the terminology, the terminology consumer needs to know when it is past is ‘sell by' date so it does not continue to get selected and used in an electronic record.
Characteristic #9 - The Terminology should be part of a well defined domain ontology
If the terminology represents a concept that is comprised of component parts, those parts should be represented by terminologies associated to those terms following the same guidelines listed above. In other words, if I have a terminology that describes a fully specified lab test, the term is naturally made up of several components, in this case: the analyte name, specimen type, method and result unit (for example) for the test. Each of the components should be represented by a terminology and my terms should have an associative relationship to those component terms. This allows the consumer to sift and sort terms and leverage the ontology to get maximum use form the terminology.
Characteristic #10 - Interoperability
A terminology should be associated to a standard interoperable terminology if one is available. When choosing a terminology the consumer needs to have the ability to exchange information with other applications. Not all domains have an interoperability standard, but those that do, like medications and RxNorm, should participate in those standards appropriately or have links to them.
Characteristic #11 - Extensibility
No terminology can satisfy all the needs of the consumer. Defining the terminology in such a way as to allow the consumer to extend the terminology facilitates the extension of the terminology to bridge a period until the term is added by the source or permanently, if the term is very local to the consumer. This can be accomplished in several ways and could also depend on how the consumer implements the terminology in their solution.
Summary
These are some of the characteristics that make up a good terminology there may be others that are both generic and domain specific. I welcome any comments and wish you luck in your personal informatics journey.