How to write Retrospective Validation Protocols without being backed into a corner by over zealous consultants, there are many instances when retrospectively validation has to be undertaken.
Some of the reasons we have encountered are listed below. This is in no way meant to be a definitive list;
In most cases it is necessary to start with a validation plan, in which the scope, the action being taken and the responsibilities can be detailed. From then on use the standard layout for your IQ's and OQ's. When the IQ and OQ are completed and the P1Q, and where required, P2Q, ensure that use an abundance of production data, produce and review plenty of it. However if the existing production data shows that the process is not consistently producing in accordance with the process specification, then you must sort out the process first. Review the whole process and ascertain where and what is causing the inconsistencies to occur. Validation is not an exercise to get the process right. You validate once your process is consistently producing product to the expected specification. Once you are certain of this, then follow your own - How to write Retrospective Validation Protocols.
Do not forget that validation is all about documented evidence. If this is a retrospective validation you will have records of the performance of the subject equipment, use them fully. Use your Validation Risk Assessment to define the validation scope and author your protocols accordingly.
Use your Validation Risk Assessment to define the validation scope and then raise your own version of; How to write Retrospective Validation Protocols.
If this system has never been validated, then you have no alternative, you must raise the full Installation Qualification (IQ), Operational Qualification (OQ), Performance Qualification PQ and perhaps Design Qualification DQ, get them approved and then execute them.
If this system is being re-validated because of discrepancies with the original validation. Then you should raise a Supplementary IQ and OQ, or in an instance where the system is small or very simple, a combined IQ/OQ. In the supplementary protocol you can review the existing validated status and list additional tests / inspection as you think necessary.
Think well before going down this road, it does highlight to a regulator all the things that were missed in the original validation exercise. The paperwork trail can become messy between original protocols and supplementary protocols. It is often best to declare that a validation review (for any of the listed reasons) is to be carried out. On the bases of the review outcome, revalidate equipment as required. Keeping the paperwork nice and simple.
Why does something as simple as a spreadsheet figure in so many regulatory citations? Good question; and at times a difficult one to answer. When you ask a group of compliance personnel the same question you will be informed that Excel cannot be validated because it does not seal the original copy (of the spreadsheet), allows the original to be modified and has an audit trail that can be disabled. All true, but none of these problems interfere with your ability to validate that the spreadsheet is fit for purpose. They only preclude you from using the spread sheet as a compliant repository for any data that has to be store in compliance with 21 CFR Part 11.
If the spreadsheet is signed off and dated by the user, their supervisor and QA, it becomes regulatory acceptable data stored in hardcopy, and Part 11 does not apply.
After numerous request for this, we have launched our brand new SOP for Spreadsheet Creation to cover these and other known target points that the regulators consistently hone into as soon as they find that spreadsheets are being used. Use this Spreadsheet Creation SOP to ensure that you create spreadsheets that are validatable. Then use our spreadsheet validation pack to validate them.