Completing a Final Validation Package in Risk Based Software Validation
Part 6: What should be included in my final validation package?
So, you’ve gone through the process and are completing the final validation package in Risk Based Software Validation. The question now is, what should be included in the final validation package? Consider the need for documentation which provides evidence that you completed your validation, records how you will use the system, and documents how you will mitigate any associated risks.
Your final validation package should include the following:
1. Process Mapping
- Process maps for each critical business process identified within the facility
- List of touch points to the critical software systems within each business process
- User Requirements document for the software system
2. Risk Assessments
- Risk Management Plan
- FMEA for the software system
- Risk Management Report for the software system
3. Functional Requirements document for the software system
4. Installation Qualification (IQ) Protocol for the software system
5. Operation Qualification (OQ) Protocol for the software system
6. IQ/OQ Execution protocols for each software system
7. Summary Report and Traceability Matrix
- Summary Report for each software system
- Traceability Matrix for each software system
Summary Report and Traceability Matrix
The Summary Report and Traceability Matrix are key documents. These documents will link all of the other documents together and will be the means by which you can quickly find all documentation related to each of the critical process that you have validated. Both you and any auditor that reviews your validation will find this document to be an invaluable tool in determining what documents and evidence exist and how they relate to the each process.
With the above documents, you’re now well positioned for any compliance audit that may occur. You also now have the tools for accomplishing the validation of any updates that you may need to make as you develop the use of your software, using the same Risk Based Software Validation process that you used for the initial validation – but that’s a whole new blog.
What about Performance Qualification (PQ)?
There is one document that we haven’t listed – the Performance Qualification (PQ). Why? Well, strictly speaking, at the completion of the validation, the performance qualification will not have been done. This is something that you would typically do once the system is ‘Live’. The PQ will provide you the verification that your process(es) and mitigation’s are consistently working as intended and will provide the means to document any changes that you may need to make if they aren’t. Do you have to wait until you are ‘Live’ before you do the PQ? No, you can run the PQ in your pilot environment prior to go live if you want but, since the PQ is designed really to be something that you typically complete over a period of perhaps weeks or even months, deciding to maintain your pilot environment for that length of time without going live, may not be something that you are willing to do.