Science: Laboratory Research:

The laboratory automation systems has created a demand for similar automation for information management with faster turnaround of data and increased access to information resources. In the past decade, the implementation of new, computerized information management systems designed to meet these needs has forced laboratories to confront the challenge of changing the way they are doing their analytical activities.

However, few issues can create the same level of chaos as implementing the new Laboratory Information Management System (LIMS). In the generic sense, the LIMS is way for a laboratory to tracks and manages its information resources, and in particularly managing the data that represents the main products for the laboratory. Any change in the system that used for data-handling, will engenders some potentially traumatic changes in the way a laboratory operates. As per a LIMS consultant , there has never been a LIMS project that  has not been marked by a "trail of bodies"through out implementation period.

Changes in the management processes of the information are always traumatic because the laboratory staff will adopt new routines, and the laboratory management has to support and encourage the use of the new system in spite that these changes are generally costly, disruptive, and unwelcome the staff who are going in the short term to practice them directly. The long-term payoff, expected from LIMS is improved effectiveness and efficiency.

However, the laboratory should be willing to devote the time and the resources for planning, selecting, and implementing the new system. In addition, the LIMS version must be customized in the right manner to be compatible with  the work nature of the organization and integrated with the quality and business objectives of the laboratory.

Our laboratories, work as services groups for a Centeral Research& Development Complex with approximately 500 staff members providing analytical services in the areas of R&D, Customer Technical Support and Environmental Science, has been involved in three implementations of LIMS projects in the past five years. In 1998, we switched from a primarily minicomputer-based system developed in-house. In 1999, we upgraded to separate client/server systems to manage the R&D and customers samples data which are of Polymers, Chemicals and Fertilizers types. 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  LIMS products with descriptions of the server databases, server platforms, and client operating systems in supporting information. 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 petrochemical market, and those are mainly specialized systems for stability. Most petrochemical companies use the general LIMS and purchase a stability-testing module as an add-on. This is also true for most manufacturing markets.

On the other hand, the R&D market seems to be driving the LIMS market. R&D activities are rapidly automating, and LIMS may offer features such as an interface with "R&D projects and projects actual cost and software. In addition, there is a market for LIMS in R&D and technology consultant offices, which are rapidly being consolidated by managed-care firms. Because these may be much smaller units, many R&D LIMS packages are "high cost".

Components of an automated LIMS

Three major functional areas of the LIMS illustrate the relationship between the information management system and the other management processes in the laboratory.

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, and sufficient raw data must be maintained to reconstruct and defend the result.

Third, these results must be organized and reported in a manner that is understandable and meets the requirements of the end user.

The basic automated LIMS consists of an application that accesses a database of laboratory information and sample information. This application takes the data and applies the appropriate business logic, such as rules for the acceptibility of data, and writes the results to the database. The database typically resides on a server such as Oracle or SQL Server, although software such as Microsoft's Access may suffice for smaller systems. Typically, the modern LIMS application uses a client/server model, in which the database server is accessed by software user on remote machines that manipulate and return the data. The use of open database connectivity (ODBC)-compliant database engines by the LIMS allows other ODBC-compliant applications, such as Microsoft's or WordPerfect's office suites, to be used and expands the utility of the LIMS package.

A local area network provides communications between computers.

Five key actions form the core of the automated LIMS application.

First, data are captured or entered into the system. This data may be entered manually or captured electronically through such mechanisms as file parsers.

Second, the data are analyzed and organized. This process typically includes adjusting for significant digits and checking against limits.

Third, the reported data are kept on hold as completed, and wait for final and authorized approval,to released.

Fourth, the LIMS provides support for lab management functions such as sample tracking and workload assignment for Laboratory equipment and the staff.

Fifth, the system will contain a number of system management functions, such as the audit trails and archival functions.

The various functions will exist to some extent in all automated LIMSs; however, the breadth of functionality varies from system to system. Some, for example, include invoicing and accounting functions for lab management. Instrument interfacing and sample scheduling are other popular features often found in these systems.

Quality control modules are another popular feature .

Applications include the transfer of reports to the user via e-mail and online access to data through a Web interface with a server-side gateway application to the database. With the introduction of scripting tools such as Java, the Web browser can be used as a client interface to the LIMS server. One emerging option uses the Internet to access a database server managed by the LIMS supplier at their site.

Hardware components of the LIMS cannot be neglected. The modern LIMS will typically operate using a server computer, typically under the UNIX, Novell, or Windows NT operating systems and through a number of PC workstations. We recommend a server with plenty of memory and redundancy. Inadequate servers harm system performance with slow transaction speeds and unreliable performance. The servers need to be fast and reliable.

We use dual central processing unit machines with redundant power supplies and hard drive arrays. The servers should be protected by uninterruptable power supplies and adequate data backup systems.

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.

When we purchased our current LIMS packages, we totally replaced the existing hardware. This decision proved to be a great benefit.

The rapid evolution of computer hardware and software means that existing hardware may not be able to adequately support the new software therefore we had invested in a new and more powerful hardware at the time of implementation.

We eventually bought  new PC workstations 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 engineers, researchers, 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. In the early stages of implementing our old LIMS in 1997, inadequate input from the end users resulted in a system that could not support some tests with more than one user or with numerical results-features necessary for the operations in our laboratory. Major modifications were needed, delaying the launch of the system.

While planning for our LIMS, we met with representatives of each , function group in the complex. 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.

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, 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 laboratories management.

A key decision for the laboratories management 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 mid-sized 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 .

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 operations 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 Existing infrastructure, such as the computer hardware, instruments, and 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 .

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. 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.

For our environmental LIMS, we held a series of meetings with the in-volved 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 requirements 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 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 .

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 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 and whether the results met the test specifications .

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 short-term 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 long-term storage. (Recent price drops in writer technology have made CD-ROM 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. 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 .

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 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  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 . 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 . 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 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 researches projects accomplishes this task through a third-party 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 researches 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 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. 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-by-laboratory 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.