DEDICARE  CONSULTING
PARTNERING for success
 
 

KNOWLEDGE BASE

 

Featured Article - The Terminology Conundrum


Several of the projects that I have worked on involve validation in its numerous forms.  One obstacle that I often encounter is confusion around the terms Installation Qualification (IQ), Operational Qualification (OQ) and Performance Qualification (PQ).  It is no wonder that confusion exists here as the regulations (21 CFR Parts 2111 and 8202) are silent on these terms, and the guidelines and standards (GHTF Process Validation3, FDA Guideline on Process Validation4, ASTM E25005, USP <1058>6, GAMP 57, to name a few) do not align.  To confuse the matter further, the application of these terms varies between the Drug and Device realms, and between system types.  This confusion in terminology can lead to a lot of miscommunication, which can waste valuable time, not to mention result in a lot of frustration.    

Let’s first look at installation qualification or IQ.  The GHTF guidance document on Process Validation, which was written primarily for the medical device realm, defines IQ as “Establishing by objective evidence that all key aspects of the process equipment and ancillary system installation adhere to the manufacturer’s approved specification, and that the recommendations of the supplier of the equipment are suitably considered.”  USP <1058>, which was written for analytical test methods, defines IQ as “The documented collection of activities necessary to establish that an instrument is delivered as designed and specified, and is properly installed in the selected environment, and that this environment is suitable for the instrument.”  The FDA Process Validation Guidance document, which was primarily written for the drug realm, does not use the term IQ, but it does imply an IQ of sorts through the use of the term “qualification” to verify “facilities, utilities and equipment” are “suitable for their intended use”.   Although IQ is not specifically referred to in the FDA Guidance, IQ is used prodigiously in the drug industry to qualify facilities, utilities and equipment.  GAMP 5, which addresses software validation, uses the term “installation testing”, to address testing of hardware and software, and correlates this to the definition of IQ provided by the PDA or “Documented verification that a system is installed according to written and pre-approved specifications”.    

It is clear among the various guidance and standard documents that IQ is intended to verify the installation requirements of system types including: process (manufacturing) equipment; test instruments; software; facilities; and utilities.  Furthermore, industry norms agree that installation verification typically includes:  system identification; configuration; utility requirements; environmental requirements, supporting documentation; preventive maintenance; calibration; and spare parts.  What is not so consistent with IQ is whether or not it includes verification of the functional elements of the system (e.g., the operating temperature of a curing oven).  In my experience, these functional tests are frequently included in the IQ effort for manufacturing equipment in the device realm.  Some companies differentiate this from pure IQ by calling it IQ/OQ, equipment OQ, or identifying specific sections within the IQ protocol.  It is important to note that this functional testing measures the performance of the equipment (e.g., temperature, speed, pressure, flow rate, etc.) and not the output of the process (e.g. tensile strength).  In the drug realm, or with other system types, these functional tests are typically performed under OQ.

While the interpretation and application of IQ is fairly consistent across different industries and system types, OQ can be a lot more confusing.  The GHTF guidance document defines OQ as “Establishing by objective evidence process control limits and action levels which result in product that meets all predetermined requirements”.  USP <1058> defines OQ as “The documented collection of activities necessary to demonstrate that an instrument will function according to its operational specification in the selected environment.”  The FDA Process Validation Guidance document does not use the term OQ, but it does describe studies that are performed during the design phase to gain “process knowledge and understanding” including the process variables and their relationship to the resulting process outputs.  Looking past the terms, the FDA guidance and the GHTF appear to align as they both address process parameters (variables) and their relation to the process outputs (product).   Although OQ is not specifically mentioned in the FDA guidance, I often see the use of OQ (following a similar approach to GHTF) in the drug industry.  GAMP mentions “operational qualification of infrastructure components”, and refers to the OQ definition from the Parenteral Drug Association (PDA) or “Documented verification that a system operates to written and pre-approved specifications throughout all specified operating ranges”, but it does not call out specific tests for OQ. 

With OQ, the first level of confusion arises as to which system type OQ applies.  GHTF and FDA Guidance align to the manufacturing process, but the other standards apply to facilities, utilities, equipment and method.  The second level of confusion with OQ is as to what is being tested within OQ.  FDA guidance and GHTF measure process performance through the product requirements, but OQ for facilities, utilities, equipment, and methods is focused on the performance of the system (e.g., temperature of the oven).   To distinguish the difference between these two types of OQ, and thus avoid some of the confusion, I refer to the process-focused OQ as “process OQ” and non-process-focused by the specific type of system to which it applies (e.g., “equipment OQ”, “facilities OQ”, or “instrument OQ”).  The third level of confusion with OQ is as to what conditions are applied during OQ testing.  When referring to manufacturing equipment and software, it is apparent that conditions involve the extremes or “worst case” testing of the system variables, but with methods testing, according to USP <1058>, testing is performed “in the selected environment”.  OQ testing for facilities is often performed under static conditions, but conversely utility testing, as in water system testing, is performed under extreme load conditions.  A further distinction within equipment OQ is that where systems consist of multiple components, performance is measured at the component-level vs. the overall system, which is typically addressed during PQ.   An example of this would be to verify the integrity of a HEPA filter that is part of the larger facility system.  

Why is Process OQ needed?

I am often asked, “Why is Process OQ conducted if it is simply a repeat or confirmation of the studies conducted during process development?”.  This question seems to be fueled by the fact that the FDA guidance indicates that this testing is a design phase deliverable, and does not even mentions OQ.  On the other hand, I often see OQ being conducted in the drug industry.  In some cases it does appear as if the Process OQ is redundant with the prior developmental studies; many OQs do look a lot like the DOE confirmations that were run during process development.  However before you jump on the redundant band wagon, it is important to consider several factors.  The first factor is, what realm are you in?  If you are in the drug realm, there may be more regulatory acceptance of leveraging the process development studies for OQ, but in the device realm, where a formal OQ after development is firmly established, this would present higher risk.  The second factor is, in what environment were the process development studies conducted?  Were the studies performed in the lab, a pilot area or in the manufacturing location?  The environment could have a significant effect on process performance for some processes, so if studies were not conducted in the actual place of manufacturing (typical for process OQ) performance may be very different than what was obtained in the lab.  The third factor is when in time, and in terms of the product life-cycle, were the studies conducted.  This could be a significant factor if changes have been made between the development and process OQ activities.  The fourth factor is, what state was the equipment in during the studies?  Was the equipment IQ’d, and was it under a state of change control?  If the equipment was not IQ’d, are you confident that it was installed properly and operating according to specification?  The fifth factor, is how well were the engineering studies documented?  If there is no documentation or the documentation is inadequate, leveraging the prior studies for process OQ becomes very difficult.  If you can adequately address each of these factors, then you have a good case to leverage the development activities for process OQ, but in my experience, it is very rare that all of the factors are addressed adequately.  This is why development followed by process OQ is the standard for the device realm, and is practiced with increasing frequency in the drug realm.      

Performance qualification is defined by GHTF as “Establishing by objective evidence that the process, under anticipated conditions, consistently produces a product which meets all predetermined requirements.”  FDA Guidance defines Process Qualification as “Confirming that the manufacturing process as designed is capable of reproducible commercial manufacturing”.  It also describes Process Performance Qualification (PPQ) as “[the combination of] the actual facility, utilities, equipment (each now qualified), and the trained personnel with the commercial manufacturing process, control procedures, and components to produce commercial batches [or finished product].  USP 1058 defines performance qualification (PQ) as “The documented collection of activities necessary to demonstrate that an instrument consistently performs according to the specifications defined by the user, and is appropriate for the intended use.”  GAMP defines Performance Qualification through the PDA, verification that the overall system is “fit for intended use” under “anticipated use” conditions.

As with OQ, confusion arises as to which system type PQ applies, and like OQ there are two distinct types.   I refer to the process-focused PQ as “process PQ” and non-process-focused by the specific type of system to which it applies (e.g., “equipment PQ”, “facilities PQ”, or “instrument PQ”).  Process PQ is focused on measuring the output of the process (the product performance characteristics), where as other forms of PQ are focused on the performance of the overall system, with all system components working together (e.g. the purity of the water in a water system).  Within process PQ there is some confusion as to scope.  The FDA Guidance PPQ involves all manufacturing processes working together to make a finished product, where as GHTF implies that PQ is performed on each individual unit operation.  In my experience, regardless of the realm, the FDA has come to expect an “overall” PQ or PPQ on the finished product, which I call “product PQ”.  This is also sometimes referred to as PV in the drug realm.  However, there is some inconsistency and debate as to whether or not PQ should be conducted on individual unit operations, which is what I call “process PQ”.  In my experience, it is prudent to perform process PQ when: 1) the output(s) of the process cannot be evaluated in the finished product, and 2) when a higher degree of confidence is desired before investing in the usually more extensive product PQ.     

Within process PQ there is agreement that the conditions for testing are “normal production” or “anticipated” conditions (not challenge or worst case like process OQ).  However, in the case of equipment PQ, there is less agreement with regard to the conditions of testing.  For example, facilities PQ is performed under “dynamic” conditions where the room is fully burdened with personnel and equipment, where as water system PQ is usually performed under normal conditions.   There is agreement among all types of PQ that an element of repeatability or consistency is to be satisfied, which is practiced through multiple runs or over periods of time (not like OQ, where test cases are usually executed once).

Why is Product PQ needed?

The product PQ has become an industry standard as investigators, and manufacturers alike have recognized that there is more to production that can affect product performance and compliance than the individual unit operations.  The so called “ancillary processes” such as material movement, personnel movement, equipment set up and break down, shift changes, etc. can all have a significant impact on product performance.  This is particularly true with more complicated manufacturing work streams.  There are also other quality system elements that are exercised during the product PQ such as quality control sampling, process monitoring and control, the non-conformance process, documentation control, personnel training, etc., and the product PQ is good opportunity to evaluate the performance of all these systems working together.  In my experience, product PQ has demonstrated its value over and over again by revealing deficiencies with the ancillary processes and other quality system elements.  This is especially true when novel products and processes are being introduced for the first time.  These deficiencies are a lot easier to deal with prior to product launch or commercial production. 

What can you do?

Although it is easy to get frustrated from the confusion around these terms, it helps to keep some basics in mind.  Simply put, IQ, OQ, PQ are all forms of system testing (with objective evidence) to ensure the pre-established requirements are met.  Generally speaking, IQ addresses the installation requirements of the system and its components.  OQ addresses the functional requirements of the system’s components, and PQ addresses the performance (output) of the system as a whole.  Performance testing (OQ and PQ) need to be conducted under challenge or worst case conditions, and under normal operating conditions. 

To avoid confusion with validation terms, it is imperative that you know in what realm the system will reside (drug or device) and what type of system you are qualifying.  The system type realm will direct you to which regulation, standards and guidelines best apply.  Using the standards and guidelines is not a regulatory requirement, but it can help avoid headaches during an investigation.   The realm can be defined at the top level as a system used for drug or device based products, and at lower levels as to where the system physically resides.  In other words, is the system used in manufacturing or in an analytical testing lab?  System types include: facilities; utilities; manufacturing equipment; test instruments; processes; software; test methods; and equipment cleaning.  The system type will determine which validation element(s) apply (IQ, OQ, PQ).  For example, refer to the following table which identifies the validation elements that apply to each system type (X indicates that it applies, empty that is does not).


System Type

Validation Element

IQ

OQ

PQ

PROCESS OQ

PROCESS PQ

PRODUCT PQ/PPQ

Facility

X

X

X

 

 

 

Utility

X

X

X

 

 

 

Lab equipment

X

X

X

 

 

 

Manufacturing Equipment

X

 

 

 

 

 

Manufacturing Process (unit)

 

 

 

X

X

 

Manufacturing Processes (all)

 

 

 

 

 

X

 

Terms associated with validation can get very confusing between drug and device realms and across system types.  As we have seen, the frustration and lost time can be avoided by understanding the context within which your system resides and its type.  Once this is reflected in the governing procedures for validation and instilled in your organization, you will be able to avoid the hang ups and get on with your validation activities. 

Writen by: John Orosz, Principal, Dedicare Consulting

Bibliography:

  1. 21 CFR Part 211.
  2. 21 CFR Part 820.
  3. Global Harmonization Task Force (GHTF)/SG3/N99-10:2004 (Edition 2) - Quality Management Systems – Process Validation Guidance.
  4. Process Validation: General Principles and Practices, FDA 2011.
  5. ASTM E2500 7 - Standard Guide for Specification, Design, and Verification of Pharmaceutical and Biopharmaceutical Manufacturing Systems and Equipment.
  6. USP <1058> - Analytical Instrument Qualification.
  7. GAMP 5, A Risk-Based Approach to Compliant GxP Computerized Systems, ISPE 2008.

 


Would you like to comment on this article?  Please complete the form below and click the submit button.