Progressive vendors are working on ways to minimize the requirement for code
customization. Figure 1: A simple LIMS workflow, displayed in a graphical editor ...
LIMS g u i d e L I M S
& I n s t r u m e n t a t i o n TM
Laboratory Informatics
L-20
lims.scimag.com
Using Workflows in LIMS to Reduce Customization Glen Maxwell
Progressive vendors are working on ways to minimize the requirement for code customization Modern LIMS are presented and sold as commercial, off-the-shelf software. However, during implementation, all solutions require a degree of configuration and/or customization to meet the specific requirements of the purchasing organization. In fact, one of the key findings in a recent industry survey by the ARC Advisory Group, “Laboratory Information Management Systems (LIMS) Worldwide Outlook” was that LIMS users find it much more productive to purchase standard software that incorporates configuration options for their specific industry. ARC explains, “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 customization 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 organizations operating LIMS, progressive vendors are working on ways to minimize the requirement for code customization. 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 ‘authorized’ 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 customization is not only complex and expensive but it can lead to problems for the customer in terms of upgrading and validating their LIMS and, therefore, significant delays in going live. R&D and contract research laboratories have a particular requirement in this regard due to their handling of many different types of analysis. They need to be able to quickly add new or amend existing workflows. A number of leading vendors are introducing functionality to handle workflows into their LIMS to reduce, or even eliminate, the need for such customization. This can have significant benefits
in the tracking of samples, easing compliance pressures, and simplifying familiarization with lab processes. Why workflows? During the LIMS selection processes, organizations will typically undergo a rigorous requirements gathering and analysis phase, whether as a matter of good practice in non-regulated industries or as mandated by regulatory agencies [1]. 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 what are often sitespecific workflows within the LIMS, it is often necessary to customize the software. This will likely entail 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 either train in-house programmers in this language; recruit highly expensive
F i g u r e 1 : A simple LIMS workflow, displayed in a graphical editor
& I n s t r u m e n t a t i o n TM
LIMS g u i d e L I M S Laboratory Informatics
contractors experienced in the language; or purchase implementation services over and above installation and validation requirements from the LIMS vendor. Virtually all large-scale LIMS installations involve many months of implementation services, whether provided by the vendor, or through thirdparty contractors. So, what happens when the work is done? 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 a decision is taken to upgrade to the latest version, there are many issues that require careful consideration. There may be new hardware requirements; software
The objective of workflows is to allow a LIMS user to generate easily the sequence of events to be undergone by a sample compatibility issues may occur where complex interfaces have been defined; new operating systems support may be required. On top of this, there will be a need, particularly in regulated industries, to revalidate the installation — including any custom code ported to the new version. The upgrade process is further complicated if there has been significant customization carried out. 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, then implementation services may need to be purchased, again, to re-implement the customization. All this adds unwelcome complications to the upgrade process. And, of course, once re-implemented, the system needs to be revalidated. Customization through programming then, as opposed to configuration within the software, is to be avoided where possible. Having a LIMS customized this way also presents problems should there be changes to laboratory procedures that impact on the sample lifecycle.
When changes to the mapped workflow are required, the clients programming resource needs to be deployed to re-code the amended functionality. This may then entail revalidation of the affected subsystem. Specifically, the objective of workflows is to allow a LIMS user, rather than a programmer, to generate easily and modify the sequence of events to be undergone by a sample or group of samples. Workflows can eliminate the requirement to customize a LIMS through interaction with its proprietary programming language, by allowing the LIMS user to graphically design and adapt a process that matches the life cycle in the laboratory. What are workflows? Recently patented functionality [2] designed by Thermo Electron Corp. (formerly Thermo LabSystems) for its Nautilus LIMS is an example of LIMS software engineering that is offering customers ease-of-use and flexibility in the creation of workflows. The 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 in the workflow execution may be automatic, or can be configured to prompt for user interaction where necessary. The LIMS workflow editor provides authorized users with an easy-to-use graphical tool for modeling laboratory processes, requiring no programming experience. Users are able to create and adapt workflows to reflect the latest laboratory procedures and changes can be applied easily. Pre-existing workflow nodes can be used to define a workflow for any purpose. Once created, workflows, which are 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 predefined specification limits. An example may be to send an e-mail notification to the laboratory manager or supervisor when a result is out of specification. 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 authorization rights. Creating workflows in a graphical editor A workflow can be used to create a sample record in the database. The workflow, when executed, will log the sample using the template associated with the sample creation node in the workflow. More complex processing steps also may be added to the workflow. For example, nodes can be used to trigger specific actions, such as when a sample status changes. User defined events such as ‘lost sample’ can be configured. Nodes can be used to prompt the user to make choices, for example depending on a Boolean comparison of values entered. More complex choices, such as the comparison of multiple values, also can be prompted. Existing workflows can be combined with other workflows to create highly complex sequences of events to meet the needs of any laboratory. To create a workflow, the user simply selects a workflow node in one pane of the Workflow editor. The node can then be inserted at the appropriate level of the workflow, which is displayed as a tree in the graphical editor. By selecting a node in the workflow, a range of properties associated with the node can be edited, making it highly configurable. This allows the definition of values according to the type of node selected. A description, which is meaningful to the user, can be applied for display in the LIMS workflow tree, which is structured like Microsoft Explorer. The functionality also allows: • Event triggers to be set, such as email notification when a status change occurs or if a result is out of specification • A user-defined message to be displayed on screen at a defined point in the workflow execution
& I n s t r u m e n t a t i o n TM
LIMS g u i d e L I M S Laboratory Informatics
L-22
lims.scimag.com
Clients have reported that the ease of configuration offered by graphical workflow functionality is
tion process cannot be completed without an established software requirements specification” (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g)). www.fda.gov/cdrh/comp/guidance/938.pdf 2. Thermo Electron Corporation has been granted a U.S. patent on its LIMS Workflow technology, which is currently deployed in Nautilus LIMS: patent number US
6,594.588 B1, entitled “Apparatus and Method for Monitoring and controlling Laboratory information and/or Instruments” on July 15, 2003.
Glen Maxwell is Manager of LIMS Development at Thermo Electron Corp., Altrincham, UK. He may be contacted at
[email protected].
a particular asset • Values on which to make decisions, such as whether to carry on executing the workflow if results are out of specification or out of trend, to be defined. With all actions configured in the graphical editor, a workflow is created that involves no new coding. Once saved, qualified lab personnel can use it to create samples, and progress and trace the sample through its lifecycle. Summary Users have reported great benefits from this approach to defining the LIMS workflow. During evaluation of the LIMS selection process, clients have reported that the ease of configuration offered by graphical workflow functionality is a particular asset. Users can see how their procedures can be easily mapped onto the LIMS. Using graphical LIMS workflows allows changes and system refinements to be made easily, involving no system downtime or input from the programmer, 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 customized code. This reduces the validation and upgrade headaches associated with heavily customized systems, while simplifying the accommodation of procedure changes in laboratories.
F i g u r e 2 : Workflow nodes for selection
References 1. General Principles of Software Validation; Final Guidance for Industry and FDA Staff Document issued on: January 11, 2002 section 4.1 Requirements “The software valida-
F i g u r e 3 : Workflow tree display showing hierarchical structure
Reprinted with permission from Scientific Computing & Instrumentation