Implementing system configuration and master data in a single LIMS instance can be quite challenging.
The Good, the Bad, and the…
LIMS systems with enterprise features typically include robust options. This is both a good thing – as it offers the flexibility to incorporate a broad range of records – but also a bad thing, since it means a large volume of electronic records must be configured as a working whole. At best, this can be a demanding, laborious process.
And this isn’t a one-shot procedure. After investing the time and effort to configure one instance of the LIMS, the entire thing will need to be re-implemented several more times.
Wait, what?
Sorry – but yes, it’s true. Work performed on development systems gets promoted to test/validation systems, which in turn is promoted to a production system. This situation is often multiplied for multi-site organizations, which might find themselves needing to promote that configuration & master data to many other sites for further development, testing, and production operations.
To make matters even more complex, it’s common practice to have multiple individuals making changes to a single system.
Not complex enough for you yet?
How about multiple individuals making changes to different systems that must be merged back together later? Good times! (For more on this topic check out: “How to Choose Between a Global LIMS or Separate Systems.”)
Wouldn’t it be much easier to just take a single system and duplicate it a bunch of times?
Sure it would, but that’s not how system implementations work. You can’t just duplicate all of your development data – errors and all – to validation and production systems and expect anything short of mayhem.
Instead, labs need a near-surgical method to identify precise configuration and master data that will be promoted from one instance to another, while at the same time supporting the work habits of distributed teams.
LabVantage 8.5: Configuration Management and Transfer
These were among the common problems labs face, and they were front and center as primary objectives when developing the new Configuration Management and Transfer feature coming in LabVantage 8.5.
Here are 3 common problems and how LV8.5’s unique CMT provides a solution (or even multiple solutions) for each one.
PROBLEM 1
Implementers cannot easily identify configuration changes during development, which leads to incomplete deliveries and unhappy business users.
SOLUTION
Change Control Scope
Identifying the scope of controlling change within LabVantage is defined at the table collection level (this is called an SDC in LabVantage lingo, which stands for Sapphire Data Collection). These are one or more database tables of related electronic records.
For example, maybe you’d want to track changes on Test Methods, or on LabVantage web page configuration. Or maybe you’d want to track changes on the Sample SDC – but only for records marked as templates while ignoring changes on sample instance records.
In other words, identifying the scope of controlling change tells the LabVantage system what types of data you believe are important.
SOLUTION
The Change Request
Configuration management begins with controlling why changes are being made. There are a number of reasons a change may be made. It may represent:
- an initial system build
- a new feature or enhancement
- repair to a configuration or master data bug, or
- something else.
The new LabVantage Configuration Management and Transfer feature introduces Change Requests as electronic records within the LIMS. These can include references to change request numbers from external systems, a description of why the change is required, a priority, due date, assigned user or group, and more.
Once created, Change Requests go through a life cycle starting at an initial state, moving through acceptance, approval, etc.
When a change is made to one of those identified records, the user making the change may relate this change to a Change Request.
SOLUTION
The Change Log
The LabVantage Change Log is exactly what it sounds like: a log of all changes executed under a Change Request and within the scope identified in the system.
But this Change Log isn’t just a static list. It also has some powerful features. Not only can a user visualize changes made at two different points in times, but a privileged user can even roll back objects to a previous state!
It’s an important capability.
Imagine a Specification has gone through 5 days of changes, only to discover that the incorrect version of the standard was used to configure the values. Now what do you do? The new LabVantage Change Log can be used to revert the Specification to its state 5 days ago.
PROBLEM 2
Implementers cannot easily co-develop with customers and across teams, which leads to conflicting configurations and frustrated developers.
SOLUTION
Check-out and Check-In
Like a source code repository, the new LabVantage Configuration Management and Transfer feature allows users to check out objects so that other team members don’t accidently make conflicting changes.
As you can imagine, the Check-out has features to support both individual users and groups – and even methods to force a check-in when team members become unavailable.
Additionally, check-outs can be configured to be somewhat ‘lazy.’ For example, you might not want to force users to identify a check-out first, but rather allow them to make changes as needed and only be prompted to associate changes to a Change Request when saving the records. Or maybe you want to allow users to identify a Change Request, then all changes that are made are associated to it, without being repeatedly prompted.
As alluded to when referring to the Change Log (above), checking-out an object causes the system to grab a snapshot of the record for future comparison.
Once changes are complete, the user can check-in the item again, and be assured that all modifications were integral and complete.
Check-in, as you would expect, causes another snapshot of the record to be created. It is these ‘before and after’ change snapshots that enable the powerful “diff view” provided by the Change Log functionality.
SOLUTION
Remote Development
Not only can a user check-out items for work, they can even export those items to be modified on a remote system – then import them back into the master system once the changes are complete!
Remote development assures the team that the master system remains unchanged while work is executed on another system. Once the work is complete, it can then be seamlessly re-integrated into the master system.
PROBLEM 3
Implementers and Testers cannot easily move configurations between systems for co-development, testing and validation. This leads to inoperable systems, failed tests, and unhappy business users.
SOLUTION
Import and Export
Getting back to the opening of this post (remember the nightmare of configuring development systems, then test/validation systems and finally production systems?), LabVantage introduces import and export.
Beyond the thorough control over changes within the LabVantage system discussed above, the Configuration Management and Transfer feature provides a new, very powerful import and export capability.
Exports of changes can include minimum or full changes as well as validation measures to ensure data is complete.
During import to another system, the user conducting the import can determine import behavior, whether to ignore certain objects or conflicts, override changes, etc. The import also includes validation of data, proper handling of autokey generation rules, and much more.
Auditing Versus Change Controls in LabVantage
As an aside, it’s extremely important to understand a clear distinction between LabVantage auditing, and system change controls. Auditing can be done automatically on LIMS records and becomes part of the GxP audit trail.
This occurs whether the data is operating under change control or not. When operating under change control, all of that auditing still occurs – but the intention of change control is to identify starting and ending points for the change.
For example, “I opened a Change Control on January 1st, made a bunch of changes to my Test Method through January 15th, then closed the change control.” Normal LabVantage auditing will automatically capture discreet modifications to the Test Method for those 15 days, but the purpose of the Change Control is only to capture a snapshot of the record at the start and at the end of the Change Control period.
Would you like to see how LabVantage 8.5 can improve the control, management, and distribution of changes within – and between – your LIMS systems? Contact us for a demo!
