LIMS, of course, is an acronym for Laboratory Information Management System. So thinking in very straightforward terms, a LIMS can be any piece of software that manages the information that is produced or digested in a laboratory setting. Unfortunately, this definition is not very good. Using this type of simple definition means that Microsoft Excel would be considered a LIMS! We certainly know that many labs are using it for tracking information in the lab, but I doubt any of them would call it a LIMS.
So we need to improve our definition a bit to exclude things like MS Excel from qualifying as a LIMS. Perhaps we can say something like: A LIMS is any piece of software that manages the information that is produced or digested in a laboratory setting, and includes support for many laboratory-specific needs." I find this definition also lacking, especially in the context of our own product, Exemplar LIMS. This type of definition potentially excludes products like Exemplar LIMS that are general data management solutions with high affinity for laboratory environments. In this new definition it comes down to what does the term "support for many laboratory-specific needs" mean exactly?
When we think of a laboratory there are a few foundational requirements that seem to apply across all laboratory types, such as the ability to track and manage samples. But even here I see problems. When we hear this item as a requested feature in a LIMS, and then get down to the details of what the customer wants, it often varies quite dramatically between labs. This is even true of labs of essentially the same type, such as next gen sequencing labs. I think that this points to the crux of the problem with defining what a LIMS is, and why you get 5 different definitions if you ask 5 different people what LIMS is. The problem, in our view, is that the laboratory setting and its needs vary widely between labs. So what a LIMS is varies significantly depending on who you talk to as their needs reflect their vision of what a lab is.
There is certainly variance in software needs in other domains as well, but I think this is particularly true in the LIMS space. If you were to plot the idea of what an accounting application should look like on a standard deviation graph, it curve would be very high in the middle and not very wide as most customer requirements would fall near the norm of requirements for other businesses. In the case of the LIMS, the center of the graph would be low and the graph as a whole would be wider reflecting the wide divergence of needs of different lab environments. So the standard deviation of the LIMS is essentially greater than for many other products.
Things are complicated by the fact that there are many different types of labs like forensics labs, environmental labs, genetics labs, chemistry oriented labs, manufacturing labs, etc. There are also distinctions such as regulated labs such as HIPAA, FDA, CLIA, GLP, etc and non regulated labs such as research labs. There is also a diversity of lab equipment such as genetics based labs, blood chemistry focused labs, proteomic labs, etc. When you group all these variables together you get a huge range of needs for a LIMS depending on the type of lab and the people running the lab.
So maybe we need to try another way to define a LIMS. Perhaps we need to take a step back and look at what might be a common functional definition across all laboratories. Here at Sapio Sciences it has become clear to us that all labs have one thing absolutely in common, and that is that each and every lab is an advanced workflow processing construct.
Think about what happens in many a laboratory every day. Samples are received and are processed according to some protocol. They may be accessioned, bar-coded, and stored in a freezer, or they may follow some other process, but the key is that there *is* a defined process that the sample will follow as laid out (usually) by the lab manager. The sample will then proceed through some lab test or process that again follows a detailed and rigorous procedure usually established by the equipment vendor. Then there will be some process for distributing test results to researchers or handing off data to some analysis tools, etc. The key here is that no matter what kind of lab you are in, you are following several distinct processes as your main function.
So now we can perhaps begin a new definition of a LIMS in this new context. essentially the LIMS should be able to support these processes in an intuitive and easy manner. But this does not cover the fact that these data tracking needs can vary widely even for the same processes. This means that there is an implicit need for flexibility of the LIMS which is reflected in our above discussion of large standard deviation of lab needs. So somehow we need to incorporate this into our ideal LIMS definition as well. There is also the need to address regulated versus R&D labs various needs. Something else to consider is what happens after the lab processing is done. There usually is some hand-off of data to some consumer of that data, so we need to address that need as well.
It may not be possible to put this in a sentence, so I will try it in bulletized fashion. I believe we should start to define a LIMS as:
A software tool that enables the following key features in support of modern laboratory operations:
- Support for the rapid implementation of detailed and adaptable workflows
- Inherent underlying flexibility in its architecture to support diverse data tracking needs
- Built in features and functions that support its use in regulated environments
- Easy to implement interfaces to support data import and export
So there you have it! We think this serves as an excellent definition of a LIMS based on our ample experience in this area. We look forward to others feedback on this topic as it is sure to generate discussion.
No comments:
Post a Comment