LII:The Comprehensive Guide to Physician Office Laboratory Setup and Operation/Data management

Data management in the physician office laboratory (POL) involves understanding workflows, choosing data management systems (like LIS or ELN), and applying best practices. This chapter talks about the common workflow and how data associated with it is better managed with informatics tools.

This fourth chapter on the topic of data management has seven sections.

-----Return to the beginning of this guide-----

4. Data Management

Functional requirements

When considering the data management requirements for any business — from a car dealership to a clinical laboratory — the workflow of the business should be one of the primary starting points. This holds equally true for the physician office laboratory (POL). As such it's important to note where the POL is located in the broad scope of clinical workflow, which is directly in the analytic stage of the process, with a few pre-analytic and post-analytic tasks occurring directly before and after. As a reminder, here's the POL workflow diagram again from part one of this guide:

Inside this workflow are various associated activities, largely dependent on the specimen and test type as well as the CLIA certificate type the POL holds:

1. Specimen collection: The physician, nurse, or office assistant will go through the necessary procedures to collect what is needed for an ordered test. Some specimens such as intravenous blood and urine will require added collection procedures beyond easy-to-collect specimen types such as capillary blood.
2. Specimen receiving: In most cases the specimen doesn't require special transportation because collection is happening at the point of care. Additionally, the specimen may not require much handling, as in the case of collecting capillary blood from the finger bed for a determination of glucose levels via a hand-held meter. More complex samples not tested at the patient's side will require extra receiving procedures, however, including adding labeling and barcoding as well as entering the specimen in a data management system.
3. Specimen preparation: In a POL where intravenous blood and urine are collected, those specimen types may require extra preparation if not performed in receiving. Blood, for example, may need to be centrifuged and have the serum plasma pipetted out as an aliquot.
4. Specimen processing and analysis: In the case of simple-to-used CLIA-waved test devices, the processing and analysis — often qualitative — is performed by the device, producing results in some cases within a few minutes. In the less frequent case of moderate to complex testing in a POL, additional processing such as the addition of a reagent or placement in an analyzer. This culminates in a manual analysis by a pathologist, cytotechnolgist, or other lab personnel or an automatic analysis by an analyzer.
5. Post-processing: This can range from simply disposing of a CLIA-waived test strip properly to reserving a portion of the specimen in storage for a set period of time in case an additional analysis is required.
6. Reporting: In many CLIA-waived devices reporting amounts to simply documenting the result of a test in a patient chart. A few waived devices and most moderate to complex analyzers will generate a report of results either digitally or as a printout. Advanced lab testing requiring human analysis may require the manual generation of a report for the office physician. In rare cases such as a positive result for HIV, additional reporting requirements to local and state authorities may be required. Of course, the final results are then related to the patient, and the physician reviews any necessary next steps.

These activities represent the core of what a basic clinical or physician office laboratory will do. However, a bevy of satellite tasks associated with the day-to-day operation of the POL add additional nuances and requirements when considering how to better manage the lab's data and activities. Ordering inventory, scheduling lab appointments, and maintaining CLIA requirements are all examples of such satellite tasks. An analysis of those tasks may in return promps questions about how more efficient they can be made, if it all, through a data management system. Additionally, systems may vary in purpose and functionality, requiring comparisons of more than one type of system based on POL requirements. A POL with a CLIA certificate of waiver that performs a handful of capillary blood and urine tests may not be able to justify a full-fledged laboratory information system (LIS) to manage the data associated with those tests. Results may just need to be entered on a patient chart and/or in an electronic health record (EHR). However, a POL certified to do moderate and complex testing and doing it in sufficient volume may need to turn to an in-house LIS.

So far we've said that looking at a business' workflow makes for a nice start to determining its data management needs. This process includes not only looking at core tasks such as sample processing and reporting but also ancillary tasks such as inventory management, payment processing, and performance tracking. What hasn't been said so far is that competent vendors of data management systems have covered a lot of that ground themselves already, determining common functional requirements of clinical labs and adding corresponding tools to their software; laboratory workflow drives LIS and other data system development. As such, looking at the features of typical clinical data management tools often provides additional insight. One other approach involves an amalgam of these two methods: a comprehensive request for information (RFI) or request for proposal (RFP) document.

Several industry-based organizations have created these sorts of documents for LIS and laboratory functionality, including the Association for Pathology Informatics (API) and the Healthcare Information and Management Systems Society (HIMSS). Those documents contain hundreds of software requirements based on the operational and administrative needs of a clinical laboratory. Using those documents and other research of vendor offerings and laboratory needs, the authors of this guide have created a similar online document to allow potential users a chance to determine if an evaluated LIS can meet a laboratory's needs. An example of functionality statements can be seen in Figure 1:

Figure 1: Sample of LIS requirements from the page Laboratory information system (LIS) questionnaire

The full set of 320 LIS requirements is included as an addendum to this guide. You can access it directly here or in the Additional Resources section of the guide. A careful review of that document should provide a clearer picture of the potential requirements of a clinical laboratory.

It must be stated, however, that as many POLs are smaller in scale, statements such as "The system includes clinical trial management tools" will be viewed as unnecessary to all but LIS-using clinical research laboratories. In other words, just because a functionality statement is listed doesn't mean that functionality will be necessary to a POL.

LIS workflow and integration with software and instruments

Given that a clinical laboratory's workflow often includes analytical instruments and other software, it makes sense that those tools should be able to interface with a data management system like a LIS. Today's interfaces are generally built on standardized communication tools, including messaging formats like Health Level 7 (HL7). Arguably, this interoperability may not be a requirement for POLs performing waived testing; CLIA-waived tests don't often require advanced equipment, and the POL may not even need a LIS to manage patient test data. But for those POLs that employ laboratory automation, the ability of clinical analyzers to send their data to a central laboratory management system is important to maintaining a streamlined, efficient workflow.

The HL7 messaging standards are particularly important to laboratory data management because they define how information is packaged and communicated from one party to another. Such standards set the language, structure, and data types required for seamless integration of various systems and instruments. Health Level 7 describes the types of information communicated between such systems in the clinical environment as including "process control and status information for each device or analyzer, each specimen, specimen container, and container carrier, information and detailed data related to patients, orders, and results, and information related to specimen flow algorithms and automated decision making."

LIS - EHR integration and interfacing

Integration of clinical and physician systems usually requires an interface — often referred to as a result interface — which isn't typically turnkey, requiring a comprehensive development plan and implementation process. If designed well, the interface allows test orders and results to be transferred back and forth between the two systems as well as permitting batch billing and admission/discharge/transfer (ADT) reporting to occur.

The reality, however, for particularly large laboratories accepting test orders from multiple physician offices is that tens of different interfaces may need to be developed, one for each different EHR. The end result: what is viewed as an unnecessarily complex process of transferring data between systems. Given this cumbersome process, some software developers have attempted to add LIS functionality to an EHR. But this approach has its drawbacks. In 2012, the College of American Pathologists' (CAP's) Diagnostic Intelligence and Health Information Technology (DIHIT) Committee identified several issues, including:

• a limited feature set, with little incentive to increase functionality;
• a failure to eliminate the need for interfaces with other systems;
• an encounter-specific approach rather than a specimen-centric one; and
• an inability to handle outreach volume and operations.

Another complaint about EHRs and the way they interface with a LIS: many don't handle test-related activities well. "[O]nly a handful of EHR products are good at supporting optimal workflow for lab test orders and lab test reporting," according to a 2015 report from Dark Daily. That same report also mentions how when test results are finally transferred back from a LIS to an EHR, the associated report will often end up "in a secondary location within the EHR, in effect separately from the patient-centric screens the physician uses to view all data needed for diagnosis and treatment of a patient" which as a result "may require the staff to print out the lab test results, which defeats the purpose of an electronic interface."

As such, any POL performing sufficient volumes of testing to benefit from using a LIS may also want to consider the costs and drawbacks, if any, of interfacing to their EHR system. In a case where the POL is in a position to consider both a LIS and an EHR at the same time, examine the features and potential integration of those products, and be sure to consider any future potential of integrating your systems with other external data management systems, including another reference laboratory. If considering an EHR that includes some LIS functionality, be sure to clearly identify the functional requirements and demo the system thoroughly to ensure test and reporting workflows make sense.