Clinical Architecture Blog

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.

Semantic interoperability deals with the actual "language" contained in the conversation between applications.  Solving the syntactic interoperability issue by using a standard message format does not mean that the terms used by one application are the understood by the other.

Applications Can't See the Bunny

In healthcare to have a meaningful exchanges we require a ‘language' that can describe characteristics about a given situation with as little ambiguity as possible.  The human brain is designed to process and recognize patterns.  It's why clouds look like bunnies and that potato chip looks like Elvis.  This is why we can read "Tummy ache" and translate it on the fly to "abdominal pain" or even "gastric distress".  We are built to process ambiguity.  Software applications do not share our gift for interpretation, at least not yet, so they need another way, to accurately and consistently describe the characteristics of a healthcare situation, hence the proliferation of codes.

Codes are unique values that have been assigned to represent a piece of information.  They can be numbers, letters or a combination of numbers and letters.  These codes can come from a content vendor, a standard public domain source or can be home spun codes created and maintained by an institution for its own purposes.

The Problem with Code Sets

It is important to note that there are relatively few code sets that have been created to foster interoperability.  In the beginning, there were not companies that specialized in the creation and management of code sets (also known as vocabularies and terminologies).  Codes were created by the organization to support the unambiguous processing of information within the organization.  As applications evolved on the business side and there was a need to exchange data with trading partners, the need for third party code sets grew.  Eventually, code set vendors (also known as compendia) sprang up and established proprietary code sets that could be licensed and used by both partners.

Healthcare applications have evolved.  Their need to express more complex and critical clinical information has created a more extensive need for stable, granular code sets across several conceptual domains.  Many code sets have evolved to support these uses and some have even evolved to help with interoperability.

Some of the domains and their code sets are as follows:

Laboratory Tests and Observation Code Sets:

• Logical Observation Identifiers Names and Codes (LOINC)
• Systematized Nomenclature of Medicine--Clinical Terms (SNOMED-CT)

General Medical Code Sets:

• International Classification of Diseases (ICD-9 and ICD-10)
• MEDCIN point of care terminology
• Medical Subject Headings (MESH)
• Systematized Nomenclature of Medicine--Clinical Terms (SNOMED-CT)

Medication Code Sets (including Medication allergies):
Public

• National Drug Codes (NDC)
• NHS Read Codes
• Health Canada Drug Product Database (DPD)
• US Veterans Administration Drug File (NDF-RT)

Commercial (in alphabetic order)

• First Data Bank National Drug Data File (NDDF)
• Gold Standard (Alchemy)
• Lexi-Comp
• Medi-Span Master Drug Database (MDDB)
• Micromedex DRUGDEX
• Multum Lexicon
• Systematized Nomenclature of Medicine--Clinical Terms (SNOMED-CT)

Units of measure:

• Unified Code for Units of Measure (UCUM)

Procedures:

• Current Procedure Terminology (CPT)

Specialty Code Set Examples:

• Current Dental Terminology (CDT)
• Diagnostic and Statistical Manual of Mental Disorders (DMS-IV)

I will stop here, but anyone that has seen the Unified Medical Language System (UMLS) list of sourcesknows that I have just scratched the surface.  There are over 100 terminology sources, and that's not counting the home grown terminologies that are still in use in many institutions for various domains.

Take the Blue Pill

So how do you facilitate semantic interoperability when dealing with such diversity?

There are two answers to this question. 

The easy way is to convince your exchange partner to abandon their code set and adopt yours.  This means that they will have to potentially rewrite their application and convert all of their patient data, but it will certainly make your life easier.  Oh yeah, you could adopt theirs - but that's crazy talk.

The other way is to create a map that facilitates the translation of your codes into theirs and vice versa.  This tends to be the way most people go about it.

Fine, Hand Built Maps

Here we engage our most expensive computing resource, the human being, who dutifully reviews each term in the source and target code sets and creates a map between them.  This can be expensive, depending on the size and complexity of the code set.  It should also be noted, that this is not a onetime gig.  Code sets are living data; they grow, shrink and change.  This means that the maps need to be tended to regularly.   It also is better is done by a knowledgeable resources who you trust to make the right choices.

Over time, our friends at the National Library of Medicine worked out a way to help those trying to make interoperability with the heavy lifting.

Universal Translator

Unified Medical Language System or UMLS was started at the National Library of Medicine in 1986 as a long term R&D project to explore how they could overcome barriers to effective retrieval of coded information.

The UMLS is comprised of three databases: Metathesaurus, Semantic Network, and the SPECIALIST Lexicon.

• The Metathesaurus represents a clinical terminology clearinghouse with inherent mechanisms for normalizing terms on a conceptual basis.
• The Semantic Network is a set of files that attempt to provide a mechanism for the categorization and hierarchical organization of applicable terms.
• The SPECIALIST Lexicon is a database designed to support natural language processing.

For the purposes of semantic interoperability, we will focus on the Metathesaurus which provides a conceptual backbone for the medical terminologies that participate. 

The Metathesaurus by itself does not do solve the semantic interoperability problem, but it does provide the functionality of a thesaurus by relating terms from different sources that have the same or similar conceptual meanings.

Using the Metathesaurus is both simple and complex.  I won't go into the details here, but I will be releasing a whitepaper in the near future designed to help understand it.  In the meantime there are a number of great sources of information starting with the NLM provided documentation, which is actually pretty good.

In a nutshell, the Metathesaurus maps the source codes provided by the creators of the different code sets to unique strings (SUIs), normalized lexical terms (LUIs) and distinct concepts (CUIs).  This information lives in the primary file in the Metathesaurus, MRCONSO.  The name of this file stands for Metathesaurus Relational Concepts and Sources in a quaint 1980's limited filename sorta way.



The second most used file in the Metathesaurus is MRREL.  This is the file that contains the relationships between concepts that supports the traversal of a source's ontology.

Also included in the Metathesaurus are files that describe hierarchies, ambiguous terms, co-occurrences and attributes among other details.

For the world of medication terminologies, NLM has created a specialized subset of the Metathesaurus called RxNorm.  Part of the complexity of using the Metathesaurus is the steps involved to extract a subset of sources.  By focusing on medication terms, RxNorm is easier to use and update.  Being focused on medication relationships, RxNorm provides an excellent source of conceptual mapping for the complex and highly utilized medication terminology subset.

Leveraging the Metathesaurus

Whether you are using the a custom subset of the Metathesaurus or RxNorm it is a useful to aid you in establishing maps between code sets in support of interoperability.  I am not sure I would rely entirely on the either as a standalone source for this task.  It is always important to note that the updates in the Metathesaurus can and will lag behind those form the sources.  If you rely entirely on the Metathesaurus the fidelity of your interoperability is likely to suffer.

This Old Code Set

It is worth noting, that if you are dealing with a homegrown code set you are pretty much on your own.  This makes more work, but remember the language of healthcare is fairly distinct, especially if you know the context if use.  A home grown code value associated with the word ‘acetaminophen' can get me to an established code value for ‘acetaminophen' if I know they are both how a patient described an ingredient they were allergic to.  If you are in a position to move off of a home grown code set, you should check the Metathesaurus source list and ask around for a good public or commercial source.

Resources That Can Help

There are a number of companies and tools that can help with the creation and management of maps.   You can find them by googling ‘clinical interoperability'.  I would also be happy to provide recommendations, so feel free to contact me.

As mentioned in the first article in this series, two critical parts of Clinical Interoperability are physical and syntactic interoperability.   These two are essentially the first and second of what I consider to be the four laws of interoperability dynamics.

In order for two applications to exchange high fidelity information about a patient, there must be:

1. A physical transport mechanism and the low level protocols that physically move the information from one system to another.
2. An understanding of how the information is packaged for transport by the sender so that the receiver can extract the information.
3. A common terminology (or translation mechanism) for the relevant, codified patient information so that the receiving application can ‘understand' the information once extracted.
4. Equivalent functionality in both applications.

This article focuses on the first two of these.

Physical Interoperability

What is interesting about the physical transport of critical information is that people outside of healthcare probably think that our industry is dominated by the electronic data transactions.  I am not sure that is the case.  One example of this is prescriptions.  According to NACDS, of the 3.5 million prescriptions filed in 2007, only 2.1% were processed via electronic messaging.   Keep in mind that the medication prescription area is one of the most advanced, in terms of electronic messaging, in healthcare.  So, today, when we talk about physical interoperability, we are talking about transport mechanisms that include ‘sneaker-net', faxing, file transfers as well as pure electronic processing.  This works today because there are people that are acting as interoperability adapters.  They are interpreting the data, transforming it and entering it into the receiving system.  This ‘chair to keyboard interface' approach is very inefficient, error prone and, technically, does not qualify as ‘high fidelity'.

When we talk about the physical transport mechanisms in the future, what are we looking for?  A combination of existing networking technology, communication protocols and data exchange software (commercial or home grown) are fairly ubiquitous.  The reason for the low adoption is not a reflection of a lack of readiness on the physical side of things.  We have the plumbing to support good clinical interoperability, so what is the problem?  Perhaps we don't have good standards for message syntax.

Syntactic Interoperability

If this were a treatise on healthcare messaging standards, it would be much much longer than an article and written by someone other than me.  Back in the early days of my career (right after we eliminated the dinosaur problem), I was involved in the business of laboratory interfaces.  In the beginning, most interfaces between applications, or applications and devices, were complete custom endeavors.  The two parties would negotiate a format and write their respective parts.  After a while, standards began to emerge.  The first I was involved in was the ASTM standard for laboratory information exchange, which went on to become what is now Health Level 7 (HL7).  It wasn't perfect, but it served our purpose and saved us from reinventing the wheel.  So we adopted it.

Today, there are several standard messaging formats that play a role in healthcare interoperability.  Their scope and maturity are proportional to their drivers and adoption.  For the purposes of this article, I will describe a few of the major formats that have significant adoption, or are in the news.

Note: If your favorite standard is not mentioned, please feel free to throw it in the comments section.  Just make sure that it is not in the standard graveyard.  My rule of thumb is, if three out of four search engine links resolve to a missing page, the standard is likely not a going concern.

---

Electronic Prescribing

NCPDP SCRIPT Standard

The NCPDP script standard is a collection of message formats designed for the express purpose of facilitating electronic prescribing.  It was approved as a national standard in 1997 and became the official standard for pharmacy claims in HIPAA in 2000.  Visit the NCPDP website for more information.

---

General Healthcare Information Exchange

These standards are designed to provide common formats to support a number of common transactions in a healthcare setting.

Health Level 7 (HL7) Version 2.x

HL7 v2.x is a collection of messaging standards including: Patient Administration, Order Entry, Information Query, Financial Management, Observation Reporting, Medical Records, Scheduling, Patient Referral, Laboratory Automation, Patient Care, Personnel Management, and Application Management to name a few.
This is probably the most widely adopted standard in healthcare.  Version 2 was first introduced in 1990 and was intended to be an '80 percent' solution. 

Health Level 7 (HL7) Version 3.0

The goals of HL7 version 3.0 were much more ambitious than its predecessor.  The goal of version 3.0 included: internationalization, a consistent data model, a more precise standard and freedom from any constraints that would be imposed by compatibility with version 2.x.  The complexity and proscriptive nature, and associated costs, have resulted in slow adoption of Version 3.0. Visit the HL7 website for more information on both version 2.0 and version 3.0.

---

Application Synchronization

HL7 Clinical Context Object Workgroup (CCOW - pronounced ‘sea-cow')

The CCOW standard was introduced to provide a standard to support the visual integration of healthcare applications.   Providers are often required to work across multiple applications.  The CCOW standard describes a collection of mechanisms that allows applications to shift focus to the same patient.  Visit the HL7 CCOW Page for more information.

---

Electronic Health Record Information Exchange

These standards are designed to support the exchange of a patient medical record.  This is different than a transaction.  A transaction is sending information and instructions to facilitate some action being performed. 
These formats are intended to share a current snapshot of a patient's clinical context. 

Health Level 7 Clinical Document Architecture (CDA)

The CDA is an XML-based markup standard intended to specify the encoding, structure and semantics of clinical documents for exchange.  CDA is based on the HL7 reference information model (RIM) and is part of the version 3.0 standard. 

Visit the HL7 CDA FAQ for more Information.

ASTM Continuity of Care Record (CCR)

The CCR was created by ASTM International, the Massachusetts Medical Society (MMS), HIMSS , the American Academy of Family Physicians (AAFP), the American Academy of Pediatrics(AAP), and other health informatics vendors. It was designed to contain the most relevant and timely core health information about a patient.  It has been adopted by a number of healthcare application vendors, and most notably by Google's Patient Health Record.  More information can be found CCR Resource Site.

HL7/ASTM combined Continuity of Care Document (CCD)

The Continuity of Care Document is an HL7 standard whereby a patient's current clinical context is expressed in the framework of the Clinical Document Architecture. More information on the CCD can be found on the HL7 website under CDA Release 2.

---

The Standards are Out there

There is likely a message format that can satisfy your need to interoperate syntactically.  The important factors are what your trading partners support and which formats can you implement without re-engineering your entire application.  There are also a number of businesses that provide adapters that can be bolted onto you application to make this easier as well.

A number of the formats mentioned also have specific terminologies that are ‘supported' by the standard.  Some support several and some require a common terminology.

This brings us to the third law in interoperability dynamics.  Even if you have an established physical transport and agreed upon standard message format, if you are not communicating using terms that the receiver can understand, you will not have a high fidelity exchange of coded information.

There are information sources and strategies for coping with terminology challenges.  Like some medical conditions, there is currently no cure, but there may be a way we can manage it until there is.  That is the subject of the next article.

Now that we have a documented definition for clinical interoperability and its macro components, the next reasonable question is: "Why is clinical interoperability important?"

Before continuing, please consider the following interoperability scale.



This scale represents the potential signal loss when information is exchanged between systems through a computer interface.  The line represents the clarity of the information as the level of interoperability improves.   This is also relevant, as the Certification Commission for Healthcare Information Technology, or CCHIT, has defined interoperability as "the high fidelity exchange of information between an EHR system and other healthcare IT systems."

Isolated systems cannot exchange clinical information about a patient, so the amount of signal loss between them is 100%.

Systems with a translational relationship exchange information, but not in a way that a software application can take advantage of.  An example of this is when systems can exchange notes about a patient or systems that can exchange free text patient information.  It requires a human to translate the information and take any action or decision support.

Interoperable systems can exchange information, and a percentage of the information can be put to coded, productive use.  This type of relationship usually has established syntactic interoperability, but less than ideal semantic interoperability.  In other words, it is getting messages but some of the information must be translated as free text for a human to interpret.

Compatible systems are leveraging established syntactic and semantic interoperability mechanisms with a high percentage of useful exchange.  An example of this is two systems exchanging HL7 messages operating on the same terminology.

Integrated systems (as the name implies) operate on a common framework.  An integrated relationship is driven by strict adherence to a common standard and a common or well-correlated set of terminologies.
It is not uncommon for people to say they have an interface between systems, even if the interface is translational and provides limited value to the consuming application.  I offer this scale to provide a vocabulary to further describe the capabilities and utility of an interface in the interoperability dialog and to further refine our question to "Why is High Fidelity Clinical Interoperability Important?"
 
There are two answers to this question.  One explains why interoperability has been important and the other tells why interoperability will become even more important in the near term future.

Interoperability has been important to the Healthcare End users for at least the last decade for the following reasons:

Data Exchange with trading partners

A system's ability to provide high fidelity information to its trading partners during a commercial transaction is imperative to supporting high-volume data exchange, as well as ensuring the accuracy of the information itself.  Some examples of this are: reference laboratory testing, e-prescribing and drug formulary compliance.

Data Exchange between Co-Mingling Applications within a Healthcare Institution

Many institutions have a core application that is responsible for the current patient information.  They may also have additional niche applications, like an Emergency or ICU specific application, that comes from another application vendor.  In this situation, the disparate applications are not integrated, but the need to exchange the patient's information is as relevant as if they were.

Data Exchange between Co-Mingling Applications within a Network of related healthcare Institutions.

There has been much consolidation in the healthcare industry as health networks merge and grow through acquisition.  When this happens, it is often the case that the new siblings do not use the same core applications.  In this situation, there is still a need to exchange a patient's information when they move from venue to venue, without the effort and risk associated with manual data entry.

Data Aggregation and Biosurveillance

With the advent of PHRs and RHIOs, there is a desire to move patient information to repositories so that the aggregated, centralized data can be put to use to the benefit of the patient and/or the healthcare industry at large.
All of these and more are reasons why the end users of healthcare IT have been rending their garments and gnashing their teeth.  These are the reasons that solutions interoperability is better now than it was ten years ago, even though it is not yet where it needs to be. 

Healthcare IT is changing. It has been recognized that for the industry to evolve and improve, it must begin movement toward convergence.  The road to convergence is paved with interoperability.

Enter the Certification Commission for Healthcare Information Technology, mentioned earlier, whose mission is "to accelerate the adoption of robust, interoperable health information technology by creating a credible, efficient certification process".

There is, and will continue to be, growing pressure on application vendors to become CCHIT certified.  While CCHIT certification is more than just interoperability, there are 39 requirements statements that relate directly to clinical interoperability in the ambulatory system certification and 22 in the inpatient system certification requirements.

The need-driven interoperability of the last decade was really about the exchange of information between distinct applications, often limited to an operational transaction.  In other words, it was sending an HL7 records to perform some discrete task or it was passing a complete patient context to a system it was tightly coupled to through a specific translational process.

By contrast, the CCHIT driven interoperability is more focused on general/holistic interoperability, requiring an accepted message format and terminology set. 

CCHIT interoperability does not require that I know about my partner.  I should be able to exchange a patient's clinical context with anyone who is CCHIT certified.

Whether you are an HIT application vendor looking to share data with business partners, cooperate with high performance niche applications and support your client's acquisition-related issues, or are concerned about being left behind because you can't put a mark in the CCHIT compliance check box, high fidelity clinical interoperability IS important.

The next question is how to make it happen.  That is the subject of another article.