A Basic Guide to IQ, OQ, PQ in FDA-Regulated Industries

In the highly regulated pharmaceutical, medical devices, and clinical industries, even tiny inconsistencies can compound into serious issues without the proper qualification and validation protocols.

As a quality assurance component, equipment validation is critical to producing consistent, high-quality products. One of the key sets of protocols within equipment validation is Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ).

This guide offers a clear and simple explanation of what these concepts are, why they’re important, what makes them successful, and a model for connecting with professionals who can plan and execute these types of projects.

If you’re planning a validation project, be sure to grab our free guide. Inside, you’ll find seven essentials to building an efficient and effective validation team along with expert insights from staffing professionals who routinely help life science organizations build successful project teams.

What is IQ, OQ, PQ? 

IQ, OQ, PQ protocols are methods for demonstrating that equipment being used or installed will offer a high degree of quality assurance such that production processes will consistently manufacture products that meet quality requirements.

Since these concepts are complex, it’s best to understand them individually.

Installation Qualification (IQ)

Newly installed or modified equipment must first be validated to determine if it can produce the desired results through Design Qualification (DQ)––a protocol defined as the documented verification of a proposed design’s ability to meet the requirements it needs to fulfill.

But how a particular hardware or software unit performs in real-world scenarios depends on the installation procedure. Installation Qualification (IQ) verifies that an instrument or unit of equipment being qualified (as well as its sub-systems and any ancillary systems) has been installed and configured according to the manufacturer’s specifications or installation checklist.

For example, a physical instrument or tool may require a specific amount of floor space, certain operating conditions, and an assurance that no damage exists on the unit. For software, IQ typically involves (but is in no way limited to) verifying folder structures are correctly established and ensuring that the minimum system requirements are met.

Regardless of whether it’s a physical unit or software being tested, the FDA’s IQ definition offers a useful statement of the overall goal: documenting that the “system has the necessary prerequisite conditions to function as expected.” 

Additionally, any CGMP requirements relevant to the IQ—and the methodology used for IQ—must be documented thoroughly in the Validation Master Plan (VMP).

After the initial IQ, re-qualification must be performed following any major maintenance or when equipment is modified. Re-qualification should also be performed as part of routine quality assurance processes.

What makes IQ successful?

Successful IQ is typically measured by how well the installation process followed the manufacturer's guidelines and met their requirements.

This often includes (but is not limited to) the following areas of focus:

• Location of install and necessary floor space
• Documentation of any and all computer-controlled instrumentation
• Gathering all manuals and certifications
• Properly unpacking and cross-checking instruments
• Examining instruments and components for damage
• Ensuring correct power supply
• Installing ancillary instruments
• Documenting firmware versions and serial numbers
• Environmental and operating conditions
• Checking software system installation and accessibility
• Recording calibration and validation dates of tools used for IQ
• Verifying connections and communication with peripheral units

Essential IQ documentation

• The IQ Protocol: The IQ Protocol is a comprehensive plan that outlines the scope, methodology, and criteria for conducting the IQ. It should include:
  • Equipment identification details (model, serial number, manufacturer).
  • A list of equipment and systems to be qualified.
  • Installation requirements as per manufacturer specifications.
  • Environmental conditions (e.g., temperature, humidity) requirements.
  • A checklist of installation criteria to be verified.
• IQ Checklist: A detailed checklist derived from the IQ protocol, covering all aspects of installation to be verified. This includes physical installation checks, electrical connections, calibration, software installation, and environmental conditions.
• IQ Report: The IQ report documents the execution of the IQ protocol, summarizing the findings, observations, and results. It should clearly state whether the equipment installation meets the predefined criteria.

Ensure that all individuals involved in executing the IQ protocol are trained on the equipment and the importance of thorough and accurate documentation practices. This training should emphasize the role of documentation in regulatory compliance and quality assurance.

Operational Qualification (OQ)

Operational qualification (OQ) is performed after meeting each protocol of IQ. OQ’s purpose is to determine that equipment performance is consistent with the user requirement specification within the manufacturer-specified operating ranges. In action, this means identifying and inspecting equipment features that can impact final product quality.

During OQ, all items in the test plan are tested and their performance is thoroughly documented. Since this is a prerequisite for acceptance of equipment and the facility, it can only be conducted once the IQ is run.

Read also: 5 Steps to Creating an Effective Life Science Validation Team

In general, OQ serves as a detailed review of hardware or software startup, operation, maintenance, cleaning, and safety procedures (if and where they’re applicable). Every unit of hardware and software must be shown to be operating within the specified limits.

What makes OQ successful? 

As we explained above, the action items of OQ are identifying and inspecting the components of equipment that impact product quality and ensuring they’re operating within specific limits.

These often include (but, again, are in no way limited to) the following:

• Temperature control and variations
• Servo motors and air flaps
• Temperature protection systems
• Card readers and access systems
• Pressure and vacuum controllers
• Temperature distribution
• Display units and signaling LEDs
• CO2 controls
• Humidity-measuring and control
• Fan and fan-speed controllers

Here are some indicative signals of a successful OQ:

• All operational tests meet or exceed the predefined acceptance criteria detailed in the OQ protocol. This is the most direct signal of success, indicating that the equipment performs reliably within its operational range.
• No significant deviations or non-conformities during testing suggest that the equipment operates correctly and consistently. Minor deviations are addressed and resolved without impacting the equipment’s ability to meet its intended use.
• The equipment's built-in error detection and handling mechanisms function as expected, correctly identifying and responding to simulated errors or failures. This capability is crucial for maintaining operation integrity under adverse conditions.
• If applicable, the equipment seamlessly integrates with other systems or processes, without any compatibility issues or disruptions. This indicates that the equipment can be incorporated into the broader operational workflow efficiently.
• Feedback from operators and end-users who interact with the equipment during the OQ phase is positive, indicating that the equipment is user-friendly and performs its intended functions effectively.
• The successful completion of OQ, with all criteria met and documented, indicates the equipment is ready to proceed to the next phase of qualification, PQ, where it will be tested under actual production conditions.

Essential OQ documentation

• The OQ Protocol: The OQ protocol is a comprehensive document that outlines the objectives, scope, methodology, and criteria for conducting the OQ. It should include:
  • Objectives: Clearly define what the OQ aims to achieve, including specific operational parameters and functions to be tested.
  • Scope: Detail the equipment, systems, and processes included in the OQ.
  • Methodology: Describe the step-by-step procedures for conducting the operational tests, including any specific conditions or setups required.
  • Acceptance Criteria: Specify the measurable criteria that the equipment must meet to pass each test. These criteria should be based on the manufacturer’s specifications, regulatory requirements, and user needs.
• OQ Test Scripts/Checklists: These are detailed instructions or checklists used to conduct the operational tests outlined in the OQ protocol. They include:
  • Specific steps to execute each test.
  • Required observations and measurements to be recorded.
  • Expected outcomes based on the acceptance criteria.
• OQ Report: The OQ report documents the execution and outcomes of the OQ testing. It includes:
  • A brief overview of the OQ objectives and scope.
  • A summary of the testing methodology used.
  • Detailed results of each test, including any measurements or observations made. This section should clearly indicate whether the equipment met the defined acceptance criteria.
  • Any deviations from the protocol, including unexpected results or failures, should be documented along with an analysis of their impact and any corrective actions taken.
  • A summary of the OQ findings, stating whether the equipment has successfully passed the operational qualification based on the predefined criteria.
• SOPs: While SOPs are not unique to the OQ phase, they play a crucial role in ensuring that the equipment is operated correctly and consistently for OQ testing. Relevant SOPs should be referenced in the OQ documentation, including:
  • Operating procedures for the equipment.
  • Maintenance and calibration procedures.
  • Procedures for handling and documenting deviations
• Calibration and Maintenance Records: Documentation proving that the equipment was properly calibrated and maintained before and during the OQ tests is essential. These records help validate the accuracy and reliability of the test results.
• Traceability Matrix: A traceability matrix connects the requirements specified in the DQ and user requirement specifications (URS) to the tests conducted during OQ. This document ensures that all necessary operational parameters have been tested and validated against the requirements.

Remember to clearly explain why each test is included, its relevance to operational reliability, and how it addresses potential risks or compliance requirements. Involve representatives from quality, engineering, production, and IT to ensure all perspectives are considered in the test plan, enhancing its comprehensiveness and applicability. Lastly, design the protocol to include a process for reviewing test results and incorporating feedback into the protocol or operational procedures as necessary.

Performance Qualification (PQ)

The final step of qualifying equipment is PQ. In this phase, the qualification and validation team verifies and documents that the user requirements are verified as being met. These user requirements should include the normal operating range required (as defined and signed off on by QA and verified in the DQ). Once you've qualified the equipment, you can develop each process required for each product. Then, once each process is fully developed, it can be validated.

Instead of testing components and instruments individually, PQ tests them all as a partial or overall process. 

Before they start qualifying, however, the team must create a detailed test plan based on the process description. It’s important to note that the qualification's quality largely depends on the test plan's quality. This is one area where a third-party specialist can (and often should) be brought in to ensure thoroughness and accuracy.

The Process Performance Qualification (PPQ) protocol is a fundamental component of process validation and qualification. Its purpose is to ensure ongoing product quality by documenting performance over a period of time for certain processes.

FDA Criteria for PQ and PPQ Protocols

In its guidance, “Process Validation: General Principles and Practices,” the FDA officially defines the PQ stage into its two elements:

1. Design of the facility and qualification of the equipment and utilities
2. Process Performance Qualification (PPQ)

During the second stage, the FDA states in its guidance that “CGMP-compliant procedures must be followed,” adding that “successful completion of Stage 2 is necessary before commercial distribution.”

The FDA guidance recommends including the following elements as part of PQ and PPQ protocols:

• Manufacturing conditions such as equipment limits, operating parameters, and component inputs
• A thorough list of the data that should be recorded or analyzed during tests, calibration, and validation
• Tests to ensure consistent quality throughout production
• A sampling plan detailing the sampling methods used during and in between production batches
• Analysis methodology for making data, scientific and risk-oriented decisions based on statistical data
• Definitions for variability limits and contingency plans for handling non-conformance
• Approval of the PPQ protocol by relevant departments, namely the Quality Unit.

More details on specific FDA expectations for PQ and PPQ can be found in the guidance document here.

Overcoming One of the Biggest Challenges to Achieving IQ, OQ, PQ Success

While the basics of IQ, OQ, PQ are critically important to understand and implement, it’s also critical to acknowledge the challenges teams encounter when doing this work in the field.

Trying to address all—or even most—of these challenges would be too ambitious for a guide like this. So instead, we asked one of our own validation experts to identify and unpack the one challenge he sees and solves most often: navigating the conflict between business goals and the deadlines attached to them—with everything needed to build a complete technical file.

Devin Mack has been steeped in product development, R&D, quality, regulatory, and manufacturing work for more than 28 years. Part of his work as a consultant involves helping life science companies align their quality management systems—including risk management and validation testing methods and procedures—between worldwide facilities, customers, and third-party vendors. Having encountered countless IQ, OQ, PQ challenges, he cites requirements gathering at the outset of a project to be among the most common, and most consequential, challenges, making it also the most impactful to handle proactively.

Here’s Devin on the broader challenge of proper planning that can have a downstream impact on activities including IQ, OQ, PQ.

“I think the crux of the matter is, you know, companies will go through their product realization process, and then they get to design transfer, and they start trying to get their technical files together. And then they realize, ‘Oh, we don't have validated systems. We didn't, validate any processes, we didn't validate the customer requirements. And further, beyond that, we don't really have a true understanding of what the requirements are.’ 

So in the end, it routes back to not having proper requirements set at the outset. And then due to [what amounts to] laziness, the rush to get stuff done, nobody takes the time to dot the I's and cross the T's making sure that the validation and verification goals match up with those design inputs and user needs. 

So, things get lost and confused because of the rush to meet deadlines. Or [teams] start skipping steps of documentation and don’t have a true understanding of their operational window and performance window. That's your OQ and PQ. And then, why bother with the proper paperwork for your equipment, and that's the IQ. So, it all comes down to the conflict between business goals, deadlines, and the mere misunderstanding of what's actually, you know, one of the must-haves to get your technical file buttoned up.

I think a lot of the ‘business’ sides of companies don’t have a full understanding of what they’re getting into. Let's say [a company] is new to [the] medical device [space]. They didn't plan for all the properly proposed testing or the time to develop the documentation to understand how well is this thing performing compared to what we're claiming it to do. And maybe they think that they can rely on predicate devices or other devices that are already out there. In the end, they're going to find that they can't, they can't fully rely upon somebody. They actually have to get the testing done on their particular products.”

— Devin Mack, Life Science Consultant

One of the main drivers of this bigger planning problem, Devin says, is a decades-long transition of influence from the engineering department over to the commercial team. 

The differing priorities between these functions can create tension that’s often uncomfortable to acknowledge, let alone confront. But as Devin explains, changes in regulatory pressures are encouraging at least some re-balancing.

“I've been an engineer for 30 years. I've seen the transition from when I was a young engineer and it was all about testing; understanding every possible question that the engineers thought of. You had VPs of engineering that were part of the management team.

But then that slowly transitioned. You no longer really have VPs of engineering anywhere these days. It's very driven by commercial, and a lot of companies have found themselves writing justifications or rationale to avoid the amount of testing that they would have done 30 years ago.

But now, I think that's changing. With the new European Medical Device Regulations coming into play, a lot of companies are pretty much faced with, ‘okay, we have, we actually do have to go back and test more than what we thought.’ It might not be to the extreme of 30 years ago, but it's probably halfway there as far as companies having to show actual data about how their products perform and show that they have control over their product realization process. So that's where, you know, IQ, OQ, OQ is pretty hot now.”

— Devin Mack, Life Science Consultant

When helping teams resolve this tension, Devin says his advice typically lands on a few points depending on the situation:

• Challenge any assumptions being made early in the product realization process—especially those that justify omitting certain activities from work plans.
• Devote ample time to, and be thoughtful about, laying out the full set of requirements for a given product with input from every impacted department.
• Acknowledge that few decisions can ever be responsibly made in a silo, especially early on. Don’t presume that a team need only be involved later on in the process.
  
  

“The advice—the ideal world is, you plan to set your requirements, you make sure your requirements align well with your design, inputs, and outputs. It should be smooth sailing from there; making sure everybody's involved early on, including manufacturing. But a lot of companies don't fully understand that or they didn't fully guage the budget to allow for that properly, so they find themselves in a bind. 'What is the minimum we have to do?' is the approach they tend to take.”

— Devin Mack, Life Science Consultant

Measuring IQ, OQ, PQ Success as a Function of Quality by Design

Like other critical steps in the lifecycle of a product, Devin suggests the effectiveness of qualification drives down to the approach of quality by design—doing things in ways that have proven to be effective time and again. Following this philosophy means, in this context, understanding your customers by identifying and human factor requirements and making them actionable design inputs.

What do customers need and want—and how can a team diagram those requirements so they can be interpreted at an engineering level? Genuine success can really only be measured by meeting these kinds of requirements, which underscores just how important identifying those requirements is early in the design process.

“How do you know you've met success? It's by doing things in a proven way. And you know, a big part of that is understanding your customer. So then you get into human factors. You hear user experience and human factors requirements. And then, again, it all comes back to setting proper requirements—having a good understanding of what your customer needs are and what your customer wants.

Diagramming that out, on your own, you have several ways of doing that. You have your value chain analysis. You have your Kano diagram, you have customer surveys. [All of these tools help you] interpret [requirements] at an engineering level. If you've met what the customer wants, then that's what success is. If you've met the expected lifetime that you have chosen for that device to have, then that is what success is.

If your requirements are properly set, so that your acceptance criteria outlined in your IQ, OQ, PQ are met, then that is what success is. But again, if they're vague and unclear, companies will struggle with not understanding what success is.”

— Devin Mack, Life Science Consultant

An Effective, Cost-Efficient Model for Accessing Qualification & Validation Services

For most organizations, equipment qualification and validation are not a constant need, so performing it in-house is seldom advantageous—sometimes outright infeasible.

Rather than filling a traditional full-time role, many life science organizations work with resourcing firms that can locate and place qualified professionals through a flexible contract staffing/staff augmentation model.

This arrangement brings a number of advantages to quality departments and hiring managers:

• Providing access to qualified personnel in an increasingly competitive labor environment
• Freeing up time and attention within your internal teams
• Reducing the costs of recruiting, screening, and onboarding staff

Unlike traditional full-time hiring, a flexible contract staffing model combined with a large, global staff of qualified personnel enables better adjustment with cyclical or project-based demand while infusing new skills and experiences into the team.

Learn more about this, and other engagement models we utilize to help thousands of life science companies get the QA, RA, Clinical Operations, Qualification, and Validation, and Manufacturing and Engineering resource and project support they need—where and when they need it:

Qualification & Validation Services:

• Managed Project Support
• Staff Augmentation
• FTE Recruitment

Want to learn more about building an effective qualification and validation team? Grab our free white paper below. Need a life science specialist or team to support a current or upcoming project? Submit the form below to tell us a little about yourself and your project or resource needs. We'll follow up within one business day.