User:Shawndouglas/sandbox/sublevel8

1. Introduction to LIMS and LIMS acquisition

Your laboratory was created to carry out specific tasks, to do work that its parent organization needed to conduct its work and reach its business goals. The lab's biggest output is analytical results of tests it conducts, and it's imperative those analytical results are accurate, timely, and unaltered. Today, lab's more than ever depend on a laboratory information management system (LIMS) to better meet those requirements.

The point of this guide is to give you the background you need to better make a case to your organization's management and key stakeholders for acquiring and deploying a LIMS. While pursuing this topic, we're going to make a couple of simple assumptions. We'll assume that your organization's senior management may not understand what goes on in your lab and how it carries out its work. We'll also assume they have a lot of things to contend with in their roles, giving them limited time to fully understand your lab's needs and the tools required to help it succeed. You want to make the explanation and justification for LIMS acquisition and deployment as easy and succinct as possible while at the same time demonstrating that this is the right decision.

The justification process for LIMS has a long history, and a lot has changed since the 1980s when the technology was first introduced. Therefore, we need to examine what a LIMS is, what alternatives people commonly turn to, how the technology has evolved, what the history of LIMS justification is, what practical and economic considerations surround LIMS adoption, and how to address any concerns management may raise during the justification process. This guide will attempt to address these things and more. First, let's look at what LIMS is, what alternatives exist, and what the acquisition process looks like. We'll also address what a LIMS matters to today's laboratory.

1.1 What is a laboratory information management system (LIMS)?

A LIMS is a specialized, software-based information management solution that offers a set of key features that support a modern laboratory's operations. Introduced in the late 1970s and early 1980s, the design and functionality of this software has changed significantly over the years, such that today a majority of a laboratory's processes can benefit from the LIMS' implementation and use. A LIMS has functionality that addresses most of the workflow phases of a laboratory, including:

• the reception and log in of a sample and its associated customer data;
• the assignment, scheduling, and tracking of the sample and the associated analytical workload;
• the processing and quality control (QC) associated with the sample and the utilized equipment and inventory;
• the storage and access management of data associated with the sample analysis; and
• the inspection, approval, and compilation of the sample data for reporting and/or further analysis.

Related is the laboratory information system (LIS), which is tailored to the workflow of a clinical laboratory. That said, the distinction between the LIMS and LIS has blurred over time, with some LIMS having the same clinical information management features of an LIS. In both cases, the software—when developed, implemented, and maintained well—can improve laboratory workflows and workloads while enhancing safety, quality, and compliance. A well-implemented LIMS can reduce the silos of information and data in a laboratory, while at the same time make that information and data more secure, readily accessible, and actionable. Additionally, many modern LIMS are able to be pre-configured out of the box with analytical and quality control workflow support tools that can be further optimized to a lab's unique industry-based workflow. When integrated with instruments and other software systems, fewer transcription errors occur and traceability becomes easier, while monitoring of supply chain issues, quality control data, instrument use, and more is further enabled, particularly when paired with configurable dashboards and alert mechanisms. This also means that the lab can react more rapidly to issues that compromise compliance with certification to the ISO/IEC 17025 standard, as is necessary in, for example, the food and beverage industry.

1.2 What are the alternatives to a LIMS?

Introducing new technologies and products often causes people to balk because it represents a change to current operations and an expense, even if the change is beneficial. As such, some may view the acquisition, use, and maintenance of a LIMS to be too daunting. The organization may even see the value in a LIMS but finds several questions arise:

• What happens if we don’t make the change to a LIMS?
• Is there an alternative technology that is less costly?

The answer to the first question is straightforward: lab costs continue to increase, operations stagnate, sample backlogs increase, and lab personnel—including management—become increasingly frustrated. This in turn means the lab may fail to achieve its goals. That second question is politically charged, however, particularly in medium to larger organizations. There are two frequently encountered answers, both involving internal software development: let's use a spreadsheet, or let's use an enterprise resource planning (ERP) system as a solution with similar characteristics to a LIMS. The latter often occurs if a company has recently invested in an ERP solution with the idea that it will take care of all of the company’s needs (i.e., they may not have checked with the labs to see if actually will).

Before we get into a response to that second question, I'd like to ask you one. What business is your company in? Is it a software development organization, or does it want to become one? I ask this because what often happens is someone in the organization proposes custom software development as an alternative. Suppose you are seriously considering developing a LIMS alternative in-house or through a consulting firm. In that case, that is something you have to think through, taking on all the issues that plague large software development projects, including ongoing maintenance and support once the project is completed.

Software development projects are fraught with issues. Reasons for software project failure include:

• insufficient organizational leadership
• insufficient understanding of business and department problems and requirements, even as they evolve during development
• inadequate planning and project management
• undefined project roles and responsibilities
• inaccurate time and cost projections
• inadequate use of available resources
• insufficient understanding of changing software development practices
• poor or mismanaged communication methods
• poor response to project challenges that inevitably arise
• lack of focus on project success
• lack of focus on soft skills such as training and team building
• scope creep

The bottom line is this: software projects develop issues, and while they may eventually succeed, they a may take a year or more to work through during development. Meanwhile, your lab is suffering under whatever issues caused you to look for a LIMS in the first place. When you're done with developing the solution, will you have something better than commercial products or just the best you can settle for? Commercial products will be continually improved with new features and capabilities added; that's their business. Do you have the resources and commitment to make it yours?

We find that software development approaches have their own issues to address, but what about spreadsheets and ERP systems? Spreadsheet-based systems, while seemingly inexpensive, are costly in development time and use. Additionally, spreadsheets are single-user-at-a-time systems. Everyone else has to wait their turn if someone is working with the system. They are fraught with errors creeping in, especially through changes that may not be documented. They are also difficult to validate and keep under modification control. Those factors are red flags to regulatory inspectors, particularly regarding development documentation. As for ERPs, those systems may address some of the requirements of your lab, but they will have significant problems with instrument connections, a significant source of productivity gains in the laboratory. Do these and similar alternatives represent the most cost-effective way to manage risk and utilize your resources towards the goal of improving laboratory productivity and compliance?

1.3 LIMS acquisition then and now

The laboratory environment of the 1980s viewed from a behavioral standpoint would be easily recognizable today: growing test workloads, everyone’s sample was a top priority, and everyone was very busy as all work was manually done. From a technology perspective, things were a lot different. For the most part, there were no computers, and instrument data systems (IDSs) were entering the marketplace. Still, IDSs hadn't become the almost automatic combined instrument-computer combination they are today. Networks were in their early stage of development. Robotics was also in an earlier part of its evolution; Zymark Corporation of Hokinton, Massachusetts (which later became Caliper Life Sciences), was an early developer of lab robotics, which was just beginning to impact the laboratory market. There was no severe shortage of educated laboratory personnel to fill open lab positions. However, few were knowledgeable in laboratory informatics.

The cost of lab operations was becoming a serious concern for lab management. Although people were available, there was a limit to how many you could hire, given the limitations of laboratory space and equipment utilization. As a result, economics played a significant role in the justification for equipment and instrumentation, in general, and LIMS, a new technology, in particular. One of the significant differences between then and today is that installing a LIMS meant installing a local computer system; cloud-based systems didn't exist.

As the productivity issue became more acute, the interest in automation and the efficiency of lab operations grew. In clinical chemistry work, the response was particularly strong with the development of an industry-wide total laboratory automation (TLA) initiative that focused on driving down the cost of laboratory testing through automation and the development of communications standards to make it easier to connect instruments and computers together into fully functioning networks that would relieve much of the manual clerical effort.

Much of the information we have on the effectiveness of laboratory automation and LIMS installations comes from the life science and clinical industries. The results of TLA could be seen in 1992, when Markin and Hald noted:

The tangible [financial] benefits which were measured prior to LIS 4 justification totaled $153,471.84 per year based upon fiscal year 1985-86 dollars. The objective re-evaluation of these activities four years after implementation and operation resulted in a measured $115,326.93 per year savings ... Implementation of the laboratory information system at our institution resulted in a 75% capture of the estimated/projected cost avoidance or cost savings.

In a more modern example from 2018, Yu et al., who wishing to improve workflow efficiency in their clinical laboratory, implemented TLA "that connected our pre-analytic processing system with various testing (hematology, coagulation, and chemistry)." They reported their results as such:

The implementation of our TLA system resulted in 86% fewer discrete processing steps in specimen handling, even when starting from a partially automated laboratory. Instrument consolidation reduced the testing footprint by 45% and reduced the number of testing personnel by 2.5 full-time employees (FTEs). An 82% reduction in hands-on time associated with add-on processes was achieved. Combining STAT and outreach work on the testing system did not impact turnaround time.

Outside of TLA, lacking other driving factors, the primary motivation for implementing automation and LIMS or LIS in the lab early on was productivity and, as a result, finances. A 1986 article by Joseph H. Golden (then at Laboratory Management Systems, Inc.), titled “Economic Considerations of Laboratory Information Management Systems,” addressed that point directly. Considerations and concerns he had included (quoting directly):

• the "impact on lab operations, reducing administrative work [and] speeding up work";
• "how the laboratory contributes to the corporate bottom line";
• the "need to consider not just what LIMS will do but what it’s worth";
• in regards to R&D, that " productivity improvements amount to at least 10% to 20% of the total staff resources of a laboratory complex”;
• in regards to QA/QC, that "time-value of information" and "ability to accept/reject raw material and avoid off-spec products" is considered, "plus 10-20% saving on clerical costs";
• that commercial testing saw "improved profitability";
• the consideration of "common lab management problems," such as "increasing data volume from increased use of smart instruments and from increased testing and record retention requirements imposed by EPA, FDA, OSHA, and other regulatory agencies; constantly rising operating and material costs; and ever-tightening constraints on staff and material expenditures, which in turn are "manifested by increasingly burdensome paperwork, inefficient utilization of resources, and exasperating searches for misplaced samples and data"; and
• the costs of "equipment, facilities, cost of money, and investment tax credits."

Citation information for this chapter

Chapter: 1. Introduction to LIMS and LIMS acquisition

Title: Justifying LIMS Acquisition and Deployment within Your Organization

Edition: First Edition

Author for citation: Joe Liscouski, Shawn E. Douglas

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: