The IQ, OQ, PQ and Their Impact on Quality Control

There are some constants that cannot be ignored, even between two radically different products.

If you were to take those two products and examine them, there is no denying there would be a long list of properties that vary greatly between the two. We’re talking shape, size, purpose, etc. In a way, they cannot be compared. Nevertheless, whatever the industry, products tend to follow similar development lifecycles. From the point at which a light bulb goes off in someone’s head up to the release of the product to the market, set stages are followed. One such stage, testing, is as universal as it gets in principle.

It’s then that the IQ, OQ, and PQ enter the picture.

For the uninitiated, the “Q” stays the same with regard to each of the above acronyms. They stand for Installation, Operational, and Performance Qualification and each impacts the product development process and quality control in its own way, but as steps, one after another.

As an illustration, consider the pharmaceutical industry. Each piece of equipment or system that enters into a drug’s “chain of custody” must be tested as being qualified for use. “Validated” is another way to put it, with validation defined as, “evidence that provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes.”

It’s an exhaustive process with many ins and outs, starting with the IQ.

Installation Qualification (IQ)

The IQ, or Installation Qualification, ensures, as its name suggests, that a product is properly installed.

Physical products like instruments or tools may call for properly allocated floor space, correct operating conditions, and that there is physically no damage to the unit in question. In the case of software, this means verifying items like whether the folder structures are intact and that the minimum system requirements are met. Checks may also include the memory of the workstation on which the software is being installed, the operating system, software libraries, and that all required files to run the application are accounted for.

“Minimum requirements” is perhaps a good way to put it in general. Whether it’s hardware or a piece of software that’s being tested, the Food and Drug Administration’s IQ definition applies. It states the objective is to document that the “system has the necessary prerequisite conditions to function as expected.”

After ensuring that the system in question can run, the focus shifts to how it runs.

Operational Qualification (OQ)

The OQ, or Operational Qualification, is next up. It is traditionally started out once the IQ has been run through, acting as a pre-requisite for technical acceptance of the software, equipment, or facility. In this capacity, the OQ tests that the functionality of a product is as desired. It acts as a review of start-up, operational, maintenance, safety, and cleaning procedures where applicable.

Each critical button/ function is tested to make sure it does what it should. This holds true for both software and hardware and includes everything from the smallest of details on displays to the exact range of temperature fluctuations, etc.

What’s critical is that every piece of equipment and software operates within the stated limits. Ultimately, that’s the point of the OQ. Once each is proven to be, it’s time to test those limits.

Performance Qualification (PQ)

The final step in the qualification process, the PQ, or Performance Qualification, is meant to ensure the product stacks up against real-world conditions, albeit in simulated scenarios. Whereas the OQ verified functionality, the PQ is results-oriented. Tests tend to have expected results attached to them, meaning they have to be consistently reproducible.

The detailed test plan itself is created from the product development lifecycle. Both the Functional Requirements Specification (FRS; document detailing the requirements that are expected to be performed) and Detailed Design Specification (DDS; document detailing how those operations are performed) factor in. System and unit testing (testing done at the modular level) are also taken into consideration.

The goal here, aside from making sure everything works, is to make sure the system is able to be validated. After all, the validation document serves as proof that the system works as expected when it is being installed at a customer site. That documentation is something the customer holds onto if ever an issue or audit arises sometime down the line.

At their cores, the IQ, OQ, and PQ are sub-sections of validation, simply parts of a larger process. The whole is greater than the sum of its parts, though.

GlobalVision as a Test Case Scenario

Take, for instance, GlobalVision, which develops automated quality control software (and various hardware accompaniments like scanners) for packaging components and product collateral. While its own quality control process is as thorough as you would expect and of course includes internal validation, let’s re-examine the pharma example from earlier.

GlobalVision offers validation execution services with industries like pharma in mind. Pharma is renowned for its stringent requirements revolving around standard documentation and GlobalVision has decades of experience within that space, among others, and caters to the top 10 pharma companies in the world.

As mentioned earlier, each piece of equipment or system that “touches” a product during its development has to be validated. Packaging proofreading software falls into that category. The pharmaceutical company in question could theoretically validate an application on its own. However, GlobalVision doesn’t just supply its own validation documents, extensively developed through its decades of experience working with companies in the industry. GlobalVision offers to execute them onsite, thereby further saving the company time and resources better devoted elsewhere.

In this case, validation execution is a value-added service tacked on to the product itself, the software. Software is somewhat of a particular case as multiple versions of a program are generally released, with each version theoretically an upgrade relative to the last, either through fixes or the addition of new features designed to address issues that had been encountered.

It further proves just how critical testing is to the success of a product, and how it’s ongoing. It’s essentially one lifecycle that never ends, further bridging the gap between different industries. Testing and the success it endeavors to achieve are their common ground.