Process validation (PQ vs PV)

GOOD VALIDATION PRACTICE (cGVP) PROCESS VALIDATION
1

Hello?
Lack of experience on process validation questions.
Please explain the exact difference of PQ and PV.
Thank you really give a concrete example.

2

[quote=zinnia7783]Hello?
Lack of experience on process validation questions.
Please explain the exact difference of PQ and PV.
Thank you really give a concrete example.[/quote]

Hi,
I have the same question. Can someone explain this?

Regards,
sheikh

3

There’s a saying that’s probably helpful: “Validate process, qualify equipment.” Process validation is the set of actions to confirm that a process results in the output consistently meeting its specifications. If there is equipment involved in the process, the equipment may need to be qualified and the common techniques include IQ, OQ, and PQ. There are no hard and fast rules and people tend to use the terms somewhat interchangeably. In the device world, the only rule is that processes whose outputs are (or cannot) be 100% verified need to be validated. How a company approaches that validation is up to them but must be defensible.

4

Thanks Yodon for your swift response.
My apology as I did not make it very clear earlier. This is what I have done.
I do IQ and OQ followed by a PV that is the end to end process instead of a PQ. The end to end process here means I perform multiple runs over all processes involved. (e.g: I have 9 different process/equipment and I do individual IQ and OQ for those 9. For PV, instead of creating individual protocol for each process, I create a PV protocol that covers all 9 processes in that. When the PV is complete, any changes to the process falls under change control process. Let say I would to replace my old equipment with a new ones, I would do a PQ that is running multiple batches for that one equipment instead of running a PV across all 9 equipment. I’m not sure if my approach is correct. I would appreciate your input here.

Thanks.

Regards,
sheikh

5

I’ve typically seen what you describe as a “PPQ” (Process Performance Qualification).

I think your approach sounds generally defensible. When replacing equipment, though, I would do IQ/OQ/PQ on that piece of equipment to ensure it does not introduce any change to the overall process. If you can demonstrate that the equipment change does not affect the output then you should be in a good position.

It would be a good idea to document this approach in either a top-level Validation Master Plan or in the process-specific Validation Plan. When you do that, you demonstrate to inspectors / auditors that you defined the approach and followed it.

6

[quote=yodon]I’ve typically seen what you describe as a “PPQ” (Process Performance Qualification).

I think your approach sounds generally defensible. When replacing equipment, though, I would do IQ/OQ/PQ on that piece of equipment to ensure it does not introduce any change to the overall process. If you can demonstrate that the equipment change does not affect the output then you should be in a good position.

It would be a good idea to document this approach in either a top-level Validation Master Plan or in the process-specific Validation Plan. When you do that, you demonstrate to inspectors / auditors that you defined the approach and followed it.[/quote]

Thanks again Yodon.
Yes, I did the IO,OQ and PQ when I replaced the equipment. That is based on the risk analysis and impact assessment that I did which concluded as revalidation (IOPQ) is required.
My question is when I complete the IOPQ for that change, do I need to run a PV or what the new term call PPQ? FYI, I have more than 30 different models that are running through that new equipment. Is PQ alone sufficient? what is correct sequence? IQ–>OQ—>PQ---->PV/PPQ or can I opt to have IQ—>OQ—> PQ or PV?

Thanks.

Regards,
sheikh

7

Without fully understanding your system, I would hesitate to say whether you need to or not. You will need to be able to defend your actions and saying you got direction from some guy in a forum wouldn’t put you in the best position. :slight_smile:

I would suggest that you do (document) a risk assessment: what COULD go wrong when you change the equipment. If you can conclude that all the risks (to product nonconformity) would be mitigated by whatever approach you choose, you’ve done your due diligence. FMEAs and Fault Trees are good tools to use to help support your risk-based decisions.

8

[quote=yodon]Without fully understanding your system, I would hesitate to say whether you need to or not. You will need to be able to defend your actions and saying you got direction from some guy in a forum wouldn’t put you in the best position. :slight_smile:

I would suggest that you do (document) a risk assessment: what COULD go wrong when you change the equipment. If you can conclude that all the risks (to product nonconformity) would be mitigated by whatever approach you choose, you’ve done your due diligence. FMEAs and Fault Trees are good tools to use to help support your risk-based decisions.[/quote]

Thank again Yodon. I appreciate that.

Regards,
sheikh