Almost a year ago I posted an item on the question of when is a LIMS an ELN, and when is an ELN a LIMS. It is still one of those questions that is causing a good deal of head scratching and cropped up again at the recent SmartLabs Exchange meeting. With the arrival over the last year of a number of ELNs appearing as extended functionality in commercial LIMS products, it is not necessarily getting any easier to provide an answer. Or is it?
The LIMS market has reached a sufficient level of maturity that (I suspect) we all know what a LIMS is, and what it does. The same is not true for ELNs. For most people, an ELN is far more than a replacement for the paper lab notebook; it needs to provide the generic capability that the paper notebook provides, but it also needs to replace the traditional cut and paste (scissors and tape) with sophisticated electronic interfaces to other laboratory systems and processes that serve specific laboratory disciplines such as chemistry, biology and analytical or Q/A. As such, the authoring tool at the hub of an “ELN’ is the equivalent of the paper lab notebook, and everything else becomes a number of integration challenges that collectively represent an electronic, or integrated lab.
One of these integration challenges is of course the LIMS, and for most organisations an interface between the LIMS and the ELN is a key requirement. The LIMS does all of the sample and test management, based around structured data; the ELN handles the unstructured and discipline-specific data. But the ELN market became a bit fuzzy with a small number of products (QA-ELNs) that were labelled as ELNs, but functionally were closer to a LIMS, albeit with a different type of workflow. The products were essentially built around an SOP-driven workflow that presented the user with the test procedure. Test results could then be added to the appropriate fields in the procedure, either manually, or by a direct instrument interface. Of course, a more typical ELN could be configured with templates that are able to replicate this type of workflow, so one of the impacts of the specialised QA-ELNs was to cause the mainstream ELN vendors to respond with this type of functionality. Having kept very much in the background, suddenly the LIMS vendors, saw the opportunity to extend their products to embrace the QA-style workflow by adding a layer of functionality to provide either a procedural driven approach, or to accommodate the unstructured data that is associated with an experiment.
The outcome then is, if you are looking for a QA-ELN, there are three options; firstly to go with a specialised ELN dedicated to QA, secondly choose a mainstream ELN that offers a QA module, or thirdly choose a LIMS with ELN functionality. There’s no easy answer to this since your organisation’s specific requirements and existing infrastructure will have a big influence, but…..
If you do not already have a LIMS or an ELN, and compliance is a big issue for you, you will probably want to look at the specialised QA-ELNs. If you need to accommodate multiple disciplines in your ELN (chemistry, biology, QA, etc) then the mainstream vendors that offer a product with discipline-specific modules may be your first port of call. And if you already are a customer of a LIMS vendor who is now offering an ELN extension, then their systems may be the first to check out.
But perhaps the real issue here is our application-centric view of laboratory systems. The move by ELN vendors and LIMS vendors to offer a suite of functionality that operates on a single platform makes good sense. And if the platform were not proprietary, then it would make even better sense.
[...] at The Integrated Lab, John Trigg looks at the ELN Vs LIMS issue which has come around again as more traditional “LIMS” vendors introduce [...]