I’m spending a couple of days at the IQPC meeting on Data Management and Knowledge Discovery in Frankfurt Germany. The agenda has a comprehensive coverage of a number of aspects relating to technology tools in the laboratory with a mix of strategic papers and case studies. As is always the case, a number of informal discussions arise as a consequence of some of the material presented. So far, there have been two topics that caught my attention. One of these was the subject of technology adoption, and I’ll come back to than in a separate post, but the topic I wanted to follow up on here was the relationship between a LIMS and an ELN. This is also the subject a separate post on this site. This question has arisen a few times recently, in part due to a trend towards convergence in some of the commercial offerings. Until very recently, no single vendor offered both products or even a single integrated product. Nevertheless, there are ELNs that function more like a LIMS, and there are LIMS that offer some limited capability to support ELN functions.
The fundamental difference between the two applications is usually attributed to their ability to handle structured and unstructured data. A LIMS is to some extent a sample and test management system that sits over a relational database and provides a number of functions to support laboratory productivity. An ELN provides generic functions to support experiment management, contributing to a knowledge base and addressing patent evidence creation and IP protection. It may also contain other discipline specific functions to support the disparate requirements of chemistry and biology. An ELN and a LIMS therefore address different, but related functions within the laboratory workflow. Typically, an experiment will generate one or more samples; a sample will require one or more tests, and a test will have one or more results. The ELN therefore sits at the top of this structure as a repository for all information associated with the experiment. The LIMS provides the transactional capability to handle sample registration and test assignment, entry of results, reporting and a host of related functions.
The interesting question that came out of a coffee break discussion was what does a LIMS need to become an ELN and what does an ELN need to become a LIMS. Conceptually, it is easier for an ELN to incorporate LIMS functions since the ELN sits above the LIMS in the hierarchy. Depending on the design of the ELN, the addition of suitable templates in an ‘experiment document’ can provide a number of LIMS-like functions. This assumes that the system’s infrastructure provides the capability to store and manage dynamic and master data. In a very basic sense, this is the architecture of those products that fall into the ‘hybrid’ category. Some of the current specific ELN products also provide this capability through user-configurable templates.
For a LIMS to incorporate ELN functions, the challenge is greater, again due to the hierarchical relationship between experiments, samples and tests. The ‘experiment’ layer really needs to be designed into the product from the start, but nevertheless I’m sure there are a number of work-arounds, that in certain circumstances can provide some capability to group data together and provide additional facilities to incorporate unstructured information such as summaries or comments. In some products, ‘batch’ or ‘job’ functions may provide this capability.
But really, the bottom line on this question is that we tend to adopt a very application-centric view of systems, and it is not always productive to adapt a product to do things it wasn’t really designed to do. Since most labs will aspire to an integrated solution that supports laboratory automation, test, sample and experiment management, it always seems to me that life would be so much easier if we could pick and choose the relative software functions that address the components of the entire laboratory workflow and install them on an open platform in order to address our specific business
