We discuss why LIMS are considered necessary, but not well liked, and how improving the LIMS experience and design will increase adoption
Please provide the following for access to content in our resource library
When it comes to scientific software, laboratory information management systems (LIMS) are simultaneously prevalent and disliked. Circumstances explain some of the emotion associated with LIMS. In the 40 years since the first discussions about how to computerize laboratory operations,1 automated workflows have increased throughput and data volumes such that LIMS are now routinely found in many labs and have consequently forced changes in comfortable, paperbased routines. Yet in that time—an eternity as far as software development is concerned—the interfaces and usability of LIMS have changed little.
“LIMS carries a lot of baggage and to many scientists is synonymous with rigidity, having to change what you do to work around or with the system, and having to get IT involved whenever a protocol or study design changes,” said Michael Elliott, founder, CEO, and chief analyst at Atrium Research and Consulting, which provides analysis, coverage, and consulting in scientific informatics.
However, several drivers present an opportunity for LIMS to substantially make over its image:
If location is key to a good real estate investment, usability is key to ensuring that LIMS are adopted and used. Three elements in particular can make the difference between a LIMS that’s loved and one that languishes:
In this paper, Michael Elliott and two research scientists describe the traditional barriers to LIMS adoption and envision a modern LIMS that helps labs conduct better, faster, higher quality science. “The primary benefit of implementing a LIMS should be around meeting a strategic goal, such as improving operational efficiency or data quality,” explained Elliott. “How you do that should be paramount—and then, oh by the way, you can support these processes and lower costs by using a LIMS.”
LIMS are widely considered one of the most mature scientific software systems. Launched as commercially available systems in 1982,3 LIMS originally aimed to automate the lab and omit what one commentator called the “clerical activities associated with the processing of analytical results” produced by lab instrumentation. At their core, most LIMS today still work effectively to help labs:
These core value propositions are, if anything, more important today as labs have become high throughput, high volume, and increasingly regulated. “I thought a LIMS was a great tool to introduce to the group and saw a real need for it given the scale of our customer load and the data and information we need to capture,” said Kathleen Lundberg, LIMS administrator and project coordinator at the Center for Proteomics and Bioinformatics at the Case Western Reserve University – School of Medicine.
Unfortunately, though, as many of the original LIMS vendors began modifying existing legacy systems to support completely new sciences and workflows, most notably in discovery research, they strayed from these core principles. Instead of retooling systems to match the requirements of new scientific areas, vendors bolted on functionality driven by custom requirements. The result is bigger and bigger systems patched together loosely and illogically.
“We called our system FrankenLIMS,” said Rob Hall, manager for the Bumgarner lab at the University of Washington. Hall was describing a LIMS built by the biotechnology company where he worked before his position in the Bumgarner group. “We didn’t understand how hard it would be to build and maintain such a system,” said Hall, and the resulting system morphed and changed as scientists redesigned fields, reused components, and created cross-references. “Ultimately,” said Hall, “we were working around the LIMS to solve problems the LIMS was creating.”
Many commercial systems resemble FrankenLIMS, according to Elliott, but that can change if vendors rethink the original LIMS value propositions from the perspective of a lab’s two primary users: bench scientists and lab managers.
“LIMS should be about doing something interesting with the data, not just shoving the data into the software, because scientists and managers want to spend their time reviewing data and making decisions, not merging data, moving it around, and processing it,” said Elliott.
However necessary a LIMS might be, they can be difficult for organizations to adopt. One barrier is systemic. Many research organizations lack the resources to assess their existing processes and fully educate themselves about how LIMS can help. “How do you choose a system when you’re caught up in the daily grind of keeping a lab running?” said the University of Washington’s Hall. “You may have in place some basic informatics that works, but you can see down the line that when you add machines or change workflows, it won’t.”
And then there’s the LIMS reputation problem, which can intimidate even the most interested lab. “LIMS are viewed as a pain to install, get running, and get people to use,” said Hall. “So in addition to overcoming the inertia associated with changing a known workflow, you’re worried that you’ll be getting this big LIMS octopus that is going to come in and take over everything.”
Scientists tend to resist using LIMS for two related reasons. First, LIMS are perceived as rigid and inflexible. Scientists assume that modifying a workflow or protocol requires at best tweaking the programming, and at worst a complete overhaul of the system. “LIMS means rigidity to many organizations, having to change everything you are doing to work around the system, and when a protocol or study design changes, having to call in IT resources or vendor staff to build custom code,” said Elliott.
The second reason scientists resist lab management systems—they slow lab work. Bolted-on functionality and poorly executed integration leads to overly complex and often illogical workflows and user interfaces. The typical LIMS user interface does nothing to streamline interactions or guide scientists through work. Many user interfaces, in fact, seem to reveal the entire system to users, probably because functionality has simply been added without regard to which users most need it. The result is often a maze of screens that scientists must navigate to complete even the most routine tasks. “It’s not uncommon to start with one screen to design an experiment, move to another screen to interface with an instrument, and then open a third screen to pull data from multiple instruments together,” said Elliott.
Hall remembered how he dealt with his company’s “FrankenLIMS” as a bench scientist. “Lab scientists have to get through a certain number of samples or protocols in a given amount of time, so if we can cut corners, we will,” he said. “So I’d do my work and then go back to the LIMS when I had a break and enter my data. Which of course meant I’d forget exactly what I did or I wouldn’t have what I needed for a given field. It was a mess.”
Given experiences such as that described by Hall, many organizations use adoption-by-edict (managers telling lab staff they must use the systems… or else). For example, Lundberg explained that her lab mandates LIMS use by requiring a LIMS-generated driver file to run experiments. Such tactics may ensure compliance, but they do little to improve LIMS’s reputation. “Wouldn’t it be better if, instead of being burdensome and intrusive, LIMS could take the drudgery out of doing lab work — aggregate data easier or faster, assist with planning complex tasks, and provide new insights that would make scientists want to use it?” asked Elliott.
The primary barriers to LIMS adoption—that LIMS slow down lab work, are rigid and inflexible, and difficult to implement all can be overcome by a focus on usability. In moving LIMS from analytical labs to various research workflows, many vendors forgot about the end user, said Elliott. “Scientists are concerned with questions like ‘Where’s my sample?’ ‘What work do I need to do on it?’ and ‘How do I get the results of that work into a report?’” Elliott explained. Scientists could also benefit from a way to answer other questions, such as, “What jobs are pending?” “Which samples didn’t pass QC?” or “Which samples do I need to escalate to the lab manager?”
Innovations in software interface development and design provide an opportunity to LIMS vendors, particularly those introducing LIMS to emerging research areas such as genomics/next-generation sequencing, and clinical or translational medicine. “These workflows are still evolving, so vendors have a real chance to get out in front of that and define optimal workflows based on industry best practices and standard operating procedures,” said Elliott.
Using modern interface design principles, vendors can implement LIMS best practices in ways that guide, rather than restrict. Workflow intelligence in a LIMS should be able to predict next steps based on a scientist’s action. When a certain type of sample is entered, for instance, a LIMS might display logical next steps in a workflow. In addition to moving scientists along a narrow path, a critical factor in regulated clinical labs, LIMS can also monitor and record which tasks were accomplished (and the resources that were consumed), by whom, and when. In this way, a LIMS can both aid scientists in their work and provide managers with ways to track overall project progress and lab productivity.
Playing this double role, though, requires LIMS to be able to capture information automatically rather than relying on scientists to enter it after the work is completed. “As a scientist, I hated entering information in the LIMS, but as a manager, I want to track each and every one of those fields so that I can find the often minute difference in a large sample set or answer questions about how many samples we are running, whether we are running at capacity, and which of my research associates are doing what,” said Hall. Ideally, LIMS should be able to capture information automatically (for instance, by applying group characteristics to samples in the same collection). Smart integration with barcode readers, robotics, lab software such as patient information systems and analysis tools, and other supporting lab instrumentation can streamline
and automate tasks to ensure faster and less error-prone research. Additionally, presets or drop-down options within a LIMS interface can facilitate up-front data entry and experimental set-up, and facilitate the execution of complex tasks.
LIMS can also shift from being a barrier to work, to a helper. “To me, the interface should provide a really limited, logical menu of options that are descriptive of the work a scientist wants to do,” said Hall. Given the role LIMS play in tracking end-to-end work in a lab, LIMS are well positioned to provide a window into lab operations. Scientists could open the LIMS and immediately see what work is in progress, what needs to be set up, and which results are ready to report. “Scientists don’t care about the nuances of the various technologies involved—and they shouldn’t have to deal with that,” said Elliott. “They want everything on one dashboard, and an interface that stays the same whether they are queuing up data, running an experiment, pulling data back into the LIMS, or reporting results. And if it can do something compelling, like highlight outliers or flag out of spec stuff so that I don’t have to hunt for it, that’s even better,” said Elliott.
Supporting standard workflows is important, but because research processes and best practices continually change, LIMS developers must learn from its history and provide easy ways for labs to configure and adjust the system over time. Configurable interfaces can help scientists tweak the LIMS to accommodate their personal style or role within an organization. Industry-standard Application Programming Interfaces (APIs) can empower labs to customize and extend the LIMS should scientists need to deviate from a standard workflow or build in labspecific requirements or integrations.
Finally, as well as making LIMS easier for labs to implement and scientists to adopt, LIMS vendors should provide support to labs as they evaluate their processes and install a system. “Implementing a LIMS is ultimately about changing business processes, so it’s a much bigger task than simply installing a system,” said Elliott. Modern LIMS vendors should provide dedicated project management teams to ensure that a lab is able to implement its selected system quickly and painlessly.
In most cases, LIMS today differ little from those introduced 20 years ago. And this explains their reputation among users. The primary reasons scientists resist using LIMS is that they are overly complicated, rigid and inflexible, and they slow lab work. Modern research workflows demand updates to this vital scientific software. Role-optimized interfaces, designed from the perspective of the scientists doing the work or the managers monitoring overall lab operations, can serve as guides to help scientists in the lab and managers who need to track project progress and lab productivity. Pre-built workflows and integrations enabled by industry-standard APIs can enable labs to codify best practices and incorporate specific functionality to automate processes and streamline routine tasks. By focusing on improving the user experience, LIMS can become systems that facilitate— rather than inhibit—research and clinical lab work.
1 Gibbon, G.A. A brief history of LIMS. Laboratory Automation and Information Management 1996. 3, 1-5.
2 Elliott, M.H. Informatics convergence presents opportunities and challenges. Scientific Computing Oct/Nov 2011. http://www.scientificcomputing.com/articles-IN-Informatics-Convergence-Presents-Opportunities-and-Challenges-111111.aspx (accessed September 8, 2012).
3 Gibbon ibid
4 McLelland, A. “What is a LIMS—A laboratory toy or a critical IT component?” http://www.rsc.org/pdf/andiv/tech.pdf (accessed September 8, 2012)View PDF