Laboratory information systems (LIS) have arguably become the single most critical component of laboratory operations. Common functions of an LIS include storing patient data, receiving test orders, sending orders to laboratory analyzers, tracking and resulting orders, transmitting orders to an electronic health record (EHR), and setting reference ranges and alerts of critical values. Many laboratories also use their LIS for tracking quality control, data mining, and more. An LIS is the brains of the laboratory, and disrupting that flow of data is a large event—even when planned, as in our hospital’s recent LIS conversion.
Early Planning Stages
A successful LIS conversion or implementation starts with planning and assessing risks from an early stage. In our case, the LIS is part of a larger, comprehensive EHR system. It was imperative that our laboratory had a seat at the table from the very beginning of the project. During the early planning stages, the hospital makes many foundational decisions and weighs priorities. It is important that all stakeholders and decision-makers understand that the LIS functionality has as much impact on patient care as those functions directly visible in patient care settings, such as emergency department tracking, nursing documentation, provider discharge, and more. It was therefore vital to our success that our laboratory was vocal at the time when the hospital was making initial decisions forming the foundation of functionality.
Registration and medical necessity checking were two functions that were not initially considered pertinent to our laboratory but had significant impact on outpatient laboratory operations. Through early planning sessions, we were able to better understand the significance of both. As the registration module was being built, the “registration” or “patient access” team was appropriately the primary stakeholder. However, the registration structure also had to work for patient visits that solely had an outpatient lab draw. Requiring a full and extensive patient registration for those visits was not efficient for high volume lab service centers, so our laboratory needed to be an involved secondary stakeholder. In addition, stakeholders were discussing new modalities such as cloud-based “hold queues” for all ancillary services order placements—including laboratory—and our laboratory’s early involvement in that conversation resulted in a much more successful outcome.
Identifying the Risks
Identifying risks prior to conversion is imperative for patient safety. Patients may have no history in a new system, so automated delta checks will not be present. Looking back at patient history can also be difficult or even impossible. Transfusion services could be impacted, as patients may not have a historical blood type in the system. The American Association of Blood Banks’ guidelines may require a second draw for blood type recheck prior to transfusion if blood bank history is not available, creating operational impact and potential delays for months after the go-live stage. These are just a few examples of why it is important to assess your risk early and throughout your planning and preparation phases and to employ ongoing monitoring for any patient impact post go-live.
It is important that laboratory managers encourage staff to identify and bring forward any and all functionality issues during pre-live testing and post go-live. Being as thorough as possible during pre-live testing is essential. Deploying small incentives for “good catches” can go a long way toward encouraging staff to speak up during testing. We used the old standby—chocolate! We gave out candy bars for things such as inverted numbers in reference ranges, pop-up comments not working correctly, and more minor errors that can easily be overlooked.
We also found it important to make the issue notification process extremely easy at the bench during go-live. For example, asking staff to use sticky notes to identify issues was a simple yet effective way to quickly document problems with functionality. It also provided staff with visibility around which issues had been identified and were actively being worked on. We found it easy to move sticky notes across “identified,” “in process,” and “completed” columns for optimal visibility. Leaders also used these boards to track department-level issues and to monitor and combine issues that were common to all areas.
One unexpected benefit of our work on the LIS conversion in the early stages was building relationships with our IT partners and other stakeholders. Our close collaboration on planning created trusted partnerships that made navigating any go-live or post go-live issues easier. By starting these conversations early, we were able to educate our IT partners on reasons for any pushback and change requests. During the beginning of the project, we gave tours of our lab to our IT partners, helping them connect our conversations with real-world, day-to-day operations. Early on, we also identified a few individuals within the IT team that would be the laboratory advocates and developed those relationships further. When crunch time came on go-live day and after, we communicated and resolved problems more efficiently with those foundational relationships already in place.
Documenting Lessons Learned
As in any large-scale IT implementation or conversion, there will always be lessons learned. Having a debriefing post go-live with all stakeholders is another important step in the total process. While it may be a decade or more before another total LIS conversion or implementation is needed, this blueprint can help you navigate any future changes or developments within your current LIS or larger EHR system.
Kacy Peterson, MBA, MLS (ASCP)CM, DLM (ASCP), is laboratory director at Avera McKennan Hospital & University Health Center in Sioux Falls, South Dakota. +Email: [email protected]