LIMS Configuration or Customization. Part 1 - What's the Difference?

This is a three part series. Part 1 discussed the differences between customization and configuration, this part 2 discusses how you can between them, while part 3 discusses the value of configuration tools.

Any individual laboratory will have its own particular way of working, and so any LIMS (Laboratory Information Management System) needs to be adapted to suit their particular needs. There is a multitude of ways in which the workflow of laboratories differ; starting from the way samples are submitted for testing, through the sample lifecycle to the point at which results are authorized, reported and the work potentially charged or invoiced.

A LIMS must therefore be flexible enough to support these different needs and working practices. In fact, the LIMS needs to be ‘configured’ to meet individual requirements, but although most LIMS are described as ‘configurable’, there are two very different approaches to achieving the final system – true configuration and customization. Most people would consider these terms to have the same meaning, and use them interchangeably but in the world of LIMS, they are very different and these differences can have significant implications both for the user and for the IT support team.

What is customization?

Customization is the implementation of working 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 cannot, therefore, 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 specific needs of the customer. Typically the supplier‘s application developers use this programming environment to create the standard functionality supplied with the system, for example the code to support batch manufacturing and lot traceability. The programming environment not only allows new functionality to be created, but also allows standard functionality to be modified, and it is this that creates the fundamental weakness of the customization approach.

What is configuration?

A simplistic approach to configuration is often seen as just changing settings and flags made available by the supplier to change the behavior of a workflow. This could be as simple as setting a flag associated with a sample to indicate it requires a preparation step. However, successful configuration of this sort requires the supplier to have anticipated all the possible switches and flags required. In a complex application such as LIMS this is pretty much impossible. When multiple configuration settings are included in specific applications it 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 the data seeming to get lost within the system. Instead of concentrating just on switches and flags configuration should be looked at in a broader sense; e.g. the way in which the standard parts of a system are arranged to make up the whole.

True configuration for LIMS

True configuration of a LIMS means the bringing together of functional objects to create a solution that meets the needs of the user, not changing standard code. In this way, a system can be built to meet exact needs without compromising supportability and upgradeability of the system or risking obsolescence of functionality. The Matrix Gemini configuration approach involves using a graphical interface and screen editor to manipulate standard functional classes in order to design and implement a workflow. Consider sample registration; a standard functional class exists that supports the registering of samples, and another that supports the registering of multiple or bulk samples. The graphical screen designer employs drag and drop techniques that allow the user 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 is then used by the appropriate object - in this case to create the sample or samples in the database.

The interface elements such as the list boxes, combo boxes and buttons are themselves 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 and many others. Other controls allow actions to be linked together to form a complete workflow. Data sets can be passed between functions or workflows without having to write data handling algorithms, and there is no need to implement typical programming features such as array handling.

Big differences between customization and configurability, but what are the real implications?

The customization approach has implications not just in the initial monetary cost of the programmers required to carry out the customization but in other less obvious, but no less important ways. Take the following example of batch manufacturing and lot traceability functionality created using a supplier’s application programming environment. Given the complexity of the potential manufacturing workflows it is entirely 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. Developing the functionality from scratch will likely recreate large amounts of existing functionality and will be wasteful and time consuming. Therefore modifying the standard code would seem the more appealing proposition. 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 obsolescence of the system. Similarly, if the needs of the user change, the code will again need to be reworked – almost certainly by the supplier’s applications programmers. Not only are there costs associated with this, but any changes in the application code may require the LIMS to be re-validated.

This scenario can be avoided in the true configuration approach. This allows the supplier, or indeed users, to create specific screens and workflows that meet their needs without having to write or modify any computer code. The standard objects are simply manipulated to create a configuration that meets the specific needs. The complete configuration is held within the database and is unaffected by any upgrades from the supplier, as these will only modify the underlying technology layer of the product and the functioning of the standard classes and objects.

Flexible and future proof

The flexible approach that comes from true configuration means that users can also create completely new functionality if required. New database tables can be defined to store specific data and generic classes and objects allow this data to be managed, manipulated and seamlessly integrated throughout the whole system. Changes can be readily made as the needs of the user evolve, and they do not even have to be done by the supplier – it is possible for the user to make the changes themselves. Most importantly, as the underlying code remains unchanged, such changes may not require re-validation of the software.

Telling the difference between configuration and customization

Clearly there is a significant difference between true configuration and customization. How can you tell if your system is, or is going to be, customized? We’ll highlight some key pointers in part 2 of this blog.