If your time is short:
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 in place.
As a component of quality assurance, equipment validation is absolutely 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 one by one.
Installation Qualification (IQ)
Newly installed or modified equipment must first be validated to determine if it’s capable of producing 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 unit of hardware or software 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.”
Along with this, 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
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.
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
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 one by one, 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 quality of the qualification depends in large part on the quality of the test plan. 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:
- Design of the facility and qualification of the equipment and utilities
- 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:
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? Contact us today to connect with perfect-match resources supported by a Total Quality Guarantee.