A proper installation alone does not prove that the equipment is ready for use. The equipment may be installed correctly, but it still needs to demonstrate that it can operate within the specified range. Operational Qualification, commonly called OQ, provides this evidence.
Operational Qualification is the documented verification that equipment and systems operate as designed throughout their expected operating ranges. It challenges controls, alarms, interlocks, software functions, and critical process parameters under controlled conditions.
Let’s understand the Operational Qualification in detail in a step-by-step approach that applies to almost every type of pharmaceutical equipment.
What Is Operational Qualification?
Operational Qualification is the documented testing of equipment and systems to confirm that they function according to approved specifications.
OQ demonstrates that the system performs correctly when operators run it through normal settings, upper and lower limits, alarm conditions, and failure scenarios.
In simple terms, OQ answers one important question:
Does the equipment operate correctly throughout its specified operating ranges?
If the answer is yes and the supporting data meets acceptance criteria, the system can move to Performance Qualification.
Why Operational Qualification Matters
Installation Qualification confirms that the equipment is present and installed correctly. Operational Qualification confirms that it works.
For example:
- A temperature sensor may be installed and calibrated, but the control system might respond slowly.
- A door interlock may be present, but it may fail to stop the cycle when the door opens.
- A low-pressure alarm may exist, but it may not trigger at the correct setpoint.
Regulatory Expectations for OQ
Regulatory authorities expect companies to demonstrate that equipment and systems are suitable for intended use.
The principles of Operational Qualification appear in guidance from the U.S. Food and Drug Administration, the European Union’s Annex 15, the International Society for Pharmaceutical Engineering, the World Health Organization, and PIC/S.
These guidelines emphasize that qualification should be science-based, risk-based, and supported by documented evidence.
Documents Required Before Starting OQ
Several documents should be available before execution begins.
The approved IQ package is the most important prerequisite. The team should also have access to the User Requirement Specification, Functional Specification, design documents, risk assessments, calibration certificates, operating manuals, and standard operating procedures.
These documents define what the equipment should do and provide the basis for test development.
Step-by-Step Operational Qualification Procedure
Step 1: Confirm Prerequisites
Before OQ begins, the team should verify that IQ has been completed and approved, calibration remains valid, utilities are available, and relevant SOPs are in place.
Any unresolved issue that could affect testing should be addressed before execution starts.
Step 2: Review Risk Assessment
The risk assessment identifies functions that have a direct product impact. These critical functions should receive the greatest attention during OQ.
Step 3: Define Critical Operating Parameters
The team should identify all operating parameters that influence performance.
Examples include temperature, pressure, speed, flow, vacuum, pH, conductivity, and software settings.
Each parameter should have a specified operating range and acceptance limits.
Step 4: Prepare and Approve the OQ Protocol
Validation should prepare a protocol that includes challenge tests for all critical functions.
The protocol should be reviewed and approved by Validation, Engineering, the user department, and Quality Assurance.
Step 5: Verify Test Instruments
All instruments used during qualification should have valid calibration. This includes reference thermometers, pressure gauges, stopwatches, tachometers, and data loggers.
Step 6: Conduct Functional Tests
The team should verify that the system starts, runs, responds to operator commands, and shuts down properly. Basic functions such as power-up, login, menu navigation, and parameter entry should be tested.
Step 7: Test Operating Ranges
Each critical parameter should be challenged at or near its lower limit, nominal setting, and upper limit. The system should remain stable and perform according to specifications throughout the range.
Step 8: Verify Control Functions
Control loops should maintain process variables within acceptable tolerances.
For example, a chamber controller should maintain temperature around the setpoint, and a pump controller should sustain target flow.
Step 9: Challenge Alarms
Every critical alarm should be tested by creating the condition that triggers it. The team should verify the alarm setpoint, message, audible or visual indication, and required response.
Step 10: Challenge Interlocks
Interlocks prevent unsafe or incorrect operation.
The team should confirm that the system stops or blocks operation when an interlock condition occurs, such as opening a guarded door or losing utility pressure.
Step 11: Verify Safety Functions
Emergency stop buttons, overload protection, and safety cutoffs should be tested to confirm proper response.
These functions should bring the system to a safe state.
Step 12: Verify Software Functions
For computerized systems, the team should test user access, audit trails, data recording, report generation, and backup functions as applicable.
It is important to verify user access privileges to ensure that role-based security, audit trails, and data segregation work properly. Testing should confirm that authorized users can perform their allowed activities, while unauthorized users are prevented from accessing restricted functions.
Step 13: Verify Data Accuracy
Displayed values and recorded data should be compared with calibrated reference instruments.
This confirms that the system measures and stores accurate information.
Step 14: Test Repeatability
Critical operations should be repeated several times to demonstrate consistent performance. Repeatability confirms that results are not due to chance.
Step 15: Conduct Power Failure and Recovery Tests
The team should simulate power interruption when appropriate. The system should recover in a controlled manner and preserve data as specified.
Step 17: Record Results and Supporting Evidence
All observations, readings, printouts, screenshots, and instrument data should be attached to the protocol. Objective evidence strengthens the qualification package.
Step 18: Document Deviations
Any unexpected result should be documented, investigated, and assessed for impact. Corrective actions should be implemented and verified.
Step 19: Review Completed Protocol
Validation should review all entries, calculations, attachments, and deviation records. The review should confirm completeness and traceability.
Step 20: Prepare the OQ Report
The report should summarize testing performed, results obtained, deviations encountered, and the overall conclusion. It should clearly state whether the equipment is suitable to proceed to Performance Qualification.
Step 21: Obtain Final Approval
Quality Assurance and other designated departments should approve the final report. After approval, the system may advance to PQ.
Acceptance Criteria for OQ
Acceptance criteria should be objective and predefined.
Typical criteria state that the equipment must operate within specified ranges, maintain controlled parameters within tolerance, activate alarms at approved setpoints, enforce interlocks correctly, record accurate data, and complete repeated tests consistently.
All deviations should be resolved or formally justified before approval.
Frequently Asked Questions
Can OQ and PQ be combined?
In some low-risk situations, protocols may be combined, but the distinction between operational testing and performance testing should remain clear.
Can OQ begin before IQ approval?
Some organizations allow conditional progression when low-risk issues remain open, but Quality Assurance should approve this decision.
How many repetitions are required?
The number depends on risk, complexity, and regulatory expectations. The protocol should justify the chosen approach.
Is vendor testing sufficient?
Vendor testing can support qualification, but the pharmaceutical company remains responsible for generating and approving its own OQ records.
