"Requirements" Validation 

A simple way to structure a Validation Test report that involves IQ, OQ, and PQs, or their equivalents:

1.  List all Requirements, e.g., Use-, Functional-, Standards, Guidance Documents, Marketing, Company capabilities, etc;

2.  Pull out those Requirements that deal with Installation (e.g., software in hardware, equipment in the facility, etc); and place these into an IQ / checklist;

3.  Take all the remaining Requirements and place in the OQ, writing at least one test case for each Requirement (the number of test elements in a test case is determined by risk to the patient / end user of the action / component / factor produced by the activity being validated);

4.  Take those OQ Requirements and determine which can be impacted by "allowable worst case variances" in your company, and place those also in the PQs, which are challenging repeatability, replicatability, reproduceability.  

E.g., if your company runs 24/7 and you're validating a piece of production equipment, you might have one PQ for the Day Shift, one for Swing, and one for Night, also one for Weekend / Sunday, and one for the next upcoming Holiday, for a minimum total of 5 PQs. 

If you're validating smart instruments usage and/or their applications / software / firmware, you might have 1 PQ for an Apple phone iOS, 1 for an Android phone, 1 for an iPad, 1 for a Tablet, 1 for a Mac laptop, 1 for a Windows laptop, 1 for an Android laptop, 1 for a Mac computer, 1 for a Windows computer, 1 for a Unix computer, or 1 for a workstation and / or 1 for a Server, and/or 1 for Mainframe, depending upon what smart instruments are allowed for use in your company *. 

Note:  the FDA has backed away from a de facto "rule of three" PQs.  You determine the number based on the above discussion.  In no case can you have less than three, in order  to prove the  3 "R's" listed above pertaining to the purpose for the PQ (to prove repeatability / reproducibility / replicatability using "allowable worst case inputs"). **

See Q&A #5:  https://www.fda.gov/drugs/guidances-drugs/questions-and-answers-current-good-manufacturing-practice-regulations-production-and-process#5  *. 

And PQ test cases would have many samples (vs. OQ test cases, which basically verify the existence and proper operation of a Requirement; hence I usually include Part 11 and cybersecurity test cases in the OQ), e.g., n=30, or n=125, or n=525, etc. (with justifications for sample sizes chosen).

I like to also have each PQ have a Shut Down, Cool Down and Start Up cycle Test Case included.

I also like to have one Unplanned Power Outage ("Pull the Plug") Test Case for all the PQs, if feasible, and definitely for software / firmware V&V to test UPS' / back-up generator functions.

- jel@jelincoln.com

08/03/23 added "back-up" to generator. - JEL

* 10/13/23 added "depending" phrase to end of para. 7. And added source for the demise of the "rule of three". - JEL

** 05/01/24 added parenthetical phrase at end of note. - JEL

       

 

Test Method Validation

Ques:  Test Method Validation, when is it required?  Only on CTQs (critical to quality)?  What is the logic behind determining if its applicable?

Ans:  Whenever you use a test to address a CGMP requirement, it is your responsibility to ensure that the test is appropriate to need and yields accurate results (see US FDA's  Data Integrity Guidance Document).  If it’s defined by a standard, USP, or similar, then it can be used as-is, ‘tho’ I would recommend some minimum verification of your company's usage, documented, initially and periodically to ensure that all variables behave as expected. 

If it’s a variation on an established test, or new / developed in-house, then it would need to be validated. 

If a test is used on CTQs, then the degree of patient risk (e.g. ISO 14971 or ICH Q9) needs to be considered as to the rigor / depth of the validation, and frequency of checks / verifications that the validation does not need to be re-done.  You as a company make these decisions, and document them, though they are subject to challenge by a regulatory inspector.

How your company addresses the above, under what conditions, would be outlined in a company SOP.

-  jel@jelincoln.com