By Joseph Liscouski
We’ve reached a point in the development of informatics technologies where the potential far outweighs our ability to take advantage of it. If companies want to make the gains in productivity that are possible, we have to change the approach used to structure corporate information infrastructures. Planning has to be more global than departmental. Those working with informatics systems need to be trained to think beyond short-term requirements and examine how the result of their work is used corporatewide.
The corporate and laboratory electronic landscape is changing, and the separation between corporate information systems and lab applications that has existed to this point needs to be reexamined. Historically, lab computing and automation has functioned like a set of isolated work cells, with computing and automation applied on a case-by-case basis. This isolation was driven by early lab systems doing real-time data acquisition, where the ability to take data at precise intervals was paramount. While there are techniques that still require dedicated processors, other common methods such as chromatography can use networked data acquisition modules that separate acquisition and processing, allowing for more flexibility in overall systems design.
Local work-cell automation was implemented without planning for integrated systems until too much product was put in place — “How do we make this stuff work together?” instead of “How do we plan our lab automation and computing?”
Over the past 30 years, laboratory information management systems (LIMS) have been implemented, often as successes, sometimes as complete failures. In many cases these systems have been implemented with lab management as the end-point of consideration, ignoring the needs and opportunities that could be satisfied if the next step in lab data/information utilization were taken into account: integration of lab test results with other corporate groups such as production, research, shipping, accounting, and legal departments.
Today, the current hot technology is electronic laboratory notebooks (ELNs) with promises of cost savings and revolutionizing the research and testing data systems structure. Both vendors and end users have cited cases where these promises are being realized. Some vendors have learned from the LIMS experience and discussed the connection between ELNs and ERP (enterprise resource planning) applications. The implementations of product offerings like these are made more complex by the use of Software-as-a-Service (SaaS) implementations. With the development of LIMS and ELNs, lab automation and computing has to move from being a side issue to part of the planning for corporate information structures. The cost in money, time, and missed opportunities is too great to continue with “business as usual” practices. IT groups and lab management have to develop a working partnership to encourage the effective use of automation and computing technologies without compromising the lab’s ability to work. IT needs to learn more about how labs work and understand the factors that drive them. Lab groups need to look beyond the science and deal with the practical aspects of technology application and management. We’re not just looking for cooperation, but for synergism.
Quality And Testing Laboratories
The diagram on this page shows a schematic of instrumentation and informatics systems in a typical testing lab. The bottom two levels are in-the-lab systems, and the upper level contains the rest of the corporate environment. Most planning for lab systems stops at the middle level. It is almost as though a wall existed between the corporate and lab management levels. Part of that barrier is built on a lack of understanding of the lab’s information and computing environment, plus a lack of training for lab personnel on the realities and impact of the current technologies used in lab work.
There is also a cultural issue born of regulatory requirements and the need for QC to be a check on production. Those requirements prevent people from seeing information until it is reviewed and approved for release, a requirement that can be managed by the use of restricted accounts (used by accounting departments to determine charges for lab work), messaging systems, and intermediate data structures. The latter two elements would be used to build a “firewall” between the labs and those requesting test results, avoiding the issue of premature access to results. Integration would only be considered between the lab management system and corporate elements; the data and information in the lower-level structure would be meaningless without the analyst’s ability to interpret the material.
The benefits of integrating lab and corporate systems include:
A reduction in management overhead in the lab — Interruptions from requests for sample status would be reduced, as would requests for administrative information. Further, accounting wouldn’t need to ask lab managers to create reports.
Having lab-generated information available in electronic format would make it easier and faster (and less expensive) to create shipping certificates of analysis and provide production with the data they require for process monitoring and control.
Well-planned and integrated automation systems would streamline the overall production process.
Research & Development Labs
The nature of R&D work prevents a straightforward analysis of the benefits of integration as noted for quality labs. The data and information generated within the lab is context-dependent; without understanding what the researcher was doing, the data has little meaning.
On the corporate side, the major benefit is access to and management of intellectual property (IP) — the result of the corporation’s investment in R&D. The increasing use of ELNs enables better management of IP. Indexing of research results provides a means of searching and retrieval, which is costly with paper-based systems.
For those doing R&D, the integration with corporate systems can yield more effective implementations with more robust backup and support. This is particularly true if we move beyond the needs of a single individual and look at the needs for collaborative/partnership research programs. Database systems — the basic sub-structure of ELNs — need maintenance and support. The more robust the system, the more intricate the database structure and need for experienced personnel. ELNs have the ability to import material from a variety of sources, including Microsoft Word and other applications, making them powerful tools. There may be sensitivities to version changes — a given version of a notebook product may work well with a specific version of a product, but if that product is upgraded — particularly if there is a change in storage format — things may break.
An effective partnership between IT and lab groups can mitigate these problems. IT can advise the labs on changes in vendor product plans so that the labs in turn can see what impact those changes will have on their operations.
In this age of lab informatics and automation, we need to adopt a new model for how labs operate and cooperate with other parts of an organization. Computing, informatics, and automation are more than incremental improvements in how lab work gets done. They are the basis for a complete change in how lab and corporate management plans and implements projects and programs. Technologies such as virtualization and SaaS change the way we look at products, their implementation, and overall product life cycle. Unless we move from piecemeal implementations to planned integrated systems, both lab and corporatewide, the real benefits of these and other developing technologies will elude us.
About The Author
Joe Liscouski is the director of the Institute for Laboratory Automation. He is an experienced lab automation professional with over 30 years experience in the field, including the design and development of automation systems, LIMS, robotics, and data interchange standards.