DQDesign Qualification

Design Qualification is the formal review that confirms a proposed design — typically the supplier's Functional Specification (FS) and Design Specification (DS) together with the configuration choices the customer has made — meets every User Requirement (URS). It happens before the system is procured, built or configured at scale, so design gaps are caught at the point where they are cheapest to fix.

DQ is not an installation check (that's IQ), not a functional test (that's OQ), and not a performance demonstration in the live environment (that's PQ). It is a paper exercise — a structured review of specifications against requirements, with explicit traceability and an explicit gap list.

EU GMP Annex 15 §3.2 makes DQ mandatory for facilities, systems and equipment used in GMP manufacture. ICH Q9 risk classification determines the depth of the DQ — a UV/Vis spectrophotometer used for in-process measurement gets a much shorter DQ than a chromatography skid for biologic purification. PIC/S, WHO TRS and FDA's 2011 Process Validation Guidance all align: DQ is the V-model entry point for any system whose performance affects product quality.

GAMP 5 maps DQ to the V-model left-arm, between URS and FS. For Category 1 infrastructure software and Category 3 non-configured products, DQ is usually a single page confirming that the catalogue product matches the URS. For Category 4 configured products (like an MES, LIMS or QMS — V5 sits here) and Category 5 bespoke software, DQ is a full structured review of every URS line item against the supplier's specs plus the customer's configuration.

1. Scope — which system, which version, which sites, which processes.
2. Reference documents — URS, FS, DS, supplier quality documentation, regulatory standards, configuration specification.
3. Requirements traceability — every URS line item mapped to where in the supplier's FS / DS / configuration spec it is satisfied.
4. Gap list — every URS line item not satisfied by the baseline design, plus the agreed mitigation (configuration change, custom development, business-process change, or formally accepted risk).
5. Risk assessment — ICH Q9-style ranking of each gap by severity, probability and detectability so the validation team know where to focus OQ.
6. Supplier assessment outcome — confirmation that the supplier's quality system (GAMP 5 Appendix M2) is adequate for the GAMP category.
7. 21 CFR Part 11 / Annex 11 mapping — explicit confirmation of how electronic records and electronic signatures are handled.
8. Approval — author, reviewer, system owner, QA, and (for higher-risk systems) IT and business sponsor signatures.

The traceability matrix is the operational heart of the DQ. It is also the asset that survives DQ and feeds OQ, PQ and every future change-control assessment. A minimum-viable row looks like:

Three columns matter most to auditors. "Covered?" must be Yes / No / Partial — never blank. The gap column must reference an open change record or accepted-risk record by ID. And the FS / DS references must point at the specific section, not at the document as a whole — "see FS" is a finding.

Modern COTS, cloud and SaaS systems shift the DQ posture. The supplier holds the FS and DS (often as confidential documents under NDA), so the customer's DQ leans on the supplier's documented internal V-model plus the customer's URS-to-FS trace. PIC/S PI 041 and the FDA 2022 CSA draft guidance both accept this risk-based posture: the customer assesses the supplier's quality system once (GAMP 5 Appendix M2), then re-uses that assessment across all DQ activities for that supplier's products, focusing customer-side DQ effort on configuration.

For SaaS with controlled releases (V5 is one), the customer's DQ also references the supplier's release-notes / change-summary so each upgrade can be re-DQ'd in hours rather than re-validated from scratch.

• Author — typically the validation lead or system owner. Drafts the requirement-to-spec mapping and the gap list.
• Independent reviewer — a second qualified individual (often the QA validation specialist) confirms the trace is complete and the gaps are correctly characterised.
• QA approval — confirms the DQ is consistent with the VMP and that all gaps either close before OQ or carry an approved risk acceptance.
• System owner / business sponsor — accepts the design on behalf of the business process.
• IT — for hosted / cloud / on-prem deployment, IT signs to confirm infrastructure and security posture meets URS.

• Skipping DQ entirely for "obvious" configured products — auditors expect the trace, even if it's short.
• DQ written after the system is already installed (reverse-engineered DQ) — a 483 / Annex 15 deviation flag.
• Generic URS items ("the system shall be reliable") that cannot be verified — clean the URS before DQ, not during it.
• Trace cells filled with "see FS" rather than section-level references.
• Gaps with no owner, no due date, no risk classification.
• DQ approved by the author alone — Annex 15 expects independent review.