Last week I published the first in a series of seven blog posts that discuss some of the misconceptions about lab interfaces and intelligent clinical data extraction software.
Below is the list of misconceptions this blog series will cover in the span of seven weeks. This post addresses the first misconception in bold type in the list below.
We are implementing or already have an interface to Quest and/or Labcorp and no longer have to manually enter test results.
Only a small percentage (typically estimated to be 10 – 30%) of lab results don’t come through the interface so it’s not a high priority problem.
We have an in-house lab that handles our lab tests.
All of our test equipment is interfaced with the LIS, which is integrated with our EMR.
For non-interfaced test results we already have scanning software.
Optical character recognition (a.k.a. OCR) isn’t accurate enough for clinical data.
Clinical data extraction software is perceived to be an alternative to a lab interface or that a lab interface with a national reference lab will be sufficient to solve the interoperability problem with lab test results from reference labs.
For reasons I won’t go into here, a lab interface, technically-speaking, is the ideal method for capturing diagnostic test data directly in patients’ electronic medical records.
However, in practice a lab interface is limited in its ability to deliver results electronically for a few reasons.
Data interfaces are point-to-point. To connect to each reference lab, hospitals must implement a dedicated interface, which also means you must maintain separate interfaces to many labs. This approach is prohibitively expensive if you must implement and maintain an interface for a large number of laboratories. I’ll discuss this issue in greater depth in a future blog post.
Data interfaces are proprietary. Each lab interface has a different data format or variation of the industry standard HL-7 messaging protocol that isn’t compatible with other reference lab HL-7 messaging implementations. Therefore, the effort to implement an interface to one reference lab can’t be transferred to additional laboratories.
Lastly, no single reference lab offers a test menu with every diagnostic test or is geographically situated near the hospital or patients to perform tests where time or distance is of the essence.
In addition to practical limitations there are market dynamics that prevent hospitals from being able to consolidate send-out tests with a sufficiently small number of providers to make interfacing with all them financially justifiable.
The market for diagnostic testing services remains highly fragmented. As a result hospitals have to order tests from many reference labs. For larger hospitals the number of laboratories serving them can count in the hundreds when send-out test activity across all specialties and clinics are accounted for.
Additionally, the pace of innovation in clinical diagnostic testing continues to accelerate. Consequently, specialization is increasing, the variety of tests is growing and smaller specialty labs are becoming increasingly important to hospitals in need of their services.
In short, the problem of integrating point-to-point data feeds from all laboratories is neither practical nor desirable. A sound strategy is to implement data interfaces with laboratories where test result volumes justify the required investment. But to stop there and continue receiving the remainder (and likely a significant percentage) of test results to the fax machine would be a mistake. The question is how much of the pain of wrestling with non-interoperable lab test results should you tolerate? That’s the question I’ll address in my next blog post on this issue.
.If you’ve already implemented a lab interface(s) and are still manually entering a lot of test results or you’re entering all of your lab results manually and haven’t yet implemented an interface, we encourage you to speak to one of our health information specialists for a no obligation assessment to determine whether an automated clinical data extraction solution is right for you.
About the Author: Greg Gies
For 20 years in the software industry, Greg Gies has been helping businesses, government agencies and healthcare organizations achieve their goals and carry out their missions by making better use of information and automating business processes. Greg has held positions in sales, product management and marketing and holds an MBA from Babson College. He works and lives with his wife and three boys in the Boston area.