Commercial laboratory information management systems (LIMS) are nowadays sold as off-the-shelf software. As the article by Peter Rees on page 16 indicates, the trend is increasingly to focus on standardised products; the consequence is that, during implementation, all systems will require a degree of configuration or customisation to meet the buyer's requirements.
The trend towards standardisation plus configuration was one of the key findings in a survey by the ARC Advisory Group from 2003, 'Laboratory Information Management Systems (LIMS) World-wide Outlook' - LIMS users find it much more productive to purchase standard software that incorporates configuration options for their specific industry. The ARC report explained: 'This allows the IT department to focus on evolving trends in the integration of all systems, including LIMS, into one environment to share information in real-time for real productivity gains. Despite the fact that these commercial systems are developed for a particular industry, they still require considerable customisation to meet the laboratory's needs. Consequently, the consulting and implementation services of the LIMS solution represent a significant portion of the cost.' While the value of such services is widely accepted by organisations operating LIMS, progressive vendors are working on ways to minimise the requirement for code customisation.
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.
Several leading LIMS vendors are introducing functionality to handle workflows to reduce, or even eliminate, the need for such customisation. This can have significant benefits in the tracking of samples, easing compliance pressures, and simplifying familiarisation with lab processes.
Workflows as part of the LIMS selection process
Organisations selecting a new LIMS will typically undergo a rigorous analysis phase, whether as a matter of good practice in non-regulated industries, or as mandated by regulatory agencies. This will include mapping the lifecycle of the lab's dynamic data, for example sample data, and the workflow to be applied during this lifecycle.
In order to map site-specific workflows within the LIMS, it is often necessary to customise the software, by developing code in the programming language native to the LIMS, or at least in a compatible language. As this language may be proprietary, the client will need to train in-house programmers, recruit expensive contractors experienced in the language, or purchase implementation services over and above installation and validation from the LIMS vendor. Virtually all large-scale LIMS installations involve many months of implementation services.
So, what happens when the work is completed? Two to three years down the line, the chosen product will no doubt boast a series of new features and benefits, from which established users will be keen to benefit. If these users decided to upgrade to the latest version, they will have to consider many issues carefully. There may be new hardware requirements; software compatibility issues may occur where complex interfaces have been defined; or support for new operating systems may be required. There will also be a need, particularly in regulated industries, to revalidate the installation - including any custom code ported to the new version.
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.
In contrast to all this, the objective of 'workflows' is to allow a LIMS user, rather than a programmer, to generate and modify the sequence of events to be undergone by a sample or group of samples. Workflows can eliminate the requirement to customise a LIMS through its proprietary programming language, by allowing the user graphically to design and adapt a process that matches the life cycle in the laboratory.
Graphical representations of laboratory and business processes
The informatics business of Thermo Electron Corporation is one vendor that has incorporated workflows functionality into its LIMS. Indeed, the company has been granted a US patent on its LIMS Workflow technology, which is currently deployed in Nautilus LIMS and is being incorporated in SampleManager LIMS. Workflows are best described as graphical representations of laboratory and business processes. The life cycle of an item - e.g. a sample - can be mapped onto the LIMS via a workflow editor. Execution of the workflow results in the assignment or creation of relevant aliquots, tests, results and associated reports. Each stage may be automatic, or can be configured to prompt for user interaction where necessary.
The LIMS workflow editor provides authorised users with an easy-to-use graphical tool for modelling laboratory processes, requiring no programming experience. Users are able to create and adapt workflows to reflect the latest laboratory procedures. Pre-existing workflow nodes can be used to define a workflow for any purpose. Once created, workflows, stored as separate models, can be conjoined to reflect a larger laboratory process. This means an individual process need only be defined once in the LIMS, but can be reused many times, and in many other workflows. This simplifies maintenance of the laboratory process for the LIMS user.
Automated decisions that affect the life-cycle of a sample can be based on the results obtained for that sample, such as whether they pass or fail pre-defined specification limits. These automated decisions help ensure error-free processing. Automated decision-making can therefore be applied to virtually any process in the laboratory, provided the operator has the correct authorisation rights.
Improved productivity
Users report great benefits from this approach. During the LIMS selection process, the ease of configuration offered by graphical workflow functionality is a particular asset. Users can see how their procedures can be mapped onto the LIMS. Using graphical LIMS workflows allows changes and system refinements to be made easily, leading to improvements in productivity over conventional LIMS developed using proprietary code. While it is recommended that changes in configuration are tested thoroughly, there is, however, no requirement to revalidate the system.
From a system-management perspective, using workflow functionality to graphically map the lab workflow onto the LIMS can greatly reduce the need to create and maintain customised code. This reduces the validation and upgrade headaches associated with heavily customised systems, while simplifying the accommodation of procedure changes in laboratories.
Colin Thurston is Senior LIMS Product Manager at Thermo Electron Corporation, in Altrincham, UK
