product review
Implementing LIMS: A “How-To” Guide A laboratory must devote the necessary time and resources to planning, selecting, and implementing a new system. George Avery, Charles McGee, Stan Falk, Arkansas Department of Health
A
utomation in the laboratory has created a demand for similar automation of information management with faster turnaround of data and increased access to information resources. Within the past decade, implementation of new, computerized information management systems designed to meet these needs has forced laboratories to confront the challenge of changing the way they do business (1, 2). However, few issues can create the same level of turmoil as implementing a new laboratory information management system (LIMS). In the generic sense, the LIMS is how a laboratory tracks and manages its information resources, particularly the data that represents the laboratory’s product. Any change in the data-handling system, therefore, engenders some potentially traumatic changes in the way a laboratory operates. As one LIMS consultant puts it, there has never been a LIMS project whose implementation has not been marked by a “trail of bodies”. Changes in information management processes are also traumatic because the laboratory staff has to adopt new routines, and the laboratory management has to accept, support, and encourage change. These changes are generally costly, disruptive, and unwelcome to those who have to deal directly with them in the short term. The long-term payoff, one hopes, is improved effectiveness and
efficiency. However, the laboratory must be willing to devote the necessary time and resources to planning, selecting, and implementing the new system (3). In addition, the LIMS has to be compatible with and integrated with the quality and business objectives of the laboratory. Our laboratory, a public facility with approximately 130 staff members providing analytical services in the areas of clinical and environmental science, has been involved in three implementations of LIMS projects in the past decade. In 1990, we switched from a primarily manual, paper-driven system to a minicomputer-based system developed in-house. In 1995, we upgraded to separate client/server systems to manage the clinical and environmental data. In each case, the process was traumatic and prone to disruption and miscalculation; however, in the end, it has improved our ability to serve our clients and provide quality data in a timely and cost-effective manner. This Product Review provides some practical advice on what to consider when implementing a LIMS. There are also three tables listing 92 LIMS products with descriptions of the server databases, server platforms, and client operating systems in supporting information (available free on the Web at http://pubs. acs.org/ac). The tables are divided among general, clinical, and specialized LIMSs. Manufacturer contact
information, including Web addresses, if available, are also found in these tables. Despite the large number of LIMS products listed, others may exist. Interested readers should contact vendors for further information. Few LIMS systems are targeted only at the pharmaceutical market, and those are mainly specialized systems for stability testing (see specialized LIMS table). Most pharmaceutical companies use the general LIMS and purchase a stabilitytesting module as an add-on. This is also true for most manufacturing markets, such as chemical companies. On the other hand, the hospital market seems to be driving the clinical LIMS market. Hospitals are rapidly automating, and clinical LIMSs may offer features such as an interface with “e-charting” and insurance billing software. In addition, there is a market for LIMS in medical doctors’ offices, which are rapidly being consolidated by managed-care firms. Because these may be much smaller units, many clinical LIMS packages are “low cost”. Some can be purchased for as little as $2500, including a single workstation.
Components of an automated LIMS Three major functional areas of the LIMS illustrate the relationship between the information management system
J A N U A R Y 1 , 2 0 0 0 / A N A LY T I C A L C H E M I S T R Y
57 A
product review
and the other management processes in the laboratory (4). The first, sample tracking, demonstrates that the appropriate work is properly completed and that the workload is properly managed. This can be as simple as correlating a sample container to an entry in a notebook, or as complex as a multistage custody chain tracked with sophisticated bar-coding equipment. Second, the sample analysis must be documented,
data are analyzed and organized. This process typically includes adjusting for significant digits and checking against limits. Third, the data are reported. Fourth, the LIMS provides support for lab management functions such as sample tracking and workload assignment. Finally, the system will contain a number of system management functions, such as the audit trails and archival functions (5). The various functions will exist to some extent in all automated LIMSs; Five key actions form the core of however, the breadth of functionality varies from system to system. the automated LIMS application. Some, for example, include invoicing and accounting functions and sufficient raw data must be mainfor lab management. Instrument intertained to reconstruct and defend the facing and sample scheduling are other result. Finally, these results must be popular features often found in these organized and reported in a manner systems. Quality control modules are that is understandable and meets the another popular feature (6). requirements of the end user. Emerging features seen in a number The basic automated LIMS consists of of LIMS packages are Internet protocols an application that accesses a database of such as hypertext transfer protocol (http) laboratory information and sample inforor “sendmail”. Applications include the mation. This application takes the data transfer of reports to clients via e-mail and applies the appropriate business logic, and online access to data through a Web such as rules for the acceptibility of data, interface with a server-side gateway and writes the results to the database. The application to the database. With the database typically resides on a server such introduction of scripting tools such as as Oracle or SQL Server, although softJava, the Web browser can be used as a ware such as Microsoft’s Access may suffice client interface to the LIMS server. One for smaller systems. Typically, the modern emerging option uses the Internet to LIMS application uses a client/server access a database server managed by the model, in which the database server is LIMS supplier at their site. accessed by client software on remote Hardware components of the LIMS machines that manipulate and return the cannot be neglected. The modern LIMS data. The use of open database connectivi- will typically operate using a server comty (ODBC)-compliant database engines puter, typically under the UNIX, Novell, by the LIMS allows other ODBC-compli- or Windows NT operating systems and ant applications, such as Microsoft’s or through a number of PC workstations. WordPerfect’s office suites, to be used and We recommend a fairly robust server expands the utility of the LIMS package with plenty of memory and redundancy. (1). A local area network provides comInadequate servers harm system permunications between computers. formance with slow transaction speeds Five key actions form the core of the and unreliable performance. The servers automated LIMS application. First, data need to be fast and reliable. are captured or entered into the system. We use dual central processing unit This data may be entered manually or machines with redundant power supplies captured electronically through such and hard drive arrays. The servers should mechanisms as file parsers. Second, the be protected by uninterruptable power
58 A
A N A LY T I C A L C H E M I S T R Y / J A N U A R Y 1 , 2 0 0 0
supplies and adequate data backup systems. We use digital audio tape drives for short-term backup and archive the databases to CD-ROM for permanent storage. A typical 10-Mbps network is generally adequate for most LIMS applications. Installing the network and cables can be a major issue depending on the laboratory’s physical plant. This has been the case in our laboratories, where the building’s architecture does not allow easy paths for cables between floors or rooms. When we purchased our current LIMS packages, we sought systems that would run on existing hardware. This decision proved to be a serious mistake. The rapid evolution of computer hardware and software means that existing hardware may not be able to adequately support the new software. We recommend that the laboratory invest in new, more powerful hardware at the time of implementation. We eventually were forced to purchase new PC workstations because existing machines proved unable to handle a large volume of work.
Implementation Planning is the first step in implementing a new LIMS, and the first step in this process is to evaluate the laboratory’s information resource needs. If there is already a LIMS, how does it operate? How does it interface with other business and quality systems? What works well, and what weaknesses are observed? Users, including analysts, clients, and managers, need to be involved from the beginning. They are the people who will have the best perspective on how the new system should work. Additionally, early involvement can help build user acceptance of the change. Resistance to change may be the biggest cause of failure in implementing a new system. The planning stage provides an opportunity to anticipate problems and educate the users on the project (7). In the early stages of implementing our minicomputer-based system in 1990, inadequate input from the end users resulted in a system that could not support tests with more than one analyte or with numerical results—features necessary for the
product review
operations in our laboratory. Major modifications were needed, delaying the launch of the system. While planning for our environmental LIMS, we met with representatives of our largest client, the state drinking water program. We examined problems with the current system, such as transcription errors; looked at desirable new features, such as interfacing with regulatory databases; and kept the representatives informed with regular progress reports. A corollary benefit was that they championed the project. Management commitment is an absolute requirement. Managers need to clearly delineate the goals to be obtained by implementing the LIMS; communicate that the change is desirable; encourage cooperation and coordination among the users, clients, and system implementers; and ensure that adequate financial and staff resources are available to implement the system. The project will fail without these commitments from the laboratory manager. A key decision for the laboratory manager is the assignment of the project manager. The critical issue is how “ownership” of the change is assigned— responsibility and authority must be clearly delineated. In most small to midsized laboratories, the project manager is probably the system administrator who will manage the LIMS. The manager needs to be familiar with laboratory operations and information technology, and, in the early stages of the project, be able to translate data management objectives into specifics that will have little adverse effect on laboratory operations. Planning requires a good understanding of the laboratory operations and the culture. The project manager must clearly communicate the project goals and status to the laboratory managers and other users (8). The system administrator needs to be sufficiently trained in information technology to be able to install, configure, and manage the LIMS and supporting hardware. For any but the smallest laboratory, system administration is likely to require at least one full-time position. We have found that the general opera-
tions of a computer-based LIMS require a knowledge of computer networking, database administration, and some level of programming knowledge, including structured query language (SQL). When a laboratory analyst is assigned to administer the system, computer training is essential. In addition, the administrator must know the culture and business practices of the laboratory.
Planning for change Planning for the LIMS involves clearly defining the information flow, the structure of the generated data, and the user requirements. Flowcharts showing where and how data are generated, transferred, and stored in the system are very useful. These charts should include decision points in the process, such as QC data evaluations, or requirements for supervisory approval before the release of reports (Figure 1). Existing infrastructure, such as the computer hardware, instruments, and
The laboratory will probably need to make tradeoffs between cost and features. Flexibility is essential because every unachieved goal provides a focus for doubters to object, which can delay and disrupt implementation. Nevertheless, the laboratory must ensure that it allocates sufficient resources to implement a workable solution. Inadequate funding could lead to a system that cannot meet expectations, lacks essential features, and delays implementation (11). For our environmental LIMS, we held a series of meetings with the involved parties and drafted a document outlining the features that were desired. Our budget for the project was established before we defined the system requirements, which proved to be a problem when our draft specification turned out to be more ambitious than our budget allowed. We drafted a model specification but overlooked establishing priorities. Unfortunately, when minor require-
Resistance to change may be the biggest cause of failure in implementing a new system. computer network, needs to be inventoried to gauge the scope of the project. This evaluation also helps the laboratory define the new system requirements and better understand its business processes. Failure to do this will likely result in the design or purchase of a LIMS that does not meet the laboratory’s needs (9, 10). The second step is to define the expectations for the system. It is very easy to imagine ways in which the lab work flow can be automated. However, ensuring that expectations stay in line with what can reasonably be achieved is difficult. At this step, budgetary and personnel considerations are projected. In drafting the specifications, the laboratory should identify the issues and features that are critical and distinguish them from desirable but nonessential features.
ments were not met, this became the basis for complaints that “the system doesn’t work.” Responding to this situation required strong leadership by the laboratory managers, but was not as effective as if the laboratory initially accepted and understood the need for flexibility and following priorities.
Validation and disaster preparedness LIMS validation is an important issue for many laboratories, particularly those that operate in regulatory environments, such as compliance with Good Automated Laboratory Practices (GALP). The laboratory should develop a formal plan for validating the system, including the test data and acceptance criteria. The validation plan should be established before purchasing the LIMS and include how the validation
J A N U A R Y 1 , 2 0 0 0 / A N A LY T I C A L C H E M I S T R Y
59 A
product review
Collection report data Collector location Date/time Test requested
Sample collected in the field
Sample receiving
Data from collection report entered into LIMS Also date/time received, accepted by
Laboratory
Data entered for QA samples and real samples Results, date of analysis, links between QA samples No
No Quality assurance
IS QA data within limits?
Yes
Yes
Generate reports
Report: Customer, date/time of collection, collector, receiver, date/time received, test/analyze/result, date of test/date of result
Mail to client FIGURE 1. Sample workflow diagram.
will be documented and how the records will be retained. The LIMS must be extensively tested to ensure that it processes and stores the data properly. Evaluation is an ongoing process to ensure that configuration changes work and that data have not become corrupted. The system needs to include a change control procedure and audit trail to document changes (4, 12–14). The first step in testing the system is to use normal, boundary value, and invalid data sets. Outlying data must be handled properly, and invalid data should be trapped by the software. Data validation is generally conducted with an off-line system using simulated data, which protects the integrity of the online
60 A
system and databases. The validation plan should test all input and output points, such as data entry screens, printers, and system transfers, to ensure that the data are transferred properly by the system. Before implementation, the laboratory should perform a system “stress”, which is a dynamic test using larger data sets that focus on possible weak points in the system. We found, for example, that although existing PC workstations were adequate to handle the small (1–2 samples) data sets used to configure our environmental LIMS, they were inadequate for processing the larger data sets routinely seen in our operations. Records need to be retained and labeled with what was being tested
A N A LY T I C A L C H E M I S T R Y / J A N U A R Y 1 , 2 0 0 0
and whether the results met the test specifications (15). The laboratory will need to establish a backup and data recovery plan to assure system security in case of an emergency. We protect the electrical components of our network and servers with an uniterruptible power supply and line-conditioning equipment. We have built redundancy into the servers, including RAID (redundant array of inexpensive disks) drive technology to protect against shortterm loss due to a hard-drive failure. We use a tape system with off-site storage for short-term backup protection, and we archive databases to CD-ROM for longterm storage. (Recent price drops in writer technology have made CD-ROM
product review
storage particularly attractive.) Another solution is to ensure that the LIMS source code is held in escrow to protect the laboratory against the possible loss of support by the vendor.
Finding a vendor Once the system requirements and budgetary limits are defined, the laboratory should examine the market to determine whether an off-the-shelf solution exists. With over 100 LIMS available on the market, it is likely that one exists (see supporting information). In such a large market, it will probably require considerable effort to evaluate the systems and find one that best meets the laboratory’s needs. The laboratory process information and draft specifications should be discussed with the vendors in detail to ensure that the system purchased can meet those requirements. The alternative to purchasing a commercial LIMS is to create one in-house. The advantage is that a homemade system can be designed exactly to meet the laboratory’s specifications. However, developing a custom LIMS is an expensive process, requiring significant validation and testing, particularly if GALP requirements are an issue, and the laboratory must support the system itself. The timeframe for implementation will certainly be longer. And, for the small lab, the process can be a nightmare. An early homemade minicomputer system used by our lab proved to be such a case, despite our sizable data processing and programming department. Whether a laboratory decides to purchase a commercial system or write one, it is critical that the decision is made systematically based on a careful examination of the laboratory’s needs and expectations (16). In recent years, our laboratory has purchased separate systems for our clinical and environmental applications. We researched the market through the literature and demonstrations at meetings such as Pittcon. Representatives were invited to our facility to demonstrate their systems to users, managers, and clients and to discuss our requirements. On the basis of that work, several systems were identified
that met most of our needs. Several issues arose during this process that affected our decision. Given a tight budget, we had to be conscious of the costs associated with the underlying database engine, including the licensing fees for clients. Our environmental laboratory system had to be configurable without requiring a lot of programming expertise, as the administrator was a chemist with minimal programming skills. We looked for a system with an interface that appealed to the users. Our clinical vendor had to be familiar with diagnostic instrumentation not found in the typical commercial chemistry laboratory. We checked references regarding the vendor’s software and installation support and visited laboratories already using the system. Implementation and ongoing technical support are critical features to consider. A LIMS vendor will probably provide as much installation support as the laboratory cares to pay for, although the level of support and price will vary. We have used technical support extensively from both of our vendors. The vendor of our clinical system has gone so far as to rewrite significant portions of the applications core code. The environmental system was purchased with the intent of being configured by our system administrator, and basic implementation support consisted of installation and training.
Configuration issues Once the LIMS is installed, it will generally require additional work before it is ready for use. The administrator will need to populate data dictionaries, configure interfaces, design reports, and test the system to ensure that it functions properly. At this point, detailed information on lab processes and the feedback from the users becomes most important. We recommend that the laboratory installing a new LIMS discuss these issues with the vendor. Populating the data dictionaries is a sizable task. The laboratory must define items such as sample types, tests, instruments, user IDs and passwords, and more. Any item that the lab desires to be
accessible through a “pick list” must be entered into the appropriate dictionary. For example, we have a large number of fixed sampling points that had to be entered in the environmental LIMS for our drinking water samples, and we have numerous health care providers who collect specimens that needed to be entered into the clinical system. The benefit of these dictionaries is that uniformity is achieved in the data, but maintaining the dictionaries is a major task. Data definitions will also be critical in the migration of data from older systems to the new LIMS. Data conversion can add significantly to the complexity of implementing a LIMS project, particularly if the older system is not well documented. Converting the older data and the semantics of the data will require a thorough understanding of the underlying structures of the old system (17). Data migration services are often available as a part of the vendor’s implementation support package. Many systems allow users to establish custom configurations for interfaces such as data entry screens. Users can be surprisingly resistant to working with poorly designed interfaces. The interface design should facilitate easy interaction with the data (18). However, this often isn’t enough. We use collection report forms in our water program that identify all the samples taken for various tests at a given locations and times, then we assign an individual accession number to each. We designed the screens so that only a label and the “test requested” had to be entered for each sample, saving a significant amount of data entry. The users revolted, however, because previously all samples collected for a specific test were numbered in sequence, and now all samples for a specific location are in sequence. We had underestimated the resistance to change, and a significant effort was required to demonstrate that the changes reduced workload. Connecting the LIMS with other computer systems can be very difficult with proprietary systems, and, therefore, we recommend the purchase of software
J A N U A R Y 1 , 2 0 0 0 / A N A LY T I C A L C H E M I S T R Y
61 A
product review
components that have open architecture and are widely available. The vendor should also provide a fully documented definition of the LIMS database structure, which is essential for accessing the stored data. Moreover, the data definition provides a glimpse of how the software works and greatly aids in solving problems. In many cases, it enables the lab to determine why an error occurs and fix it by “tweaking” the configuration. In others cases, the lab will be able to clearly identify a problem to the vendor’s technical support staff and solve it quickly. Interfacing instrumentation to a LIMS can be a complicated process. For example, our environmental project accomplishes this task through a thirdparty commercial product, which parses the text files produced by the instrumentation software into a form that is read by the LIMS. Similar functionality can be accomplished through relatively simple programs in a scripting language such as Perl. The clinical project, in contrast, has a parsing functionality built into the core code, which is on another level, is effectively an interface for our older system. Some packages allow even tighter integration of the LIMS and instruments. A potential problem with tightly integrated systems is that instruments not supported by the LIMS vendor cannot be interfaced. In general, the laboratory will want to modify a vendor-provided report or create a series of custom reports. The real power of the automated LIMS is the ability to query and organize the data rapidly. Programming and reporting tools, such as InfoMaker and Crystal Reports, have made this an easy task. For example, we created a report that reduces the several-hour manual task of compiling monthly workload statistics to less than five minutes. The greatest difficulty has been in testing and debugging the underlying SQL scripts. SQL code tends to be unforgiving of errors and executes with an annoying degree of literalness. It is our experience that training on the LIMS best occurs in increments.
62 A
Because a modern LIMS contains a bewildering array of features, we have found that it is best to teach the users to master the basic data entry and retrieval functions and then move on to more advanced features. The system administrator conducts a demonstration, and then personnel are assisted through their initial attempts to use the system using simple checklists and flowcharts for reference. Training and documentation are particularly critical when implementing a new system, because the user cannot obtain assistance from an experienced colleague. Similarly, we implement a new system test-by-test and laboratory-bylaboratory to allow more interaction with and support for the unfamiliar system. We have tried group training, but the results have been unsatisfactory. Support and training will be major ongoing issues throughout the life cycle of the LIMS. In the process of installing and implementing the system, even the best prepared laboratory can expect to encounter unforeseen delays and interruptions in the normal work flow. Planning can minimize these problems. The laboratory management must expect that these problems will occur and be ready to take an active role in mediating the disputes that will arise. The laboratory management has to maintain this commitment throughout the lifecycle of the LIMS. A successful LIMS implementation will involve an ongoing process of evaluation and modification. With careful attention and a sincere commitment, implementation should result in significant improvements in the way the laboratory does business.
References
A N A LY T I C A L C H E M I S T R Y / J A N U A R Y 1 , 2 0 0 0
(1) (2) (3) (4)
Paszko, C.; Miller, T.; Vranken, R. Environ. Test. Anal. 1998, 7(5), 22–24. McDowell, R. D. Anal. Chem. 1993, 65, 896–901. Gillespie, H. Sci. Comp. Automation 1992, 8(12), 48–54. Weinberg, Spelton, and Sax, Inc. GALP Regulatory Handbook; Lewis: Boca Raton, FL,1994.
(5)
(6)
(7) (8)
(9) (10) (11)
(12)
(13) (14)
(15)
(16) (17) (18)
ASTM LIMS Guide. In 1994 Book of ASTM Standards; American Society for Testing and Materials; 1994; Vol. 14.01. Hinton, M. D. Laboratory Information Management Systems; Marcel Dekker: New York, 1995; pp 7–53. Persoon, T.; Schwabbauer, M. Med. Lab. Observer 1995, 27(7), 32–36. Hutchinson, D. Total Quality Management in the Clinical Laboratory; American Association of Bioanalysts: St. Louis, MO, 1994; p 27. Roseman, E. Med. Lab. Observer 1995, 27(5), 36–38. Gibbon, G. A.; Golden, J. H. Today’s Chemist At Work 1996, 5(9), 14–18. Starling, G. Managing the Public Sector; Wadsworth: Belmont, CA, 1993; pp 206–207. Huber, L. Validation of Automated Computer Systems; InterPham Press: Buffalo Grove, IL,1995; pp 4–58. Scott, C.; Hengesbaugh, J. H. Med. Lab. Observer 1998, 30(8), 32–40. Steane, S., et al. Responsibilities in Implementing and Using a Blood Bank Computer System; American Association of Blood Banks: Arlington, VA, 1989. Laboratory Instruments and Data Management Systems: Design of Software User Interfaces and End-User Software Systems Validation, Operation, and Monitoring; Approved Guideline; NCCLS: Wayne, PA, 1995; GP-19A. Winstein, D. Adv. Admin. Lab. 1998, 7(1), 40–43. Skjei, E. CAP Today 1998, 12(11), 44–50. Phillips, J. B.; Price, G.; Phillips, A.; Bradley, M. L. Sci. Comp. Instrument. 1999, 16(9), 49–52.
George Avery is a chemist, Stan Falk is the director, and Charles McGee is a senior programmer/analyst in the quality assurance, data automation, and safety section of the public health laboratories at the Arkansas Department of Health. Avery is also an adjunct professor at Pulaski Technical College and a member of the regulatory coordination committee of the National Environmental Laboratory Accreditation Conference. Avery works on issues involving environmental testing and LIMS. Address correspondence about this article to Avery at Division of Public Health Laboratories, Arkansas Department of Health, 4815 West Markham, MS 47, Little Rock, AR 72205 (
[email protected]).
