Is Your LIMS Sustainable? Why Configuration is the Way to Go (Part I of II)

Do you remember the time when every organization went out and hired teams of consultants to customize their LIMS for each lab’s workflows and requirements?

No? Well, that’s the way a lab’s custom LIMS used to be created.

The process typically involved custom software developers taking apart a vendor’s out-of-the-box (OOB) software and meticulously reassembling it – often in a manner the vendor never intended. This happened because early LIMS systems were not based on open standards and contained little ability to alter essential functions. They also completely lacked support for the robust enterprise interfaces laboratories required.

wrenchThis type of customized legacy system may, in fact, be what your lab is using today.

The impact of these customizations?  Cost, lost productivity and time delays.

Not only did organizations need to absorb the additional time and costs required to disassemble, modify, and reassemble the LIMS software, but also the time spent conducting rigorous validation and testing of the resulting customizations. If you’re using Good Automation Manufacturing Practices (GAMP) as a guide, making significant changes to a Category 4 system (configured, off-the-shelf-software) causes it to be validated under Category 5, which is usually reserved for only bespoke, custom-coded software.

Additionally, organizations have experienced poor long-term support for customized solutions. The original consultants have inevitably moved to other customer projects, and the company’s internal SMEs either get promoted, move to other departments, or even retire!

On top of all of these issues facing labs, there is no guarantee customized functions will survive a vendor software upgrade. This causes the initial excitement of newly-updated software to quickly wane, turning into frustration and alarm when these functions stop working altogether—or worse, damage the integrity of lab data.

Why Is Configuration Better than Customization?

As you can see, customizing a LIMS – as opposed to configuring a LIMS – has a number of drawbacks. But what’s difference?

‘Customization’ is typically used to denote modifications that require coding – making changes to the underlying LIMS software.

‘Configuration,’ on the other hand, relies on built-in system tools in the LIMS to change the appearance or functionality, while eliminating the need to change the core underpinnings of the platform. This is a key distinction, as any changes to the core platform through coding demands extensive testing. Customization can also result in a situation in which updates may render the customized portions unusable.

Unfortunately, some well-known LIMS still lack a robust configuration strategy. These systems neither rely upon open standards nor include the ability to introduce configuration without risking the integrity of the entire system. You’ve likely seen many blog posts written about modifying vendor scripts in a way that doesn’t break entire feature sets, or even the entire LIMS. And while you might think this is simply a problem from the past, it can be a very real problem today.

Ensuring LIMS Long-Term Sustainability
We treat the LabVantage core LIMS product as sacred. This helps control product quality by ensuring that individual implementations cannot fundamentally break core functions.At LabVantage, we implement software configurations in several unique ways. Below, we explore one of the ways LabVantage makes systems robust, secure, and sustainable.

Essential to LabVantage’s configuration strategy is the fact that the core product is entirely secured against modification by individual labs and even against modifications by our own Professional Services Department!

Simply put, the LabVantage core product is sacred. This helps control product quality by ensuring that individual implementations cannot fundamentally break core functions. (To better understand this, see illustration.)

Product Node
At the lowest level is the LabVantage Product node. This layer contains the core product web page configuration, business processes compiled into the LabVantage EAR file (a standards-based Java application), and the database tables and columns fundamental for a LabVantage system to operate properly as a LIMS, an ELN, and an LES. This layer also contains all optional modules, such as Lab Consumables, Lab Investigations, Stability, and an entire feature dedicated to enterprise communication through web services.

If you need to apply a LabVantage Maintenance Release to address certain bugs that happens at the Product Node. If it’s time to upgrade your software to a new version? Again, Product Node is what you need! Because we never touch the Component and Customer nodes, you can have peace of mind knowing that no update or upgrade can break the configurations you have made for your lab.

Component Node
In the Component Node, you find additional functional components as released by LabVantage. They are available to customers through certain industry accelerators, and are made available by request during certain customer implementations. Like the Product Node, the Component Node is secured against all modifications except for applying upgrades LabVantage releases.

Customer Node
Finally, the Customer Node is where all the action happens! If you want to change the name of a field, add a new column to a database table, add that column to a web page, or even implement extra business logic – everything is executed in the Customer Node. This is also where our Professional Services group makes changes during project implementations, enabling individual labs to maintain the configuration long after all the consultants go home.

Configuration – Putting it Into Practice
Here’s an example of a situation in which a lab wants to relabel a core product field to “Analyst.”

With no additional configuration, every user would see “Analyst” on their screen.

A Component Node change can then be installed which alters that label to “Lab Personnel.” Now, the core product still contains the “Analyst” label – but users will always see “Lab Personnel.”

Finally, a lab may want to relabel the field as “Bench Superstar,” on the Customer Node. Done! Every user will now see “Bench Superstar” on their screens, but the Component and Product nodes will remain unchanged while users will always see their preferred label.

This label will survive core product updates, upgrades, and even updates and upgrades to Components.

This is just one way that LabVantage delivers a modern, secure, and sustainable configuration strategy— stay tuned for future blog posts exploring even more.

Part II of this series is available here: