|
The HITECH provision of the American Recovery and Reinvestment Act (ARRA) has created the impetus for exponential growth in the adoption of electronic medical record (EMR) systems. Today, just 6% of U.S. office-based physicians have deployed a fully functioning system. However, according to a recent survey, 58% of U.S. physicians not currently using EMRs intend to purchase an EMR system within the next two years.1
To compete effectively in this rapidly-evolving healthcare landscape, hospitals and clinical laboratories must make EMR system integration a core thread in their IT strategies. Ultimately, they must be able to successfully create interfaces from their laboratory information systems (LISs) to the myriad of EMR systems in use within physician practices-enabling them to electronically receive orders and deliver results to their physician clients. With more than 300 EMR vendors currently operating within the healthcare space, this is not an easy task.
EMR Order Entry Deficiencies
Compounding this task is the fact that most physicians utilize multiple labs and route tests to a particular lab, depending on the patient's health plan and the type of tests required. Practices also refer patients to local hospitals for testing. Yet, many EMR systems contain deficiencies that limit lab transactions. For example, the EMR systems are unable to prompt for "ask at order entry" (AOE) questions, receive images embedded in reports, or perform medical necessity checking to support the Center for Medicare & Medicaid Services Advance Beneficiary Notice (ABN) requirement.
Unfortunately, many EMR systems cannot overcome all of these lab-specific deficiencies while also meeting the necessary requirements for "meaningful use" certification. These criteria include the ability to: 1) support ambulatory computerized physician order entry (CPOE) and 2) drive clinical lab-test results into EMRs as structured data.
What is needed is middleware with the ability to route orders to multiple labs via a centralized lab hub with universal requisition capability. Support for universal requisition or "split reqs" must include the ability to generate multiple requisitions from the data collected in a single CPOE workflow. Specimen temperature, performing facility, patient insurance and test availability are all triggers that drive the splitting of an order to multiple requisitions.
Significant Diversity in Lab Source Data
An estimated seven to ten billion lab tests are performed in the U.S. each year, providing the majority of information for clinical decision-making.2 Approximately 55% of lab testing is performed by 6,000 hospitals3, with the balance being handled by national and independent reference labs and a small but growing number of physician office labs. The automation of laboratory processes, including results reporting, has significantly improved lab productivity and reduced turnaround times-allowing critical results to reach physicians more rapidly and facilitating better clinical outcomes.
However, the information systems and test methodologies that labs employ are extremely diverse, creating substantial variation in laboratory source data. Considering that lab data constitutes as much as 94% of the objective data in a patient's clinical record,4 it becomes imperative to achieve a method of consistent data capture and normalization from the thousands of available data sources.
The Case for Middleware
Currently, there is no government-mandated data format for lab transactions. As a result, each lab vendor must work with every EMR vendor on a point-to-point basis. This has a substantial impact on lab service providers both from a cost and resource standpoint. Because the interfaces between labs and EMR systems are generally one-to-one relationships where each physician practice represents a unique connection, the legacy standalone proprietary LIS systems in place today are not equipped to enable the EMR systems to address the new HITECH requirements. In fact, a recent report suggests that healthcare providers will likely encounter difficulty in their attempts to capture and enter data as structured data elements.5
Continued on page 2...
|