Making LIMS Work
What is LIMS?
Laboratory Information Management Systems are specialized applications for laboratory automation that offer significant benefits:
- Optimal utilization of laboratory resources
- Reduction in manual operations and errors due to repeated data entry
- Adherence to regulatory requirements
- Standardization of procedures and enforcement during actual operation
- Collaboration and sharing of laboratory information with other departments and customers
- Automatic collation of test results into standard reports
- Instant identification of anamolies and exceptions
Challenges in LIMS implementation
Several laboratories realize the need for installation of LIMS to automate the processes in the laboratory, but LIMS installations are not cheap, and certainly not easy. The main hurdles in LIMS implementations are:
- Wide vareity of testing equipment – Laboratories use a wide vareity of testing equipment such as pH meters, balances, spectrophometers, autoanalyzers, and chromatography data systems. In addition, specialized laboratories have testing equipment specific to the type of samples that are tested. Though most standard LIMS packages have built-in facilities for integration with most standard equipment, there is significant effort required to integrate LIMS with non-standard or non-computerized equipment. Based on our experience of studying LIMS requirements and solutions, we have a different view on handling this issue in LIMS installations. We have found that laboratory technicians, especially in smaller laboratories, are not overly bothered by having to record test results manually. In fact, we would venture to guess, that if a LIMS solution were to merely provide a mechanism to manually export data from computerized data loggers that are anyway used with most modern testing equipment, it would more than suffice the requirements of small and medium sized laboratories. As for those equipments that do not have any computerized data loggers, test readings anyway need to be recorded manually – in which case, the technicians can directly enter the data in the LIMS forms.
- Different operating procedures – each laboratory has its own operating procedure, based on the industry and nature of operations or tests carried out in the laboratory. The sequence of processes, data formats used to record test results, sources of information, formats of reports generated, everything changes from one laboratory to another. Standard LIMS packages do have facilities for customization or configuration to a certain extent. However, there is almost always a need to write custom code. As Colin Thurston, Senior LIMS Product Manager at Thermo Electron Corporation, in Altrincham, UK reports in Scientific Computing World – LIMS: WORKFLOWS
In a typical LIMS, the sequence of work is broadly fixed, with no logic built into the sample lifecycle. Limited modifications are normally possible at each individual step, usually actioned by the system administrator. For example, changes in status of a sample such as ‘login’, ‘testing complete’, or ‘authorised’, would lead to different options being available to the user. Changing the sequence of events, or adding further logical branches (e.g. if . . . then . . . else nodes) to the sequence, usually requires the development of custom code, generally in the programming language of the LIMS. This can often be a proprietary language unique to that LIMS. Such customisation is not only complex and expensive, but it can lead to problems for the customer when upgrading or validating their LIMS. The consequence can be significant delays in going live. R&D and contract research laboratories handle many different types of analyses, so they need to be able to add or amend workflows quickly.
One approach that is used by some LIMS providers such as Thermo Electron Corporation is to use workflow management technology to handle this burden of customization by providing graphical editors that can be used by the laboratory technicians themselves to customize the process at any time during the life cycle of LIMS.
This is certainly a step in the right direction. As consultants for workflow management solutions, we completely identify with their vision in using workflow management to alleviate customization requirements. However, merely giving a graphical tool to edit process descriptions has its limitations.
We have found that any workflow management solution that is purportedly easy to customize by using graphical process modelling requires significant skill enhancement of users. There is no doubt that simple process modifications are easy to handle in a graphical modelling tool. However, it is far easier to write a procedure in a programming language than using a graphical process representation, if a programmer is available when required, and if modifications to the process logic can be made on-the-fly.
It is these two attributes :
- Availability of a programmer when required and
- Ability to modify workflow logic on-the-fly
that makes a workflow solution successful. This is precisely the reason why we insist on LIMS, or any other workflow implementation as a software service and not a one-time product installation.
3. Customization requirements during change in procedures or software upgrades – If a laboratory implements a standard LIMS package, but with significant amount of customization, the customized version may become incompatible with new upgrades of the LIMS package. As Thurston reports
Upgrading will be complicated if there has been significant customisation. Is the code compatible with the new version of the LIMS? Do you have access to the people responsible for the code – contractors or in-house? If not, implementation services may need to be purchased, again, to re-implement the customisation. All this adds unwelcome complications to the upgrade process. And, of course, once re-implemented, the system needs to be revalidated.
Having a LIMS customised this way also presents problems should there be changes to laboratory procedures. When changes to the mapped workflow are required, the client may have to re-program the LIMS. This may then entail revalidation of the affected subsystem.
Again, this problem only occurs if LIMS is installed as a one-time package, and not when LIMS is treated as a software service.
4. Integration with existing systems – Laboratories may already have some software systems and LIMS needs to be integrated with those systems. This integration is also case-specific, requiring additional efforts and cost. As Jason Simpson reports in Integration Of LIMS Offers Compelling Advantages For The Production Environment,
Under increasing pressure to harmonize their business processes, science-based organizations are taking measures to standardize on computing applications such as Laboratory Information Management Systems (LIMS) and also to integrate these with enterprise platforms and systems. Often different locations within the same organization will employ information management systems from a variety of vendors for the same purpose. Industry mergers and acquisitions have only added to this diversity. For these reasons, it is no surprise that the standardization and integration of systems typically represents around 30% of IT budgets.
Most standard LIMS packages have built-in facilities for integration with external systems using APIs (Application Programmers Interface). However, some LIMS packages like Thermo Electron Corporation’s SampleManager LIMS are beginning to use XML-based standard integration facilities, or Web Services to allow easier integration of LIMS with disparate systems.
Our LIMS solution, offered as a completely Web based system, uses XML not only as a way to integrate data with external systems, but as a native object database technology.
Summary
LIMS can make a huge difference to the productivity of an R & D Laboratory. However, a standard LIMS package may not be the most suitable solution, due to the amount of ongoing customization required as is typical in an evolving enterprise – of which a Laboratory is a prime example.
However, if a LIMS solution is built and delivered as a software service by utilizing workflow modules as building blocks, with a scripting language that can be used for on-the-fly customization, evolution of the code can match changing requirements of the laboratory.
Also, creating LIMS as a web-based service, with a native object database to store and retrieve data, integration with other disparate software systems can be done with a minimal overhead and cost.
