Design Qualification (DQ) in Equipment and System Qualification

Design qualification is documented verification that a proposed facility, system or equipment design is suitable for its intended purpose, as defined for EU human medicinal-product manufacturing in the Annex 15 glossary.

Common aliases are DQ and design qualification DQ. In practical qualification work, intended purpose means more than an equipment name or nominal capacity. It encompasses the product being handled, the process being supported, the operating environment, the people using or maintaining the system, and its interfaces with utilities, equipment and information systems.

A useful DQ conclusion identifies the design revision assessed, the requirements used as the assessment basis, the evidence supporting the decision and any conditions attached to acceptance. This makes the conclusion specific: suitability applies to that configuration and intended use, not to every application of the supplier’s equipment family.

A design description explains what is proposed. A reasoned suitability assessment explains why that proposal meets the stated needs. For example, listing a vessel’s construction material describes the design; relating that material to the intended product contact and cleaning conditions provides a basis for judging suitability. A drawing or catalogue can support the assessment without being the assessment itself.

The practical boundary here is the manufacturing facility, equipment or system—not the manufactured product’s own design. Product design verification addresses a different object of review. These document-control conventions explain how practitioners make a DQ decision usable; they are not additional legal definitions. The lifecycle section distinguishes this design assessment from subsequent qualification testing.

For EU human medicinal-product manufacturing, the Annex 15 glossary definition of URS connects owner, user and engineering requirements with a feasible design meeting the system’s intended purpose. In practical planning, the user requirements specification therefore gives reviewers the basis for judging the proposed design, rather than simply describing the equipment being purchased.

A common qualification planning sequence is URS, DQ, FAT/SAT, then IQ/OQ/PQ. This is presented here as operational practice, not a mandatory Annex 15 gate sequence. The comparison below uses illustrative evidence, not a prescribed document set.

The V-model is a planning aid: it connects requirements and design decisions with later verification. For example, a specified operating range informs both equipment selection and the challenges planned for testing. Requirements traceability makes those connections visible without forcing every activity into a rigid chronological order.

A favourable DQ conclusion concerns the proposed design; it does not establish what was actually installed or demonstrate operating performance. Those questions need installation records and test results. Justified overlap and iteration are common: a supplier demonstration can inform design review, while a later test finding can reopen a design decision. Documenting the reason preserves the distinction between useful early evidence and unresolved verification.

Here, PQ means equipment performance qualification within IQ/OQ/PQ, not the FDA process-qualification terminology discussed in the jurisdiction section.

Map DQ to the product and market before choosing a review template. Distinguish the authority behind the assessment from the local procedure used to document it.

For US drug manufacturing, FDA Process Validation guidance, section II.B, describes Stage 1, Process Design, as defining the commercial manufacturing process using development and scale-up knowledge; Stage 2, Process Qualification, as evaluating whether that design can deliver reproducible commercial manufacturing; and Stage 3, Continued Process Verification, as gaining ongoing assurance during routine production that the process remains in control.

As an analytical comparison, equipment DQ asks whether a proposed equipment design suits its intended use; process validation addresses the manufacturing process, extending into continued process verification. A local DQ procedure can organise design decisions without making those activities equivalent. In practice, label each review criterion by its basis: applicable regulation, official guidance or site-defined acceptance criterion. This helps reviewers distinguish an external obligation from a locally chosen control.

In EU medicinal-product GMP guidance, Annex 15 sets out the sequence. Section 3.1 says qualification activities should consider all stages "from initial development of the user requirements specification through to the end of use", and notes that the suggested stage criteria depend on individual project circumstances. Section 3.2 makes the URS "a point of reference throughout the validation life cycle". Section 3.3 then names DQ as the next element, "where the compliance of the design with GMP should be demonstrated and documented", adding that "the requirements of the user requirements specification should be verified during the design qualification." FAT/SAT, IQ, OQ and PQ follow in sections 3.4 onward. This is guidance-strength text for EU GMP; in the US, 21 CFR 211.63 requires equipment of appropriate design without prescribing a DQ document.

Practical DQ review topics depend on intended use and risk; they are not a universal checklist. The assessment changes with what the proposed design controls and how failure could affect the process.

• Equipment and utilities: possible site-defined topics include capacity, materials of construction, access for cleaning and maintenance, instrumentation, utility demand and physical installation constraints. Reviewers commonly examine whether these features work together under the intended operating conditions.
• Computerized systems: possible topics include intended workflows, configurable rules, data structures, permissions, interface boundaries, failure behaviour and record retrieval. A practical review connects these choices to user tasks and data integrity by design, rather than assessing screens alone.

Worked case: a temperature-controlled vessel

Assume a proposed vessel supports a defined non-sterile liquid process. Its URS expresses working volume in litres, product temperature in degrees Celsius and exposure time in minutes. No technical limits are assumed here.

The supplier’s heater rating alone does not establish that the vessel and control arrangement can deliver the intended product-temperature profile. The illustrative reviewer examines the heat-balance calculation, including product heat capacity, starting temperature, heat losses and heating time; sensor location and its relationship to product temperature; mixing assumptions across the working-volume range; and the control description, including how exposure timing starts.

The reviewer leaves the temperature-profile requirement unresolved until the design rationale addresses the stated operating envelope. Once resolved, the handoff identifies subsequent operational testing through operational qualification to verify the predicted behaviour, including temperature response and exposure timing under the selected operating conditions.

A practical DQ boundary diagram includes the equipment controller, MES, ERP, laboratory system and interfaces carrying manufacturing records between them. For each record, identify its creator, permitted modifiers and authoritative system for each business decision: order execution, material consumption or acceptance of laboratory results. Review both MES–ERP exchanges and laboratory interfaces; authority should be assigned explicitly rather than inferred from where data are displayed.

As integration-design practice, examine message identity, units, timestamp meaning, acknowledgement state, processing sequence and reconciliation. Define permission boundaries for sending, editing, replaying and resolving records, with an owner for each recovery action. These are design questions, not assumed software capabilities.

Worked case: dispensing retry

Assume a dispensing interface sends a mass in kilograms and a transaction identifier; timestamps use UTC. A timeout can trigger retransmission of the same transaction. No transaction volume or outage duration is assumed.

Follow the original message into the receiver. If processing succeeds but its acknowledgement never reaches the sender, a retry could count the dispensing event again. Alternatively, an unresolved status could persist, or duplicate filtering could silently discard an event whose original processing never completed.

The proposed design uses a persistent source-and-transaction identity retained across retries, duplicate handling that checks committed processing state, and a reconciliation view showing sender, receiver and acknowledgement status. The manufacturing systems owner coordinates recovery with production confirmation of consumption; conflicting payloads are held for review rather than overwritten. In this illustrative review, the interface conclusion remains open until normal processing and recovery are explained.

Later tests challenge interrupted transfer, retry, out-of-order arrival and corrected data. Design evidence describes proposed behaviour; test evidence records observed behaviour, linked through requirements traceability.

In practical DQ review, evidence is useful when it answers a requirement-specific question—not because the supplier dossier is large. Typical evidence roles are:

• Approved requirements establish what the site needs; design specifications explain the proposed solution.
• Drawings show physical arrangement and connections; calculations assess capacity and margins under stated assumptions.
• Component selections explain suitability for service; interface descriptions identify dependencies and exchanged signals or materials.
• Supplier technical responses clarify ambiguities; relevant test records, including applicable factory acceptance testing, show what was demonstrated under recorded conditions.

Frame each acceptance criterion around the requirement, operating context and expected evidence. An objective design criterion might accept a calculation demonstrating the required delivery pressure under defined demand. A future test criterion instead compares measured pressure with the approved range during specified operating conditions. They answer different questions.

Check supplier evidence against the selected model, configuration, revision and intended use. An unsupported suitability declaration does not explain its technical basis. Resolve conflicting drawings, identify excluded options, and check whether conclusions depend on site power, cooling, inlet conditions or other infrastructure.

Worked case: product-contact gas utility

Assume the URS defines gas-quality attributes and point-of-use pressure requirements in kilopascals; this example assigns no pressure, purity or microbiological limit. The compressor’s nominal rating alone does not establish point-of-use performance. Review distribution layout, pressure-loss analysis, treatment arrangement and simultaneous-user assumptions against the URS.

Retain unresolved questions with named owners: ask the supplier engineer for the pressure-loss calculation at the specified concurrent demand, and the site utility engineer to confirm infrastructure assumptions. Identify later point-of-use pressure measurements under defined demand and gas-quality sampling against the site-defined attributes. Plan these in the appropriate site qualification protocols, including operational qualification where applicable; planned measurements are not existing DQ evidence.

In common DQ practice, review effort follows intended use, credible failures and uncertainty—not document volume. A practical risk-based validation chain connects intended use → requirement → failure scenario → design control → supporting evidence → planned verification. For a temperature-controlled vessel, this could connect product holding conditions to a temperature requirement, loss of cooling, an alarm and protective response, control drawings and capacity calculations, then planned challenge testing.

Keep product quality, data reliability, operator safety and availability distinguishable. An interruption may affect several categories, but combining them into one score can hide the reason for a control. Record the consequence and assessment basis for each relevant category.

A supplier's standard feature can still deserve close review when its behaviour or applicability is uncertain. Repeated design elements with relevant operating history commonly need less investigation than novel interfaces or assumptions sensitive to ambient conditions, loading or utility pressure. Evidence strength depends on applicability to the proposed configuration and operating envelope, not merely supplier familiarity.

Requirements traceability works in both directions: each important requirement has a design disposition, and each claimed control has an identified purpose. Review for orphan requirements, unreferenced controls and evidence covering a different revision. A document reference alone does not establish that the proposed design addresses the requirement.

Explicit review outputs commonly include residual risk, unresolved assumptions, owners and closure conditions, recorded in the DQ findings or a linked quality risk register. Acceptance rests on documented reasoning within the site's quality framework, rather than a universal numerical threshold. A minimum implementation model links requirement, design item, evidence reference, review finding and decision; this supports the later data diagram but is not a prescribed regulatory database schema.

A practical requirements traceability table separates what the design proposes from whether a reviewer accepts its rationale. The illustrative entries below suggest document types, dispositions and accountable roles; they are not completed evidence or approval decisions. The vessel and utility entries extend the worked cases above without repeating their calculations.

A document type is a collection target, not a usable evidence locator. Populate each reference with the actual controlled identifier, revision and relevant drawing detail, section or calculation. Recording a design response means the requirement has been addressed; supported means the reviewer has accepted the cited rationale for the assessed baseline.

Not applicable with rationale is an assessed disposition explaining why the requirement does not apply, not a blank cell. A planned future test is a handoff item, not evidence of demonstrated operating performance; link it to the relevant operational qualification activity where appropriate.

The controlled-revision row highlights why unchanged URS wording does not preserve an earlier decision: a drawing change can invalidate its evidence reference. Reassess affected links rather than carrying acceptance forward unchanged.

The accompanying relationship diagram preserves those links: URS need → assessed design baseline → revision-specific evidence → review decision → later verification. The same relationship model works in a controlled document set or a database.

A practical DQ package makes the assessed design and the acceptance decision reproducible. It typically contains scope and intended use, requirement and design baselines, review criteria, risk rationale, evidence references, findings, conclusions and approval records. This is a controlled-review approach, not a universal document template.

The package need not be a single standalone DQ document. A summary can connect drawings, specifications, risk assessments and review records through document control. References should identify the versions and relevant locations clearly enough for another reviewer to reconstruct the assessment without relying on the author's memory.

Implementation checklist

1. Confirm boundaries: identify included equipment, systems, interfaces and exclusions.
2. Identify revisions: record the requirement and design versions actually assessed.
3. Assign reviewers: allocate questions and approval authority using the site's responsibility model.
4. Establish criteria: define what evidence would support acceptance before judging it.
5. Assess evidence: record references, reasoning and gaps against the criteria.
6. Resolve or disposition findings: distinguish completed corrections from justified outstanding actions.
7. Record the conclusion: accept the assessed design, request revision or withhold a favourable conclusion; retain approver identities and approval dates.
8. Transfer conditions and verification tasks: identify owners and destination records, such as the site acceptance test plan.

Engineering typically reviews physical design; process users assess operational suitability; automation or IT specialists assess controls and interfaces; quality personnel review the quality rationale and procedural alignment. Supplier authorship does not itself establish site acceptance.

For a conditional conclusion, record the open issue, its effect on the conclusion, accountable owner, closure evidence and permitted next activity. Judge the restriction against the affected activity: an open item is neither automatically harmless nor necessarily a project-wide stop. Under the site's approval model, authorized people decide qualification progression and, separately, product release; software status changes do not substitute for those decisions.

Moving on before every DQ item is closed is possible under Annex 15 section 2.10, but only with its stated condition: conditional approval to proceed to the next qualification stage "can be given where certain acceptance criteria or deviations have not been fully addressed and there is a documented assessment that there is no significant impact on the next activity." The open-item owner, due date and permitted next activity are the site's own practical fields for managing that decision; the documented no-significant-impact assessment is the guidance condition.

These practical diagnostics focus on whether the evidence supports the design decision—not on supplier reputation or signature count. Treat each warning sign as a reason to examine the reasoning, not as an automatic rejection rule.

Distinguish presentation defects from missing technical support by asking whether correction changes the suitability reasoning. A typographical error may be editorial when the intended reference remains unambiguous. A conflicting drawing revision is not merely editorial if it leaves the assessed configuration uncertain.

Use the risk-based review and disposition approach covered above, rather than a separate score. Follow the affected requirement-to-evidence link, identify what remains unsupported, and document whether the gap prevents a defensible suitability conclusion.

In common qualification practice, the DQ handoff carries operating assumptions, configuration boundaries, critical controls, open conditions and planned verification into execution protocols. Each unresolved condition has an owner, a closure criterion and an identified dependency: which test or operating decision depends on its resolution. Link design conclusions to planned challenges in operational qualification and confirmation under intended production conditions in performance qualification.

Contradictory test results can reopen the design rationale, not merely the test record. Reviewers commonly distinguish an execution error from an invalid assumption, then identify affected conclusions before agreeing corrective action and further verification.

Practical change-screening checklist

For each proposed change, identify which prior conclusion and evidence reference could be affected:

• Intended use: suitability rationale and approved requirements.
• Capacity: sizing calculations and loading assumptions.
• Materials: compatibility evidence and cleaning assumptions.
• Control logic: sequences, interlocks and failure-response evidence.
• Interfaces: data mappings, ownership and recovery tests.
• Infrastructure: utility specifications and dependency assessments.
• Operating envelope: justified ranges and boundary-test coverage.

Record the impact decision against those references, including the rationale where existing evidence remains applicable.

For EU human medicinal-product manufacturing, Annex 15 section 4.1 recommends evaluating equipment, facilities, utilities and systems at an appropriate frequency to confirm continued control. For the same EU human medicinal-product scope, Annex 15 section 4.2 recommends justifying the period and defining evaluation criteria where re-qualification is necessary and performed at a specific interval.