Laboratory Information Technology - American Chemical Society

---

A/C

Interface

Laboratory Information Technology The Questfora Business-Grade System Successful IT systems must capture the vision of the entire company, not just the needs of the laboratory Everyone agrees that information technology (IT) is important, even essential, to the analytical chemist. Yet there is no agreement on how to plan and achieve IT. The classic image of the scientist is that of a solitary individual patiently and obsessively pursuing a goal. Today, however, cross-trained teams work openly, sharing information to meet quality, time, and cost targets. IT is too important to be left to IT professionals. Today's chemist must understand enough about the implementation strategies and alternatives to ensure that IT networks are helpful servants rather than masters—that •

0003-2700/95/0367-173A/$09.00/0 © 1995 American Chemical Society

they do things for the laboratory rather than to it. Previous articles in this series have examined IT and laboratory information management systems (LIMS) at the tutorial level. This article presents a set of guidelines to help laboratory scientists and managers successfully implement IT in their own workplace—it is, in effect, the laboratory manual for the course. Changing our work habits to use these new tools will take some effort and time, but the rewards are well worth it. We think you'll like IT. Raymond E. Dessy Series Coordinator

W

££W

W hy bother to automate the laboratory?" or "why expand or upgrade [an existing automated laboratory]?" Anyone involved in laboratory data management has probably had to answer these questions at least once, either rhetorically or for upper management when presenting a request for automation. Or you may be the one asked to decide whether to automate the lab. On what grounds should you base your decision? LIMS have traditionally met the needs of the laboratory without necessarily supporting the objectives of the corporation as a whole. Today, successful implementation of laboratory information technology (IT) involves deploying a "business-grade" system that provides exactly the right information at exactly therighttime for both

S t e v e n A. W a r n e r Hydra Technologies J a m e s W. S y w i l o k JWS Associates

Analytical Chemistry, Vol. 67, No. 5, March 1, 1995 173 A

A/C

Interface

the laboratory and the corporation. This is especially important for laboratories that use IT to support total quality manage­ ment (TQM), continuous quality im­ provement (CQI), Joint Commission on Accreditation of Healthcare Organizations (JCAHO), ISO 9000, or other certification or accreditation programs currently in use by industry. In the recent past, IT implementation was "technology-limited," and planning fo­ cused mostly on technical issues (1). Technology and standards have now de­ veloped to a point where the focus can be shifted to address people and business is­ sues and to match the available technol­ ogy to these requirements (2). It is espe­ cially important that clear, "big picture"oriented communication occur between corporate management and laboratory management. This communication should begin with a shared vision for IT in the laboratory.

An automated testing system is needed that can provide results within 45 min of receipt by lab, can do the following tests..., can be interfaced with Brand X LIMS already in the lab and with manufacturing's process control system, and must not exceed $X in operation costs.

The vision

Technical requirements

Corporate goals must drive laboratory op­ erations, and management must define these goals and the intermediate objec­ tives required to achieve them. Critical success factors (CSFs) are the quantitative statement of these objectives—the things that must gorightin an organization. These items together must drive IT analy­ sis and implementation (see box). Only when the technical requirements have been thoroughly defined can the design of the system and the necessary successive steps be initiated. The flow between steps must be clearly defined and viewable, in obvious and concise terms, to all manage­ ment levels. Higher level steps must de-

Detailed vendor-independent specifications that satisfy functional requirements.

I

Corporate business goals

+

Business objectives and critical success factors

• ΠΠ / Functional requirements [ % / \ D I \l_Jf

? ' Technical requirements

\/

Implementation

\/

+

Figure 1 . Flow of requirements into business-grade systems. 174 A

Example of requirements flow into a manufacturing system Goal

To provide the best value in electrostatic-proof plastic bags on the market. Objectives

Bags must shield electronic components, be produced as inexpensively as possi­ ble with existing manufacturing equipment, and be recyclable. Critical success factors

Bags must shield against an electrostatic discharge of at least X volts. Cost of raw materials cannot exceed $X/Y units. Raw materials must be provided just in time for production, they must be in the lab for QC testing within 15 min of off-loading, and their acceptability must be deter­ mined within 1 h of receipt at plant. Bags must be of Ζ type material for optimum recycling across customer base. Functional requirements

Implementation

Vendor surveys, further design, prototyping, training, and documentation.

fine successive lower level steps, and lower steps must verifiably support higher steps, as shown in Figure 1. Failure of this flow of information results in either the failure to justify the cost of implemen­ tation or the failure of the system itself to meet the corporation's needs once it is ac­ tually implemented. Unfortunately, this failure commonly occurs with the imple­ mentation of IT in the laboratory. Laboratory information systems (LIS) consist of LIMS, data acquisition systems, instrument and robotic control systems, and the necessary network and communi­ cations infrastructure. As is true for other information systems, corporate manage­ ment may perceive LIS as ranging from a necessary cost to a strategic investment. The reality and the perception of where a given system fits depends on corporate management's philosophy toward IT, how closely the system matches the re­ quirements and goals of the organization, how closely the system fulfills the techni­ cal requirements, how effective the com­

Analytical Chemistry, Vol. 67, No. 5, March 1, 1995

munication is between corporate and labo­ ratory management, and past successes and failures in similar endeavors. Corporate management must clearly communicate its objectives (CSFs) to labo­ ratory management. In turn, laboratory management must show how it can satisfy corporate goals by fulfilling its own goals, objectives, and functional requirements. Although the terminology used here im­ plies a major corporation, these concepts are true in any environment, including small business or government. The interplay between corporate man­ agement and laboratory management is better understood when the rest of the cor­ poration is viewed as the customer of the laboratory. The product of the laboratory is information. This information can be crucial to such aspects of the business as quality control, process control, research and development, diagnostics, and envi­ ronmental monitoring. Information must be accurate, timely, consistent, and in a format that can be

used by other IT systems. For example, failures in process control could result in increased manufacturing costs, whereas failures in medical diagnostics could re­ sult in increased litigation costs. However, these failures are often not curtailed or eliminated because of logical disconnects (broken flows of information) that do not allow the information to reach the ap­ propriate people. Furthermore, the infor­ mation may be lost to the laboratory it­ self, preventing reuse in other studies. If IT is to be successfully implemented within a laboratory, it must demonstrate operational efficiency, end its isolationism, and become part of the corporate infra­ structure. Examples from corporate America

The integration of business goals and IT is no small undertaking and has chal­ lenged the management of corporate America for decades, long before LIMS or LIS were developed. In the 1950s and 1960s, a company's financial information system was one of the first to be devel­ oped because it contributed most to the success of the corporation by tracking the flow of money. The earliest systems emulated manual operations performed by people except that computers worked more rapidly and with greater precision. Later systems went beyond mere "automation of paper" to provide new capabilities. With automated systems, corporations could obtain a more accurate and timely view of their finan­ cial picture, from which management could make decisions. Most financial infor­ mation systems consist of three input components, a central database, and three output components, as shown in Figure 2a. The input components include data processing (accounting, inventory, sales, payroll), financial intelligence (stock mar­ ket performance), and internal audit. Out­ put components include forecasting, funds management, and control. The corporate financial information system interacts with other organizational components or departments such as pro­ duction, marketing, finance, and human resource management. For example, an increase in production will affect not only working capital (finance) but also the num­ ber of employees (human resource man-

(a)

Input components

Corporate database

Data processing External sources

a

Output components

Forecasting

Financial intelligence

Funds management

Audits

Control

Internal sources

L (b)

Input components

ι

ι

Corporate database

Output components

Corporate database

Output components

Internal sources

(c)

Input components

Internal sources

Figure 2. Types of information systems. (a) Financial information system: (b) Manufacturing information system, (c) Hospital information system. Analytical Chemistry, Vol. 67, No. 5, March 1, 1995 175 A

tions, a brute-force approach that occasionally worked. These limitations have now largely disappeared, and systems can and should be based on a requirementsdriven approach. Unfortunately, this message hasn't gotten totally through yet. The truth is that LIS are often viewed only from a technological point. Systems "planning" is usually limited to buying and installing off-the-shelf hardware and software. Leaps of faith are made that these components will fulfill the requirements; however, this "off-the-rack" approach typically results in systems that have a logical disconnect from the rest of the corporation, and only coincidentally do they meet the generic requirements of the laboratory. Another stumbling block to a requirements-driven, planned approach is that some organizations are psychologically unable to plan (5). This inability stems from a variety of behaviors, such as intoxication with the past, unplanned performance, or paranoia regarding change and its impact on job security. We have plenty of technological power, but how do we apply it? Realizing the goal of business-driven systems will require leveraging therighttechnologies, determined and implemented according to the right approach, which includes a basic understanding of the role, work flow, and information flow requirements for the laboratory within the corporation. The right questions to ask include: "What business am I in?" "Where do Ifitin within my corporation?" "Who are my customers?" In short, 'What is the goal of my function and how does it fulfill the objectives of my corporation?" Having a clear understanding of the answers to these questions will put you on the road to a successful LIS implementation.

the laboratory's part in a much larger picture—a business environment—and its need to support other business functions. Laboratories that fail to participate in this context cease to exist. All laboratories must strive to produce accurate, consistent, traceable, and timely results at minimum cost. Business-grade LIS, by definition, supports this goal, and all analysis and implementation must

The goal of the laboratory

clearly show how new or enhanced information systems will better support the goal.

All laboratories, regardless of industry (petrochemical, medical, forensic) or type (R&D, process control, diagnostic), produce results, either as raw data or information extracted from data. The laboratory produces these results for customers, who may be internal (in a process control environment, the customer is someone in manufacturing) or external (contract laboratory environments). Some laboratories have both internal and external customers. Common to all of these scenarios is

Technology and standards have developed to th§ point where the focmxan be shifted .to address people md business issues.

Requirements analysis

The need for implementation of a new LIS usually begins with the perception that the laboratory is not meeting its goal. The process often begins with informal discussions and may then proceed to a more formal dialogue. The most beneficial discussions are those that are painfully honest yet nonconfrontational; they should re-

sult in a clear statement of what the shortfalls are, their impact on the corporation, and the capabilities necessary to alleviate them. It is important to realize that at this stage these discussions are a crude first cut, and by themselves are not sufficient to proceed. Instead, they serve to commission a formal investigation called a requirements analysis. Requirements analyses expand earlier dialogues into formal and detailed statements of the functional requirements (the job to be done) and the technical requirements (how to do the job). Experience is key to the successful performance of this step, and external consultants, experienced in the industry but unbiased by subjective internal considerations, are crucial. Typically, requirements analysis includes defining affected business processes, including data flow, participants, time constraints, deficiencies, and current IT support (6); assessing these processes in terms of the corporation's goals, objectives, and critical success factors; assessing the functional requirements to define the technical requirements; defining one or more generic technical approaches for implementation (essentially a high-level design); assessing the initial, support, and maintenance costs (including staff resources) for each approach; assessing the relative benefits and impacts of each approach; and determining an approximate schedule for the implementation of each approach. A properly performed requirements analysis serves as a briefing for all levels of management and will spell out alternatives, costs, and relative benefits. Work and data flows will be clearly indicated and costs will be justified. There are no logical disconnects and the effect on the big picture is clearly stated. Management is then able to make an informed and rational decision about a course of action. Once that is selected, an implementation plan that specifies detailed resource requirements, schedules, milestones, sanity checks, training, documentation, information resource management (IRM) support requirements, and phasing with other ongoing projects will be prepared. Design and prototyping

The modern approach to implementation consists of iterative design and prototyp-

Analytical Chemistry, Vol. 67, No. 5, March 1, 1995 177 A

A/C

Interface

ing. Design consists of laying out the details of the system and is intended to eliminate leaps of faith. Design often proceeds hand in hand with a survey of available IT and should include prototyping so as to determine the design's suitability in meeting the technical requirements. Prototypes can be horizontal, providing a simplified subset of the capabilities of all components of the US, or vertical, providing a complete set of capabilities for only a few components. Successively more complete prototypes result in the full implementation of a system. Because specifications and standards on paper do not always translate into reality, prototyping is highly recommended. Prototyping also eliminates "paralysis through analysis" caused by overanalyzing and overdesigning a system. In such cases, the analysis and design phase may never be completed, a system may be designed that is so comprehensive that it cannot be built, or the system may become obsolete by the time it is built. There are no perfect systems, but those that fulfdl the majority of the requirements are usually successful.

Design includes assessing what can be obtained commercially and what hardware or software must be custom-developed. This assessment includes examining the tradeoffs between custom and commercially available components and selecting the approach that provides the best fit to the requirements at the least cost. This cost analysis is usually a refinement of the analysis performed during the requirements analysis. Management must be fully involved so that they are aware of the cost-benefit tradeoffs between alternative approaches. Wherever possible, think standards. Standards are the basis for componentbased systems in which smaller hardware and software systems become part of a larger system. However, a standardsbased approach to design is only a beginning, because standards (and the ways and degrees to which vendors implement them) can vary. Prototyping and planning a system in time-phased modules are two approaches that best lead to success. Because technological constraints affect your plans, they should ideally be identified during early prototyping.

Table 2. IT trends Technology

Current

Future

Physical networks

802.3 (Ethernet), Token-Ring, fiber-optic network backbones with twisted-pair segments to workstations

Inexpensive > 100 Mbps systems (asynchronous transfer mode, fast Ethernet)

Network operating systems

32-Bit operating systems with varying degrees of transparency to the user (Novell Netware, Windows)

32-Bit operating systems with full user transparency; remote management of the user workstation and network resources Transparent access provided by network operating system with boundary between LAN and WAN concealed from user

Wide area networks Generally accessible by (WAN) gateways but not transparent to user Workstations

Applications

Software development environments

178 A

80486 and Pentium workstations running Microsoft Windows; RISC-based systems (PowerPC) Mail and network integration commonplace within specific network and mail environments; can program extensively within applications (macros, Visual Basic) Discrete development environments (Paradox for Windows, Access) with integrated applications by DDE and OLE and application programming interfaces (API) such as MAPI and VIM

Independent, fully operating RISC-based systems; extensive off-the-shelf network integration Universal mail and network integration

Further blurring of the lines between development and applications environment because of universal APIs and object-oriented tools (FoxPro 3.0)

Analytical Chemistry, Vol. 67, No. 5, March 1, 1995

Key IT trends and technologies are shown in Table 2. Many technological standards, such as local area network architecture, workstation architecture (PC or Macintosh) and brand, office automation software, and groupware (electronic mail) may already be dictated within your corporate organization and are not subject to change unless strong and compelling arguments can be made to do so. All of these areas may be dictated by corporate standards and blanket corporate purchasing agreements. However, these standards will probably facilitate your efforts because users are already familiar with them and they usually have a support and training program in place. Other systems, such as document management, laboratory data management, and instrument interfaces may or may not be subject to your control. Author John W. Campbell once said, "Pioneering essentially amounts to finding new and horrible ways to die." This is especially true in pioneering new systems! Do not take standards and vendor claims on faith. Take for granted that new versions of hardware and software will have problems. Prototyping means "to build and test a system a piece at atime,with planned decision points for project continuation, redirection, or termination," and it is during this phase that you will discover where these problems are. Pieces are designed, built/assembled, and then tested in a real-world environment before committing to their deployment within the lab on a full-time operational basis. Managing the process

Where do users fit into this process? Everywhere! No one knows better what users do than the users themselves, and their feedback is critical. Users will better accept a new system that they have been involved with throughout the development process. From this group of users will emerge "power users" who will take ownership of successive levels of the prototype. They will move into the forefront of the implementation effort and begin to steer it in the right direction. Sometimes the users that accept this empowerment are not the ones that management would have predicted! Strong management and constant eval-

These efforts have paid off in minimal training and support requirements. As the system has grown, many of the users have become "gurus" in its use.

Data analysis tools Chemical information systems

Nonlinear curve fitting

Laboratory instruments

Microsoft Excel

Raw data

Input components

Implementation

Statistical analysis

Information publication Output components

Figure 3. The Glaxo system.

uation are required to keep analysis and implementation from turning into chaos. Much of this consists of doing nothing more than sticking with your implemen­ tation plan once you've made it. You must also work within the framework of your corporation's IRM organization. Unfortu­ nately, these organizations vary widely in their approach to working with their inter­ nal customers. Some of this difference is due to users' lack of understanding of the IRM organization's requirements and available resources. A good dialogue with your IRM organization results in its be­ coming a "guide and provider of enabling technologies." However, even if users have done all their homework, some IRM organizations are obstructionist and ef­ fective automation often occurs only with extreme difficulty. A c a s e study

Glaxo Research Institute is implementing a system (7) with an integrated set of user tools that illustrates the businessgrade approach. The project manager be­ gan with a requirement to increase pro­ ductivity via automation while at the same time reducing the burden on IT support staff. The requirements for the new sys­ tem included ease of use, flexibility to meet changing research needs, support for both PC and Macintosh environments, support for automation of data analysis,

and access to a variety of tools from a sin­ gle workstation. The system (Figure 3) was designed to be modular so that individual components could be easily replaced to leverage new technologies and meet new requirements as they developed. Glaxo selected Mi­ crosoft Excel as the basis because it was already a corporate standard and there­ fore familiar to the users, because it is available for both PC and Macintosh envi­ ronments, and because it can be pro­ grammed and extended to support the cus­ tomization required and access other components of the system. Excel's capabil­ ities were extended using tools such as C and Visual Basic. Where Excel was not the right tool, others were substituted, such as RS/1 and SAS for statistical analysis, Oracle for data access and storage, and MDL's ISIS for manipulation of chemical struc­ tures and access to chemical databases. Significant effort was placed on the design and prototyping of the system's user interface, with heavy user involve­ ment in the process. The goal for the user interface was to preserve the illusion that the user is working with a single product. For example, a user in Excel can select a compound name and a menu option that causes ISIS to display the structure within a spreadsheet cell. Even though ISIS did the work, the user is presented with the illusion that Excel did the work.

Imagine that you've done all the right things. You've defined your requirements based on an extensive dialogue between the users in the lab, users of the lab's data, management, and IRM, and you've de­ fined a set of capabilities that the system must provide to fulfill these requirements. These capabilities define a system that is the "85% solution" and that omits delays caused by occasional exceptions and rare occurrences. You've defined your technical requirements and entered imple­ mentation. Your business-grade system will be based mostly on off-the-shelf com­ ponents to which you will add functional capabilities with minor programming. Your iterative design and prototyping flows from the requirements and is pro­ ceeding nicely. But you're not done yet—as requirements are fulfilled, new ones will emerge. Corporate goals and ob­ jectives will evolve as new challenges and technologies enter the marketplace. So when is the job done? The most likely answer is never! Implementation is a jour­ ney without end. References

(1) Warner, S. A. Anal. Chem. 1990, 62, 94A-102A,389A-396A. (2) Dessy, R. E. Anal. Chem. 1992, 64, 733A-739A. (3) Nolan, R. L. Han. Bus. Rev., March/April 1979, pp. 115-26. (4) Madnick, S. The Strategic Use of Informa­ tion Technology; Oxford University Press: New York, 1987. (5) Cohen, W. Α.; Cohen, C. The Paranoid Corporation and 8 Other Ways Your Com­ pany Can Be Crazy; American Manage­ ment Association: Washington, DC, 1993. (6) Dessy, R. E. Anal. Chem. 1993, 65, 802A-809A. (7) Gill, J. Presented at Microsoft Tech*Ed, Phoenix, AZ, March 1994. Steven A. Warner is a biochemist who has spent the past 12 years as a systems engi­ neer implementing IT in both scientific and nonscientific environments. James W. Sywilok is a systems engineer with 12 years of experience in managing office automa­ tion. Address correspondence about this arti­ cle to Warner at Hydra Technologies, 5014 Roslyn Rd.,Annandale, VA 22003.

Analytical Chemistry, Vol. 67, No. 5, March 1, 1995 179 A