Design Qualification is documented evidence that a proposeddesign or selected solution is suitable for its intended purpose and can meetapproved requirements.
DQ is normally performed before final design approval,purchase, or implementation. For custom systems or equipment, it may includeevaluation of design documents, architecture, functional specifications,components, and applicable requirements.
For commercial software and SaaS, organizations may use adocumented product-selection or design-assessment process to determine whetherthe proposed solution can meet the URS. Supplier assessment is related butdistinct and evaluates the supplier’s capabilities, quality practices,services, support model, and available evidence.
The outcome should document whether the proposed solution issuitable, identify gaps, define how those gaps will be addressed, and recordthe approval or rejection decision.
Frequently Asked Questions
Is DQ mandatory for software systems?
The need for a separately titled DQ document depends on theapplicable regulatory framework and organizational methodology. Theorganization should retain objective evidence showing how the proposed solutionwas assessed against approved requirements.
What is the difference between DQ and a supplier audit?
DQ or product assessment evaluates whether the proposedsolution can meet intended use and requirements. A supplier audit evaluatesselected aspects of the supplier’s quality system and practices. The activitiescomplement each other but are not interchangeable.
We skipped DQ and the system is already live. What should we do?
Perform a documentedretrospective suitability assessment under the quality system. Compare theimplemented system with approved requirements and intended use, identify gaps,evaluate risks, and define corrective actions or controls. Clearly identify theassessment as retrospective.