Kevin Ballard/Director of Software Validation/MasterControl
Software validation is required by law for companies that operate under the purview of the FDA and EMA. Companies must validate their systems (such as those for quality management and compliance) to comply with a number of regulations including 21 CFR 11, 21 CFR 210-211, 21 CFR 820, 21 CFR 600, and 21 CFR 1271.
Although it’s required, the FDA does not specifically tell companies how to validate. Companies are required to explain how they intend to validate their software and show evidence it has been validated the way it was explained. This lack of specifics from the FDA led to an excess of validation. At its core, validation is documenting that a process or system meets its pre-determined specification and quality attributes. In other words, software validation 1) ensures that the software has been installed correctly, 2) ensures that the product will actually meet the user’s needs, and 3) confirms that the product, as installed, fulfills its intended use and functions properly.
The FDA recommends that companies pursue the “least burdensome approach.” But how do they do that? Traditionally, companies implemented an Installation Qualification (IQ), Operation Qualification (OQ) and Performance Qualification (PQ), essentially a series of tests and documented evidence of the testing.
Installation Qualification (IQ): The FDA defines IQ as “establishing confidence that process equipment and ancillary systems are compliant with appropriate codes and approved design intentions, and that manufacturer’s recommendations are suitably considered.” For European companies, Annex 15 defines IQ as the “documented verification that the facilities, systems, and equipment, as installed or modified, comply with the approved design and the manufacturer’s recommendations.”
Operational Qualification (OQ): The FDA defines OQ as “establishing confidence that process equipment and sub-systems are capable of consistently operating within established limits and tolerances.” Annex 15 defines it as the “documented verification that the facilities, systems, and equipment, as installed or modified, perform as intended throughout the anticipated operating ranges.”
Performance Qualification (PQ): The FDA defines PQ as “establishing confidence through appropriate testing that the finished product produced by a specified process meets all release requirements for functionality and safety.” Annex 15 defines PQ as the “documented verification that the facilities, systems, and equipment, as connected together, can perform effectively and reproducibly, based on the approved process method and product specification.”
One way to achieve the “least burdensome approach” is to integrate validation into a change control process trigger, such as the installation of new software or an upgrade. When incorporating validation into such an event, effort is more likely to remain focused on verifying that the change meets user requirements and is less likely to experience the “scope creep” often associated with validation.
A company’s validation strategy should also be risk-based. The FDA currently advises that the level of validation should be parallel to the level of risk potential. Taking a risk-based approach to validation ensures that critical processes are the focus, rather than testing areas of the software that have little impact or are in low-risk areas. This lets companies focus their time and efforts on their business activities. Proper risk-based validation can help companies remain in a validated state, even when faced with frequent software upgrades. Companies are also encouraged to leverage vendor testing efforts and audit the vendor where possible. This would let them use their vendors’ test methods and evidence as their own test evidence, and further streamline efforts.
This validation approach will ensure that companies pursue the least burdensome approach, help reduce overall costs and ensure continuous compliance.
