In the software industry, changes to existing software installations generally fall into two categories, updates and upgrades. An upgrade is what occurs when a computer running Windows 8 is upgraded to run Windows 10. An update, on the other hand, is what occurs when a computer downloads and applies patches to existing software. From a risk perspective, an upgrade is more concerning, so important documents might be first backed-up in case of failure. However, updates imply much less risk, so many computers are frequently configured to allow these to be downloaded and installed in the background, often without user intervention.
At LabVantage we distribute full software releases, which are software upgrades for organizations running a previous release of our software. Companies running validated systems are usually well acquainted with the effort required to re-validate a system upgrade, which can be intensive and expensive.
We also distribute patches, which are a very specific form of update containing only a handful of bug fixes targeting a specific function. A patch does not contain a full software release, rather, touches a certain number of files related to the fix. These are rather easy to validate since the organization has already determined that the fixes are required for their system, specific testing of the function can be very precise, and there’s a guarantee that other portions of the system remain unaffected.
Finally, LabVantage distributes maintenance releases, which contain a full release of the software and include fixes for bugs identified up to a certain point in time. For customers installing new systems, this is the most convenient method of ensuring software quality: rather than installing the full release and applying a bunch of patches, a maintenance release contains both of them all in one convenient package.
Additionally, using a maintenance release has the following benefits over applying individual software patches during a software update.
- Eliminates questions concerning the order of patch installations
- Consolidates fixes affecting entire functions
- Greatly reduces the potential for installation errors
- Eliminates potential for missed notices regarding critical fixes
- Validates that all fixes work together properly
- Improves the turn-around-time of software fixes to the customer
However this raises the question, “What is the best method of validating a LabVantage maintenance release when performing an update?”
The simplest manner of explanation is to consider all aspects of a risk-based software upgrade, keeping in mind that the amount of effort required to execute this update will likely be orders of magnitude less intensive and expensive than an upgrade. Borrowing from the ICH Q9 Quality Risk Management method, the steps to assess the risk of a maintenance release are as follows.
Risk Assessment
Included with the LabVantage maintenance release is a spreadsheet called Software Fixes Report that contains a list of all fixes made to the software since the last release. The data provided is as follows.
- VC ID: The ID of the bug as recorded in our Vantage Care software
- Product Risk Priority: The risk priority to the product as determined by an ICH Q9 style analysis, which includes a consideration of the potential regulatory impact, the urgency of the customer business case and more. This attribute uses a 4-point classification of Critical, High, Medium and Low.
- Functional Area: The area of the software affected by the issue
- Description: A brief description of the issue
- Root Cause: A technical analysis of what caused the issue
- Fixed Note: A technical description of what was changed
- Modified Files: A list of files that are included in the patch
- Steps to Reproduce: A list of steps to reproduce the issue prior to applying the fix
Start by filtering the spreadsheet to remove all issues having functional areas not used in your system. For example, a pharmaceutical laboratory would hide all issues having a functional area called BioBanking; similarly, an organization that does not use the LabVantage Workflow capability will hide all Workflow-related issues.
Next, filter the spreadsheet to hide all Medium and Low issues. These may require later inspection, but most risk-based approaches would not require any mitigation for items having these severity levels.
As a final step of risk evaluation, review the Steps to Reproduce column against the operations of your laboratory and hide any issues that are not relevant to your organization. For example, if an issue only affects systems with product names over 40 characters and your organization standardizes all products with a 6-digit code, then the issue can also be hidden.
Risk Control
Now that the list of issues has been culled based on potential risk, sort the spreadsheet by functional area and begin to plan the tests by function keeping in mind that some testing can be easily combined. For example, tests for data entry might easily be combined with those relating to batch management, since batches require data entry as a step toward release. Of course, this manner of control assumes the desire for complete prevention through objective validation, although other methods of risk control (e.g., avoidance, reduction, sharing) might be acceptable.
Output / Result of Risk Management Process
Continuing the ICH Q9 risk method, the next step would be to use the output of the risk assessment as an input to the test plan, thereby scaling the validation effort to only include only those tasks and activities that represent potential risk to your organization.
Although planning to receive a maintenance release of software might be new, a balanced, risk-based approach will allow your organization to keep its LIMS running smoothly and within all the expectations for systems running in regulated environments.
