We have just begun the implementation of a new LIMS system. Hopefully this analysis will help to guide our laboratory as we move towards its implemenatation.
Analysis of a Laboratory Information Management System (LIMS)
Dan Bentley
MSIS 488
Dr Sauter
November 29, 1999
In the typical scientific laboratory there is a large amount of data that must be tracked and analyzed. In my current work setting we collect data from outside laboratories, analyze the data, and then return the data. We process thousands of samples per week. This makes tracking and sorting the data very cumbersome. We basically serve as a clearinghouse for data to be batched out to our customers, the independent researcher.
Our laboratory considers itself a high-throughput sequencing center. Our daily objective is to make the lab more automated. We are continually striving to use more robots or automated data entry. For automated data entry we use bar codes. Bar coding tends to have fewer errors in data entry. It also allows us to generate a greater amount of information for any given sample. The more we can automate the process the more samples we are able to put through the system.
Each of the independent researchers in the company is looking for a particular disease by identifying the disease-causing gene. Once the gene has been located the researcher must get the DNA sequence from the gene. That is our job. We at the sequencing center take the DNA sample, with the gene, and run the sample on our automated machines. Once the sample has been analyzed we put the analyzed sample, also known as the DNA sequence, into a database that the researcher can access. This is a very general idea of what the Sequencing Center does. The role of the Laboratory Information Management System (LIMS) is to keep track of this data.
The accuracy of the LIMS is crucial for an efficient and effective workflow. The
analyzed sample must be coordinated with the correct sample name that the researcher gives
to the Sequencing Center. This means that everything must be entered into the database
correctly. The data must also exist in a safe and accessible database. The data flow can
be characterized in the following context diagram.
We have just begun the implementation of a new LIMS system. Hopefully this analysis
will help to guide our laboratory as we move towards its implemenatation.
The history of LIMS [1] :
Originally, LIMS were developed in-house by organizations who wanted to streamline their data throughput and reporting processes. In-house LIMS can take considerable time and resources to implement. The need for a more immediate solution helped drive LIMS to the next stage in the 1970s. During this time, custom-built systems became available. These early custom systems were one-off solutions designed by independent systems development companies to run in specific laboratories.
Parallel to these custom-built LIMS implementations were the initial efforts to create commercial LIMS products. These extensive research efforts resulted in the first commercial solutions that were formally introduced in the early 1980s. Such commercial LIMS were proprietary systems, often developed by analytical instrument manufacturers to run on the instrument the manufacturer manufactured.
These commercial systems, while typically developed for a particular industry (such as the pharmaceutical industry), still required considerable customization to meet a specific laboratory's needs. In particular, laboratories often expect -- and in many cases require -- very specific format and reporting requirements. However, such demands for customization increase the cost of the commercial LIMS and extend the implementation time.
Parallel to the rise in commercial LIMS was the increase in processing speed; the increase in third-party software capabilities; and the reduction in PC, workstation and minicomputer costs. These advantages have been transferred to the laboratory and LIMS environment.
As a result, the migration away from proprietary commercial systems toward an open systems approach is in full swing. Now, commercial LIMS offer increased flexibility and functionality.
The following chronology gives a view of the development of LIMS since computers began to replace notebooks in the lab.
LIMS Development [1]:
Pre-1982 Laboratory notebooks and handwritten reports/charts were used to track and report information. In-house information systems were configured by a few laboratories. Custom-built LIMS became available from third-party vendors.
1982 The first commercial LIMS, known as first generation (1G) LIMS, are introduced. These 1G LIMS placed laboratory functions onto a single minicomputer, providing greater lab productivity and functionality as well as the first automated reporting capabilities.
1988 Second generation (2G) LIMS become available. 2G LIMS used the available market technology of third-party commercial relational databases (RDB) to provide application-specific solutions. Most 2G LIMS relied on minicomputers, but PC-based solutions were beginning to emerge.
1991 The move toward open systems ushered in third generation (3G) LIMS, which combined the PC's easy to use interface and standardized desktop tools with the power and security of minicomputer servers in a client/server configuration.
1995 Fourth generation (4G) LIMS decentralize the architecture further. Processing can be performed anywhere on the network. Thus, all clients and servers can operate in either capacity depending upon the data load at any particular instance
Common issues for LIMS implementation:
Most LIMS products allow the laboratory to; register work requests; print analytical worksheets; monitor and communicate sample/technique backlogs; schedule work; acquire and store analytical data; monitor the quality of all analytical work; approve analytical data for client release; print and store analytical reports and invoices; protect the security of all data; track and locate samples in storage; track and communicate all quality control in the laboratory; provide laboratory management with production and financial statistics and with client information, e.g., names, addresses, sales figures, etc. [10] An appropriately designed and installed LIMS can quickly bring accuracy and accessibility to the flow of samples and data in any laboratory. The real value of a LIMS is the ability to maximize sample throughput and minimize labor costs.
Laboratory throughput is improved in a number of different ways. The most obvious gain in productivity occurs through the elimination of data entry via on-line instruments. Also, there will be a significant decrease in data entry errors. Finally, the up-to-date sample in-flow data available from a typical LIMS allows laboratory supervisors and bench personnel to better schedule analytical work, minimize "downtime" and maximize batch size. Some other effects are that there are better visible quality control checks and centralized data. [11, 16, 17] The ability to monitor, track and communicate data and quality control information gives the laboratory the tools to improve methods and work practices. The end result is that people in the lab able to process more samples per hour worked.
Design/Scoping Process
The design/scoping stage prior to acquiring our LIMS has involved the review and analysis of available software/hardware packages as well as the definition and documentation of our laboratory’s requirements. The error here is could be that bench personnel are excluded from the process. To resolve this problem we have had frequent meetings with the personnel in our lab.
Some laboratories might go into a LIMS program believing that future requirements for bench level supervision will be reduced or eliminated. It has been recognized by many that LIMS is simply a tool and as such cannot manage the laboratory or take the place of personnel supervision. A LIMS will effectively provide current, reliable and complete operational data. The easy access to accurate data allows management to significantly enhance the quality and speed of decision making. Decision making becomes based more on fact rather than instincts.
Many LIMS products tend to function more like accounting or financial databases. [11,12,15]This could be related to the educational and work experience of most software professionals. The demand for financial and accounting database packages means that the software industry is more familiar with this type of requirement than with a highly technical application like a LIMS. Thus, the average software professional does not usually have the background to effectively interpret a laboratory’s requirements. This communication problem can manifest itself in LIMS systems that do not easily fit into laboratory operations. Often the laboratory must significantly alter procedures and work flow in order to conform to the LIMS. This requirement for wholesale change significantly complicates LIMS installations and it might have poor acceptance and commitment support personnel to the project.
A similar problem often occurs in large organizations with dedicated Information System (IS), departments. Significant conflict and problems can arise when IS personnel recommend the most up-to-date hardware or software architecture regardless of the functionality, fit or overall cost to the laboratory. [4] The end result of this process is that the laboratory must undergo significant change in order to conform to the product purchased. In the extreme case laboratories can wind-up having to increase overhead, e.g., more data handling, in order to use LIMS systems that have been designed not for the laboratory but for the accounting or production departments.
The keys to success are flexibility, adaptability, ease of evolution and support, and most importantly overall system speed. [5] The speed issue is very critical as bench personnel will not use something that is slow or awkward. If the system saves bench personnel time they will quickly "buy into" the project and aggressively move the process forward.
The key in any LIMS development should be to achieve a majority of the desired functionality without compromising system speed. Most laboratories need time to assimilate a LIMS before being able to take full advantage of all of its features. As a result of this ‘break-in period’ the more complex features can usually be postponed a year or two without affecting the success of the program. [17] This implementation delay may also allow laboratory personnel the chance to provide more input into the critical final stages of system optimization.
Installation Phase:
The goal of any LIMS installation must be to acquire a system that will make the jobs of bench personnel easier and thus increase the efficiency of the organization. [13, 17] In order to be successful, the LIMS system must be accepted and welcomed by the bench personnel. Often the first contact front-line personnel have with the new system is during installation, long after all decisions have been made. This situation often leads to significant software and LIMS configuration problems that require major software re-writes, hardware retro-fits and/or disruptive organizational changes. In addition, analytical and support staff are more likely to resist the new system if they have had little input into it’s design and operational characteristics.
The installation phase of a LIMS program is critical to the overall success of the project. It is during LIMS installation that personnel must be taught how to use the product and where the software designers get their first view of how the LIMS will fit into and function in the laboratory. The installation phase of a LIMS project can take from weeks to months depending on the size of the laboratory and the complexity of the project. [2]
Some of the problems:
Rushed or Incomplete Installation
LIMS installation can be expensive. As a result laboratory management has a tendency to reduce costs by shortening the time spent on-site by the design team. In addition, several installation phases may be required in order to allow laboratory personnel time to learn and apply each LIMS feature before adding the next. Effective communication between the bench personnel and the design team is key to ensuring a successful project. The best way to facilitate this communication is by extending and phasing the installation.
No Staff Training
Bench personnel must be taught how to use the LIMS. As with any subject laboratory staff must be taught progressively so that personnel have a chance to use and apply what they learn. In laboratories where the LIMS training has been available and sustained the staff will be using the LIMS at a similar level. [13] This consistency of approach builds team work and staff efficiency increases. In laboratories where training has not been a priority, staff will be using the LIMS at different levels. This situation can create a great deal of competition in the laboratory as turf wars erupt over the adoption of new or unused LIMS features. Poorly trained staff fear the new features and as a result delay or resist their implementation.
Unrealistic Implementation and Economic Targets
Another serious mistake made by many organizations is a desire to move too fast. The installation of a LIMS is a major step for any laboratory as it affects all aspects of the operation. As a result time must be built in to allow analytical and support personnel the opportunity to learn and apply the technology as well as adjusting their work habits. Rushing the process to meet pre-defined targets will only create confusion and fear among the staff. This will lead to mistakes and stress as they are confronted with the prospect of rapid change.[4]
All laboratories are dynamic organizations in a constant state of evolution. The pace of this change has also increased as technology improves at an ever-increasing rate. Thus the success of any LIMS hinges on the ability of the system and the laboratory to anticipate and respond to this rapid growth and change in technology.
Some of the problems:
Lack of Technician Access to the LIMS
A problem that arises in some organizations as laboratory and support staff begin to use the system is a failure to recognize and remove access bottlenecks. For a LIMS to function smoothly all personnel must have their own access point. Access expansion can usually be spread over six to eighteen months as the laboratory assimilates the LIMS and usage increases.
Poor Feedback Mechanism
As noted above communication is a key component of any successful LIMS project. It is important that laboratories make sure that a well developed feedback mechanism is put in place during the installation of a LIMS so that laboratory personnel can bring forward problems and see quick resolution. Staff often hesitate to bring forward complaints and will instead work around the problem. One successful approach that has been used by organizations to solve this problem has been regular procedural audits. [6] The process required to perform an audit usually brings to light LIMS defects or problems that staff have been coping with. This is has already been implemented for other laboratory procedures in our lab.
Conclusion:
The laboratory is not unlike many other business environments that are supported by
information technology. There are common difficulties in implementation of an information
system in all industries. The purpose of this analysis was to point out common problems
involved with implementation as they relate more specifically to a laboratory. Hopefully
this analysis will serve as a guideline as we begin the process of implementing LIMS.
1.
"A Brief History of LIMS", Dr Gerst Gibbon, published in Laboratory Automation and Information Management Issue 32, 1996, pp 1-5.2. "Data Unlimited International releases Starfruit DNA software", published in NetSci , Vol 4, April – May.
3. "Recent Applications of Associated Analysis Protocol" , Edward H. Kerns*, Kevin J. Volk, Mark E. Hail, Jeffrey L. Whitney, Robyn A. Rourick, Steven E. Klohr, and Mike S. Lee, published in Journal of Management of Information Systems, (May, 1997).
4. "Automation of Structure Analysis in Pharmaceutical R&D", Gary A. McClusky, Brian Tobias, Robert Short, Dana DeJohn, Leslie McMacken, Carmen Faraianu, and Bryan Judge, published in Journal of Management of Information Systems (June, 1997).
5. "Beyond Accuracy: What Data Quality Means to Consumers.", Wang, Richard; Strong, Diane, Journal Of Management Information Systems. Vol 12., No. 4, Spring 1996 p. 5-33.
6. "Turning around troubled Software Projects", Keil, Mark; Robey, Daniel, JMIS, Vol 15, No 4, Spring 1999, p63-88.
7. "Assessing Data Reliability in an Information System", Sai, Naichman; Sia, Siew Kien, JMIS, Vol 4, No 2 Fall 1987, pp34-44.
8. "LIMS Framed", www.users.fast.net/~miller/lims.html , accessed 9/20/99, updated 9/19/99.
9. "Lab Master; Lims Program", www.dynamicdatabases.com, accessed 9/26/99, updated NA.
10. "Computing Solutions", www.labsoftlims.com, accessed 9/26/99, updated NA.
11. "Labvantage", www.lims.com, accessed 9/20/99, updated NA.
12. "Labware Product Overview", www.labware.com, accessed 9/27/99, updated 9/27/99.
13. "LIMS", www.atlab.com/lims.html,accessed 9/25/99, updated NA.
14. "LIMS Publications", lims.mech.nwu.edu/publications/format.html, accessed 9/23/99, updated 9/23/99.
15. "Telecations LIMS family", www.telecation.com/products, accessed 9/23/99, updated NA.
16. "Laboratory Data Management Systems", www.beckman.com/Beckman/biorsch/prodinfo/lao/laohome.asp, accessed 9/23/99, updated November 1999.
17. "LIMS and Sample
Tracking Systems", www.chemsw.com/lims.htm,
accessed 9/23/99, updated November 1999