During a discussion around the future of LIMS over at LinkedIn, one poster suggested that the term “WebLIMS” be stricken from our vocabulary. I tend to agree, for the reasons specified. Perhaps we should start a list like the one that comes out every January, listing terms that should be stricken from the language for misuse and overuse. The first one on my list would be the term LIMS, itself.
LIMS would qualify on the misuse grounds. The reality of every LIMS that I’ve seen(and I’ve seen all of the major ones) is that they are not at all focused on managing laboratory information. Rather, they are generally sample logging and test result recording systems. To argue that this represents “laboratory information” is like arguing that an engine is the entire car. The engine may be central and critical, but it is not what most users of the car interact with directly.
When a laboratory embarks on implementing a LIMS, there are very much competing interests on the part of the stakeholders. Unfortunately, this is often overlooked. It may even be that some stakeholders misunderstand their own interests. For instance, people who submit samples to an analytical lab think that by supporting the analysts’s request for increased efficiency they are supporting their own desire for improvement in their business processes. In other words, they substitute the analytical groups requirements for their own. However, simply improving turnaround won’t generally fulfill all the needs of the submitting groups. Does faster turnaround result in easier submission? Easier status updates? Easier data mining? Getting results faster is certainly a requirement, but it is not the only, nor necessarily the most important, to key sets of stakeholders.
If we look management, a similar problem occurs. For a service organization like an analytical lab, happy customers are the requirement, as is the collection of metrics that facilitate a true quality management program (you just knew I would throw that in there).
If we look at all of these additional requirements, we should realize a couple of things. One is that laboratory information is much broader than most LIMS really take into account, and the second is that we should rethink the process by which we implement LIMS. In other words, in order for LIMS to truly be LIMS, we need to do things and think about things very differently. No longer will simply slapping the latest interface technology, or installing yet another new LIMS fix the inefficiencies and challenges our analytical laboratories face. Many years ago, W.E. Deming made the point that the latest new gadget will not fix your quality challenges. That notion is as true today as it was then.
If LIMS is to be truly LIMS, it needs to be as concerned with metrics as with test results, with metadata as much as logging procedures. These cannot be secondary concerns, relegated to mere afterthoughts in the implementation process. Only once LIMS really addresses, and effectively, all laboratory information, will LIMS implementations begin to succeed.