Book:The Comprehensive Guide to Physician Office Laboratory Setup and Operation/Data management/Workflow and functional requirements

From LIMSWiki
Jump to navigationJump to search
-----Return to the beginning of this guide-----

3. Data management

Data management in the physician office laboratory (POL) involves understanding workflows, choosing data management systems, and applying best practices. This chapter talks about the common POL workflow and how data associated with it is better managed with informatics tools. However, this chapter also recognizes that not all POLs can justify a best-of-class laboratory information system (LIS) in their operations, noting that hybrid electronic health record (EHR) systems that include some LIS functionality may make more sense. The concept of middleware is also addressed as another possible means of integrating instrument system data into EHRs, skipping the LIS entirely.


3.1 Workflow and 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 the first chapter of this guide:

POLWorkflow.png

Inside this workflow are various associated activities, largely dependent on the specimen and test type, as well as the Clinical Laboratory Improvement Amendments (CLIA) certificate type the POL holds[1]:

  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 specimens 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 an information 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-use 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 may be required. 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, the reporting process 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 necessitate the manual generation of a report for the ordering physician. In rare cases such as a positive result for HIV, additional reporting requirements to local and state authorities may also be required.[2] 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 prompt questions about how their efficiency can be improved, if it all, through an information 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 knowledgeable vendors of information 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 information system development.[3] As such, looking at the features of typical clinical data management tools often provides additional insight. However, another more practical approach involves an amalgam of these two methods: developing a comprehensive request for information (RFI) or request for proposal (RFP).

Over the years, several industry-based organizations have created RFI- and RFP-style documents for LIS and laboratory functionality, including the Association for Pathology Informatics (API) and the Healthcare Information and Management Systems Society (HIMSS).[4][5] Those documents contain tens to hundreds of software requirements—which may or may not be organized into a full-fledged specification—based on the operational and administrative needs of a clinical laboratory. An example of requirements statements can be seen in Figure 1:

LIMSpec22 Example.png

Figure 1: Sample of laboratory informatics requirements from LIMSpec 2022 R1

While helpful to develop a full list of requirements for your lab, often times such requirements documents turn into a mix of "wishlist" requirements from potential and active clients, as well as regulation-mandated requirements. The wishlist items aren't necessarily ignored by developers, but they do in fact have to be prioritized as "nice to have" or "essential to system operation," or something in between.[6][7][8]

If the POL is fully set on acquiring an LIS, it could turn to a more modern approach to requirements specifications in the form of LIMSpec 2022. Built from more than 100 regulations, standards, guidance documents, and more, LIMSpec may be a useful component to your LIS acquisition research. A careful review of LIMSpec 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, more than a few statements—such as "The system includes clinical trial management tools"—will be viewed as unnecessary to all but clinical research laboratories. In other words, just because a requirement statement is listed doesn't mean that functionality will be necessary to a POL.

References

  1. Laughlin, Sandra; Feldman, Deb (22 October 2015). "The LIS, the healthcare market, and the POL". Medical Laboratory Observer. MLO – NP Communications, LLC. https://www.mlo-online.com/information-technology/lis/article/13008470/the-lis-the-healthcare-market-and-the-pol. Retrieved 17 May 2022. 
  2. "HIV Disclosure Policies and Procedures". HIV.gov. U.S. Department of Health & Human Services. 15 May 2017. https://www.hiv.gov/hiv-basics/living-well-with-hiv/your-legal-rights/limits-on-confidentiality. Retrieved 17 May 2022. 
  3. Sinard, J.H. (2006). Practical pathology informatics: Demystifying informatics for the practicing anatomic pathologist. Springer-Verlag. doi:10.1007/0-387-28058-8. ISBN 9780387280585. 
  4. "LIS Functionality Assessment Toolkit". Association for Pathology Informatics. 20 September 2013. https://www.pathologyinformatics.org/lis-toolkit. Retrieved 17 May 2022. 
  5. "RFP Sample Documents". Healthcare Information and Management Systems Society. March 2012. Archived from the original on 02 June 2016. https://web.archive.org/web/20160602193653/http://www.himss.org/resourcelibrary/TopicList.aspx?MetaDataID=565. Retrieved 17 May 2022. 
  6. Aasem, M.; Ramzan, M.; Jaffar, A. (2010). "Analysis and optimization of software requirements prioritization techniques". Proceedings from the 2010 International Conference on Information and Emerging Technologies: 1–6. doi:10.1109/ICIET.2010.5625687. 
  7. Hirsch, J. (22 November 2013). "10 Steps To Successful Requirements Gathering". Phase2 Technology, LLC. https://www.phase2technology.com/blog/successful-requirements-gathering. Retrieved 17 May 2022. 
  8. Burris, E. (2007). "Requirements Specification". CS451R, University of Missouri–Kansas City. University of Missouri–Kansas City. Archived from the original on 24 July 2019. https://web.archive.org/web/20190724173601/http://sce2.umkc.edu/BIT/burrise/pl/requirements/. Retrieved 17 May 2022.