DQ vs IQ vs OQ vs PQ: Practical Differences in MedTech Manufacturing
DQ, IQ, OQ, and PQ are often used as shorthand, but each stage answers a different engineering question. When they are blurred together, teams usually end up reworking tests, rewriting protocols, or arguing about what evidence actually proves. A practical approach is to keep the intent clear: DQ verifies the design choice, IQ verifies the installation, OQ verifies the operating window, and PQ verifies performance under real production conditions.
Below is a hands-on view of what each stage should prove for manufacturing equipment, which artifacts are worth capturing, and how to keep the scope lean without losing confidence in the results.
Design Qualification (DQ): prove the design choice makes sense
DQ is about the design decision before the equipment is fully installed. The question is simple: does the selected machine or custom build meet the user need and the critical requirements? This is where you lock in the intended use, critical functions, and acceptance criteria. The output is not a pile of tests — it is a clear, reviewed rationale for why the chosen design will meet the requirement set.
In practice, DQ evidence looks like a requirements review, a risk-based justification for the scope, and a traceable mapping between critical requirements and planned tests. If a requirement is missing or vague, fix it here. Every ambiguity you leave in DQ becomes an argument during OQ.
Installation Qualification (IQ): prove the install is correct and stable
IQ confirms that the equipment is installed as intended and is ready to operate. This is where you verify utilities, environment, calibration status, firmware/software versions, safety circuits, and mechanical setup. If the machine is supposed to sit in a cleanroom with a defined power or compressed air spec, IQ is where you check that the environment and setup actually match those assumptions.
Useful IQ evidence is concrete: installation checklists, wiring and utility verification, calibration certificates, and as-built configuration. The goal is to remove doubt about the baseline state so later performance tests are meaningful.
Operational Qualification (OQ): prove it runs within limits
OQ tests how the equipment performs across its defined operating range. It is not just "does it run" — it is "does it meet performance limits under controlled, repeatable conditions." For a test stand, that might mean verifying force, speed, and repeatability across a set of defined points. For a production machine, it often means verifying alarms, interlocks, and key process settings at the edges of the allowed window.
A strong OQ focuses on the parameters that actually impact product quality or safety. If you test everything, you will drown in data. If you test too little, you will miss the failure modes that matter. A risk-based selection of test points, clear acceptance criteria, and a repeatable test method keep OQ credible and efficient.
Performance Qualification (PQ): prove it performs in real production
PQ moves from controlled testing to real-world manufacturing conditions. The core question is whether the process performs consistently with actual materials, operators, and normal variability. This is where you confirm yield, capability, and product quality over a representative run, not just a few test points.
Good PQ evidence includes defined lots/batches, clear acceptance criteria tied to product requirements, and data that shows stable performance over time. If OQ shows the equipment can hit the limits, PQ shows it actually does so in routine production.
Where FAT and SAT fit
FAT and SAT are checkpoints, not replacements. FAT is an opportunity to confirm the build before shipment, while SAT confirms the equipment after installation. Both can provide evidence that supports IQ or OQ, but only if the tests are aligned with your intended qualification scope. Treat them as sources of data, not as the qualification itself.
Common pitfalls and how to avoid them
The most common failure is mixing intent. If DQ becomes a test execution phase, or if IQ tries to prove performance, everything gets muddy. Keep each phase aligned to its purpose and you will avoid rework. Another common pitfall is poor test methods: unclear steps, missing equipment settings, or unvalidated measurement tools. If the test method is weak, the evidence is weak.
Finally, do not ignore integration points. Software versions, sensor calibration, and utility stability are often the hidden causes of failed OQ tests. Capture those details during IQ so you can trace any performance issue back to the baseline configuration.
Practical takeaway
DQ answers "should this design work," IQ answers "is it installed correctly," OQ answers "does it perform within limits," and PQ answers "does it perform reliably in production." Keep those questions separate and the qualification effort becomes simpler to plan, easier to execute, and faster to defend. The goal is not more paperwork — it is clear evidence that the equipment will behave as intended in manufacturing.