I came to GenoLogics just under a year ago and having come from a background in data analysis software I wondered at first why customers and LIMS vendors alike always talked about (and compared lengths of) the time it takes to implement a LIMS system. With analysis software systems I’d worked with this process was straightforward; you’d install the software, train the administrators & end-users, and you are done, system implemented. I soon found out, however, after talking to several different laboratories that implementing a LIMS is often a long, time-and-resource-consuming, process. So why do some laboratories take years to implement a LIMS and how can we do something about it?
As I came to learn more about LIMS I encountered four general themes that seemed to stymy an organizations efforts to get a LIMS system into production. These themes are: under-resourced in-house development, instrument integrations, workflow customization and system usability.
In a recent discussion with a client they told us that they had spent a few years investing in building an in-house LIMS that never reached production and now were looking to start over and purchase a system. This turns out to not be an uncommon story. Unfortunately, in-house built LIMS projects are often underestimated and are therefore often under-resourced, with one or two (if you’re lucky maybe four) core developers expected to build a fully functioning, fully integrated LIMS. This type of undertaking by a small team can take several years and become outdated before it ever gets a chance to be utilized. At GenoLogics, we have a completely focused development team of 20; few organizations are willing to make that type of personnel investment.
“It is wise to spend your precious in-house resources building onto a system rather than building a system”
I encourage those that are considering building a LIMS and need a system in production in anywhere under 24-months to consider starting with some base LIMS. Regardless of what system you choose to implement, it is wise to spend your precious in-house resources building onto a system rather than building a system.
The second theme has to do with instrumentation. There are so many instruments in the laboratory eco-system with a diversity of instrumentation software capabilities, versions, and levels of instrument vendor-support for integrations. We see many LIMS implementations from other vendors and in-house systems fail as a result of inability to manage the varying file types, instrument vendor software release cycles, and instrument upgrades that come up day-to-day. Even the savviest of LIMS vendors find configuring instrumentation integration to a clients desire to be one of the time-consuming process during an implementation. So how does one manage this key element of a successful LIMS?
In our experience a successful instrumentation integration strategy comes with a combination of generic software elements that can be customized to specific instrument vendor software, along with a well-developed relationship and understanding of our common instrument vendors, such as Illumina. This allows us to meet and exceed our customer’s expectation for integrations rapidly.
Although many labs are running the same instruments with the same protocols, every lab has their individual ways of implementing those protocols into their own standard operating procedures. Even if a LIMS vendor has pre-configured workflows for next-generation sequencing (which BaseSpace Clarity LIMS does) these pre-configured workflows need to be flexible enough so that they can be customized quickly to the individual needs of the customer. How quickly is the difference between a good implementation and a flawed one. This is where many LIMS vendors struggle. In building the BaseSpace Clarity system this is an issue we took very seriously. We set out to design an interface which both includes template workflows for common instruments and protocols while having a streamlined user interface for tweaking these workflows to the desired level of customization. Tackling this one issue has shrunk our time from purchase to production by at least a third.
So now you’ve built your system (or purchased it), you’ve integrated it to your instruments, and you’ve customized it to your laboratory workflows, you’re done right? Unfortunately, this last theme is the most common place where we see a LIMS project die on the vine. Your system may have the ability to collect all the data you’ve ever wanted, but if your lab staff has trouble using it, your data is going to be questionable. A system that isn’t usable by staff as they are working along at the bench will create human workarounds that ultimately mean information gaps and lost opportunities to prevent errors. Take the quote in a recent white paper from Robert Hall at the University of Washington “We found ways to work around the system”. You can enforce that your staff utilize a difficult to use LIMS but these staff will find ways to get their work done faster, if that means writing in a notebook and transcribing to a LIMS later then that’s what will happen. These types of workarounds mean transcription errors, and or no chance to flag a problem process before it takes place. This is all not to mention the general workplace satisfaction and moral of a team forced to work with a difficult system.
In the end, haw fast is fast, depends on your organization. We have customers who are looking to have a system up and running in under three weeks (Personalis) and we have customers who are not planning to launch for several months. Whatever your timeline we’ve designed a system that allows this deadline to be determined by you rather than by the capabilities of our system.
When planning a LIMS project of any kind take these four themes into account and you are likely to understand your timeline from kick-off to wrap-up.