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.
实验室系统使用结构的早期采用者d 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:
- 你只不ed 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.
As a lab, if you do not want to create your own lab 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 aint broke, don’t fix it’ moniker.
How avoiding interoperability issues helped create an industry
Prior to 1986, pharmaceutical companies used many local andregional 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.
