Design verification

Design controls split the right-hand leg of the V-model into two distinct activities that auditors will never let you conflate. Verification is objective evidence that the design outputs meet the design inputs — every spec, drawing, code module, label and packaging artwork is checked against the input it was meant to satisfy. Validation is objective evidence that the finished device, in production-equivalent form, meets defined user needs and intended use in the actual or simulated use environment.

FDA's 1997 Design Control Guidance and ISO 13485 §7.3.6/§7.3.7 both insist on the distinction because the two activities use different methods, different test subjects, and protect against different failure modes. Mixing them up — for example, declaring bench testing alone to be "validation" — is one of the most common findings in 483 letters citing 820.30(g).

Verification is broad and methodical. Every design output traces to a design input, and every input is verified by at least one of four method classes:

• Inspection — visual/dimensional check against a drawing or spec (CMM reports, microscopy, gauge readings).
• Analysis — engineering calculation, FEA, worst-case stack-up, software static analysis, biocompatibility extractable-chemical risk assessment.
• Demonstration — qualitative functional check (the button lights, the alarm sounds, the screen renders).
• Test — quantitative measurement against an acceptance criterion (electrical safety per IEC 60601-1, EMC per IEC 60601-1-2, biocompatibility per ISO 10993, software unit/integration testing per IEC 62304, packaging per ISTA 3A, accelerated aging per ASTM F1980).

Each verification record carries the version of the input being verified, the version of the output, the protocol number, the sample size and rationale, the acceptance criterion, the result, who executed it, who reviewed it, and the disposition. Failures feed back into design changes — not into a quiet post-hoc tightening of the acceptance criterion.

Validation tests the finished device in the hands of representative users, in a representative environment, performing the actual tasks the device is intended for. The sample units must be made under production-equivalent conditions (initial production lots are typical) — validating a benchtop prototype rebuilt by R&D the night before is the second most common 483 finding in this section.

• Simulated-use studies — clinicians or patients use the device on bench models, mannequins or cadavers under realistic conditions.
• Clinical evaluation / investigation — when bench/simulated cannot answer the user-need question, ISO 14155 (EU MDR Article 62) or an IDE study (US 21 CFR 812).
• Human-factors validation — summative usability study under IEC 62366-1 / FDA 2016 HF Guidance, with ≥15 representative users per distinct user group, evaluating critical tasks for use errors.
• Software validation — the integrated software-system test under IEC 62304 plus, where the software is the device, the clinical-evaluation evidence required by IMDRF SaMD N41.

Because use-related risk is one of the leading causes of device-related harm, FDA and the IEC 62366 series carve out human-factors validation as a discrete activity inside design validation. The summative HF study evaluates the device on tasks that the formative work and risk analysis identified as critical (those whose failure could result in serious harm).

• Recruit ≥15 representative users per distinct user group (lay user, nurse, physician — each is a separate cohort).
• Use the production-equivalent device, the production labelling, the production IFU, and the actual use environment (or a high-fidelity simulation).
• Record every use error, close call and operational difficulty. Conduct a root-cause interview immediately after each session.
• Feed use-error root causes back into ISO 14971 risk control — do not close the study by simply adding a warning to the IFU.

The traceability matrix is the single artefact every notified-body, FDA and MDSAP auditor reaches for to navigate a DHF. For each user need it shows the design input, the design output, the verification record proving the output meets the input, and the validation record proving the output meets the need. A complete trace looks like:

Gaps in the matrix are gaps in the DHF — and the inspector will spot them in minutes. The matrix is also the single document you maintain through every design change: a change to an output triggers re-verification; a change that touches user needs or intended use triggers re-validation.

820.30(i) requires every design change to be identified, documented, reviewed, verified and (where appropriate) validated before implementation. The decision tree:

1. Does the change affect a design output? → re-verify the affected output against the relevant input.
2. Does the change affect a design input, intended use, user need, or critical task? → re-validate (and trigger an IEC 62366 use-related risk re-evaluation).
3. Does the change affect risk? → re-run the ISO 14971 risk file for the affected hazard chain.
4. Does the change require a regulatory submission? → 21 CFR 807.81(a)(3) significant change → new 510(k); EU MDR Article 120 → notified-body assessment.

• Treating V&V as a single activity ("V&V testing") so it is impossible to tell whether outputs were verified or whether the device was validated against user needs.
• Validating on prototypes, not production-equivalent units.
• No HF validation, or HF "validation" run with engineers as the users.
• Acceptance criteria written after results are in.
• Traceability matrix maintained offline in a spreadsheet that no longer matches the latest spec versions.
• Design changes implemented without re-running the affected V&V protocols.
• Test failures "resolved" by rewriting the acceptance criterion rather than by changing the design.