Whether to solve LIMS design puzzles via configuration or customization is an age-old question, right behind “Which came first: The chicken or the egg?” Ok, maybe it’s not that universal, but it is one of the most asked questions within laboratory informatics. What is the difference between customization and configuration, where is the line between the two, and which approach is the correct one to use in solving your design problems? 

Put generally, customization requires a developer to make changes to code whereas configuration can be done by changing settings that are native to the system—even when those setting changes are very complex. Many laboratory informatics solutions offer some level of customization and configuration, and as enterprise LIMS expand their capacity and introduce ever greater flexibility, the hard line between configuration and customization blurs.

Customization

Customization may be required for various LIMS systems and implementation goals. Interfacing other systems and complex instruments almost always requires custom drivers to bridge the gaps between disparate systems. Niche laboratory processes or execution details unique to your lab may be beyond the capabilities of an out-of-the-box (OOB) enterprise LIMS. 

A developer will write specific code to make the system work as you want it to. This code can span from custom interfaces between the LIMS and other applications, to supplementing or tweaking existing workflows within the LIMS, or to implementing entirely new functions.

Configuration

To understand configuration, consider our trusty pal, Microsoft Office. Sure, you can change which icons are in your toolbar based on how you typically use the applications, but at the end of the day, there are only certain predefined settings you can change or move around. If you aren’t happy with the outputs, you don’t have an option to write lines of code; you deal with it or switch to a different application. 

Similarly, LIMS configuration may include revealing, hiding, or moving functionalities; determining where data is displayed within the system; or streamlining workflows. Modern LIMS offer a huge array of configuration options, some of which blur the line between configured and customized.

Where it Gets Blurry

Some enterprise LIMS include powerful configuration tools that give administrators with proper training almost unlimited control over the data model and system functions. This may range from building-block-like actions that can be chained together to create new system functions without knowing a line of code, up to and including blocks of code (written in SQL, Groovy, JavaScript, etc.). These blocks of code plug directly into the system interface without changing the core compiled code of the system. Because the core system code remains untouched, this operation is often considered advanced configuration instead of customization. Nonetheless, it should be approached with increased caution compared to an entirely no-code configured system, as the inclusion of interpreted code allows you to make changes outside of the design of the system with very few limitations or guard rails, which may undermine the native functions of the LIMS and complicate the validation work, if that is required. 

Decisions, Decisions

When making the decision about which LIMS is best for your company, it is important to understand the benefits and downfalls of each. Also important to note, is how the level of customization or configuration will impact the software classification category within GAMP5 and therefore the level of testing required to qualify the system. 

The best starting point is a system that meets most of your needs off the shelf. Taking the time to find the best-fit Commercial Off the Shelf (COTS) system, regardless of which approach you take to make said system yours, will help to keep your timeline and budget under control by minimizing how much the “configure vs customize” question comes up in the first place. 

To determine which system best meets your needs, the first step is creating a wish list of features, also called User Requirements Specifications (URS). From there, you can assess the native functionalities of various LIMS and how they relate to your requirements and decide what level of configuration or customization your project requires. Bear in mind that you shouldn’t turn to customization to solve problems that could be solved via configuration by someone with a strong understanding of the capabilities of the LIMS. To avoid this, employ knowledgeable third-party consultants (not the vendor’s developers) before and during your implementation project. These experts understand the full scope of functions available OOB as well as what to consider when implementing customizations. They can help you decide whether you need additional modules or features, some customization, or just careful configuration.

___________________________________________________________________________________________________________________________________________________________

Which of the two options, configuration or customization, worked better for you in your lab? Leave your responses in the comment section below. 

‍