The laboratory information system (LIS) is arguably the most prominent piece of software in the clinical laboratory. It is often the first stop for inbound electronic messages (orders) received from the electronic health record and the last stop for outbound messages (results).
However, between the LIS and the instrument now sit an increasing number of software components, most of which have emerged contemporaneously with the increasing prevalence of laboratory automation solutions. Referred to as middleware, these emerging software components often allow laboratory analysts to manage clusters of automated instruments from a central computer workstation.
Per the CLSI AUTO03-A2 standard on automation communications, middleware designed for process control of total laboratory automation (TLA) systems is known as the laboratory automation system (LAS). Indeed, the LAS is a major component of TLA solutions, and it comes with varying degrees of end-user support and maintenance needs.
The growing sophistication of LAS design has profound implications for staff training, organization, and the future of information technology-intensive roles in the clinical laboratory.
Staffing the Laboratory Automation System
In 2018, our institution implemented an automated front-end specimen processing unit that was coupled with clusters of chemistry analyzers. The LAS, which governs the function of these TLA-modules, is a useful and representative example for discussing lessons learned, and the complexity of LAS-middleware support.
One of the fundamental considerations for any newly acquired software system is deciding which team within an organization is going to be responsible for the application. At our institution, we felt it would be beneficial for the LAS support analysts to have hands-on experience with the workflows that the LAS is governing. Accordingly, we chose to train medical laboratory scientists (MLS) in the maintenance and support of the LAS. This created a novel IT-support (ITS) structure within our organization to operate semi-independently from the LIS team, which organizationally resides within a centralized ITS structure serving the entirety of the healthcare delivery organization.
Creating this new LAS team required close coordination with central ITS and training of the MLS employees on institutional IT practices, such as security protocols (e.g., user authentication and authorization), assignment of end-user privileges (e.g., administrative vs. standard users), ensuring a 24/7 on-call schedule for end-user support, and change control for configurations in the LAS (e.g., process control rules).
Change control was a particularly novel concept to the laboratorians involved in this project, although it harbors many parallels with good laboratory medicine practice. In the IT service industry, change control is generally described as a documentation process that captures information about changes made to a software system: What is the change, and why was it made?
At our laboratory, we implemented a form-based change control process that we analysts use for any LAS-modification (see example online at www.myadlm.org/cln). These forms undergo two-person review and are ultimately signed by the lab supervisor and medical director. In addition, analysts store all configurations of the predicate state in a readily available location that allows them to revert changes if they observe unintended errors. While the particular change control processes we have implemented may not be widely generalizable across laboratories, they exemplify the significant oversight and process control required for the maintenance of these complex automation systems.
With respect to server maintenance, the LAS support analysts must routinely schedule several software updates in coordination with laboratory operations to allow for LAS downtime during server restart periods. These updates may include the server operating system (e.g., Windows Server), other server application software, and the LAS itself. To minimize downtime, updates need to be done in close coordination with LAS analysts, laboratory staff, and in some cases, the institutional server management teams.
Data storage hardware and disk space also require the careful attention of the LAS support analysts for regulatory compliance (CAP GEN.20377 Record/Specimen Retention). At our institution we have 46 instrument connections to our LAS and verify approximately 8,000 tests per day. In the last 4 months, we have generated approximately 600 GB of data. Due to limitations in our initial storage capacity requirements, we encountered emergency issues that required offloading of data and expansion of storage in real-time.
Rethinking Roles and Relationships
As technology in the laboratory continues to progress, the lines between ITS and laboratory medicine may need to be redrawn with the creation of novel organizational structures. While there are similarities among best practices between both fields, there are sufficient differences. Dedicated training and socialization to informatics culture is a prescient need when considering implementation of automated systems.
As with any complex system, modifications can result in unintended adverse consequences, which in some cases can go unnoticed for prolonged periods of time. To this end, we have tried to implement robust safeguards to protect against these types of errors, in hopes that with the adoption of novel automation systems, we can continue to ensure the fidelity of laboratory results and provide the quality of service our clinical colleagues have come to expect.
Thomas J.S. Durant, MD, is an assistant professor of laboratory medicine and informatics researcher at the Yale School of Medicine and the medical director of chemical pathology and laboratory information technology at Yale New Haven Hospital. +Email: [email protected]
Jasmine Messina, MLS(ASCP)CM, is a clinical chemistry manager at Yale New Haven Hospital. +Email: [email protected]