Cahir MedTech
All insights

QMSR Design Controls: A Practical Guide for Medical Device Teams

Build inspection-ready design controls under QMSR: input-output traceability, decision-grade design reviews, verification and validation evidence, and risk linkage, with an editable planner.

QMSR Design Controls: A Practical Guide for Medical Device Teams

The Quality Management System Regulation (QMSR) is FDA's medical-device quality-system regulation in 21 CFR Part 820. Effective February 2, 2026, it incorporates ISO 13485:2016 by reference while retaining FDA-specific requirements. Design controls sit at the center of that framework: ISO 13485 clause 7.3 governs design and development, and FDA investigators will test whether those controls actually shaped the device you sell, whatever its risk class or technology.

A defensible design-control system does not depend on a thicker design history file. It depends on a traceable chain from user needs to released product, with decision records at each gate. An investigator should be able to pick one requirement and follow it through inputs, outputs, verification, validation, transfer and change control without relying on one engineer's memory. This guide turns that objective into practical preparation for any device category—not a promise that any inspection will end without observations.

Start with the current rule, not legacy guidance

One housekeeping item matters before you reorganize anything: FDA withdrew its 1997 Design Control Guidance when QMSR took effect. The agency's withdrawn or expired guidance list records the withdrawal, so procedures and training that cite the 1997 document as the operative interpretation should be updated to reference current Part 820 and the incorporated ISO 13485 clauses. FDA's QMSR overview and QMSR frequently asked questions explain the combined framework.

Scope first. Design controls apply to the design and development activities your organization actually performs, whether you design in-house, share development with a partner, or own the design history for a product built by a contract manufacturer. Map which devices, variants and outsourced design activities fall inside the system before assigning remediation work. The QMSR implementation guide provides the broader operating sequence, and the ISO 13485 versus QMSR gap analysis helps identify where certification alone leaves FDA-specific exposure.

Build the input-to-output traceability chain

Design inputs are the physical, performance, safety, regulatory and usability requirements that the design must satisfy. The practical test is not whether inputs exist but whether each one is unambiguous, verifiable and traceable. Vague inputs—"easy to use," "reliable," "fast"—produce verification arguments instead of verification evidence.

Design outputs are the specifications, drawings, software configurations, labeling content and acceptance criteria that allow the device to be built and evaluated. Every output should trace back to the inputs it satisfies, and every input should land in at least one output and one verification activity. A simple traceability matrix, maintained as the design evolves rather than reconstructed before an audit, is usually the fastest way to expose gaps. When a requirement changes, the matrix should show which outputs, tests, risk controls and labeling claims move with it.

Make design reviews decision records

Clause 7.3 expects planned, documented reviews at suitable stages, with an independent perspective. In practice, reviews fail inspection in two ways: they become status meetings with no recorded decisions, or the record shows agreement without the evidence reviewers actually examined. A decision-grade review record captures the stage, the evidence package reviewed, the issues raised, the disposition of each issue, the decision to proceed or hold, and the assigned actions with owners and dates.

Risk management belongs inside those reviews rather than in a parallel silo. FDA recognizes ISO 14971:2019 as a consensus standard for risk management; you can confirm current recognition status in FDA's recognized consensus standards database. Each review should confirm that new hazards identified during development were evaluated, that risk controls became design inputs, and that residual-risk conclusions still hold as the design matures.

Connect verification, validation and change control

Verification asks whether design outputs meet design inputs; validation asks whether the resulting device meets user needs and intended uses under actual or simulated use conditions. Keep the two distinct in both planning and records. A strong verification protocol defines methods, acceptance criteria, sample rationale and equipment before execution, and a strong validation uses production-equivalent units and representative users or environments. Where software is involved, verification evidence should reflect the software's role in device functions and risk controls rather than generic test logs.

Change control closes the loop. Design changes—whether driven by test failures, supplier issues, complaints or cost work—need documented review, verification or validation appropriate to the change, and approval before implementation. The record should identify affected documentation, inventory and fielded product, and should state whether the change alters risk conclusions or regulatory status. Transfer of the finished design into production carries its own controls; the companion design transfer guide covers that handoff, and the complaint, MDR, CAPA and risk management guide covers how field data feeds back into design decisions.

Swipe horizontally to see all columns.

Design-control stageEvidence to samplePractical failure signal
InputsOne requirement traced to outputs and testsVague or unverifiable wording
OutputsSpecifications against input matrixOutputs with no input parent
Design reviewOne review package and decision recordMinutes without evidence or dispositions
VerificationOne protocol and report pairCriteria written after testing
ValidationProduction-equivalent units in use conditionsBench units only
Change controlOne design change end to endRelease before impact review

Download the design controls evidence planner

Download the editable QMSR Design Controls Evidence Planner.xlsx. Use it to assign owners, map each stage to its evidence, record review gates and track gaps. It is a preparation aid, not an FDA form, certification tool or substitute for device-specific regulatory judgment.

  • Design-control procedures reference current Part 820 and ISO 13485, not the withdrawn 1997 guidance.
  • Every design input is verifiable and traced to outputs and verification activities.
  • Design reviews record evidence, decisions, dispositions and action owners.
  • Risk management updates are evaluated at each design gate.
  • Design changes are reviewed, verified or validated, and approved before implementation.

FDA primary sources

Start with FDA's QMSR overview, QMSR frequently asked questions and the Inspection of Medical Device Manufacturers compliance program, which describes how investigators evaluate design controls under CP 7382.850. Use current 21 CFR Part 820 for binding quality-system text, FDA's recognized consensus standards database for ISO 13485 and ISO 14971 recognition status, and the withdrawn or expired guidance list to retire superseded references.

Turn design documentation into controlled execution

Use MedTech Copilot to organize requirements traceability, review decisions, verification evidence and design-change impacts around traceable decisions. Qualified human owners remain responsible for design approval, release and regulatory determinations. The goal is practical, evidence-backed, inspection-ready implementation—not automated assurance of compliance.

Share thisLinkedInXEmail

Follow MedTech Insights

New articles on FDA 510(k) and De Novo pathways, CE Mark and EU MDR, and device reimbursement — sent to your inbox as they publish.

See the CAHIR MedTech Suite in action

Request a demo