What design verification means for medical devices
Design verification confirms that design outputs meet design inputs: the device you built matches the requirements you wrote. FDA’s QMSR training puts it simply: verification is “Output meets Input requirements” or “I made the device correctly,” while validation is “I made the correct device” (FDA, QMSR Design and Development). (In chip design, “design verification” refers to simulation and formal checks of hardware logic; that discipline is not covered here.)
Verification is the largest body of evidence in most design files. It includes bench testing, inspections, analyses and tests to recognized standards such as electrical safety, biocompatibility and software testing.
For how verification differs from validation, with checklists for both, see Design Verification vs Design Validation: Medical Device Checklists for 2026.
What the requirements say
Since February 2, 2026, US design controls follow ISO 13485:2016 clause 7.3, incorporated into the QMSR. For verification (clause 7.3.6), FDA summarizes that it must be:
- “performed per documented plans and procedures to ensure outputs meet inputs”
- planned with documented “methods, acceptance criteria, and statistical techniques”
- confirmed for “connections or interfaces with other devices or systems” when the device connects to them
Source: FDA, QMSR Design and Development. BSI’s training on the same clauses stresses “statistical techniques with rationale for sample size” in verification and validation plans (BSI).
For software, FDA’s premarket guidance expects verification evidence and “traceability analyses” linking requirements, design and tests (FDA).
Verification methods
| Method | Use it when | Example |
|---|---|---|
| Test | The requirement is measurable on built units | Flow rate accuracy across temperature range |
| Inspection | The requirement is a visible or dimensional property | Label content, connector dimensions |
| Analysis | Testing is impractical or a model is validated | Tolerance stack-up, thermal simulation |
| Standards testing | A recognized consensus standard applies | Electrical safety, biocompatibility, luer connector standard |
| Software testing | The requirement is implemented in software | Unit, integration and system tests with pass/fail results |
Planning verification that holds up
- Start from verifiable inputs. Clause 7.3.3 requires inputs that are “able to be verified or validated” (FDA). Rewrite vague requirements before writing tests.
- Write the protocol first. Define method, setup, acceptance criteria and sample size before testing.
- Justify sample size. Link it to risk: higher-severity requirements need higher confidence and reliability. For pass/fail attributes with zero allowed failures, a common approach is the success-run calculation (n = ln(1 − C) / ln(R)), which gives 59 units for 95% confidence and 95% reliability.
- Test representative units built with production-equivalent processes and materials, or justify differences.
- Cover the whole product family, or explain why tested variants represent untested ones.
- Handle failures openly. Record deviations and retests; do not average away failures. BSI’s example of 57 units tested, 4 failures and a “pass” claim shows the reasoning auditors reject (BSI).
- Trace results back to each requirement and risk control.
What FDA cites
Two recent warning letters show the most common gaps.
- Coverage of the product family. In March 2026, FDA found that “design verification testing was only performed on a single female luer connector,” that the tested part was not in the final design change file, and that a rationale “fails to explain how design verification testing” of one part number covered other products (FDA warning letter, Medline Industries).
- Acceptance criteria and test plans. In October 2025, FDA found that a firm’s software “Test plans do not include established acceptance criteria prior to testing” and that security test reports were incomplete (FDA warning letter, Contec Medical Systems). FDA cited this under design validation, but the gap, criteria set after the fact, applies equally to verification.
Both inspections predated the QMSR and cite 21 CFR 820.30; the same expectations now sit under ISO 13485 clauses 7.3.6 and 7.3.7.
Design verification checklist
- Verification plan references every design input and risk control
- Protocols approved before testing, with acceptance criteria
- Sample size rationale tied to risk and statistical method
- Units representative of production, or differences justified
- Product family coverage explained
- Interfaces with connected devices or systems verified
- Recognized standards and versions identified
- Deviations, failures and retests documented and assessed
- Results traced to requirements in the traceability matrix
- Reports reviewed and approved; stored in the design and development file
Check verification reports for evidence gaps
Verification reports fail on details: criteria added after testing, unexplained sample sizes, a family claim based on one part. AskDona reviews verification protocols and reports against your procedure, ISO 13485 clause 7.3.6 or the applicable standard, flags missing criteria, weak rationales and coverage gaps, and cites the passage behind every finding.
Run a sample verification report assessment on one protocol and report pair. AskDona shows the evidence; your engineers decide.
FAQ
What is design verification? Objective evidence that design outputs meet design inputs.
What is the difference between design verification and design validation? Verification checks the device against its requirements; validation checks that the device meets user needs and intended use (FDA).
Which regulation covers design verification in the US? Since February 2, 2026, ISO 13485 clause 7.3.6 as incorporated into the QMSR; it replaced 21 CFR 820.30(f).
How do I justify sample size for verification? Base it on risk and a stated statistical method, such as confidence and reliability levels, and document the rationale in the protocol.
Can one test cover a product family? Yes, if you document why the tested configuration represents the others; FDA has cited firms that did not (FDA).
References
All pages opened and checked by October 14, 2026.
| Source | Type | Date | Used for |
|---|---|---|---|
| FDA: QMSR Design and Development (slides) | Regulator training | 2026 | Clause 7.3.6, verification vs validation |
| BSI: Validation and verification webinar | Notified body | Nov 9, 2016 | Sample size rationale |
| FDA: Device software premarket guidance | Regulator guidance | Jun 14, 2023 | Software verification |
| FDA warning letter: Medline Industries | Regulator | Mar 25, 2026 | Family coverage |
| FDA warning letter: Contec Medical Systems | Regulator | Oct 2, 2025 | Acceptance criteria |