The lab systems we have today are not built for integration system-wide. They are built by vendors and developers to accomplish a set of tasks, and connections to other systems are either not considered or are avoided for competitive reasons. If we want to consider the possibility of building integrated systems, the following five elements are needed:
• Education
• User community commitment
• Standards—file format and messaging/interconnect
• Modular components
• Stable operating system environment
Education
Facilities with integrated systems are built by people trained to do it. But the educational issues don’t stop there. Laboratory management needs to understand their role in technology management. It isn’t enough to understand the science and how to manage people, as was the case 30 or 40 years ago. Managers have to understand how the work gets done and the technology used to do it. The effective use/misuse of technologies can have as big an impact on productivity as on anything else. The science also has to be adjusted for advanced lab technologies. Method development should be done with an eye toward method execution— can this technique be automated?
User community commitment
Vendors and developers aren’t going to provide the facilities needed for integration unless the user community emands them. Suppliers are going to have to spend resources in order to meet the demands for integration, and they aren’t going to do this unless there is a clear market need and users force them to meet that need. If we continue with “business as usual” practices of force-fitting things together and not being satisfied with the result, where is the incentive for vendors to spend development money? The choices come down to these: you purchase only products that meet your needs for integration, you spend resources trying to integrate systems that aren’t designed for it, or your labs continue to operate as they have for the past 30 years—with incremental improvements.
Standards
Building systems that can be integrated depends on two elements in particular: standardized file formats and messaging/interconnect systems that permit one vendor’s software package to communicate with another’s.
File format standards-The output of an instrument should be packaged in an industry-standard file format that allows it to be used with any appropriate application. The structure of that file format should be published and include the instrument output plus other relevant information such as date, time, instrument ID, sample ID read via barcode or other mechanism, instrument parameters, etc.
In the 1990s the Analytical Instrument Association (now the Analytical and Life Science Systems Association) had a program under way to develop a set of standards for chromatography and mass spectrometry. It was a good first attempt. There were several problems with it that bear noting. The first point is found in the name— Analytical Data Interchange Standard. It was viewed as a means of transferring data between instrument systems and served as a secondary file format, with the instrument vendors being the primary format. This has regulatory implications, since the FDA requires storage of the primary data and requires that the primary data is used to support submissions. It also means that files have to be converted between formats as they move between systems.
Ideally, the standard format would be THE format for an instrumental technique. Data collected from an instrument would be in that format and be complemented and used by each vendor. In fact, it would be feasible to have a circuit board in an instrument that would function as a network node. It would collect and store instrument data and forward it to another computer for longterm storage, analysis, and reporting, thus separating data collection and use. A similar situation currently exists with instrument vendors that use networked data collection modules.
The issue is further complicated by the nature of analytical work. A data file is meaningless without its associated reference materials—standards, calibration files, etc.—that are used to develop calibration curves and evaluate qualitative and quantitative results. While file format standards are essential, so is a second-order description—sample set descriptors that provide a context for each sample’s data file. A sample set might be a sample tray in an autosampler; the descriptor would be a list of the tray’s contents (standards, sample ID, etc.).
The second issue with the AIA’s program was that it was vendor-driven with little user participation. The transfer to the ASTM should have resolved this, but by that point user interest waned. People had to buy systems, and they couldn’t wait for standards to be developed and implemented. The transition from proprietaryfile formats to standardized formats has to be addressed in any standards program.
The third issue is standards testing. Before you ask customers to commit their work to a vendor’s implementation of a standard, they should have the assurance through an independent third party that things work as expected.