The short and simple answer is this – Process Validation is a means of demonstrating to a statistically valid level that a process, when followed rigorously, delivers results consistent to a predetermined set of requirements.
In pharmaceutical manufacturing and volume production of any kind a solid, clean, validation of a process is needed to have a high degree of confidence that each and every part or product coming off the line is within the requirements for the product.
Process requirements vs Product requirements
Requirements for a Product apply to an individual deliverable from a process. These requirements are separate from the Process requirements – while a process is used to create a product the product requirements tell you if the product is valid. Product requirements for a machined part are contained in the drawing for the part – features and tolerances and materials and finishes. Product requirements for a pharmaceutical are contained in the product performance records developed during clinical studies, and the percent of active to inert material(s) in the product. Product requirements for a vehicle are defined in the Product Requirement Document (PRD) and describe performance, size, features, etc. Measuring a product against product requirements is called Verification or Inspection and is done one product at a time.
Requirements for a Process apply to the steps taken to create a product, including the pace (takt), inspection or verification method, allowable fallout, etc. These requirements use the process requirements only to verify that the process output is within operating parameters by comparing to a run chart or a control chart. Process Requirements are contained in the Procedure (a procedure is a document describing a process). Monitoring the process to see if it meets the process requirements is Verification of the process.
When to validate a Process
If you have a process where every product is inspected then a process validation may not be needed – validation is typically needed in cases where the output is not 100% verified. Let’s assume you have a process that makes car seats. These are not sold individually, they are assembled into cars. When the car seat comes in the back of the building they get an initial check for shipping damage and then put on the production line. When the seats reach the installer they get installed and checked by the operator – it is the operator’s responsibility to notice any defects. As the vehicle proceeds down the line the seat will be examined and tested for functionality and visually inspected by no fewer than 21 additional people, all of whom have been tasked with finding defects and stopping them from leaving the plant. This level of inspection on every single car seat means the process for making the seats does not require validation – the output is inspected 100%. On the other hand, the vendor making those seats may validate the process anyway since they are under tremendous pressure to never, ever, deliver a bad seat.
HOWEVER – if the operators on the line were not given the responsibility of finding defects and were told to keep product moving out the door no matter what, NOW the process needs to be validated.
How to Validate a Process
Validation is not a thing unto itself. It is a series of several cascading elements ending in a continuous improvement effort. Here are the steps:
- Product Requirements – this describes the requirements for a single product so it can be measured and verified.
- Process Requirements – this describes the process requirements so it can be monitored and verified.
- Process Development – the work to build a real process by establishing these elements:
- Equipment Selection Operational Requirements
- Process Map
- Takt Time and flow requirements
- Equipment Installation Qualification (IQ) – done for each piece of equipment to verify the installation meets manufacturer’s requirements, city requirements, safety requirements, etc.
- Equipment Operational Qualification (OQ) – done for each piece of equipment to demonstrate the equipment meets the operational requirements
- Performance Qualification (PQ) – done for the entire process to demonstrate the process meets the process requirements. This will include meeting the product requirements in order to meet the output requirements in terms of yield.
The Performance Qualification needs to include instructions for the frequency of repeating the PQ to demonstrate consistency over time, including what to do if the on-going PQ data indicates the process is exceeding the Process Requirements (reduction in inspection or increase in duration between PQ) and what to do if the data indicates the process is not meeting the Process Requirements. In other words a validated process is one that has been qualified, uses qualified equipment, and is being monitored long term to assure the process remains in a qualified state. Once the monitoring stops the process is no longer valid. Keep in mind, Performance Qualification should cover multiple challenges of the process. A single demonstration of a process is a sample of one, and a single sample is not statistically significant.
A word on PQ
FDA (21 CFR 211 for Pharmaceuticals) has guidance that describes PQ as two parts – first is the design of the facility and the qualification of utilities and equipment, the second is Process Performance Qualification, PPQ. In this guidance the FDA has mixed the terms PQ and PPQ such that folks outside of Pharma get asked for a PPQ and they don’t have a good answer. The answer is pretty simple – PQ, as described above in this post, qualifies the process and in a Pharmaceutical realm it would be called PPQ. In the Pharma realm a PQ is built from the list above – Requirements, development, IQ, and OQ. The PQ is now named PPQ, and the Validation itself is now named PQ – Performance Qualification. So for everyone outside of 21CFR211 we tend to refer to the performance qualification as PQ, Pharma Pholks refer to this as PPQ. When they say “PQ” they are referring to the overall validation with all its components.
sigmakatadojo.com 