Computer System Validation (CSV) is a process that organizations–particularly those in industries where there is potential risk to the public like product manufacturing and healthcare–go through to ensure products are safe, reliable, and effective as required by regulating bodies like the FDA and CAP/CLIA.
We are often asked by clients and prospects if our LIMS software, Labbit, is fully validated off-the-shelf. The answer is no, as it is actually not possible for a vendor of configurable software to provide a fully pre-validated system. The reason is that the software is a component of a unique system and validation requires investigation into how it operates within that system. Additionally, it is the responsibility of the system’s owner to validate it in the eyes of regulatory agencies. CSV requires more than software testing; it requires a combination of software assurance, good procedural controls, and system governance.
That being said, a software vendor like Labbit can provide a system that can be validated and also make this an easier process by providing documents, automation, and services.
This article aims to demystify system validation with clarity on the different activities involved, where and how a software vendor can provide assistance.
First, a little background information
The overall goal of computer system validation is to prove that laboratory processes like tests and workflows operate as intended. At a high level there are three steps to validate any part of a process:
- Say what it is going to do
- Have it do what you said it was going to do
- Provide unalterable evidence that it did what you said it was going to do
Before we dive into where and how a software vendor can help with validation, it’s important to outline four categories of functionality that dictate how challenging a task it will be:
- The functionality is used exactly as intended out-of-the-box
- The functionality is used as intended out-of-the-box, but the system requires some configuration to make it work how the lab needs it to, like setting up a lab’s specific location hierarchy for example
- The functionality is used as intended out-of-the-box but the software has been extended through custom coding to cover feature gaps
- The functionality works in a different way than intended through customization of the underlying system
At this point, we should clarify the difference between configuration and customization. Configuration involves setting up software applications using predefined options and settings provided by the software vendor. This process does not involve writing code. Customization involves adding additional code to the to add or alter existing functionality, or integrate with other systems. This process can significantly change the software’s behavior and appearance.
Computer System Validation: What’s involved?
The Labbit Computer System Validation Methodology involves a series of qualifications:
- Installation qualification (IQ) – Was the software installed according to the vendor’s specifications and all necessary components and documentation in place?
- Operational qualification (OQ) – Does the software operate how it is supposed to according to the specified functional requirements?
- Configuration qualification (CQ) – Do the client’s specific configurations of the software work as expected? Are configurations documented and any changes made through a controlled, recorded process?
- Performance qualification (PQ) – Does the whole overarching process perform as it should from start to finish? Does it operate at the required performance level?
Let’s examine each of these individually and highlight how a software vendor can assist with each.
Installation Qualification (IQ)
As mentioned, this qualification aims to demonstrate that a component of the system, in this case, the software, was installed correctly. A software vendor should have a list of specifications that should be met–CPUs, memory, disk space, wifi bandwidth, even environmental conditions like temperature–for the product to work as intended.
This information is general and not customer-specific and can be provided by Labbit or whichever vendor has created the software in use.
Operational Qualification (OQ)
The purpose of this qualification in the case of software is to show that all of its features, as supplied by the vendor, work as intended and it is free of critical bugs.
As is the case with IQ, this qualification is not customer-specific information and Labbit can show unalterable evidence that its features have been tested to ensure they operate as expected in all scenarios.
Configuration Qualification (CQ)
This validation involves ensuring that any configurations made to the off-the-shelf software (recall from earlier that this refers to configurations made within the software to ensure it works as they need it to like setting up the lab’s location and storage hierarchy) operate as intended. This includes verifying that all components, settings and parameters are configured according to predefined specifications and that any changes are managed through a controlled process.
Configurations should be performed on a system in a controlled, well documented manner. For example, configuration requirements should be managed in a requirements management system, and should fully define acceptance criteria. The system should support the import/export of files that fully define system configuration so that these files can be stored in a revision control system. The configured system should be progressively tested by users, confirming adherence to the acceptance criteria. And ideally, the system supports the efficient creation of CQ evidence as the iterations progress.
Performance Qualification (PQ)
This qualification aims to demonstrate that the entire process performs as intended. As mentioned, this is the responsibility of the owner of the process to provide unalterable evidence that the process and its outputs are safe, reliable, and effective.
In addition to providing documentation for IQ, OQ, and CQ, some software vendors, like Labbit, offer services to help with this more comprehensive validation step.
This video outlines a commonly used methodology for computer system validation.
In conclusion, choosing the right LIMS software is crucial for achieving validation with minimal complications. Custom-coded or significantly modified software can complicate the validation process due to a lack of existing vendor documentation. Additionally, as validation ultimately falls on the customer, relying on vendor IQ and OQ documentation is feasible only if the vendor demonstrates an understanding of the full validation process and how these documents fit within it. Customers should adopt a risk-based approach, concentrating resources on high-risk areas of the system while considering vendor-tested components as lower risk. Thus, clients should primarily focus on Configuration Qualification (CQ) and Performance Qualification (PQ).
