Making References Labs More Competitive and Profitable with an Integration Engine
The Advantages of an Integration Engine in Reference Labs
Strengthening and streamlining the community of referring physicians
Why are healthcare reference labs using an HL7 interface engine for electronic data exchange more competitive and profitable than labs using a paperbased data exchange method?
Reference lab managers searching for ways to electronically receive orders and send results to their clients can use this paper to:
Confirm current interfacing challenges including:
Paper and electronic workflow
Reasons to shift from paper to electronic
Electronic messaging issues
Understand the role of an interface engine within a reference laboratory
Discover the advantages delivered by an interface engine
Learn the attributes of a quality interface engine
Realize that the Corepoint Integration Engine is an ideal interface engine solution
The reference laboratory challenge
Finding success in the reference lab market requires more than providing clinical and specialty testing. Increasing revenue requires reference labs to provide more services to a growing variety of clients while continually striving to improve quality while producing, managing, transmitting and archiving test results at lower costs.
Physicians and their patients rely on reference labs for the timely and precise communication of test results as the foundation of diagnosis and treatment. It is, therefore, critical to manage the flow of orders and results among a wide variety of clients in a timely and accurate manner.
Effective management is getting more difficult each day. The list of client types and healthcare systems served by reference labs grows daily (see the table below), and the quantity and variety of clients greatly increases the complexity of the work flow.
Workflow in the traditional reference lab is designed around receiving specimens along with a paper requisition from clients. This manual system uses order entry clerks to manually enter requisitions into the Laboratory Information System (LIS) as the specimens are received. After processing the specimens, results are typically delivered to the physicians via fax or an alternative “paper” based method. This manual order entry is slow, error-prone, inefficient and expensive.
Data movement begins when the client enters an order into the order entry system or into the reference lab’s web portal. Specimens are shipped after the order data is sent electronically to the reference lab.
Upon receipt of a specimen, clerks merely scan a barcode on the specimen to lookup previously transmitted order information. This approach significantly reduces the time for processing requisitions and reduces the number of errors due to illegible and improperly entered requisitions.
As soon as a test is complete, results are delivered electronically to the ordering physician. They are communicated via real time links, batch file retrieval or via a secure web site.
A message structured using the HL7 data standard can easily be modified to accommodate the requests of each client. Requests are often minor changes of the message content or vocabulary. For example, mapping from reference lab test local codes into LOINC codes during message preparation is a common task.
Why shift from paper to electronic data movement?
The demand for electronic data movement is real.
Electronic communications provides lower cost, faster delivery of accurate results, and is more easily configured to meet client requests making a reference laboratory more competitive and profitable.
As a reference lab’s clients deploy more systems focused on clinical information, the requirement to enter orders and review results on the clients’ system is accelerating. How a reference lab responds to this accelerating demand is critical to short-term survival and long-term growth.
Two transitional opportunities for clients
The physician client
Imagine a five physician office that historically used their practice management system (PMS) application to process only demographic and billing information.
Upon the installation of a new electronic medical records (EMR) application, new electronic opportunities become available to those physicians. By placing lab orders in the EMR’s order entry module and receiving results electronically, the patient charting module in the EMR now charts lab results for the physicians to view.
Desirable capabilities like this are strengthening the partnerships between reference labs and physician groups.
The hospital client
For several years, the typical 300 bed hospital has electronically exchanged patient data between the hospital information system (HIS) and the laboratory information system (LIS). The interface is “fully integrated” where orders and results flow between these two critical, in-house systems. Reference labs have historically provided services on the fringe of this tightly-coupled environment by using paper or faxes to deliver results to the hospital.
In order to integrate the reference lab into this world, the lab must implement additional electronic interfaces. In order to speak the language spoken by the hospital based HIS and LIS, the interfaces will most likely be implemented using HL7.
As more and more physicians require that all results appear in electronic form, competitive reference labs will respond with a solution. The advantage to the doctor is one consistent, electronic view of all results.
The advantage to the LIS manager is the ability to easily and more closely track the status of specimens. Both benefit from timely and accurate access to data when and where needed.
The Electronic Network
HL7: the foundation of healthcare electronic messaging
HL7 is the messaging standard used by healthcare applications to electronically share data. This international standard provides the flexibility to support many different care settings. For example, information received from each of the following sources may be quite unique; however, the HL7 standard ensures electronic message compatibility:
A lab order sent from a physician’s office
A lab order sent from a small specialty clinic
A lab order sent from a large hospital.
Historically, electronic links between reference labs and clients were built on an ad hoc basis and deployed in a point-to-point fashion. This approach provided a workable solution for the most critical clients at the largest labs.
Figure 1 illustrates how point-to-point connections look in a reference lab environment.
The challenge with this approach is the links are typically built by LIS vendors and can be expensive to build and maintain. The environment illustrated above can easily cost $60-80K, in addition to the time needed to implement functionality outside of the LIS vendor’s core competency.
As more lab clients demand electronic communications, the point-to-point approach becomes unmanageable.
The above image illustrates the natural progression and the result of adding one interface at a time using the point-to-point method.
This environment can easily cost a reference lab $200–300K. Initial cost starts around $15K per connection with added implementations and/or customizations, plus maintenance.
One can see the complexity in building and maintaining this environment. Since the interfaces constructed in this point-to-point world are typically built by the vendors who create the LIS software, the lab is dependent on the LIS vendor. The LIS vendor’s schedule and the tools they use to develop interfaces may make deploying a quality, timely interface that deals with each client’s specific needs challenging.
Long lead times and expenses often mean electronic messaging is only practical for the largest clients. In today’s competitive market, it may prove detrimental to leave a large number of smaller lab clients without electronic connectivity to the reference labs.
Integration Engines in Reference Labs
An interface engine creates an easy to manage messaging network by becoming the centralized, automated hub. It acts as an intermediary for all messaging between clinical systems and clients.
Since only a single, robust demographics, orders and results interface is required between the interface engine and the LIS, the dependency on the LIS vendor is radically reduced. More importantly, the engine’s core competency is building and supporting interfaces. Through the use of the tools specifically designed to build interfaces, interfacing cost is logically more affordable and interfaces are easier to manage.
History of engines in reference labs
Several years ago the largest labs discovered they could use an interface engine to solve the data movement challenge. While license fees were historically expensive and engines required a highly-technical staff, larger labs found interface engines provided them with a competitive advantage when building interfaces for larger clients. Until recently, lower volume clients still were forced to deal in the “paper” world.
Some labs now offer an interim approach to solving this problem. This approach ensures larger volume clients get a direct interface through a communications engine, while lower volume clients still send “paper” orders and receive results from a web portal or in paper form. This approach forces clients to use non-standard communications links and a proprietary coding scheme/message structure.
More importantly, many web portal and proprietary solutions simply deliver results electronically and do not insert results into a client’s IS or EMR system.
The dilemma is clear. Clients want tighter interfaces with their lab partners and the cost and manageability of the point-to-point method is not practical. Therefore, labs are faced with taking an ad-hoc, time consuming, and expensive interfacing technique and transforming it into a more flexible, precise, timely, and cost effective solution.
The good news is that the introduction of easier to use and less expensive interface engines has made electronic efficiency available to reference labs of all sizes. Regardless of market niche or size, most labs can now deliver the electronic connectivity required by their clients.
Many larger labs are finding that the efficiency gained by installing a newer, more efficient engine is the only way to provide effective connectivity to clients. Lower volume labs can now install the same technology and move each of their clients closer to the world of “interoperability.”
Advantages of an engine
Here are a few of the advantages reference labs report when using an interface engine to manage their HL7-enabled, client interfaces:
Decreased LIS-vendor dependence
Reduced interface-development costs
A single inbound orders interface from an engine to the LIS and a single outbound results interface to the engine will likely serve all clients.
Faster interface development for new clients and applications
Since the LIS vendor does not have to be involved in each inbound orders and outbound results interface, and the engine provides better tools for building interfaces, each interface can be built in a fraction of the time required in the point-topoint network.
Greater control of data communications
Reduced interface maintenance requirements allowing for reductions in support staff
Increases in communications reliability and accuracy
Selecting an interface engine
A quality interface engine operates smoothly behind the scenes while seamlessly coordinating the exchange of data between a variety of HL7- compliant systems. A great engine operates so efficiently that one soon forgets it is there.
An interface engine simplifies the highly complex task of mapping dissimilar data types and formats used within the healthcare industry. It also provides a detailed log to indicate the successful delivery of messages.
Here are the high level attributes one should look for in an interface engine:
Easy to implement, configure, and deploy
Does not require a programmer to install or maintain
Has the flexibility to adapt to the many diverse interpretations of HL7 provided by your clients
Labor-saving, centralized interface management The following list of specific features is critical for an effective interface engine:
Easy to use, step by step screens and wizards to walk users through workflow related to building, testing, implementing and maintaining interfaces
An interface management console that provides a visual means for monitoring the status of interface connections
Store and forward message queuing to assure proper order of receipt and delivery of messages and associated acknowledgements (ACKs)
Extensive logging that tracks transaction history and creates message archives
“Out-of-the-box” specifications to all published HL7 releases in use today should be available to the implementer
Tooling to facilitate quick support of nonstandard HL7 data
An easy method of handling “one off” details such as “Z” segments
Validation and testing of interfaces should be easy
Testing tools and the ability to edit messages should be easy
The most successful electronic networks are built when a relationship with an interface engine company is structured around common goals. The provider of your interface engine must work well with your staff and your other vendors.
More competitive reference labs have discovered an interface engine is no longer optional. It has become mission critical—an indispensable tool for delivering better service with faster and more accurate results electronically.
In addition to providing results to one’s clients in a more efficient manner, a properly implemented interface engine will reduce staff requirements thus mitigating exposure to increasing labor costs. It will improve cash flow by speeding the transmission of accurate billing information. Overall, an interface engine enhances the bottom line.
About the author
Sonal N. Patel, MBA, BS, MT(ASCP) has extensive experience working in healthcare from both the provider and vendor perspective. Prior to her role as Chief Customer Success Officer, she served as a Medical Technologist and Laboratory Supervisor at Roche Diagnostic/Golden Triangle Regional Medical Center/Baptist Memorial Hospital and also operated in several client services, support and training roles at Antrim/Sunquest/ Misys Healthcare Systems.
You might also like
Addressing NHS challenges: the role of next generation interoperability
A vendor-neutral & innately interoperable technology stack can help NHS solve data exchange and data quality challenges.