Featured Article
Aside from the testing process, there are many ways in which laboratory workflows differ—from the way samples are submitted for testing, through their lifecycle, to authorization and reporting of results and invoicing of the work. A typical laboratory process workflow is shown in Figure 1. LIMS must be flexible enough to support the needs and work practices of the individual laboratory. This is generally referred to as system customization or configuration. While these terms are often used interchangeably, in the world of LIMS they are very different.
Figure 1 – Typical laboratory process workflow.Customization
Customization is the implementation of business needs and work practices by changing the standard code supplied with the system or creating new code from scratch. While the source code for the underlying technology of many LIMS is provided in a compiled form and thus cannot be customized, the same is not necessarily true for the application code. Many suppliers provide a computer programming environment that allows code to be written to meet the specific needs of the customer. The supplier’s application developers typically use this programming environment to create the standard functionality provided with the system, for example, the code to support batch manufacturing and lot traceability. This programming environment not only allows new functionality to be created, but also enables standard functionality to be modified—this is the fundamental weakness of the customization approach.
Configuration
In the context of software, configuration is often seen merely as changing settings and flags made available by the supplier to change the behavior of a workflow. It could be as simple as setting a flag associated with a sample to indicate a preparation step is needed. However, for this type of configuration to be successful, the supplier has to anticipate all possible switches and flags. This is nearly impossible in a complex application like LIMS. Multiple configuration settings included in specific applications can lead to the creation of configuration wizards with complex interrelated settings. These can be difficult to set up, manage, and verify. Incorrect setting of incompatible configuration options can also lead to data becoming lost within the system.
Rather than concentrating on switches and flags, configuration should be looked at in a broader sense, that is, how the standard parts of a system are arranged to make up the whole. Take the example of a laptop PC. Its configuration is created by bringing a set of standard options (functional objects) together: a processor powerful enough to run the required applications, adequate memory, and storage, and a range of peripherals such as CD ROM, mouse, and an external drive, depending on how the PC will be used.
True configuration of a software application means the same thing—bringing together functional objects to create a solution that meets the user’s requirements, not changing standard code. In this way, a system can be built to meet precise needs without compromising supportability and upgradeability of the system or risking obsolescence. One true configuration approach involves using a graphical interface and screen editor to manipulate standard functional classes to design and implement a workflow. Consider sample registration: a standard functional class exists that supports sample registration, and another supports the registration of multiple or bulk samples. Drag-and-drop techniques are implemented that allow users to design their own specific data-input screens utilizing standard interface elements such as text boxes, combo boxes, list boxes, and buttons. The data entered are then used by the appropriate object, in this case to create the sample or samples in the database.
Interface elements such as list boxes, combo boxes, and buttons are standard objects (also known as screen controls) with associated properties that allow the user to select, change, and modify their behavior as required. Other functional classes support standard LIMS elements such as test assignment and result entry. Figure 2 shows how such functionality can be used to build a sample received screen. Other controls allow actions to be linked together to form a complete workflow, such as that shown in Figure 1. Data sets can be passed between functions or workflows without the need to write data-handling algorithms or implement programming features such as array handling.
Figure 2 – System functionality can be used to build a sample received screen.
Customization or configuration
Customization has a number of important implications beyond the cost of employing application programmers to carry it out. Consider batch manufacturing and lot traceability functionality created using a supplier’s application programming environment. Given the complexity of the potential manufacturing workflows, it is possible that the application as developed will not meet the needs of an organization. If that is the case, there are two options: develop the functionality from scratch or modify the existing code to do what it was not originally designed to do. The first option will likely re-create large amounts of existing functionality and will be wasteful and time-consuming. Modifying the standard code would therefore seem more appealing. However, what are the consequences if the supplier issues an upgrade to the system that adds new functionality, fixes known errors, or supports technological changes? At best, the customized code will need to be reworked to support the changes (if that is possible); otherwise the customized code will need to be left as is, risking system obsolescence. Similarly, if the needs of the user change, the code will again need to be reworked, likely by the supplier’s programmers. Not only are there costs associated with this, but any changes in the application code may require that the LIMS be revalidated.
True configuration allows the supplier and users to create screens and workflows that meet their specific needs without having to write or modify any computer code. The standard objects are simply manipulated to produce the desired configuration. This is held within the database and is unaffected by upgrades made by the supplier, as these will only modify the underlying technology layer of the product and functioning of the standard classes and objects. Users can also create completely new functionality if required. New database tables can be created to store specific data, and generic classes and objects allow the data to be managed, manipulated, and seamlessly integrated throughout the system. Changes can be made by the supplier or user as needed.
Most importantly, because the underlying code is unchanged, software revalidation may not be necessary.
How can you tell if your system is, or is going to be, customized? Here are some key indicators:
- Does the supplier refer to its technical consultants as programmers?
- Does the supplier say its configuration tool is similar to C, C#, Visual Basic, or some other programming language?
- When you ask if you can do the configuration yourself, is the answer “Yes, if you have someone who understands computer programming”?
- When you ask for standard functionality to be changed, does the supplier talk about “programming in” the modification?
- When standard functionality is changed, is the original program copied, renamed, and then worked on to prevent future upgrades from overwriting your changes?
- Are upgrades to your system time-consuming and expensive, requiring rework of your changes?
- Is your LIMS outdated? Are workflows not fully supported because your specific functionality cannot be upgraded?
- When new functionality is created for your system, does the supplier start with a blank program file and start writing computer code?
If the answer to one or more of these questions is “yes,” then your system has been customized.
Summary
Choosing a system that supports true configuration, which is a great deal more than just turning switches and flags on and off, will help ensure long-term supportability of your system, protect your investment, and ensure that the LIMS can evolve as needs change.
Simon Wood is product marketing manager, Autoscribe Limited, 1-2 Venus House, Calleva Park, Aldermaston, Reading, Berkshire RG7 8DA, U.K.; tel.: +44 118 984 0610; e-mail: simon.wood@ autoscribe.co.uk; www.autoscribeinformatics.com