Integrating the Laboratory's Islands of Automation

Aug 01, 2009

LIMS, CDS, ELN, and so forth — these acronyms conjure up an impression of a laboratory that is well equipped and superbly efficient. What is the reality? Close at best, but only in a minority of laboratories, and miles away in the majority of laboratory situations. A laboratory may have a number of scientific applications purchased but the real question is: Can they implement each one effectively and get it to work efficiently and save time for the users? The problem is that many applications when implemented actually cause the users more work not less.

Let us ask some (awkward) questions:
Are any analytical instruments connected to your laboratory applications?
Are applications interfaced together to avoid retyping of data?

If the answer (please don't ask to phone a friend or go 50-50) to either of these questions is no, then your laboratory has islands of automation floating serenely in an ocean of paper. Your interface is paper. This is inefficient, error prone, and slow.

The problem is that we hardly ever consider connecting these applications as the topic usually is considered outside the scope of each project. Lack of interfacing compounds the problem of inefficiency in the laboratory as all manual input into any computer system needs to be checked manually by a second person to reduce typographical errors. Interfacing the instrument to an application or interfacing two applications together is a crucial factor in improving the efficiency of the laboratory as well as eliminating one of the real non-added value jobs in the laboratory — transcription error checking. Paper interfacing is easy to achieve but is not cheap, as it requires continual human labor for input and checking the entries also is error prone, as there is no automated data-extraction routine.

Let us look at the question "why interface?" in more detail. Here, we will look at the major area for the laboratory and its analytical instruments interfaced to either an electronic laboratory notebook (ELN) or laboratory information management system (LIMS). The best way to shame you into considering interfacing more proactively is to look at a very common application in the laboratory — a chromatography data system (CDS). The majority of CDS implementations will control the gas and liquid chromatographs interfaced to it, determine the method that an instrument will run, inject the samples according to a sequence file, acquire and interpret the data, and generate the results — all in a single system. This is a great example of interfacing laboratory instrumentation to an application.

Going into more detail, what is the advantage of interfacing to the users? In a single system, you can set up, control instruments, and acquire chromatographic data. Working electronically, the analyst can view the chromatograms on the screen and reintegrate where appropriate and calculate the final results. The majority of networked CDS applications have the ability to incorporate custom calculations, which means that the analyst does not have to print out data to input them into Excel for final reporting. When an analyst is finished, they will ask their supervisor to check their work. Instead of printing out piles of paper, a supervisor can review the results including retention times, peak shape and resolution, standards, and quality control samples to show that the method was under control. Furthermore, they review the integration and determine if the decisions made by the tester were appropriate and change anything if required. All this work will be audit-trailed so that any quality assurance checks can determine easily if procedures were followed. Note, in this discussion, there is no mention of transcription error checking but there is no transcription to check as it is all electronic.

So, if we can do it for a CDS why not a LIMS? It is too much work, too complex, or can we wait until later in the project phasing? The reasons might be all of the above. However, that misses the point. Implementing a LIMS requires that there is immediate benefit for the users and payback for the organization who is paying for your incompetence in not interfacing instruments into the process.