Joe Liscouski, executive director of the Institute for Laboratory Automation, discusses how informatics standards can lead to the transformation of laboratory work
There have been a number of articles written about data format and interchange standards in laboratory work, most stressing the ability to export instrument data and providing a basis for the integration of lab systems. Both are spot on and valued justifications for an industries-wide effort in their development. If we needed an example, we can look to the transformation of the clinical chemistry laboratory where cost-centres have become profit-centres. The bottom line is simple: standards that lead to integration and data exchange benefit all aspects of the lab automation community. And that is as far as most articles go; we’re going to move further in this piece and get into scientific speculation. How else will standards development change lab work? How can it lead to streamlined operations, lower cost and all the things automation was supposed to do? We’ll look at one possibility.
The samples are set up in an auto-sampler and the chromatograph is told what the pattern of standards, samples and replicates are. Instrument operating parameters are downloaded as part of the sample initialisation scheme. As each sample is processed, the instrument builds up a data set containing the raw data and description of each vial. When the auto-sampler run is completed the entire data set is sent to the data library and the analyst is notified that it’s available for evaluation. The analyst may choose to have it processed according to a standard procedure description with the results sent to an electronic lab notebook where they can be reviewed and forwarded to the lab information management system.
Another option is to describe a new method by choosing processing routines, including specialised peak-processing algorithms and baseline correction from a menu and applying it to the data set. The analyst may, for example, want to compare the standard peak processing system with a newly-developed approach selected from a library of routines available from instrument vendors, commercial software developers and researchers. If the new software looks promising, it can be applied to older data sets to see how it affected those results. Any of the data – current or historical – can be examined interactively using a graphical interface. This same process could be used with almost any instrument.
Although the flow might seem familiar, the details are quite different from today’s lab work due to the availability of one element: standardised formats that describe not only the data for each sample processed, but the organisation of samples in a set. These are standards, values and sample positions that could be confirmed with barcode scans – a structure similar to that proposed by the ANiML working group.
Among the differences are:
• Data collection, data set formatting and transmission are done within the instrument. Standardised message formats and communications protocols are needed; they could be an extension of existing methodologies.
• A library of laboratory data sets has been developed to hold all instrument output rather than have it distributed in multiple database systems. This provides easier management, searching, backup, etc. This library could be lab-wide or part of a larger corporate database – an important element for corporate electronic lab notebook implementations.
• The analyst has a choice of data analysis routines from a variety of sources. Since the ability to access data is no longer restricted to vendor provided systems, more research can be done on data analysis algorithms, with some routines tailored and standardised to meet specific applications.
• The availability of access to historical data in forms that allow it to be re-evaluated with new techniques and viewed graphically as if it had just been collected.
• Systems available today provide remote access to data and data analysis, however this capability would be extended to provide interactive or batch processing at the lab level, or anywhere on the network. This would enable remote access and control of instruments, and help implement advance in-line process monitoring of manufacturing operations.
• It would also end the need for labs working in the same facility to have common software systems from the same vendor.
This single fundamental element – well-designed data standards that incorporate both data and a complete description of a test/experiment run – provides a basis for the complete redesign of laboratory systems and workflows. Both components of the standard are critical; the data from a single sample in a standardised format is of little value. Most instrumental techniques require access to reference standards.
Add the ability to provide messaging systems between informatics products and instruments – something that exists in clinical environments – and we have a major part of what lab managers have been asking for since the basic ideas of lab automation were first proposed. The issue of sample preparation has to be addressed, but that is another article.
A small development can make a significant change in laboratory automation and provide the architectural basis for designing lab systems. Making this happen is dependent on the lab automation user community, not the vendors. As we’ve seen in other fields, vendor-driven implementations lead to multiple standards, none of which meet the need. In computer graphics, vendor-driven efforts led to EGA, CGA, VGA and Hercules ‘standards’ on the hardware side and others in software. In computer networks, we had vendor’s proprietary standards and TCP/IP. In both cases, and in others, it was need/user-driven efforts that led to the development of a standard that provided the basis for today’s successful systems.
Rather than talking about the need of having ‘someone’ solve the problem, let’s come together as a community and begin the work of drafting the requirements for standards that will do the work needed.
1 Analytical Information Markup Language (AnIML) ASTM XML standard, ASTM E13.15 working group, http://animl.sourceforge.net/astm
2 including DARPA and internet development