Validation Testing in Pharmacovigilance: IQ, OQ, PQ and User Acceptance Testing

Validation testing generates objective evidence that a computerised system can support its intended regulated use. In pharmacovigilance, the question is not whether every software feature has been tested equally. It is whether the functions and controls that matter to patient safety, regulatory reporting, data integrity and reliable operation have been assured to a depth proportionate to risk.

Purpose and Regulatory Context

EU pharmacovigilance legislation does not prescribe a universal IQ/OQ/PQ/UAT sequence for every pharmacovigilance system. GVP Module II — Pharmacovigilance system master file (Rev. 2) requires the PSMF to summarise the validation status of key computerised-system functionality, including change control, the nature of testing, back-up arrangements and relevant repositories.

This creates a requirement for defensible assurance, not for a particular set of document names.

EU GMP Annex 11 contains explicit lifecycle validation requirements for GMP-regulated computerised systems. It is an important reference where GMP scope applies, but it should not automatically be cited as the direct legal basis for a standalone pharmacovigilance application outside GMP scope.

Testing Begins With Intended Use

A test is valuable only if it demonstrates something the organisation needs to know about system fitness for purpose.

For a pharmacovigilance safety database, important test questions may include:

• Can users create and maintain ICSR records accurately?
• Do workflow rules identify relevant case states correctly?
• Are regulatory messages generated and transmitted as intended?
• Can failed transmissions be identified and managed?
• Are user permissions effective?
• Are audit trails generated and retained where needed?
• Do interfaces preserve required safety information?
• Can data be recovered following relevant failure scenarios?

These questions arise from intended use and risk, not from a generic validation checklist.

Objective Evidence

Validation conclusions should be supported by evidence that another qualified reviewer can understand. Depending on the test, evidence may include executed scripts, system-generated outputs, audit-trail records, interface acknowledgements, data comparisons, logs or controlled screenshots.

The evidence should show:

1. what was tested;
2. which requirement or risk the test addressed;
3. what conditions were used;
4. what result was expected;
5. what actually occurred; and
6. how any deviation was assessed.

A signed test script without meaningful evidence can provide less assurance than a concise, reproducible test with clear system output.

Risk-Based Testing

Testing depth should reflect the consequence and likelihood of failure. A function affecting expedited ICSR submission ordinarily deserves greater assurance than a cosmetic preference in a reporting screen.

Risk factors may include patient-safety consequence, regulatory significance, data integrity, security, interface complexity, configuration, custom code, supplier maturity and detectability of failure.

Risk-based testing does not mean testing less by default. It means directing testing effort where failure matters most.

IQ, OQ, PQ and UAT: What the Terms Mean

Traditional validation programmes often organise testing into Installation Qualification (IQ), Operational Qualification (OQ) and Performance Qualification (PQ), with User Acceptance Testing (UAT) used to confirm business suitability. These labels can be useful, but they are not the only valid way to organise assurance.

Installation Qualification

IQ traditionally demonstrates that the required hardware, software, infrastructure or configured components have been installed correctly in the intended environment. For cloud or software-as-a-service systems, much of the underlying infrastructure evidence may be supplier-controlled, so the regulated organisation may focus instead on what it can and must verify about the deployed service, configuration and access.

Operational Qualification

OQ traditionally tests whether configured functions operate across expected ranges and conditions. It may include business rules, permissions, interfaces, negative tests and exception handling.

Performance Qualification

PQ traditionally demonstrates that the system supports the intended business process under realistic operating conditions. For pharmacovigilance, end-to-end scenarios can be particularly valuable because they test the interactions between users, configuration, interfaces and procedures.

User Acceptance Testing

UAT demonstrates that users can perform the intended business activities with the implemented solution. UAT may overlap with PQ in some organisations. The important distinction is the assurance question being answered, not the label attached to the protocol.

Avoiding a Document-Label Fallacy

A system does not become validated merely because documents called IQ, OQ and PQ exist. Conversely, an assurance model is not deficient merely because it uses different terminology.

A mature validation strategy asks whether:

• important requirements are covered;
• risk determines test depth;
• supplier evidence is used appropriately;
• configuration and interfaces are verified;
• deviations are assessed;
• the production-relevant operating model is represented; and
• conclusions are supported by objective evidence.

Positive, Negative and Boundary Testing

Testing only the successful path can miss important controls. Depending on risk, the organisation may need to test what happens when:

• mandatory information is absent;
• a user lacks the required permission;
• an interface rejects a message;
• duplicate information is encountered;
• a regulatory message fails transmission;
• an invalid code or value is entered; or
• a workflow reaches an exception state.

Boundary and negative tests are especially useful for rules whose failure could lead to missed reporting, corrupted data or uncontrolled access.

Interfaces and End-to-End Testing

Interfaces deserve dedicated assurance because errors may arise from mapping, timing, retries, transformations or reconciliation rather than from either application individually.

An end-to-end ICSR reporting scenario might test:

case entry → coding → medical review → reportability decision → E2B(R3) generation → transmission → acknowledgement or rejection → status update.

The exact scenario depends on the organisation's systems and reporting model. The purpose is to confirm the regulated outcome across the actual chain.

Supplier Testing and Leveraged Evidence

Commercial suppliers may already perform extensive software testing. Repeating all supplier tests locally can add little value.

The regulated organisation should instead determine:

• what supplier evidence exists;
• whether supplier controls are credible;
• which functions remain standard versus locally configured;
• whether the local environment changes risk;
• what critical workflows need independent verification; and
• whether supplier changes can affect the validated state.

Leveraging supplier evidence is a risk-based assurance technique, not a transfer of accountability.

Deviations During Testing

A failed test does not automatically mean the system is unacceptable. The deviation should be understood.

Relevant questions include:

• What requirement or risk is affected?
• Is the failure reproducible?
• Does it affect regulated use?
• Is remediation required before release?
• Is regression testing needed?
• Does the deviation reveal a weakness in requirements or configuration?

Closing a deviation administratively without understanding its impact undermines the validation conclusion.

Lifecycle Testing and the Validated State

Validation is not a one-time implementation event. Changes to configuration, interfaces, infrastructure, supplier releases, regulatory rules or business processes can alter the assurance basis.

Change control should therefore determine:

• which requirements are affected;
• what existing evidence remains applicable;
• whether new or regression testing is needed;
• whether supplier evidence remains relevant; and
• whether the production state remains fit for intended use.

The objective is preservation of the validated state, not repetition of the original project package after every change.

Practical Implementation

A risk-based validation-testing strategy can follow this sequence:

1. define intended use and critical regulated processes;
2. identify important requirements and failure risks;
3. determine what evidence can be leveraged from the supplier;
4. select test types appropriate to the assurance question;
5. test high-impact workflows and controls at appropriate depth;
6. include negative and exception scenarios where risk justifies them;
7. document deviations and their impact;
8. confirm that unresolved issues are acceptable before release; and
9. reassess testing after material change.

This is recommended operational practice rather than an EMA-prescribed IQ/OQ/PQ sequence.

Illustrative Example

For an E2B(R3) reporting interface, the assurance package might include:

• evidence that the configured reporting route is installed or enabled correctly;
• verification of message mapping;
• positive submission tests;
• rejection and error-handling tests;
• acknowledgement processing;
• user-access testing;
• end-to-end workflow testing; and
• evidence that relevant deviations were resolved or accepted with rationale.

An organisation may label these activities IQ, OQ, PQ and UAT—or organise them differently. The assurance value comes from coverage of intended use and risk.

Potential Failure Modes

The following are illustrative failure modes, not reported inspection findings.

Inspection Considerations

An inspector may ask the organisation to demonstrate how it knows that critical PV-system functionality works as intended. Useful evidence may show:

• how test coverage was derived from requirements and risk;
• why certain supplier evidence was accepted;
• how critical interfaces were verified;
• how failures and deviations were evaluated;
• what changed during the latest upgrade; and
• how the organisation concluded that the system remained fit for purpose.

A large test-script inventory is not, by itself, evidence of an effective validation strategy.

Practical Review Checklist

1. Does testing trace back to intended use and important requirements?
2. Is test depth proportionate to patient-safety, data-integrity and compliance risk?
3. Are high-impact interfaces and workflows tested end to end where appropriate?
4. Are negative and exception paths considered?
5. Is supplier evidence used only after applicability is understood?
6. Are deviations linked to affected requirements and risks?
7. Is objective evidence sufficient for an independent reviewer?
8. Are unresolved defects considered explicitly in the release decision?
9. Does change control determine regression-testing needs?
10. Does the testing model remain maintainable through the system lifecycle?

Key Takeaways

Validation testing demonstrates fitness for intended use through objective evidence. It is not synonymous with producing documents named IQ, OQ and PQ.

IQ, OQ, PQ and UAT are useful assurance concepts, but organisations may structure testing differently when the resulting evidence is scientifically justified and risk-based.

Critical PV workflows, interfaces, data-integrity controls and regulatory reporting functions should receive assurance proportionate to the consequences of failure.

Supplier evidence can be leveraged where appropriate, but local configuration, intended use and regulated responsibility remain with the organisation.

Lifecycle validation depends on impact assessment and targeted re-verification after change rather than automatic repetition of the original test package.

References

1. European Medicines Agency. GVP Module II — Pharmacovigilance system master file (Rev. 2). EMA/816573/2011 Rev. 2.
2. European Medicines Agency. GVP Module I — Pharmacovigilance systems and their quality systems. EMA/541760/2011.
3. European Union. Commission Implementing Regulation (EU) No 520/2012, as amended.
4. European Commission. EudraLex Volume 4, Annex 11 — Computerised Systems. Revision January 2011. GMP-scoped reference.
5. European Commission. Stakeholders' consultation on revision of EudraLex Volume 4 Chapter 4, Annex 11 and new Annex 22. Consultation closed 7 October 2025.
6. ISPE. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition. Industry guidance; not legislation.

Regulatory Note

EU pharmacovigilance requirements call for fit-for-purpose, controlled computerised systems and appropriate evidence of validation, but they do not prescribe one universal IQ/OQ/PQ/UAT lifecycle for all PV systems. As of 8 September 2026, the adopted EU GMP Annex 11 remains the January 2011 revision; the 2025 revised Annex 11 was consultation material and should not be treated as final adopted law unless formally issued.