Clinical Architecture Healthcare IT Blog

Quick Freebie - ISMP Tallman and RxNorm

On the resources page, I have posted an excel spreadsheet that includes ISMP Tallman drug names and the RxNorm CUIs they are directly and indirectly related to.  The first tab is the ISMP Tallman names and the RxNorm ingredients (TTY=IN) and brand names (TTY=BN).  The second tab lists the relationships between the ISMP Tallman names and more granular RxCUIs.  This was done by creating links based on the RXNREL table from the ingredient and brand names to their related concepts. 

This uses the August 2010 RxNorm data and the latest ISMP Tallman drug names.

Here is my disclaimer - Use this file at your own risk.  If you find any issues with it or have any questions, please let me know.

If you would like these in a pipe delimited test file format, with instructions, you need to email us and let us know who you are so that we may stalk you and fill you email inboxes with spam (not really).

If you find this useful, please let me know.  We are considering maintaining this with each RxNorm update cycle. 

For more information on the Institute for Safe Medication Practices go here: http://www.ismp.org/

For more information on RxNorm go here: http://www.nlm.nih.gov/research/umls/rxnorm/

For more information on interoperability, clinical decision support or clinical architecture go here: http://www.clinicalarchitecture.com (Wait... you already are here...)

A Primer on the Vocabularies of Meaningful Use – Allergy Vocabulary

PLEASE NOTE: The Meaningful Use Final Rule was released on July 12 and the UNII is no longer listed as the standard for allergy terminology.  In fact, there is NO standard listed for allergy interoperability.  For the record, I do not think that the following blog post, which "aired" on June 30th, influenced the governments decision making process in any way.  My next post will suggest a significant stimluls for healthcare IT companies with the word 'architecture' in the name... just in case.  In order to preserve history, I am leaving the post as it was.  It still provides a decent overview of UNII for those of you that would like to leverage it.

The vocabulary chosen to represent patient allergies is the FDA Unique Ingredient Identifier or UNII (I guess ‘UII' would be a difficult acronym to use in casual conversation...).

The UNII is part of the Substance Registration System whose purpose is to provide unique identifiers for:

Foods

• Food substances are specific foods or components of food, regardless of whether the food is in conventional food form or a dietary supplement, such as vitamins, minerals, herbs, or other similar nutritional substances.

Drugs

• Drug substances include both active and inactive ingredients used in drug products, including those for veterinary purposes.

Biologics

• Biologic substances include both active and inactive ingredients used in biologics, such as blood products, therapeutic products, vaccines, cellular and gene therapy products, allergenic products, tissues, and certain devices (e.g., enzymes in stabilized solutions).

Devices

• Device substances include certain components of some devices (e.g. silicon for implants, and chemical reagents for glucose test kits).

Cosmetics

• Cosmetic substances are components of cosmetic products, such as flavors, fragrances, colorants, vitamins, plant- and animal-derived ingredients, and polymers.

 There is more general information on the UNII here: http://www.fda.gov/ForIndustry/DataStandards/SubstanceRegistrationSystem-UniqueIngredientIdentifierUNII/default.htm

According to the above site, the UNII is:

• One of the core components of the United States Federal Medication Terminology.
• Used in the FDA's Structured Product Labeling
• Used to assist in the generation of the National Library of Medicine's (NLM's) RxNorm.
• A US government standard for drug ingredient and food allergen identifiers
• A component of the Environmental Protection Agency's Substance Registry System (future)

The UNII may be found in:

• NLM's Unified Medical Language System (UMLS)
• National Cancer Institute's Enterprise Vocabulary Service
• USP Dictionary of USAN and International Drug Names (future)
• FDA Data Standards Council website
• VA National Drug File Reference Terminology (NDF-RT)
• FDA Inactive Ingredient Query Application

The UNII is provided, rather inconveniently, in excel format. 

There is a multi-worksheet (A-S, T-Z), denormalized, zipped excel workbook dated 6/25/2010 at the following location.

http://www.fda.gov/downloads/ForIndustry/DataStandards/StructuredProductLabeling/UCM217498.zip

The sheets are difficult to work with because they have combined the concepts and their synonyms into a single list.  It is also worth noting, that in the data provided the synonyms do not have unique identifiers.

Sheet Structure

The primary sheets with the UNII codes in them have the following columns:

Preferred substance name	This is the preferred name of the substance
UNII	The Unique identifier the preferred substance name
Substance name	A synonym for the preferred substance name
IT IS TSN	This is not really documented, BUT I believe it is, where applicable, a code representing the USDA Integrated Taxonomic Information System (ITIS) Taxanomic Serial Number (TSN).   This appear to only be populated for food ingredients
Molecular Formula	This is, you guessed it, the molecular formula.  It seems to only be populated for chemical ingredients.

Code structure and design

The UNII code is a ten character alpha-numeric code.  The first nine digits are randomly generated and the tenth digit is determined by an algorithm (a check digit for you old timers who wrote serial port interfaces...).

 The Numbers

There are 16,655 unique UNII concepts in the provided list.

There are 67,715 synonyms, including the preferred names.

What's missing?

UNII Type:             

We know that the scope of the UNIIs covers a number to types of substances.  It would be very useful if there was a way of telling which UNIIs are of which type so that we could filter them.  I may not want to include cosmetics OR biologics in my allergy pick list, for example.

Allergies:              

In most systems that track allergies, medication allergies in particular, they allow the user to represent allergies using medication ingredients, common brand names OR allergy classes.  The UNII scope only covers one of these.  How will we use UNII to represent and documented allergy or adverse reaction to ‘Nyquil' or ‘cephalosporins'?  Also, if you are going to represent allergies should the list include animals and environmental allergies.

Not a Rant

I don't want to get off on a rant here... but it seems like for some of these meaningful use terminologies, rather than creating a terminology designed to support appropriate interoperability, we looked to see what we already had lying around.  UNII is not an allergy terminology, it is a substance terminology. They are not the same thing.  They are terminology domains that merely overlap.  I know, creating a terminology is hard but, ahem, 19 billion dollars!  This is not a criticism directed at the UNII codes or the people that maintain them.  It looks like a very thorough substance terminology with a fairly simple design, but it will not support allergy interoperability as it should be supported.  Now, we could change UNII terminology to include allergy classes, animals and environmental terms, but that would make it a less wonderful substance terminology then, wouldn't it?  Perhaps a better approach would be to use UNII in our allergy interoperability terminology, in the utopian future, to represent substances (with types please) and we could append the other allergy types (classes, animals, environmental) to save money and reduce the deficit.  I could live with that.

 (I will now climb down from my virtual soap box, so that you can come out from behind your furniture...)

To make up for the non-rant, I am happy to provide a normalized version of the most recent UNII data for your experimentation.  It is provided in a zip file as two, pipe ‘|'delimited text files with the following structure.

If you would like to receive this file, contact us and ask for it.  We will email it to you or provide you with access to our FTP server. 

I want to thank Bonnie for reminding me that I should do this post.

I will try to post more frequently.

 

A Primer on the Vocabularies of Meaningful Use - Introduction

I recently had a request to create a post providing a primer on the vocabularies of meaningful use.  Let's start with a review of the vocabularies that are named in the meaningful use criteria described on pages 21 and 22 of the January 13^th release of the federal register located here: http://edocket.access.gpo.gov/2010/pdf/e9-31216.pdf.

The "Chosen Ones"

The listed vocabularies and their purpose are as follows:

Terminology	Stage	Purpose(s)
ICD-9-CM	Stage 1 Stage 1	Problems Procedures
ICD-10-CM	Stage 2	Problems
ICD-10-PCS	Stage 2	Procedures
SNOMED-CT	Stage 1 Stage 2 Stage 2	Problems Problems Lab Results (Submission Public Health)
CPT-4	Stage 1 Stage 2	Procedures Procedures
Third Party Drug Vocabularies*	Stage 1 Stage 1	Medications Electronic Prescribing
RxNorm	Stage 2 Stage 2	Medications Electronic Prescribing
UNII	Stage 2	Medication Allergies
CVX	Stage 1 Stage 2	Immunization Registries Immunization Registries
LOINC	Stage 1 Stage 1 Stage 2 Stage 2	Lab Orders (from Reference labs) Lab Results (from reference labs) Lab Orders (All) Lab Results (All)
UCUM	Stage 2	Units of Measure
CDA template	Stage 2	Vital Signs

* Third Party drug vocabularies that are listed as complete in RxNorm by the NLM

Meaningful Selection

What does it mean that a vocabulary is one of the chosen ones?  My understanding is that the meaningful use criteria (based on my reading of the federal register) defines that to be certified EHR technologies must provide patient summaries and interoperate (exchange data) using the listed vocabularies for their defined purposes.  In other words, the vocabulary standards are for interoperability not native persistence in the EHR application.

It is not reasonable to expect that every hospital / physicians office in the US will migrate their patient data to these standards (and then do it again for 2013).  As a good application architect, your objective is to determine how you will be able to express your client's patient information in the anointed vocabularies.

Where to Learn More

There is a lot I can say about these vocabularies, both their suitability to the task that have been so capriciously assigned to them and the challenges associated in working with each of them.  This is not the post for that particular diatribe.  In this post, I will try to give you some high level information and some places to find out more.  So strap on your learning caps and practice your right click ‘open in new tab' skills.

The next post will cover the problem vocabularies.

Medication Concepts – Engineering Primer – [Part 3] - The Secret Ingredient

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.

Medication Concepts - Engineering Primer [Part 2]

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.

Medication Concepts - Engineering Primer [Part One]

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.