Despite the economic downturn, the attendance at this week’s IQPC 8th Annual conference on ELNs and Advanced Laboratory Solutions was up on recent years, and overall it proved to be a lively event. The format was a 2-day conference preceded by a ‘focus day’, targeted at people starting to get into ELN technology. You can see my focus day presentation on ‘Starting from Scratch: the ELN Reality’ here.
There were two important themes that emerged from the main conference. The first of these was the thorny issue of integration which has bedevilled the laboratory software domain for years. Despite the heroic efforts of the few, the need for messaging and data interchange formats has never been addressed with sufficient inertia to generate any real progress.
The point was addressed by Michael Elliott (Atrium Research) with a renewed call to arms, based on the growing demand for data interchange between laboratory systems such as ELNs, LIMS and SDMs. Further presentations raised the same issue, but from different perspectives. Single-vendor solutions to the integration problem are being developed; in some cases, vendors publish an API; some products (ELNs and LIMS) are increasingly incorporating web services; but for a user community looking to implement and integrate best of breed tools, the challenge remains.
In another presentation, David Drake (AstraZeneca) talked about the Pistoia Alliance and the work currently being undertaken by member companies to develop an open ELN data query standard to support the interchange of data between CROs and their major customers in the Pharmaceutical industry. This new initiative does hold some realistic promise due to the limited scope of the project, and by a growing sense of urgency to solve the underlying business problem.
The other key theme in the conference was the increasing confusion over different brands of ELNs. Whereas Chemistry ELNs are reaching a level of maturity, numerous questions remain over how to address the biology market. Furthermore, the line between a process, or QA ELN and a LIMS is becoming increasingly grey.
The approach to dealing with biology hinges to a large extent around the use of Excel, widely recognised as the biologists’ favourite tool. The dilemma is whether to develop an ELN that wraps some generic functions around Excel in order to leave the biologists free to continue doing what they already do or whether to develop specific functionality, typically based on a spreadsheet format, but which addresses more tightly defined bioinformatic requirements. There are advocates of both approaches.
A further dimension to the biology question was raised by Seth Pinsky with the observation that biology ELNs are more or less dedicated to testing, whereas greater benefit could be achieved with the incorporation of more intelligence in order to address the evaluation of results and the generation of hypotheses. Seth left us with this question: is it possible to automate innovation or creativity?
The LIMS/ELN convergence question has no clear resolution. The underlying distinction is about workflows. Those ELNs that fall within this category tend to be procedure (SOP)-driven, i.e. the ELN presents the procedure, results are then entered and relevant calculations preformed, all in accordance with appropriate regulatory requirements. This same functionality can of course be incorporated in a LIMS, although this may represent a less typical workflow than the norm. The basic difference is in the infrastructure of the application. A LIMS is typically designed to handle structured data, whereas an ELN is typically designed to handle unstructured data. From a functional perspective, our application-centric view of laboratory systems seems to require us to call the ‘system’ a LIMS or an ELN, when what we are really dealing with is data capture, data processing and data management functions. How much does this matter to users? Difficult to say – perhaps it matters more to the vendors?
Overall, the conference had a slightly different feel than previous years. There is a growing sense of maturity about some aspects of ELNs, but the integration issue is starting to take on more and more relevance as users come to terms with the implications of working in an electronic environment. In particular, the Pistoia project will be watched with considerable interest.
Thanks for this John well summarised.
I posted my thoughts http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=1148517&discussionID=7871874&goback=.anh_1148517
The question of structured data vs unstructured data is key. A lot of suppliers talk about structured data pointing to tables in an ELN document as though this is structured data. The key to structured data is that this structure enables you to mine, search and exploit the data in a meaningful way without needing to analyse and interpret structure.
For this reason we have started with LIMS like data management and then embedded that into a page to form a truely structured notebook solution. This means tables of data can be searched by parameter (columns) and values (rows) together with unstructured data.
This blurs the lines between LIMS and ELN because essentially your LIMS is in the page of your ELN capturing structured and unstructured data together.
Another theme was Master data management. Something I’ve been advising my consulting customers for a long time. This is a phrase for things we’ve always done but perhaps not in a joined up way.
One of the modules of BioRails is a master data management catalogue allowing organisations to categorise and implement all their terminology in one place (federated from other solutions like LIMS and ELN) into one central served set of Master data. This is the foundation of good data management practice.
more on that later…