Buying a laboratory information management system (LIMS) is a major undertaking, and it is critical that the system selected fulfils not only all of the laboratory’s current requirements but also allows for future development. Surprisingly perhaps, there are very few LIMS available today that are flexible enough to be good in five years, in ten years, and so on. This article provides an overview of the selection and implementation process. It should be remembered that software offers a flexibility found in few other products, so it is essential that customers ensure that the software in its delivered form can really meet the required specifications. It is no good if you find that the software is capable of doing something that you want but only at extra cost! Similarly, many people just assume that the software has a particular feature or function when comparing software specifications from different vendors. In addition, it should be realized that the responsibilities for a successful LIMS project do not lie solely with the supplier—the customer also has significant responsibilities as well!
Where to start?
Given that a detailed, thorough, and disciplined approach is required in the purchase of a LIMS, it makes sense for the customer to appoint an internal “LIMS champion” for the project who documents all actions and activities. It is good practice to have a backup person in place who is kept up to date on the project and can step in should the champion be unavailable because of illness or even leaving the organization. The first activity is to identify the benefits that a LIMS would bring to the organization. These should not be restricted to improvements in laboratory-based functions, as a LIMS is potentially a business management tool if the correct one is purchased. This list of benefits can be converted to a requirements document that specifies the features and functions needed. Inputs from laboratory staff and others likely to benefit from the implementation of a LIMS should also be encouraged. Benefits that are quantifiable are those that will most help the case for investment in a system.
Below are just a few examples of benefits that should be considered. A much more detailed example list is available elsewhere.1
• It reduces/eliminates the need for paper and laboratory notebooks.
• It speeds up the retrieval of information.
• It allows fast production of regular laboratory reports that can be used to identify the workload by person, by instrument, by test, by customer, etc. It can also include other data such as laboratory costs, data trends, outstanding work, and sample turnaround times.
• Clients can register their own samples, monitor sample status, and search for approved results using a web interface to the LIMS. Make sure that the LIMS can safely segregate the data for each customer.
• Transcription of data can sometimes be eliminated. High sample throughput instruments/systems can link to the LIMS for direct capture of data. Bidirectional links allow the transfer of a sample list to the instrument/system.
• It introduces intuitive, easy-to-use workflows to match all workflows used in the laboratory. The system should allow new workflows to be added easily without dependence on the vendor.
• Tracking the location of each sample and each sample movement effectively creates a chain of custody. The location of each sample is known at any given time.
• Time, date, and operator ID stamping of all data and result entries lead to improved traceability, adherence to enhanced quality procedures, and regulatory compliance.
• Management has immediate access to all data, reports, statistics, etc.
• The LIMS can be integrated with other software packages used by the company.
• The LIMS provides for phased and evolutionary changes over time, extending the useful life of the system and maximizing the return on investment as well as protecting historical data.
These inputs can be used to produce a requirements document that eventually will be sent to a number of suppliers as part of the purchasing process.
Setting out the requirements
The requirements document mentioned above should cover what the system should do now and in the foreseeable future, giving a clear idea of the initial number of concurrent users and likely expansion over the next five years. This document should be thorough and succinct and should avoid the use of qualitative terms such as “user friendly,” “flexible,” or “integrated,” as these are ambiguous. Everything should be aimed at providing as much quantifiable detail as possible. The document should concentrate on the software. Although the hardware represents a significant part of the total expenditure and it is sensible to indicate the preferred hardware platform and operating system(s), it is the software that defines what can and cannot be done with the computer system.
If the software is easy to use and is just right for what is needed, all other considerations (the hardware, the support, etc.) become much less relevant; less training, less support, and fewer alterations will be needed, and the implementation will be easier and faster. The requirements document should naturally set out the LIMS technical requirements, which should include topics such as the requirements for sample registration (login and receipt), label generation, and work lists and worksheets (allocation of work to analysts). A section on acquiring analytical results should detail both keyboard (manual) entry and automatic (online) entry, specifying the instruments that will be connected online. Other key considerations are validation and approval of data, reporting, statistics and general calculations, graphics, communications, security, and archiving tables of reference information.
Evaluating the available LIMS
Armed with an appropriate requirements document, the next stage is to identify potential suppliers and begin the product evaluation process. At this point some people might enlist the help of an “independent software consultant.” Since this can be an expensive exercise in itself, customers should satisfy themselves that any consultant used is truly independent and has no affiliation with one particular supplier, that he/she has a thorough understanding of LIMS software in particular and not just software in general, and that he/she does not have any ulterior motive such as providing implementation services for the system he/she recommends for purchase. Talking to potential suppliers is the very first stage, and even over the telephone they should be able to grasp customer needs and give ballpark costs. Be wary of suppliers who claim that their software is “approved”; there are no relevant BS or FDA standards or anything similar for LIMS software!
A preliminary meeting with a supplier in advance of a demonstration enables the customer to brief the supplier on an outline of requirements and allows the supplier to present the highlights of the product and explain details of the company and operation. A visit to the supplier’s premises offers the chance to meet the team, including development people, support people, and top management, and even to conduct an audit or get an overview of the supplier’s quality management system and support systems. The next stage is the system demonstration, using a demo checklist based on the requirements document. It is essential that “live software” be demonstrated and that there is sufficient time for the supplier or even the customer’s own staff to do some live configuration exercises, as system configuration is likely to be an important issue, as indicated in Figure 2. If the demonstration has been preceded by an initial meeting, it is reasonable to expect that it should relate directly to the customer’s requirements rather than be a “standard” demonstration. Ideally, customers should try to have demonstrations from all the selected suppliers over a short period such as a week so that everything is fresh in their minds as they make their choice.
One powerful and effective method of evaluating systems after demonstration is to evaluate up to three systems for at least one month on-site. This will involve at least a partial configuration of the systems by the suppliers and therefore is likely to be chargeable. This is an excellent test of the configurability of the evaluated system and its ease of use. If it is intuitive, then training can be minimized. Following up customer references once a preferred system has been chosen is completely acceptable. Another good indication of responsible supplier activity is the existence of a supplier-organized user group to encourage exchange of user experiences and knowledge. An evaluation of the support and maintenance offered by the supplier is also important. Another vital issue is the upgradeability of the software. Some suppliers do not have an upgrade path commitment, others charge for upgrades, and some introduce new versions that are incompatible with previous versions. Customers should check the reputation of suppliers in this most important area, as it dictates how long a life the system will have.
One might be forgiven for thinking that all LIMS software is essentially similar. In fact, in addition to “off the shelf ” LIMS software, there is bespoke/ custom software specifically written to meet the customer’s requirements, typically a one-off program representing a “snapshot in time” set of requirements. Although at first this might seem to be an attractive solution, issues of ongoing support, upgrades, enhancements, future configurability, etc., must be carefully considered. In-house software is another bespoke/custom software option where the software is written by an internal or outsourced IT department. This route can often suffer from underestimation of the coding task and peripheral issues such as documentation. Finally, some suppliers of ERP/MRP systems claim that their systems can provide the functionality of a LIMS or even replace an existing LIMS. However, these systems are simply unable to track samples within the laboratory at a level that would meet audit requirements
LIMS hardware really needs only to be up to date enough that the system has enough speed and expansion capacity and that the spares are available and likely to be so in the future. It is important that a large portion of the initial investment doesn’t have to be written off if the business expands, so customers should find out how much it would cost to double or triple, for example, the number of users, the storage capacity, the number of sites, or whatever else might be required.
Once the decision has been made, the order placed, and the system delivered, the work really begins! A typical system implementation process includes:
• Detailed review of project requirements
• Review of functional specifications
• Interfacing of laboratory instruments
• Installation of configured system
• Familiarization training
• Review meetings
• Data loading
• Formal acceptance testing
• Going live
While no two projects are approached in exactly the same way and the implementation process should be adapted to meet local requirements, this provides a proven framework to develop clearly defined responsibilities, goals, and milestones to ensure joint success.
1. “How (and how not) to Buy a Laboratory Information Management System,” www.autoscribe.co.uk/how-to-buy-a-lims.
John Boother, managing director at Autoscribe Limited, can be reached at firstname.lastname@example.org or +44 118 984 0610.
Like this article? Click here to subscribe to free newsletters from Lab Manager