LIMS Is Not a Just Another Four-letter Word

By: Joe Liscouski

Factors that affect the adoption and utilization of laboratory systems like a laboratory information management system (LIMS)…

There was a time when the idea of purchasing a LIMS would be met with skepticism. In the past, a LIMS purchase was less about a product installation and more about a project definition. This came with a genuine prospect of failure or delays, frustration, redefinition, and risking your job at best. And sometimes things worked.

A lot has changed since the 1980s, and LIMS installations routinely work. This article will look at the factors that affect technology adoption, how they are applied to LIMS and other laboratory systems, and how we got from the problems of the ’80s to the success we see now. As with many technologies and products, our successes with today’s LIMS technologies are built upon the early problems of the past.

A brief, useful look at history…

In the late 1960s and early 1970s, instrument vendors began looking at a new entry in the electronics market, the computer, and how it might benefit laboratory work. Their initial entries comprised a range of “data systems,” a device created by connecting a computer to an instrument’s measurement output and converting the analog signals into laboratory “data.”

One of the first applications was in the widely used technique of chromatography. This useful labor-intensive analytical technique generated many feet of chart paper with a continuous line in the form of a series of peaks that had to be evaluated by hand to produce the needed results. The biggest hurdle was quantifying the size of those peaks; peak heights could be measured easily, but areas gave better results with greatly increased difficulty. Some of the earliest computer applications resulted in microprocessors built into integrators used to measure peak characteristics, including height, area, and elution time. This had the potential to reduce the analyst’s workload and increase productivity. Over time the “data station” landscape was populated with labor-saving equipment in the form of computers that carried out the complete analysis, and autoinjectors/samplers that introduced samples into the instrument for chromatography and other techniques.

Instrument vendors and consulting companies began to address another aspect of lab productivity: managing all the data generated in the laboratory, while keeping track of samples that had to be processed, their status, and their results. If computers connected to instruments were “data stations” then computers that managed laboratory operations were “information systems” or “laboratory information management systems,” the forerunners of today’s LIMS.

New products and technologies for laboratory applications are continually being developed and introduced. However, their success depends upon market acceptance, which in turn depends on people’s readiness to accept them.

That acceptance depends on the potential customers’ understanding of:

• Cost/benefit trade-off: What will the product cost me and what are the benefits? How will this product improve my lab’s operations and help me justify bringing it into my facility?
• Complexity: How easy is this to use, and how much training will my lab personnel need to use it correctly? What are the risks and consequences of it being used incorrectly?
• Integration: How does it complement other systems in the lab? Is there a synergistic relationship or an antagonistic one?
• User adoption: This parallels the complexity issue. How steep is the learning curve, and what will happen to productivity while it’s being integrated into my procedures? Will this require a re-validation of methods and create compliance problems with regulation guidelines? Is it worth it?
• Vendor support: How much support and assistance will the vendor provide to bring it into the lab and keep it working?

How much pain people were willing to endure depended a lot on how much of a perceived benefit there was. In the chromatography example, the payoff was clear: if the integrator (and later full computers for data acquisition, storage, computation, and reporting) worked, productivity would go up and it would reduce the need to hire more people while increasing sample throughput. In other applications, the payout wasn’t as clear. It might involve programming; who was going to do it? The vendor took pains to produce data in a format that could be used by a spreadsheet because “everyone knew how to use a spreadsheet.” Another factor was how closely the product matched lab personnel’s understanding of science vs. software (programming) and computer science, increasingly foreign territory. Many of the issues that faced early LIMS weren’t encountered by early instrument data systems. Those systems still addressed laboratory science, safe ground, and whose role was easily understood and accepted. LIMS was a management system on a different plane from “science.”

Perceptions of early LIMS

Early LIMS suffered from several problems, not the least of which was defining what a LIMS actually is. The name itself had much to do with the issue: “laboratory information management system.” To some it didn’t mean anything; to others, it meant that it covered everything from lab data to personnel files, documents, schedules for sample processing, and people’s vacations. If customers could apply the word “information” to it, LIMS should handle it. But it didn’t. LIMS, in its first creation, was simply a sample tracking system. Then the vendor had to explain why the customer needed a sample tracking system. Lab size was a factor. Some were too small and quite happy with paper-based approaches that had worked for years. LIMS also meant that you needed a computer. Who was going to take care of it?

In the early 1980s, when LIMS was first introduced, information technology (IT) only existed in a few companies, although the need was beginning to be felt. Computers (if there was more than one in a company) were managed by management information systems (MIS) using IBM hardware. That created political issues. MIS didn’t want to give up control, so bringing in another (non-IBM!) computer required a lot of management meetings. Early systems were less about products than they were projects, requiring hardware installation, software, systems configuration, and a lot of things that don’t happen with today’s cloud-based products. These aspects were all things lab personnel weren’t ready for.

LIMS began to take on a lot of user satisfaction issues. Too complex, too much work, and cost were an issue. The most significant issue resulted from the lack of education about what is now laboratory informatics. LIMS projects took on all the trappings of large software projects in other applications, including why they failed. Budget overruns, extended installation schedules, scope creep, and customer and management frustration were just a few of the problems encountered.

User expectations were a serious concern. Published articles and presentations by vendors at conferences gave the impression that a new model for lab operations was in order. That model was based on LIMS, networking, and computers doing data acquisition, analysis, and reporting, along with the potential for connecting those data systems to LIMS. The reality was something else; it was possible, yes, but not easy. At this point we’re still talking about projects, not easy-to-install products, or the modern no-installation-needed cloud-based systems.

However, two things happened to improve the situation: vendors produced better products, and potential customers became better educated about what products are and how they might be used. The latter point was facilitated by two organizations. The LIMS Institute (now closed) in the 1980s — through the efforts of R. Megargle, Gerst Gibbon, R. Mahaffey, and others — and the Pittsburgh Conference (still in existence) provided a forum for vendors to discuss their offerings and for users to meet, discuss issues and take courses on the products and technologies. Those efforts advanced the state-of-the-art and end-user acceptance.

Today’s reality is very different, but some things remain the same…

In 2023 all the things we thought could happen are now a reality. Finally, the new model of the 1980s and 90s works. LIMS and associated laboratory informatics can provide a comprehensive solution to a lab’s needs. These needs can include managing samples, documentation, instrument management, and data communication between instrument systems and database systems. Today’s cloud-based database systems relieve a lot of the stress found in the implementation of early on-premises systems. For example, no IT support or product hardware/software installation is needed. The confusion and lack of product/technology understanding have to some extent been addressed, but there is still more work to do. A major issue is the lack of formal education about products and technologies that is necessary for lab personnel to accept and utilize laboratory informatics.

What have we learned?

As with coins, there are two sides to the learning that occurred in the marketplace: the vendors and the users/consumers. Vendors have learned how to do a better job of helping users understand their products and produce systems that are either easier to install or require no installation. The early LIMS product purchases were just the starting phase of a project, although many users needed to realize that. The vendor did realize that, and many had relationships with consultants that would assist users in the process of installing, configuring, and using LIMS software. These were often projects that would last a year or longer.

We also learned why projects failed, and for the most part, they were the same reasons large software projects failed in other areas of corporate life. Some of those still need to be understood and addressed today. Those elements include:

• Lack of education about informatics: This is probably the biggest issue that needs to be addressed. Everything else stems from this point.
• Lack of management understanding and support: Early LIMS projects often had optimistic implementation timelines and expectations. Those timelines contained more what management needed to hear rather than being realistic. That still needs to be managed, but cloud-based systems and vendor experience can mitigate that problem.
• Scope creep and lack of clear criteria for success: When is the work completed, and what constitutes a finished project? Scope creep — continually adding more capability and requirements — causes projects to extend to unreasonable lengths. Part of this is a lack of education.
• Poor project management: Having the right people to manage IT-related projects is always critical, and LIMS implementations are no different.
• Insufficient budget: This is often caused, in part by previous points.
• Lack of vendor support: We find today that vendor support for an implemented LIMS is a critical component of success, but this was not always the case. Support is the difference between paying for a product or a full solution. Almost always better to budget for the services than try to go it alone.

These points are not just LIMS issues, but laboratory informatics issues in general. The scope of what can be done to improve lab operations has increased and with it the need to better understand and plan informatics programs.

The first bullet point is the most serious. If you don’t understand the technologies, opportunities will be missed, products misapplied, spending resources inappropriately allocated without getting the returns you should reasonably expect.

As noted earlier, there are two sides to laboratory technologies: those that address laboratory science, and, those that address informatics technologies that can support lab operations and management. The former is met through formal education at the undergraduate and graduate education levels. The latter is sometimes addressed through short courses and self-education, yet these are the tools that can make or break a lab’s ability to meet its goals. Lab personnel need to be educated to understand the technologies available to them and to make the choices necessary for successfully planning for product selection and introduction.

That lack of education shows up, for example, in the scope creep problem. As people learn more about what can be done, they want to add it to the criteria for their project. That results in more development, longer implementations, and increased costs.

In closing…

In the 1980s a new set of opportunities was created to improve the efficiency and effectiveness of laboratory operations in the form of a LIMS. As with many new and emerging technologies, not just in labs but across the technology spectrum (e.g., self-driving cars for example), it takes time for these opportunities to be understood, have their expectations scaled by reality, and be properly applied to solve real-world problems successfully. That was the situation with 1980s LIMS: lab personnel, and technology both needed maturing.

In 2023, LIMS constitutes a set of product capabilities that meets the expectations that were set in its early incarnations. It can function as a LIMS or as a hub for organizing lab operations including instrument connections and sharing data with other systems. Depending on organizational requirements and support options, both on-premise and cloud versions are available. Cloud versions, like ELab LIMS, allow for faster incorporation into a lab’s operational life, with minimal support requirements.

Read more Blogs, News, and Events from LabLynx here.