Did we build the device according to its own specification, and separately: did we build the device users actually need?
These sound close enough to be interchangeable, and the words get used loosely outside regulated engineering — but under design controls, they're two structurally different questions with two structurally different answers. Design verification asks whether the device, as built, conforms to its own design inputs — the specifications the design team wrote down. It's an objective, testable, internally-referenced question: does output X meet spec X. Design validation asks a different, externally-referenced question: does the device, under actual or simulated use conditions, meet the user needs and intended use it was meant to serve — confirmed through methods like simulated-use and human factors testing, not just spec comparison.
Verification's reference point is entirely internal to the design record: a design input says the device shall deliver infusion accuracy within ±5%, and verification testing measures whether the built device actually does — a pass/fail comparison against a number the design team itself wrote. Validation's reference point sits outside the design record entirely, anchored in the actual clinical or user context: does a nurse under realistic time pressure, using the actual device and its actual labeling, correctly and safely operate it to deliver the intended therapy — a question no amount of comparing the device to its own spec sheet can answer, because it's possible to write a spec that's internally self-consistent and still misses what users actually need or how they actually behave in practice.
The reason regulators require both, as independent activities under ISO 13485 and 21 CFR 820.30, is that a design flaw in the original user-needs translation is completely invisible to verification testing. If a design input was written incorrectly — say, an alarm threshold spec that technically matches what engineers agreed on but doesn't actually reflect the clinical urgency a nurse needs to safely respond — a device can pass 100% of its verification tests (it does exactly what its own spec says) while still being clinically unsafe or unusable, because the spec itself was disconnected from the real user need. This is precisely the failure mode design validation exists to catch: it goes back to real or simulated use conditions and the original user needs, independent of what the design inputs happened to say, and checks whether the actual outcome for actual users is correct.
Verification is a closed-loop, internally consistent check: it confirms the device matches a specification, but has no mechanism to notice if that specification was wrong in the first place. That's not a weakness in verification's methodology — it's simply outside the question verification is designed to answer. Validation is the only activity in design controls that steps outside the design record entirely and re-anchors on the original, independently-defined user needs and intended use, which is exactly why it has to involve real or realistic use conditions (simulated-use testing, human factors studies) rather than more comparisons against internal documents.
A test protocol's rigor doesn't determine whether it counts as verification, validation, or both — what determines that is what it's being compared against. A bench test confirming the device meets its dimensional or performance spec is verification, no matter how thorough. Only testing that specifically re-confirms the device against user needs and intended use — typically involving representative users under realistic or simulated conditions, not just engineers running a spec-comparison protocol — counts as validation. Running one type of test more times doesn't substitute for running the other type at all; design controls require documented evidence of both, addressing two different questions.
Explains why design verification — confirming a device conforms to its own written design inputs — and design validation — confirming the finished device actually meets user needs and intended use under real or simulated use conditions — are two distinct, independently required activities under ISO 13485 and 21 CFR 820.30, and why passing one provides no evidence about the other.
The two terms are close enough in everyday English that they get used interchangeably outside regulated contexts, and even experienced engineers sometimes describe a single thorough test campaign as covering 'verification and validation' without distinguishing what each specific test was actually being compared against. The distinction that matters isn't test rigor — it's reference point. A test comparing the device to its own design inputs is verification, however sophisticated. A test comparing the device to user needs and intended use, via real or realistic use conditions, is validation. Conflating them risks skipping the one check (validation) that catches errors baked into the design inputs themselves.
Under 21 CFR 820.30(f), design verification confirms that design output meets design input requirements, using objective evidence. Under 21 CFR 820.30(g), design validation ensures devices conform to defined user needs and intended uses, and requires testing on production units or their equivalents under actual or simulated use conditions, with a specific expectation that validation include or reference risk analysis and, where relevant, human factors/usability testing. ISO 13485:2016 clause 7.3 imposes closely analogous requirements. Both standards require these as separate, documented activities within design controls — neither permits treating one as automatically satisfying the other.
Design teams should write design inputs deliberately traceable back to user needs, so that verification (checking output against input) and validation (checking the finished device against the original user need) form a coherent, closed chain rather than two disconnected checklists. When validation testing surfaces a problem — a usability issue, a mismatch between the device's actual behavior and what clinicians expected — the root cause is very often traced back to a design input that didn't correctly capture the underlying user need in the first place, which is exactly the class of error verification testing structurally cannot detect no matter how rigorously it's executed.
Verification typically happens earlier and more incrementally — individual design outputs are verified against their corresponding inputs as they're developed, often at the subsystem level. Validation typically happens later, on production-equivalent units, because it needs a sufficiently complete, representative device to test under real or simulated use conditions. In practice, some validation activities (like early formative human factors studies) can and should happen earlier in development specifically to catch user-needs mismatches before they're expensive to fix, even though the formal summative validation used for regulatory submission happens later.
The verification/validation distinction applies to software too, but IEC 62304 (medical device software lifecycle) adds software-specific rigor: software verification includes code review, unit testing, and integration testing against software requirements, while software validation confirms the software, integrated into the finished device, meets user needs. Software's unique risk (the same code path can be retested unlimited times without physical wear, but also can harbor design flaws invisible until a specific, rare input combination triggers them) is why software V&V typically demands more structured, traceable requirements coverage than hardware V&V.
It depends on the root cause. If validation reveals the design inputs themselves were wrong or incomplete (the common failure mode design validation exists to catch), the design inputs typically need to be revised, which cascades into re-verifying whatever design outputs were built against the corrected inputs — a real rework cost. If validation instead reveals a usability or labeling issue unrelated to whether the device met its technical specs, the fix may not require re-verification at all, just a design or labeling change followed by re-validation of that specific use scenario.
Try our Biomedical Engineering
More calculators, simulators, and guides for this discipline.