Part 6

6.1 What Is Design Qualification?

Design Qualification (DQ) is the documented verification that the proposed design of a facility, utility, equipment item, or system is suitable for its intended purpose and appropriately addresses applicable GMP and user requirements.

In practical terms, DQ asks:

If we build, purchase, configure, and install the system according to this design, will it be capable of meeting its approved intended use and GMP requirements?

DQ should therefore occur sufficiently early to identify deficiencies before fabrication, construction, installation, or final configuration makes correction expensive or difficult.

6.2 Position of DQ in the Qualification Lifecycle

A typical lifecycle is:

Business/Process Need

↓

Intended Use

↓

URS

↓

System/GMP Impact Assessment

↓

Quality Risk Assessment

↓

Conceptual/Detailed Design

↓

Design Review + Design Qualification

↓

Approved Design Baseline

↓

Fabrication / Configuration

↓

FAT

↓

Installation

↓

SAT / Commissioning

↓

IQ

↓

OQ

↓

PQ

↓

Qualification Summary / Release

DQ is therefore a major bridge between:

What the user requires

and

What engineering/vendor proposes to build.

6.3 Why DQ Is Important

Many qualification failures originate from design deficiencies.

Examples include:

• unsuitable product-contact material;
• inaccessible cleaning areas;
• insufficient equipment capacity;
• incorrect instrument range;
• inadequate alarm strategy;
• poor drainage;
• insufficient utility capacity;
• uncontrolled recipe modification;
• inadequate user-access architecture;
• missing audit-trail functionality;
• inadequate backup arrangements;
• poor maintenance access.

Discovering these during OQ is late.

A strong DQ attempts to prevent them during design.

6.4 DQ Is Not Simply a Document Review

Weak DQ:

“URS reviewed against vendor quotation — acceptable.”

Strong DQ:

URS Requirement → GMP/Risk Significance → Proposed Design → Design Evidence → Compliance Status → Open Action

The second approach creates traceable evidence that the proposed design addresses requirements.

6.5 DQ vs Design Review

These concepts overlap but should be understood.

Design Review

A multidisciplinary technical review of the design.

It may evaluate:

• process;
• mechanical;
• electrical;
• automation;
• safety;
• maintenance;
• constructability;
• operability.

Design Qualification

The GMP qualification activity that establishes documented evidence that the design is suitable for intended use.

A company may combine the two activities if its procedures allow and the resulting documentation provides adequate evidence.

6.6 DQ vs IQ

The distinction is fundamental.

DQ

Is the proposed design appropriate?

IQ

Was the approved design correctly installed?

Example:

DQ

Verify that SS316L is specified for a defined product-contact component where justified by the approved requirement.

IQ

Verify that the installed component corresponds to the approved material specification using appropriate documentation/evidence.

Thus:

DQ = Design Intent

IQ = Installed Reality

6.7 DQ Inputs

A meaningful DQ requires adequate design information.

Typical inputs include:

• approved URS;
• intended-use statement;
• system boundary;
• GMP impact assessment;
• quality risk assessment;
• vendor proposal;
• design specification;
• functional specification;
• equipment drawings;
• GA drawings;
• P&IDs;
• process-flow diagrams;
• electrical drawings;
• instrumentation list;
• component list;
• automation architecture;
• software/functional descriptions;
• utility requirements;
• material specifications;
• room/layout drawings;
• cleaning philosophy;
• maintenance requirements.

Not every system requires every document.

The required inputs should reflect system complexity and risk.

6.8 DQ Prerequisites

Before formal DQ approval, confirm as applicable:

• □ Intended use defined
• □ URS approved
• □ System boundary defined
• □ GMP impact assessed
• □ Risk assessment available
• □ Vendor selected or proposed
• □ Relevant design documents available
• □ Process requirements established
• □ Critical aspects identified
• □ Relevant sames identified

DQ performed with incomplete design information may require staged review or documented open actions.

6.9 DQ Team

DQ should generally involve appropriate cross-functional sames.

Actual responsibilities should follow the company’s PQS.

6.10 DQ Review Philosophy

For each important URS requirement, determine:

1. What does the requirement mean?
2. Is it GMP/risk significant?
3. Where is it addressed in the design?
4. What document demonstrates this?
5. Is the design adequate?
6. Is clarification required?
7. Is a design change required?
8. Does the requirement require later verification?

This creates the chain:

URS

↓

Risk

↓

Design Feature

↓

Design Evidence

↓

DQ Decision

↓

FAT/IQ/OQ/PQ Verification

6.11 URS Compliance Review

A DQ should systematically evaluate relevant URS requirements.

A practical table is:

This provides much stronger evidence than simply signing the vendor drawing.

6.12 DQ Compliance Status

A standardized status system is useful.

For example:

C — Complies

Requirement adequately addressed.

PC — Partially Complies

Some aspects require action.

NC — Does Not Comply

Design does not satisfy requirement.

NA — Not Applicable

Requirement does not apply, with rationale.

O — Open

Additional information is required before final disposition.

Definitions should be established in the DQ protocol.

6.13 Process Requirements Review

DQ should verify that the proposed equipment/system can support the intended process.

For a compression machine, this might include:

• product type;
• batch requirements;
• tablet dimensions;
• tooling requirements;
• production capacity;
• turret-speed capability;
• feeder capability;
• compression-force capability;
• pre-compression capability;
• tablet discharge arrangement.

The design should not merely be capable of operating—it should be capable of supporting the intended pharmaceutical process.

6.14 Capacity Review

Capacity should be assessed against actual user requirements.

Example:

URS

Required production capability: 250,000 tablets/hour under defined product conditions.

Vendor design

Maximum nominal capability: 400,000 tablets/hour.

DQ should not simply conclude:

400,000 > 250,000, therefore acceptable.

The team should consider whether the claimed capability applies to:

• intended tooling;
• tablet size;
• product characteristics;
• feeder limitations;
• quality requirements.

Capacity claims should be evaluated in context.

6.15 GMP Design Review

The DQ should evaluate GMP-relevant design characteristics.

Potential areas include:

• cleanability;
• contamination prevention;
• cross-contamination control;
• product-contact materials;
• product retention;
• accessibility;
• dead spaces;
• drainage where applicable;
• segregation;
• controlled access;
• GMP record generation;
• data integrity.

6.16 Product-Contact Materials

DQ should verify that materials specified for product-contact surfaces are suitable for intended use.

Review may include:

• material grade;
• chemical compatibility;
• corrosion resistance;
• product compatibility;
• cleaning-agent compatibility;
• documentation/certification requirements.

Example evidence:

• material specification;
• drawing;
• vendor material list;
• certificate requirements.

The installed material is later verified through IQ/turnover evidence as appropriate.

6.17 Surface-Finish Requirements

Where surface finish is important, DQ should confirm that the design specification contains appropriate requirements.

Consider:

• product retention;
• cleanability;
• corrosion;
• hygienic design;
• process needs.

Values should not be copied automatically from previous equipment without justification.

6.18 Cleaning Design Review

Cleaning should be considered during design, not after equipment installation.

DQ may assess:

• access to product-contact areas;
• dismantling;
• removable components;
• crevices;
• product traps;
• drainability;
• cleaning-agent compatibility;
• CIP functionality where applicable;
• inspection access.

Key question

Can the equipment be practically and reproducibly cleaned using the intended cleaning strategy?

6.19 Cross-Contamination Controls

DQ should evaluate design features intended to control cross-contamination.

Examples:

• enclosed product path;
• dust extraction;
• containment;
• seals;
• dedicated connections;
• cleanability;
• pressure control interfaces.

The scope should reflect product/process risk.

6.20 Containment

Where containment is required, DQ may evaluate:

• enclosed transfer;
• extraction;
• isolating features;
• glove interfaces;
• seals;
• pressure-control strategy;
• cleaning/decontamination arrangements.

Performance requirements should be linked to the applicable risk assessment and intended process.

6.21 Utility Requirements

DQ should confirm that required utilities are correctly defined.

Potential utilities include:

• electricity;
• compressed air;
• vacuum;
• Purified Water;
• WFI;
• clean steam;
• chilled water;
• nitrogen;
• process gases.

Review:

• pressure;
• flow;
• quality;
• temperature;
• connection;
• capacity;
• redundancy where required.

6.22 Utility Capacity

The review should assess both:

Equipment requirement

What does the machine need?

and

Site capability

Can the facility reliably provide it?

Example:

Machine compressed-air requirement:

6 bar at defined maximum consumption

Site utility:

Available pressure and capacity must be demonstrated adequate at expected operating demand.

This prevents commissioning problems later.

6.23 Instrumentation Design Review

DQ should evaluate critical instrumentation.

Consider:

• measurement parameter;
• instrument type;
• range;
• accuracy;
• resolution;
• location;
• accessibility;
• calibration;
• output;
• alarm/control function.

6.24 Instrument Range

A common design error is selecting an instrument whose range is poorly matched to the operating range.

Example:

Process normally operates:

1–3 bar

Instrument selected:

0–100 bar

Even if calibrated, this may be inappropriate depending on required measurement performance.

Therefore:

Calibration alone does not establish suitability.

DQ should consider the relationship between:

Process Range → Required Accuracy → Instrument Range → Control Requirement

6.25 Automation Design Review

For PLC/HMI/SCADA-controlled equipment, DQ should assess the automation concept.

Potential topics:

• PLC architecture;
• HMI;
• control sequences;
• alarm philosophy;
• interlocks;
• recipes;
• user roles;
• data storage;
• audit trails;
• interfaces;
• reports;
• backup/restore.

Testing occurs later, but DQ establishes whether the design contains appropriate controls.

6.26 PLC Design

Review may include:

• controller architecture;
• I/O capacity;
• communication;
• redundancy where justified;
• program backup;
• software/version control;
• access restrictions.

The depth depends on system risk and complexity.

6.27 HMI Design

Assess whether the HMI supports intended operation.

Consider:

• process status;
• critical parameters;
• alarms;
• operator prompts;
• recipe selection;
• user access;
• trends;
• reports where applicable.

Cosmetic preferences should not be confused with GMP-critical design requirements.

6.28 SCADA Design

For SCADA-controlled systems, DQ may additionally consider:

• server architecture;
• historian;
• interfaces;
• redundancy;
• data storage;
• network;
• time synchronization;
• backup;
• restore;
• security.

6.29 Recipe Management

Recipe design should be evaluated where recipes influence GMP processing.

Questions include:

• Who can create recipes?
• Who can modify them?
• How are recipes identified?
• Are parameter ranges controlled?
• Is approval required?
• Are changes traceable?
• Can obsolete recipes be controlled?

These requirements should derive from intended use and risk.

6.30 User Access Design

Role-based access should be assessed where relevant.

A conceptual matrix might be:

The actual matrix should follow approved business and GMP requirements.

6.31 Audit-Trail Design

Where audit trails are applicable, DQ should consider whether the proposed system can capture appropriate GMP-relevant events.

Potential events include:

• parameter changes;
• recipe changes;
• configuration changes;
• user-management changes;
• data modification;
• significant actions.

DQ should also consider whether records are:

• reviewable;
• retained;
• protected;
• time stamped appropriately.

6.32 Electronic Records

DQ should identify:

• what records are electronic;
• where they originate;
• where they are stored;
• how they are protected;
• how they are retrieved;
• how long they are retained;
• whether interfaces exist.

This should be based on intended use rather than assuming every machine display constitutes a regulated electronic record.

6.33 Electronic Signatures

Where electronic signatures are intended, DQ should assess the proposed design against applicable requirements.

Questions include:

• What action is being signed?
• Who is authorized?
• How is identity established?
• How is the signature linked to the record?
• What meaning is associated with the signature?

If electronic signatures are not part of intended use, the requirement should not be artificially imposed.

6.34 Backup and Restore Design

DQ should evaluate:

• what must be backed up;
• backup location;
• frequency;
• configuration backup;
• recipe backup;
• GMP data backup;
• restoration capability;
• responsibilities.

A backup that cannot be restored is not an adequate recovery control.

6.35 Data-Flow Review

For complex computerized systems, DQ should understand data movement.

Example:

Machine Sensor
      ↓
     PLC
      ↓
     HMI
      ↓
   SCADA
      ↓
 Historian / Database
      ↓
      MES
      ↓
 Batch Record / Report

Each interface may introduce risks such as:

• missing data;
• duplicate data;
• incorrect mapping;
• timestamp mismatch;
• communication failure.

6.36 Cybersecurity Considerations

Cybersecurity should be considered where relevant to the reliable GMP operation of the system.

Design considerations may include:

• authentication;
• password management;
• network segmentation;
• controlled remote access;
• firewall architecture;
• malware protection where applicable;
• patching strategy;
• removable media controls;
• administrator access.

The scope should reflect system architecture and GMP risk.

6.37 Alarm Design

DQ should assess whether alarms exist for significant abnormal conditions identified by risk assessment.

For each important alarm, consider:

• trigger condition;
• setpoint;
• priority;
• operator response;
• acknowledgement;
• record/history;
• reset behavior.

Alarm proliferation should be avoided.

Not every event requires a critical alarm.

6.38 Interlock Design

Interlocks may protect:

• product;
• equipment;
• process;
• operator.

Examples:

• guard interlock;
• low lubrication pressure;
• high compression force;
• dust-extraction permissive;
• utility failure.

Risk assessment should determine which interlocks are important to qualification.

6.39 Failure-State Design

DQ should consider credible failure scenarios.

Examples:

• power failure;
• compressed-air failure;
• network failure;
• PLC restart;
• sensor failure;
• communication loss;
• emergency stop.

The design should define safe and controlled system behavior.

6.40 Power Failure and Recovery

Questions include:

• What happens when power fails?
• Does the machine stop safely?
• Are critical parameters retained?
• Are recipes retained?
• Are records preserved?
• What happens after power restoration?
• Does the system automatically restart?
• Is operator intervention required?

These decisions should be established during design rather than discovered during OQ.

6.41 Safety Requirements

DQ should verify applicable safety requirements are incorporated.

Examples:

• guards;
• emergency stops;
• safety interlocks;
• overload protection;
• electrical safety;
• pressure relief;
• safe access.

Safety assessment may be governed primarily by engineering/EHS requirements, but safety functions may overlap with GMP qualification where failure can also affect product/process control.

6.42 Maintenance Design

Maintainability should be considered early.

Review:

• component access;
• calibration access;
• lubrication points;
• filter replacement;
• critical spare parts;
• diagnostic capability;
• software backup;
• safe maintenance access.

Poor maintainability can undermine the qualified state.

6.43 Preventive Maintenance

DQ should identify the manufacturer’s proposed PM requirements and determine whether the design supports:

• inspection;
• lubrication;
• replacement;
• adjustment;
• calibration.

These requirements later feed into the site’s maintenance program.

6.44 Spare Parts

Review should identify critical spares.

Examples:

• sensors;
• PLC modules;
• HMI;
• drives;
• seals;
• filters;
• motors;
• product-contact components.

For computerized systems, obsolescence and replacement compatibility may also be relevant.

6.45 Documentation Requirements

DQ should verify that the supplier will provide the required turnover documentation.

Typical documents include:

• GA drawings;
• P&IDs;
• electrical drawings;
• pneumatic drawings;
• instrument lists;
• component lists;
• material certificates;
• calibration certificates;
• manuals;
• software documentation;
• I/O lists;
• alarm lists;
• spare-parts lists.

6.46 Documentation Deliverable Matrix

A practical table:

This prevents missing documentation at project closeout.

6.47 Design Risk Assessment

DQ and design risk assessment should interact closely.

A design FMEA may examine:

DQ verifies that appropriate controls have actually been incorporated into the proposed design.

6.48 Design Qualification and FAT

DQ establishes what the design should provide.

FAT then provides an early opportunity to demonstrate that the fabricated/configured system actually provides important functions.

Example:

DQ

Confirms design includes automatic tablet rejection.

FAT

Physically/functionally challenges the reject system.

Thus:

DQ = Review Design

FAT = Test Fabricated/Configured System

6.49 Design Qualification and IQ

DQ establishes the approved design baseline.

IQ verifies the installed system against that baseline.

Example:

DQ

Critical instrument range specified as appropriate.

IQ

Installed instrument:

• correct tag;
• correct manufacturer/model;
• correct range;
• calibrated;
• correctly installed.

This relationship is essential for traceability.

6.50 Design Qualification and OQ

DQ should identify important functions that later require operational challenge.

For example:

DQ identifies:

• critical alarm;
• guard interlock;
• recipe control;
• reject mechanism;
• access-control architecture.

OQ demonstrates:

• alarm triggers correctly;
• interlock prevents operation;
• recipe controls operate correctly;
• reject mechanism works;
• unauthorized access is prevented.

6.51 DQ and PQ

DQ should confirm that the system has the design capability needed to support eventual PQ.

Example:

For a blender:

• minimum load;
• maximum load;
• operating speed;
• timer;
• control functions.

PQ then evaluates performance under actual or appropriately simulated routine conditions.

6.52 Design Changes During DQ

Design changes are normal during pharmaceutical projects.

They should be controlled.

Typical sequence:

Design Review

↓

Deficiency / Improvement Identified

↓

Design Change Proposed

↓

Impact Assessment

↓

Risk Assessment if necessary

↓

URS Impact

↓

Design Document Updated

↓

DQ Re-review

↓

Approval

Design changes should not result in uncontrolled discrepancies between:

• URS;
• drawings;
• specifications;
• software;
• qualification protocols.

6.53 Example — Design Change

Original requirement:

Compression machine shall support defined product-dedusting interface.

During DQ, the proposed outlet elevation is found incompatible with the selected deduster.

Action:

1. Record DQ open item.
2. Engineering revises discharge design.
3. Vendor updates GA drawing.
4. Interface dimensions reviewed.
5. Risk assessment updated if needed.
6. Revised design accepted.
7. DQ item closed.

This is preferable to discovering the incompatibility during SAT.

6.54 Open Items

Not every DQ issue must necessarily stop the entire project.

Open items should be categorized according to significance.

Example:

Critical

Design deficiency affecting GMP suitability.

Disposition: Resolve before design approval/fabrication as appropriate.

Major

Significant issue requiring closure before FAT or installation.

Minor

Documentation/detail that can be closed later without compromising design suitability.

The company’s procedure should define categories and release rules.

6.55 DQ Punch List

A DQ action register may contain:

Open items must be traceable to final closure.

6.56 DQ Deviations

A distinction should be made between:

• design review comment;
• open item;
• specification discrepancy;
• formal GMP deviation.

Not every design comment is automatically a GMP deviation.

However, significant departures from approved requirements or controlled qualification activities should be managed according to the applicable PQS.

6.57 Requirement Deviations

Suppose the vendor cannot meet a URS requirement.

Do not simply write:

“Vendor standard accepted.”

Instead evaluate:

1. Why can the requirement not be met?
2. Is the requirement truly necessary?
3. What GMP/process risk exists?
4. Is an alternative design available?
5. Does the URS require formal revision?
6. Is risk acceptance justified?
7. Who approves the disposition?

The approved requirement should not be silently ignored.

6.58 URS Change During DQ

Sometimes DQ reveals that the URS itself is incorrect or unnecessarily restrictive.

A controlled process should be used:

Issue Identified

↓

URS Change Proposed

↓

Technical/GMP Justification

↓

Risk Assessment

↓

Change Approval

↓

URS Revision

↓

Design Updated

↓

Traceability Updated

Do not retrospectively rewrite the URS merely to make the vendor design appear compliant.

6.59 Supplier Design Review

Supplier participation is valuable because the vendor understands:

• equipment design;
• component selection;
• software architecture;
• standard limitations;
• engineering constraints.

However:

Supplier acceptance of its own design is not a substitute for user/quality review.

The pharmaceutical company remains responsible for determining suitability for its intended GMP use.

6.60 Design Qualification Meeting

For complex equipment, a formal DQ review meeting can be effective.

Suggested agenda:

1. Intended use
2. URS
3. GMP impact
4. Risk assessment
5. Process requirements
6. Mechanical design
7. Product-contact materials
8. Cleaning
9. Utilities
10. Instrumentation
11. Automation
12. Data integrity
13. Safety
14. Maintenance
15. Documentation
16. FAT strategy
17. Open items
18. Approval/readiness decision

Minutes and actions should be controlled according to project/PQS requirements.

6.61 Recommended DQ Protocol Structure

A comprehensive DQ protocol can contain:

1. Document Control

• document title;
• document number;
• revision;
• equipment/system ID;
• project number.

2. Approval

• prepared by;
• reviewed by;
• approved by.

3. Objective

State what DQ intends to establish.

4. Scope

Define:

• equipment/system;
• included subsystems;
• exclusions;
• interfaces.

5. References

Examples:

• URS;
• VMP;
• qualification plan;
• risk assessment;
• applicable specifications;
• drawings;
• company procedures.

6. Definitions and Abbreviations

7. Responsibilities

Define roles.

8. System Description

Describe:

• intended use;
• process;
• major components;
• automation;
• utilities.

9. DQ Prerequisites

List documents required before execution.

10. Design Documents Reviewed

Create a document register.

11. URS Compliance Review

Requirement-by-requirement assessment.

12. GMP Design Review

13. Process Design Review

14. Mechanical Design Review

15. Product-Contact Material Review

16. Cleaning Design Review

17. Utility Review

18. Instrumentation Review

19. Automation Review

20. Data-Integrity Review

21. Safety Review

22. Maintenance Review

23. Documentation Review

24. Risk-Control Verification

25. Open Items

26. Deviations

27. Traceability

28. Conclusion

29. Approval

6.62 Example DQ Test/Review Sheet

DQ Test No.: DQ-04

Title: Product-Contact Material Review

Objective:
Verify that the proposed materials of construction for product-contact components satisfy approved requirements.

Reference:
URS-MOC-001 to URS-MOC-008

Documents Reviewed:
Material specification, GA drawing, vendor component list.

Method:
Review the specified material for each identified product-contact component against the approved URS/design requirement.

Acceptance Criteria:
All applicable product-contact components shall be specified using materials that comply with approved requirements, or any exception shall have an approved documented disposition.

Actual Result:

Conclusion:
Pass / Fail / Open

Reviewed By:

6.63 Example — Automation DQ

Requirement

URS-AUT-014

System shall provide defined role-based access.

Risk

Unauthorized users could modify process-critical configuration or recipe parameters.

Design Review

Review:

• role definitions;
• permissions;
• administrator controls;
• recipe privileges;
• configuration privileges.

DQ conclusion

Design architecture provides required access levels.

Later verification

FAT/OQ: Challenge actual access permissions.

Thus:

DQ verifies the design; OQ verifies the implemented function.

6.64 Example — Audit Trail DQ

URS

GMP-relevant changes shall be appropriately traceable where audit-trail functionality is applicable.

DQ Review

Assess:

• which events are recorded;
• user identity;
• date/time;
• old/new value where applicable;
• reason for change where designed/required;
• review capability;
• retention.

DQ Result

If vendor system cannot record relevant critical changes, this should be identified before procurement/final configuration, not discovered during OQ.

6.65 Example — Tablet Compression Machine DQ

Consider a new compression machine.

Intended Use

Manufacture tablets within approved process ranges.

Critical Design Areas

Mechanical

• turret;
• punches/dies;
• feeder;
• compression rollers;
• discharge;
• reject system.

Process Controls

• turret speed;
• feeder speed;
• fill depth;
• pre-compression;
• main compression;
• weight control where provided.

Safety

• guards;
• emergency stop;
• interlocks.

Automation

• PLC;
• HMI;
• alarms;
• recipes;
• user access.

Data

• audit trail where applicable;
• reports;
• electronic records;
• backup where applicable.

6.66 Compression Machine DQ Matrix

This matrix becomes an important traceability bridge.

6.67 DQ Acceptance Criteria

DQ acceptance criteria should be predefined.

A practical overall criterion may be:

All GMP-critical and high-risk URS requirements shall be demonstrated as adequately addressed by the proposed design or have an approved documented resolution prior to final design acceptance. Other open items shall be assessed for impact and assigned documented actions and closure requirements.

Do not use a blanket criterion such as:

“90% of requirements must comply.”

Ten percent could contain the most critical requirements.

6.68 DQ Final Disposition

The DQ may conclude:

Approved

Design is acceptable.

Approved with Controlled Open Items

Design is acceptable to proceed to the specified next stage, subject to documented closure requirements.

Not Approved

Significant design deficiencies prevent progression.

The disposition should clearly define what activities may proceed.

6.69 DQ Summary

A DQ summary should document:

• documents reviewed;
• URS compliance;
• risk-control status;
• open items;
• deviations;
• design changes;
• unresolved issues;
• final conclusion.

The summary should answer:

Does the proposed design provide sufficient assurance that the system can meet its intended GMP use?

6.70 Final Approval

DQ approval typically involves the relevant:

• User;
• Engineering;
• Validation;
• QA;
• Automation/IT where applicable.

The approval means more than:

“Document reviewed.”

It indicates acceptance of the design within each function’s responsibility.

6.71 Common DQ Deficiencies

6.72 Inspector Perspective

An inspector may ask:

Show me how you determined this equipment design was suitable before purchase.

Expected evidence may include:

• URS;
• risk assessment;
• design review;
• DQ;
• vendor documents.

Another question:

Your URS requires audit trails. Where was that requirement evaluated during design?

The team should trace:

URS → Risk → Design Specification → DQ

The inspector may then ask:

Where did you verify that the implemented function actually works?

Continue:

DQ → FAT/OQ

This demonstrates lifecycle traceability.

6.73 Potential Inspector Red Flags

Examples include:

• DQ approved after FAT;
• DQ copied from another machine;
• no design documents referenced;
• no URS traceability;
• GMP-critical requirement marked “vendor standard”;
• open critical items at approval;
• missing automation review;
• no data-integrity consideration;
• changes after DQ not assessed;
• installed configuration materially differs from approved design.

6.74 DQ Inspection-Readiness Checklist

Before DQ

• □ Intended use approved
• □ URS approved
• □ Impact assessment complete
• □ Risk assessment available
• □ Design documents available
• □ sames identified
• □ DQ protocol approved

Process/Mechanical

• □ Capacity reviewed
• □ Operating ranges reviewed
• □ Product-contact materials reviewed
• □ Surface finish reviewed where relevant
• □ Cleaning requirements reviewed
• □ Drainability reviewed where applicable
• □ Cross-contamination controls reviewed
• □ Containment reviewed where applicable

Utilities/Instrumentation

• □ Utility requirements reviewed
• □ Site utility capacity considered
• □ Critical instruments identified
• □ Instrument ranges reviewed
• □ Accuracy requirements reviewed
• □ Calibration capability reviewed

Automation/Data

• □ PLC architecture reviewed
• □ HMI reviewed
• □ SCADA reviewed where applicable
• □ Recipes reviewed
• □ Alarms reviewed
• □ Interlocks reviewed
• □ User roles reviewed
• □ Audit-trail requirements reviewed
• □ Electronic records reviewed
• □ Electronic signatures reviewed where applicable
• □ Data flow reviewed
• □ Backup/restore reviewed
• □ Security considered

Maintenance/Safety

• □ Maintenance access reviewed
• □ PM requirements considered
• □ Critical spares considered
• □ Safety systems reviewed
• □ Failure/recovery strategy reviewed

Documentation

• □ Vendor deliverables defined
• □ Drawings reviewed
• □ P&IDs reviewed where applicable
• □ Software documents identified
• □ Certificate requirements defined
• □ FAT requirements established

Closure

• □ All critical requirements assessed
• □ Noncompliances documented
• □ Open items classified
• □ Actions assigned
• □ Design changes controlled
• □ Risk assessment updated where necessary
• □ Traceability updated
• □ Final DQ conclusion documented
• □ Approval completed

6.75 Design Qualification Evidence Chain

A mature DQ should establish:

Intended Use

↓

URS

↓

GMP Impact

↓

Quality Risk

↓

Critical Design Requirement

↓

Design Solution

↓

Design Evidence

↓

DQ Acceptance

↓

FAT/SAT/IQ/OQ/PQ Verification

This prevents qualification from becoming disconnected from engineering design.

6.76 Golden Rule of DQ

The most important DQ question is not:

“Does the vendor design match the quotation?”

It is:

“Does the proposed design adequately address the approved intended use, GMP requirements, identified risks, and critical user requirements—and can those design controls subsequently be verified through objective evidence?”

A design should be qualified before the organization becomes commercially or technically locked into a deficient solution whenever practicable.

Part 6 — Key Takeaway

Design Qualification is the stage where pharmaceutical requirements and risk controls are converted into an approved engineering and functional design baseline.

A robust DQ demonstrates:

URS → GMP Impact → Risk → Critical Aspect → Design Solution → Design Review → DQ Acceptance → Verification Strategy

It should establish that the proposed design adequately addresses:

Process + GMP + Product Contact + Cleaning + Cross-Contamination + Utilities + Instrumentation + Safety + Maintenance + Automation + Data Integrity + Lifecycle Requirements

and should identify where each important design feature will later be physically or functionally verified.

Therefore, successful DQ does not prove that the equipment has been correctly manufactured or that it operates successfully. It establishes that the proposed design is suitable enough to proceed to fabrication/configuration and subsequent verification.

The next lifecycle stage is Part 7 — Factory Acceptance Test (FAT), where the approved design moves from paper to physical/configured evidence through mechanical, electrical, instrumentation, PLC/HMI, alarm, interlock, sequence, recipe and data-integrity testing at the supplier’s facility before shipment.

About the Author

Ramesh Palav is a pharmaceutical professional with 20+ years of industry experience in manufacturing, GMP, quality systems, validation, compliance, and operational excellence. Through Pharma Manufacturing Hub, he shares practical insights on pharmaceutical careers, manufacturing, quality, validation, Pharma 4.0, AI, and professional development.

His goal is to help students, freshers, experienced professionals, and career-break professionals build the knowledge and skills needed to succeed in the pharmaceutical industry.