HPLC/UHPLC Qualification: DQ, IQ, OQ and PQ

The approach below concerns pharmaceutical QC instruments, software and accessories. The matrices and cases are original GuideGxP planning aids, not ready-to-execute protocols. EU GMP references apply within their relevant human-medicines scope. The applicable quality system, approved procedures and instrument safety instructions remain the basis for execution.

Define the system boundary and responsibilities

Start with an identifiable configuration: pumps, mixing components, injector, sample management, column compartment, detector and relevant fluidic accessories. Add controlling software, firmware, workstation or network dependencies and data interfaces. State which elements belong to the equipment qualification and which are covered by linked computerised-system validation. A boundary that stops at the instrument cable can leave acquisition or processing changes unassessed.

The laboratory owns the intended use and the decision to accept the evidence. Qualified staff may perform tests; the supplier can contribute installation, technical knowledge and test records. Quality oversight and approval roles follow the site’s quality system. Define who writes, executes, reviews, resolves deviations and authorises the next stage or routine use. Outsourcing a test does not outsource the laboratory’s understanding of its scope.

Qualification does not establish that every analytical method is valid for every product. Method validation evaluates the procedure for its intended analytical purpose; calibration establishes relevant measurement relationships; system suitability assesses the analytical system in the method and sequence context. Plan complementary evidence rather than using one successful activity as a blanket substitute for the others. [1] [2]

DQ: review the design against the URS

Design qualification asks whether the proposed configuration can satisfy the approved user requirements. Connect each critical requirement to the selected modules, software functions, installation prerequisites and a credible verification route. Check compatibility between components, not just their individual catalogue ranges. Record why the complete configuration is appropriate for the method portfolio and where evidence is still needed.

Supplier documentation is useful when its configuration, version, conditions and limitations are known. Compare it with your requirements and assess gaps before relying on it. An application demonstration on a different detector cell or fluidic arrangement is not automatically evidence for the ordered system. Factory tests may support later work when their relevance and the absence of installation or transport effects are justified; they are not a reason to skip site-specific checks without assessment.

Resolve design discrepancies explicitly. If a requirement changes, retain the rationale and approval rather than silently adapting the URS to the purchased equipment. DQ should leave a clear connection between intended use, configuration and the evidence planned for acceptance.

IQ: make the installation identifiable and suitable

Installation qualification records what was actually installed and checks it against the approved configuration and installation requirements. Include module identity and serial numbers, firmware/software versions, licences where relevant, connections, utilities, location and necessary accessories. Confirm that the environment and services are suitable. A serial-number list proves identity but does not, by itself, demonstrate correct installation.

Collect the instructions, configuration records and relevant certificates needed to operate and maintain the system. Check the status and suitability of measurement references used for subsequent tests. Define prerequisites such as training, approved protocols, available solutions and controlled data storage. Missing prerequisites should be visible decisions, not blank fields completed after the event.

For software-connected equipment, reconcile instrument identity with the configured controller and data path. Confirm that the installed versions correspond to the reviewed configuration. If a network or account prerequisite belongs to another validation package, reference the evidence and responsible owner so that neither team assumes the other has verified it.

OQ: challenge relevant functions and ranges

Operational qualification examines whether the installed system operates as intended across the justified operating range. Choose tests for the pump and gradient, injection, temperature control, detector, relevant alarms and digital functions according to the URS and risk. Specify conditions, references and criteria before testing. A test at one convenient point does not automatically support a much wider claimed range.

Module tests can help isolate performance, while a combined system test can reveal interactions. Neither approach is universally sufficient alone. For example, acceptable module results do not prove that the selected acquisition settings capture narrow application peaks adequately. Conversely, a good chromatogram does not isolate the accuracy of every module. Explain what each test demonstrates and what remains outside its scope.

EDQM’s LC qualification guidance provides technical examples for HPLC/UHPLC and different detector technologies. Its stated scope is the OMCL network; other laboratories may use it voluntarily. Its example procedures and typical limits are not universal GMP acceptance criteria for every QC instrument. Select and justify an applicable approach instead of copying a table of numbers. Perform alarm or fault scenarios through approved safe methods; never bypass protective functions or attempt service-only interventions. [3]

PQ: demonstrate performance in the intended work

Performance qualification connects the qualified configuration to the laboratory’s actual use. Define representative methods, relevant sample or reference materials, operating conditions and the period or pattern of work needed to answer the performance question. Explain the coverage of the selected challenges and any exclusions. A convenient standard mixture may be useful, but it does not necessarily represent the critical demands of the method portfolio.

Keep three conclusions distinct: the system performs in the intended operating context; the analytical procedure is validated or otherwise demonstrated suitable as required; the particular sequence meets its system suitability requirements. Routine SST records can contribute to ongoing evidence when appropriately planned, but a single passed SST does not close all PQ, software or lifecycle requirements.

Use evidence that can be reviewed: complete sequences, preparation records, instrument configuration, acquisition/processing settings, relevant environmental information and deviations. Define which performance observations will be trended after initial release. If several methods or configurations are represented by a subset, document why the subset covers the relevant risks and what would trigger reassessment.

Protocols, deviations and release

A workable protocol defines purpose, scope, responsibilities, prerequisites, test conditions, references, acceptance criteria and the treatment of unexpected results. Link each test to its requirement and preserve original observations, calculations, metadata and review history. A final “pass” without the underlying evidence is difficult to assess. Chapter 6 places laboratory documentation and equipment records within the quality system. [4]

Record failed criteria and deviations when they occur. Investigate causes and impact, determine corrective actions and justify any repeat. Keep the original result; do not replace it with a successful rerun or move the acceptance boundary simply to obtain a pass. The report should explain the disposition of every relevant gap and the resulting permitted use or restriction.

Annex 15 allows a documented, justified conditional progression to a subsequent qualification stage in certain circumstances. That is not automatic permission for routine QC use with unresolved critical deficiencies. Distinguish progression to the next test stage from release for intended operation, and state the authorised scope, restrictions and outstanding actions explicitly. [1]

This matrix is a reasoning aid. It does not dictate four separate binders or remove the need to justify combined stages, reused evidence and the order of activities. Traceability is useful only if a reviewer can reach the actual evidence and understand its limitations.

Maintain the qualified state

Qualification continues through maintenance, calibration, changes, incidents and periodic review. Use equipment history, trends, the consequences of failure and applicable requirements to justify review and requalification arrangements. Neither “every year for all systems” nor “never after initial qualification” is a defensible universal rule. Define what prompts an impact assessment and who controls return to use.

A change can affect more than its immediately visible component. A different mixer can change gradient behaviour; a software update can affect calculations or access; relocation can change services and environment. Identify affected requirements, evidence that remains valid and tests needed to close the uncertainty. Annex 11 provides the relevant framework for controlled software changes and periodic evaluation. [5]

Two simulated changes, two assessment paths

Case A: replacing a pump module. The laboratory records the fault and the last known acceptable state, then assesses whether earlier results may be affected. It compares replacement type, firmware, mixing arrangement and intended flow/pressure envelope. An apparently equivalent spare is not accepted solely by its external appearance. The team updates installation identity, performs the justified affected flow/gradient and safety checks, and evaluates relevant system performance. If configuration differences alter method behaviour, the change assessment expands accordingly. Release records the evidence, resolved deviations and authorised use; it does not automatically require repeating every unaffected test.

Case B: updating the CDS version. The hardware stays in place, but the team reviews release information, supported instrument drivers and changes to acquisition, integration, calculations, roles, audit trails and interfaces. It preserves recoverable records and defines a controlled recovery arrangement before the update. Tests challenge the affected workflows using retained or controlled test data as appropriate, including error handling and report meaning. Existing calibration evidence may remain relevant when the measurement chain is unaffected, but that does not prove the software workflow. The system is released only after the documented assessment and required tests support continued use.

These are invented planning scenarios, not reports of experimental results. Both require a justified scope and an authorised conclusion. Their test sets differ because the possible effects differ, not because one change is automatically “minor”.

Return-to-use checklist

• Is the current configuration and intended use unambiguous?
• Are affected requirements and retained evidence identified?
• Are reference status, original records and test conditions available?
• Are failures, repeat tests and their impact explained?
• Does the release state authorised use, restrictions and responsible approval?
• Are maintenance, training and ongoing checks updated where needed?

Does a service certificate prove qualification is complete?

No. Review what was tested, in which configuration, against which criteria and with what unresolved gaps. The certificate may support the package, but the laboratory must assess coverage of its intended use.

Must a change always trigger full requalification?

No universal answer is justified. Determine the effects on requirements and existing evidence, perform the necessary targeted or broader work, and document the decision. A narrowly justified scope must still address interactions and potential effects on previous results.

Sources and limits

Sources checked on 28 September 2026. The applicable full text of USP 〈1058〉 was not accessible. Its publicly accessible 2025 briefing describes a proposed revision based on the 2017 chapter; it is not used here as proof that a new revision is official. Consult the applicable licensed text when using that framework. EDQM guidance is explicitly distinguished from universal GMP requirements.

1. European Commission — EU GMP Annex 15 (2015), §§1–4, 11 and glossary. Lifecycle qualification, documentation and changes within its applicable scope.
2. FDA — ICH Q2(R2), Validation of Analytical Procedures (March 2024). Final guidance; analytical procedure validation.
3. EDQM — PA/PH/OMCL (11) 04 R7, Qualification of Liquid Chromatography Equipment. Effective 15 November 2023; OMCL scope, voluntary use by other laboratories.
4. European Commission — EU GMP Chapter 6, Quality Control (2014), §§6.6–6.7, 6.15–6.16. Laboratory documentation and analytical control.
5. European Commission — EU GMP Annex 11, Computerised Systems (2011), §§4, 10–12, 16. Software lifecycle and operational controls.
6. USP 〈1058〉 — public revision briefing (2025). Proposal preview only; not the verified current full chapter.