Showing posts with label PQ. Show all posts
Showing posts with label PQ. Show all posts

Wednesday, March 23, 2016


WHY  VALIDATE? 

The simple answers:  "It's the law." "The CGMPs require it." 

The real answer:  Yes it's the law, and the CGMPs require it.  But let's look beyond such negative motivators. 

Consider the real purpose of V&V. Not to satisfy a reg or audit, tho that's what motivates many. The real purpose is to prove that whatever you're verifying and validating (V&V) does what it's required to do, why it was acquired and installed (requirements)? That requires that before you spend time on other V&V activities, you verify (inspect, test, check, qualify) that it is installed properly, i.e., all applicable manufacturer's requirements have been met (electrical voltage, current, grounding, air exhaust, air treatment, safety, environmental prep, and so on). If this isn't done first, then subsequent V&V activities are compromised. 

If some process or equipment may have been running for X years, and will be retroactively validated, it's safe to assume that it's installed properly. However, "assume" is not in the QMS (Quality Management System) vocabulary, so even with an established system, some checks must be performed (IQ), and all QMS' require documentation of that activity. You may do so and find some problems which will have to be addressed. Then you can progress with verifying and/or optimizing the settings used (DOE may be involved), whether you call it an OQ or not. Then you challenge the system repeatedly with all the extremes of allowable inputs (material, personnel, times of day, utilities fluctuations, etc) to show (whether you call it a PQ or not) that the system being V&V is robust and will virtually always deliver expected levels of quality with known and acceptable levels of variation (see recent drug process validation guidance from FDA), which will change / improve over time / lifecycle. These should be done, as needed, all or part, over the life time of the product / process / equipment involved. 

-- John E. Lincoln, J. E. Lincoln and Associates LLC; jelincoln.com      
RETROSPECTIVE  VERIFICATION  AND  VALIDATION (V&V)

Based my 30+ years experience with the FDA, "deviations" and definitions as "legacy" won't cut it with them regarding omitting a validation. The FDA does accept retrospective V&V on processes and production / test equipment, and expects the documentation to be thorough, though much of your data can be reduced by a review of the last several lots through that process / equipment. With a retrospective validation, you do what you can, but I would certainly include an IQ, OQ, and several PQs (or DHR reviews, documented, covering varying operating conditions, shifts, operators, and RM lots) as part of that. Your procedures for such V&V should be addressed in an SOP and/or a Validation Master Plan, as well. 

Software must be fully validated, and hardware / equipment can be validated to the extent that there is no 100% downstream verification (QC / inspection) performed / documented. As part of Lifecycle considerations, you are required to re-V&V or at least re-evaluate the need for additional V&V, periodically (defined in your SOP / VMP) any way, so, if not done at all up to the Current time, you would be expected to do it starting as of the present. I've never seen the FDA give a company a "pass" on validation just because it wasn't done previously, and have lost several arguments along that vein with their auditors and the relevent FDA District Office.

However, the FDA prefers prospective V&V, because, by definition, retrospective means product was built and released previously using non-V&V'd processes / equipment, in violation of the CGMPs, and hence that product is technically "adulterated" -- challenges to such by companies have ended up in court, and no matter the outcome in the court, have been extremely costly to the company in terms of share value, lost market share, public reputation, and an adversairial relationship with the Agency, and have not changed the Agency's policies to such situations.
        
True, you can reference ASTM E2500 to justify not using the terms IQ, QO, PQ, but are still expected to "verify" (qualify, inspect, check ...) proper installation (or "IQ"), proper selection (and initialization) of settings / parameters / tolerance ranges (or "OQ"), and consistent reliability / reproducibility, et al, of your equipment / processes, under allowable "worst case" conditions (all worst shift variations, RM / lot variations, power / air fluctuations ...; or "PQs"). And as evident by some forum discussions, define your terms in your documents (validate, verify, qualify, commission, FAT, SAT, etc) with your own "working definitions" under the broader (but harder to "real world" implement definitions under the CGMPs and/or ISO.  -- John E. Lincoln, J. E. Lincoln and Associates LLC; jelincoln.com      
IMPORTANCE  OF  MULTIPLE  PQ  RUNS

Recently I had to disagree with several postings on a popular validation forum on the minimizing of the importance of several (more than 3) PQ (Performance Qualification) runs in a validation. 

The goal of a validation is to assure that the equipment and process produce acceptable product (CGMP and ISO definitions, e.g., 21 CFR 820.3z (1, 2, and3)), repeatedly, and reproducibly. The product is verified by adherence to validated process / equipment parameters and/or QC inspections (100% automated (validated) or sampled) / verifications. And to assure such, the PQ runs should incorporate all foreseable allowable variations in inputs, especially allowable worst case variations, e.g., RM (raw material), personnel, work shifts, power variations, tolerance ranges of all acceptable settings, et al. Failure to do any of this results in the many production "surprises" that appear to be behind most product recalls. So, getting back to the original question, one's production equipment / process validation should include several PQ runs with varying lots of RM -- which can be a challenge with silo / rail car / truck-trailer loads of the same lot of RM, different products expected to be run on that line, the different work shifts, and week ends / holidays, different acceptable power / compressed air loading, ..., if the line normally runs then, and similar considerations.

With large incoming RM lots, e.g., APIs (Active Pharma Ingredients) or plastic resin lots (molded plastic parts), I might choose to run three PQs at least to validate the process and that first RM bulk lot. Then release lots having that RM bulk lot could be released to the field.  Then as another bulk lot came in, I would run at least one more PQ using the new lot, to quality that FG lot using the new RM lot to be released.  I would then do one more PQ on the next bulk RM lot, to qualify it.  If there were no evidence of major variability in those three RM bulk lots, I would probably then consider the process with it's "worst case" allowable RM lots to now be fully validated, unless further QC / CAPA monitoring pointed to some additional problems.

Why a minimum of 3 lots?  The FDA has backed away from 3 as a de facto minimum for PQ runs; and with good reason.  One run proves nothing.  Two runs does not prove a pattern.  Three runs may if there's minimum variability between process inputs.  But in many cases, more that 3 may be required, as in the example of bulk RM mentioned above.  Other examples of allowable "worst case" inputs, were as alluded to in the first paragraph:  If your production runs 24/7/365+, then you might want to do 3 runs on 1st shift weekdays, to prove the process design, and add a 3rd shift, and/or a Sunday, and/or a holiday, or all, for a total of 4, 5 or 6 PQs to cover potential problems caused by reduced supervision, casual attitudes of operators, impaired behavior of operators, or similar, due to odd shifts and/or holiday work.  A further example of allowable worst case variables could be software / apps platforms, e.g., iPhones, Android phones, iPads, tablets, Macs laptops, Surface laptops, Android laptops, Mac desk computers, PCs, Unix, mainframes, servers, and so on, each with it's own PQ if required.

Another consideration alluded to above might be a company's electrical and/or compressed air variability in it's internal grid, e.g,. brownouts, especially when every one comes in to work at the same time and throws the power on to each of their workstations.  If product is produced at that time, some may be compromised, not getting the full amount of electricity or air that the validated parameter settings imply, until the grid(s) stabilize.  UPS and surge tanks may help, but these are some examples of considerations in validations I often see omitted.
  
Your company's unique situation and it's allowable varying worst case inputs would assist in making such a determination.  A cause and effect diagram can help in determining worst case allowable process inputs.  -- John E. Lincoln, J. E. Lincoln and Associates LLC; jelincoln.com  

Updated: 06/20/2022