Reassessing LIMS: The Failures of Current Lab Software

Lab work can be a challenge. Compliance issues, training, and quality control measures, not to mention day-to-day hassles like tracking samples and incomplete assays, can overwhelm anybody, from the lab technician up through the lab’s management.

Lab work can be a challenge. Compliance issues, training, and quality control measures, not to mention day-to-day hassles like tracking samples and incomplete assays, can overwhelm anybody, from the lab technician up through the lab’s management. Where does lab software fit in all of this? A necessary evil? A tool that makes life better, easier, more efficient? Or somewhere in between? As far as we can tell, lab software seems pretty broken, and it amazes us that in this era of agile software development and user-centered design, labs still have to deal with applications that look and feel like 1999, or require a whole team to manage. We’ve been doing some digging, interviewing experts and folks with years of experience in the lab, and uncovered a few primary ways in which lab software underserves the people who use it.


Putting data to work: the challenge of getting information out of the LIMS

“Traditionally, our systems are great at collecting data,” Gloria Metrick, author of the blog Out on a LIMS and an expert on lab software, said. “We’re just crummy at doing anything with it. They’re ‘data graveyards’: that’s where data goes to die and it’s never seen again.” Metrick very concisely voices a very common complaint from those working at all levels of the lab, from technicians, to CSO’s, to lab managers, to those in the IT department. While LIMS may capture the data produced, getting it out for the purpose of making good decisions about the lab’s quality or operational improvement efforts is a pain, if not impossible. In many cases, retrieving valuable insights into the lab, whether to pinpoint “what went wrong” or how to do better, requires writing SQL statements or scripts in order to grab data from the database and present it in an intelligible report. In some scenarios an IT team member is available to do this type of task, or even create a separate reporting application for the rest of the lab (that is, if the LIMS hasn’t created a “black box” around the mechanisms that would export the data, which is not uncommon). In recent years, some labs have attempted to rectify the problem with reporting by bolting other applications, either exclusively for reporting or for larger business intelligence capabilities, onto their existing LIMS. While some of these “hacks” might solve some of the problem, few, if any, applications have emerged on the market that take into account the overall data and information needs of a lab, whether it’s sample tracking, document management, or business intelligence.


Expensive to implement and maintain: the cost burden, and trap, of current LIMS

Those who have set up a lab know that software can significantly add to the bill, ranging from a few thousand for licenses to hundreds of thousands of the lab intends to retain an IT staff and continue to maintain the software. “These programs are still really difficult to implement…you have to have a pretty big IT department to manage these things on a larger scale,” Metrick said. “They’ve failed because they’re a lot more expensive to implement than to actually buy licenses for. In fact, the license is a small part of the implementation—services are incredibly expensive.” The implementation of new software has in many cases hindered innovation in labs, at least on the software side. With so much invested in a particular suite of programs, labs feel locked into the software they have, and software providers have little incentive to develop their product with the end user in mind. As a result, labs end up with bloated applications that become more and more heavy as the years pass, or a hodge podge of home grown applications that require a team of experts to maintain. Big labs pay through the nose, and smaller or startup labs struggle to get into the game, and end up buying software that simultaneously provides for more features than they need, and doesn’t meet the needs it has.

Falling behind: Outdated development practices for LIMS

Lab equipment, especially in the field of genomics, is astoundingly advanced, while ironically at the same time most lab software is many years behind in terms of how software is developed, improved, deployed, and hosted. Most software providers still operate according to outdated development practices, and can’t easily change or improve a thing, even when they want to. For example, while some cloud-based systems have entered the market, software providers are years behind in taking advantage of this manner of hosting data. Software providers have also been slow to embrace providing solutions as a web application, which would enable not only use from any desktop computer, but any tablet or even mobile phone. Unfortunately, many of the most entrenched systems are huge and code-heavy, and entered the market at a time when software providers didn’t care as much about the user’s experience. While there’s certainly diversity in the market for LIMS between small and large companies, some of which work to respond to new demands from labs, the industry itself has lagged far behind others in terms of its embrace of multi-platform, agile, user-centered software.

Get the whitepaper

Get the latest laboratory insights and best practices delivered to your inbox weekly.

Linking Genomic and Phenotypic Data to Better Understand the Patient Journey

In partnership with Datavant, we explore how researchers can overcome the challenges posed by..

Case Study: Realizing the value of biospecimens for life sciences research in IBD


We looking forward to speaking with you!