"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