By: Charlie Harp

Whether you have been following the buzz related to the ARRA meaningful use criteria or you are involved in clinical information exchange, you have likely run across the acronym LOINC recently. A significant chunk of my career has been spent in the lab system environment, so I thought it might be useful for me to share my thoughts and experience on the lab domain and LOINC.

What is LOINC?

LOINCstands forLogical Observation Identifiers Names and Codes. It is maintained byRegenstrief Instituteand, according to their website, it’s purpose is “to facilitate the exchange and pooling of clinical results for clinical care, outcomes management, and research by providing a set of universal codes and names to identify laboratory and other clinical observations.”

What LOINC is most commonly known for is lab test-related codes. In order to understand LOINC, you must first have a basic understanding of the Lab domain.

An Overview of the Lab Domain

When it comes to structured terminology, there are a handful of concept types in the lab domain that a healthcare information architect needs to worry about.

Lab Order

Lab orders are the codes that one entity sends to another when it isrequestingthat a test, or group of tests (also known as a Panel or Battery), be performed. An order is not a clinical entity, it is an administrative entity. Other than seeing which orders might be pending, no clinician cares about an order. You can think of an order as anexpectation of clinical data.

通常,价格与订单相关联。作为a result, additional specificity may be required in the expression of an order so that it can be billed appropriately. For example, a test done using an automatic method is likely less expensive than one done manually. In that case, expressing the method in the term allows us to assign a higher price to the manual test, even if it does not make a difference clinically.

A panel, or battery, order represents a group of individual lab orders. Some of these, like a CBC or Complete Blood Count, can be fairly standard. Consider a typical CBC or Complete Blood Count panel:

[Order] Complete blood count (hemogram) panel in Blood by Automated count

[Result] Leukocytes [#/volume] in Blood by Automated count

[Result] Erythrocytes [#/volume] in Blood by Automated count

[Result] Hemoglobin [Mass/volume] in Blood

[Result] Hematocrit [Volume Fraction] of Blood by Automated count

[Result] Erythrocyte mean corpuscular volume [Entitic volume] by Automated count

[Result] Erythrocyte mean corpuscular hemoglobin [Entitic mass] by Automated count

[Result] Erythrocyte mean corpuscular hemoglobin concentration [Mass/volume] by Automated count

[Result] Platelets [#/volume] in Blood by Automated count

有时一个面板可以代表一个自定义组tests that are associated with a special group price. Very often, panels represent tests that are performed on the same instrument. It is always good to know if a given lab order represents a single order or multiple orders and which lab results you can expect to receive if the order is fulfilled.

Lab Result

Lab results are the codes that represent an analytical result and are returned when an order is fulfilled. A lab result is a clinical entity. It represents a piece of information about the patient that is important to the delivery of care.

There are many types of lab results and their structures vary accordingly. The most typical lab result is asimple analytewhich consists of a result code, result value, result unit, reference ranges and abnormal flags.

Below are some examples of common analytical lab results.

These results were extracted from actual, anonymous HL7 lab result transaction records. The lab result names were the actual names represented by the result codes in the record.

A real lab result, encountered in transactions today, is comprised of the following parts:

• Lab result code or mnemonic
• Lab result term
• Lab result value
• Lab result unit of measure
• Lab result applied reference range
• Lab result abnormal flag

Of these, the Lab result term is the most dynamic in how it manifests itself in local and standard lab result terminologies. The lab result term is also the item that gets mapped to a LOINC term.

A lab result term is what is displayed or printed on a lab report when the lab results are presented to the patient or provider. The lab result term may imply a number of things about the context of the lab result. Some common attributes implied by a lab result term are as follows:

Analyte	This is the specific characteristic that a lab result is measuring. This attribute is always represented in a lab result code in some form or another.
Analyte Context	Some lab tests may include words that apply additional context to the analyte. For example a result may have a peak and trough value. This context does not change the nature of the result but impact how it is interpreted.
Specimen Type	This is the type of specimen that was used to perform the test. This is oftennot explicitly statedin local lab terminologies if it is commonly known.
Time Specific Data	Some tests may be performed as a timed series or have time specific collection characteristics. If this is the case the lab result term may include applicable time information.
Result Type	This is the nature of the result itself. For example, a specific analyte may fall into a category where it can be measured either quantitatively or qualitatively. This may also be represented by a specific word like ‘ratio’. Like the specimen type, this is typically omitted if the type is generally accepted for a given analyte. This can also be inferred from the result unit associated with the lab result.
Testing Method	This is the method that was used to perform the test. In some cases the method can alter how the result is interpreted; in others it may provide a degree of certainty in the results validity. In most cases this information is not represented in local lab result terminologies.

In the grid below you can see a number of actual lab result terms and how they break down into the attributes mentioned above.

I should point out that these attributes are slightly different than the attributes used in LOINC. We will discuss in more detail later. However, this is the way that I thought about lab codes before LOINC became the standard that it is today. You will also note that what is being described here is simple analytes, not microbiology, radiology or other types of results. This is because they are fundamentally different and have their own, in some cases more complex, frameworks and attributes.

在接下来的救援队cle, I will write about the history of result codes and why exchanging them, in general, is difficult.

---

Lingua freaka– a‘Battery’of tests

Every now and then you come across a word and it makes you go “hm?”. When that happens to me, I like to chase it down and figure out what caused the blip on my cognitive radar. As I was writing this article, my radar was ‘pinged’ by the term ‘Battery’ as it refers to a group of lab tests.

In typical American discourse, the term most commonly refers to a portable power cell that you buy at the store and load neatly into your 5-year-olds “I’m ready – SpongeBob talking action figure”, but they can also be used for good.

So what does a portable power cell have to do with a grouping of related tests? The answer is an excellent example of how the meaning of language can change based on the irresistible force of common use.

According toWiktionary, the origin of the word is the Old Frenchbaterie,which means “the action of beating.” While this is oddly appropriate, considering the effect that the SpongeBob talking action figure has on my brain (and its use in ‘assault and battery’), it actually adds to the confusion.

It would seem that in the 1500s, the term shifted to also mean a grouping of artillery units as in a “gun battery”. So this notion of grouping tools in an arsenal is the likely source of a “battery of tests”.

But why do we call a portable cell a battery? This is because of Benjamin Franklin. In 1748 he described multiple Leyden Jars (early capacitors) by analogy to a battery of cannons.

So, if you want to be a smarty pants, the next time you are at a dinner party and someone refers to a ‘Energizer AA’ as a battery, you can explain that since it only consists ofonecell, it is not technically a battery.

Lab Orders and Results prior to LOINC

I was hired by Medi-Span in 1998 to run their software products team. In a meeting with product management someone was explaining a CDS module that involved lab results and proudly informed me that they had cross referenced their internal lab codes to LOINC codes. I said, “That’s great… what’s a LOINC code?”

What’s relevant about this little anecdote, is that prior to starting at Medi-Span I had spent the prior ten years developing lab information systems with a focus on system interfaces. During that time with the countless client interfaces, in both the reference lab and clinical lab environment, I had never come across LOINC codes.

Why was I unaware of LOINC in 1998, four years after it had been initiated? The more important question is why now, 14 years later, are most labs still struggling with LOINC? Part of the answer lies in the way lab systems evolved.

Lab systems were early adopters of using structured codes to store and organize information. This was because the nature of the information necessitated it. The orders and results, typically related to a visit oriented grouping entity called an ‘Accession’, were used to track what was ordered for billing and the associated tests that were to be performed in the lab and resulted for the client. Once the testing was complete, the client was billed and the test results were then reported, mailed, faxed, auto-dial printed or transmitted using a custom or ASTM (now HL7) interface. Having stable codes for lab results also made it easier to compare values over time to look for trends or significant shifts (or deltas).

During these early days, the most common output of a lab visit was a paper report that listed the results, their reference ranges and abnormal flags. The results were not intended to be exchanged (combined) electronically, so the codes were described to the extend they needed to be to appear unique on a lab report. Information, like the method the test was performed, was only included in the term if it effected how the result was interpreted. Other attributes, like specimen type, were only included if they were atypical.

So, as a hospital lab or reference lab, the rules of engagement for lab order and result terminologies were something like this:

• You only need to define lab order and result codes for tests that you perform and report
• The codes themselves only need to be described to the extent they are unique within the lab
• The specific attributes (method, property, specimen type) need not be described in the terms as they are known within the lab unless they are required for uniqueness or interpretation.
• Lab terms may include workflow information that is not relevant to the order or result.

If there was a need to exchange information, like between a hospital lab and reference lab, test codes were mapped and unit conversions were applied within the interface. This was less of an issue because referral testing was typically limited to a subset of tests that could not be performed in house.

Islands of terminology

The early adoption of terminologies created for internal use resulted in decades of labs existing as islands of terminology.

Unlike the medication domain, there are no commercial, proprietary lab terminologies that a lab can license (despite my efforts to get every content company I have worked for to do this…). CPT (Common Procedure Terminology) codes have been around for years but they are expensive to use and are geared toward billing and not clinical use.

作为一个实验室,如果您不想创建自己的b terminology, your choices are LOINC or SNOMED-CT Procedures. The result is that Hospital labs and other local labs create their limited set of simple test codes. Large reference labs like Quest and Labcorp use internal codes as well, but typically provide LOINC codes (if they exist for a given test), on request, in their result transactions.

Many of the systems in use today have been around awhile, operating under the ‘if it ain’t broke, don’t fix it’ moniker.

How avoiding interoperability issues helped create an industry

Prior to 1986, pharmaceutical companies used many local and regional laboratories to perform safety and efficacy testing while conducting clinical trials. One problem with this approach was that it resulted in a 39% error rate. Human error accounted for the majority of data inaccuracies, which were caused by such things as mislabeled test kits, incorrect tests, and missing specimens. The other problem was that differences in methodology, terminology, result units, reagents and reference ranges resulted in a “combinability” problem. These inconsistencies between information sources resulted in uncertainty when the information was brought together into a central location for analysis. In order to deal with this the combined information would need to be “cleaned” before it could be used.

The monumental difficulties of interoperability (syntactic, semantic) as well as the deeper problem of clinical equivalence resulted in delays, rework and significant cost.

The pharmaceutical industry was facing a problem very similar to what we face in healthcare today when it comes to coordination of care. They were lucky however because each clinical trial was a contained system so rather than address the interoperability issue and an industry, they gave birth to a new business segment, the central lab.

The pioneer in the space was SciCor (Now Covance Central Labs). They are here in Indianapolis and I worked there from 1993-1998. Through the course of events they addressed many of the problems with a number of innovative approaches in specimen collection, workflow, centralized data management and reporting (most of which happened before I got there…). The error rate is now somewhere around 2%.

The clinical trial interoperability problem was resolved by removing it from the equation. All (or most) tests were performed in a single lab using the exact same methods. The combinability of the data became a non-issue…cheaters.

There is a lesson to be learned here, but it is not what you think. What worked for the microcosm of individual clinical trials will not work for the entire healthcare industry.

Finding the right solution for lab result interoperability

We must find a different solution to the current interoperability problem that allows a federated approach to combining clinical information while managing uncertainty. Can LOINC play a significant role in this solution? Before we can ponder that, we need to understand the intent and structure of LOINC, and assess the strengths and weaknesses of it as it stands today.

Lab Domain and LOINC Overview

First, Everything I learned about LOINC is based on information and data that came from theLOINC website. If you are interested in making the most of LOINC, I recommend you check it out.

作为I mentioned in the beginning of this post the mission of LOINC is “to facilitate the exchange and pooling of clinical results for clinical care, outcomes management, and research by providing a set of universal codes and names to identify laboratory and other clinical observations.”

So the objectives are to:

1. Facilitate theexchangeofclinical results
2. Facilitate the pooling (aggregate) ofclinical results
3. Facilitate outcomes management (through the application of 1 and 2)
4. Facilitate research (through the application of 1 and 2)

And this is accomplished by:

1. Providing a set of universalcodesandnamestoidentify laboratory observations
2. Providing a set of universalcodesandnamestoidentify other clinical observations

If you read the previous post, this may seem familiar. The objective of LOINC seems to coincide with the objectives in the pharmaceutical industry in the mid-80s relative todata combinability.

We will get into the structure of LOINC later, but I think it is a safe bet that when LOINC began it was focused on laboratory observations and the “other clinical observations” was added later.

We humans have a peanut-sized part of our brains called the amygdala (no, I am not talking about Luke Skywalker’s mom…). The amygdala assesses whether a situation is dangerous, then fires signals to other parts of the brain. When I hear words like “other”, “miscellaneous” and “universal” my amygdala says{Do you hear that?!?}My latent informatics super powers notwithstanding (eat your heart out spiderman) this is largely based on years of observing unintended consequences of good intentions in terminology evolution.

For now, let’s pretend that the “other clinical observations” does not exist and just focus on “laboratory observations”. We will come back to the “other” part of LOINC later.

The Official LOINC terminology

You can download theofficial LOINC datafromhere. I typically download LOINC in MS Access format. I am going to provide a high level overview of the structure of LOINC but I strongly recommend the LOINC manual as a great source of more information for those that want to do a deeper dive.

The Code

LOINC代码本身就是一个3 - 7位顺序英航se number followed by a required hyphenated check digit (0-9). Regenstrief recommends you support a 10 character field to allow for future expansion. Obviously, unless you enjoy calculating check digits, you would store the LOINC code as text not as a number. The number itself is a ‘dumb number’, in that it has no inherent meaning in and of itself.

The Term

Each LOINC code has an associated term. The term has several incarnations. There is a short name, a long common name and the distinct parts that describe the term. Initially we will focus on the parts.

A given LOINC Term is comprised of six major parts (with a total potential of 16 parts when you factor in optional sub-parts and sub-classes). {Do you hear that?!?}

Here are the major parts:

Component	This is the principle name of the order or result. As depicted above the component has the potential to be fairly convoluted and complex.
Property	This is the nature of the property being measured. You can almost think of this as the type of result unit. For example: ‘mg/dL’ is a ‘Mass Concentration’ property.
Time Aspect	For most results this is ‘Point in time’. For results whose value represents a measurement that in measured or calculated over an interval of time this represents the time interval.
System	This is the substance that the test was performed on. I tend to think of this as the specimen type.
Scale	This is the measurement type. A majority of the lab result LOINC codes are either Quantitative or Ordinal (89%). In fact, 65% of them are Quantitative.
Method (optional)	The method is how the test was actually performed.

Preparing your working LOINC subset

If you are going to dig into the Official LOINC data, with a focus on lab results, the first thing you need to do is prepare your working subset. To do that you need to do the following:

1. Identify the Active Lab Observation population of LOINC codes

I am going to be throwing some numbers at you as we continue. The subset I am going to be focusing on is the following LOINC terms:

• Are laboratory observations (CLASSTYPE equals ’1’)
• Are active (STATUS is equal to ‘ACTIVE’)
• Represent lab results (ORDER_OBS is either ‘Observation’ or ‘Both’)

For those of you playing the home game… here is the query I am using.

SELECT LOINC.CHNG_TYPE, LOINC.CLASSTYPE, LOINC.ORDER_OBS, LOINC.*
FROM LOINC
WHERE ((Not (LOINC.STATUS)=’ACTIVE’) AND ((LOINC.CLASSTYPE)=1) AND ((LOINC.ORDER_OBS)=’observation’ Or (LOINC.ORDER_OBS)=’both’));

This results in a list of about 41,313 distinct LOINC terms in the database I am working in.

I am excluding lab orders because they are not clinical terms (Orders are administrative terms).
I am excluding ‘other clinical observations’. {Do you hear that?!?}
I am excluding terms that are not active… because I only care about active terms.

2. Only include LOINC relevant LOINC fields

According to the LOINC documentation there are a number of columns that are no longer updated, deprecated or for internal use. I create a view that allows only shows rows that are useful. These are the following:

Column	Description
LOINC_NUM	The Unique LOINC code
COMPONENT	Term – part 1 – Component
PROPERTY	Term – part 2 – Property
TIME_ASPCT	Term – part 3 – Time aspect
SYSTEM	Term – part 4 – System
SCALE_TYP	Term – part 5 –Scale type
METHOD_TYP	Term – part 6 – Method Type
STATUS	The status of the term (should all be active from step 1)
CLASSTYPE	1=Laboratory class; 2=Clinical class; 3=Claims attachments; 4=Surveys
SHORTNAME	The short name (not very useful)
EXAMPLE_UNITS	These are not consistently populated but worth keeping around
ORD_OBS	Indicates whether the term is an order, observation or both
INPC_PERCENTAGE	INPC result volume indicator
LONG_COMMON_NAME	“human readable” constructed term description

Here is the query (combining the useful columns and the term filters from above):

SELECTLOINC.LOINC_NUM, LOINC.COMPONENT, LOINC.PROPERTY, LOINC.TIME_ASPCT, LOINC.SYSTEM, LOINC.SCALE_TYP, LOINC.METHOD_TYP, LOINC.STATUS, LOINC.CLASSTYPE, LOINC.SHORTNAME, LOINC.ORDER_OBS, LOINC.EXAMPLE_UNITS, LOINC.INPC_PERCENTAGE, LOINC.LONG_COMMON_NAME
FROMLOINC
WHERE(((LOINC.STATUS)=”Active”) AND ((LOINC.CLASSTYPE)=1) AND ((LOINC.ORDER_OBS)=”Observation” Or (LOINC.ORDER_OBS)=”Both”));

---

Lingua Freaka: Amygdala hijack

Amygdala hijack is a term coined by Daniel Goleman in his 1996 bookEmotional Intelligence: Why It Can Matter More Than IQ.(it would also be a cool name for your band…)

The amygdala is responsible for our fight or flight response. This function, that evolved very early, is designed to react in milliseconds to perceived danger without thinking twice. The term Amygdala Hijack is used to describe emotional responses from people which are out of measure with the actual threat because it has triggered a much more significant emotional threat.

An amygdala hijack exhibits three signs: strong emotional reaction, sudden onset, and post-episode realization that the reaction was inappropriate.

Know the signs… and remember to apologize.