Risk-based validation means taking the right steps to manage the risk of using certain materials from a software vendor and having confidence in the system the vendor has provided. Most system vendors have developed documentation to accelerate the validation efforts of their customers; however, some vendors are offering tools that may unintentionally lead to ineffective systems and at worst, noncompliance. When risk is properly evaluated and the right supporting materials from the system vendor are used, validation costs and efforts can be reduced while still ensuring compliance. Everyone interprets risk-based validation differently, yet most companies generally look to leverage documentation created by the vendor to help reduce the burden of testing. The main challenge with this approach is making sure that there is enough objective evidence to support a validated state. Do you have a vendor auditing system in place? Do they have acceptable processes and procedures in place to assure trust in their validation processes and documentation? The proper vendor documentation can reduce your validation burden by providing you with objective evidence, including IQ/OQ test scripts, requirements documents, and validation reports. You can then perform an impact assessment to determine what level of additional testing is needed.
Even with best practices based systems, it is impossible for vendor documentation to provide truly turn-key Performance Qualification/User Acceptance Testing (PQ/UAT) documents because the goal of this part of testing is to confirm that the system meets all requirements from the user requirements specification (URS), an inherently internal document. Any PQ/UAT documentation provided by a vendor should be utilized as a template and a starting point to build your company’s specific URS and SOPs. No vendor has the ability to test a customer’s SOPs to ensure that the end users can perform the system functions and processes, which is a key step in PQ/UAT testing. Differences in each customer’s product offerings and manufacturing and quality policies inevitably result in deltas that must be accommodated in validation documentation.
Most vendors offer materials that help reduce validation efforts while still leading to a compliant system, yet there are some software and service providers that offer validation products that bring in revenue for their company without helping their customers achieve true compliance. Certain vendors have validation products that compile and run test scripts for each set of requirements with just a single click. While it certainly sounds like a simple, attractive solution to validation, there are several questions that beg to be asked. How do the reports that are run in the system map back to the original user requirements? If the system is self-validating, how can it possibly fail? Just because a process can be completed from start to finish does not mean the process is correct for the task at hand. When the validation passes, how do you capture the data to prove it and provide objective evidence?
Generating test scripts from the system based on configuration rather than from the URS is certainly suspect and borderline noncompliant; and it is simply impossible for a vendor to test for intended use and system administration since these factors are based on the company’s procedures. Furthermore, self-validating systems also present an issue when it comes time to maintain validation as system configuration changes. If the system has validated itself, how can validation be done to test any changes to the configuration without starting from scratch? While there are plenty of realistic and professional vendors looking to help their customers by providing effective documentation, products, and services to support validation efforts, companies must be careful to avoid the pitfalls that can lead to systems that do not fully meet the specified requirements and can create regulatory exposure.
Connect with Ashley Watkins on Google+.