91³Ô¹Ï

If you work inÌýmedical device development, you haveÌýprobably heardÌýthese two terms in the same sentence more than once: verification and validation. And ifÌýyou’reÌýhonest, you might admit thatÌýthe lineÌýbetween themÌýstillÌýfeels a little blurry.ÌýÌý

You’reÌýnot alone. Even highly experienced engineers use themÌýinterchangeably orÌýtreat them as the same regulatory checkbox. They are not. The FDA andÌýISO 13485Ìýtreat them as distinct activities, and mixing them up can lead toÌýcompliance gaps, failed audits, or worse, a product thatÌýdoesn’tÌýperform the way patients need it to.ÌýÌý

This article breaks down the difference in plain language, explains when each activity takes place in yourÌýdevelopment process, and shows you what a solid verification and validation strategy looks like in practice.Ìý

Key Takeaways

• Verification asks: Did we build the product according to design inputs?
• Validation asks: Does the product meet user needs and intended use?
• Both are required under and — they are not interchangeable.Ìý

What Is Design Verification for Medical Devices?

Design verification is the process of confirming that your product meets its design inputs — the specific, measurable requirements you defined at the start of the project.  

Think of it this way: verification is checking your work against the plan. If your design input says the device must withstand 50 Newtons of compressive force, verification is the test that proves it does.  

Under 21 CFR 820.30(f), the FDA requires that design verification be performed under defined conditions, with results documented in the design history file (DHF). ISO 13485 section 7.3.6 has the same expectation.  

Here are some common verification methods: 

• Testing: Physical, electrical, mechanical, or chemical testing against defined specifications
• Inspection: Visual or dimensional checks to confirm compliance with drawings or standardsÌý
• Analysis: Computational modeling, simulations, or engineeringÌýcalculations
• Demonstration: Showing that a feature or function works as designed under defined conditions

Verification is not a one-time event.ÌýIt happens throughout development at multiple design stages and should be planned early, notÌýbolted onÌýat the end.ÌýÌý

What Is Design Validation for Medical Devices?

Design validation is where you step back from your specifications and ask a bigger question: Does this device really do what patients and users need it to do? 

While verification checks compliance with your own design requirements, validation checks alignment with user needs and intended use. These are not the same things! A device can pass every verification test and still fail in the hands of a real user.  

Under 21 CFR 820.30(g), the FDA requires validation to be performed under actual or simulated use conditions using initial production units or equivalents. ISO 13485 section 7.3.7 adds the requirement to document the rationale for the use conditions selected.  

Here are some common validation methods:  

• Usability testing with representative end-users (including formative and summative studies)Ìý
• Clinical evaluation or clinical investigation, depending onÌýdevice classÌý
• Simulated use testing in environments that replicate real-world conditionsÌý
• Software validation, including validation of any automated processes or algorithmsÌý
• Sterilization validation, biocompatibility testing, and shelf-life testing as applicableÌý

Important note: Validation must be completed on devices that are representative of the final design. Testing early prototypes does not count.ÌýÌý

What’s the Difference Between Design Verification and Validation?

The simplest way to frame it comes directly from FDA guidance: verification confirms you built the product right, and validation confirms you built the right product.  

Here’s a side-by-side comparison:

Question	Design Verification	Design Validation
What does it check?	Did we build the product right?	Did we build the right product?
Reference point	Design specifications/inputs	User needs/intended use
When does it happen?	Throughout development	Near the end of development
Who is involved?	Engineering team	Engineers and representative end-users or patients
Methods used	Testing, analysis, inspection, demonstration,	Simulated or actual use testing, usability studies, clinical evaluation
Regulatory basis	21 CFR 820.30(f) & ISO 13485 7.3.6	21 CFR 820.30(f) & ISO 13485 7.3.7
Key output	Test reports, traceability matrix	Validation protocol and report

The distinction matters because regulatory reviewers, notified bodies, and FDA auditors look at these separately. Submitting validation data where verification data is expected, or vice versa, is a common 483 observation.ÌýÌý

When Should Verification and Validation Happen in the Design Process?

This is where a lot of teams get into trouble. They treat verification and validation as an end-of-project activity instead of building it into their development plan from the start.  

Verification should be happening throughout your development cycle, at each design review gate, and whenever a major design change occurs. If you wait until you have a finished product to start verifying, you’re setting yourself up for expensive rework.  

Validation, on the other hand, is a later-stage activity by nature. You cannot validate against user needs until you have a device that reflects your final design intent. But the planning for validation, including writing protocols and identifying representative users, should start well before that.  

A word of caution: Changing your design after validation has started is painful. It typically means you need to update your traceability matrix, re-run affected tests, and justify the change in your design history file. The more rigorous your verification activities are early on, the less likely you are to discover fundamental design flaws during validation.  

What Does the FDA Require for Design Verification and Validation?

The FDA’s Quality System Regulation under 21 CFR Part 820 (now being harmonized with ISO 13485 through the Quality Management System Regulation, or QMSR) lays out specific requirements for both activities.ÌýÌý

For verification (820.30(f)), you need to:  

• Define the methods you will use and under what conditions
• Accept the testing results against predetermined criteria, not after the fact
• Document everything in the design history file
• Ensure that software used in verification is validated for its intended use

For validation (820.30(g)), you need to:Ìý

• Validate the design using initial production units or equivalents
• Define acceptance criteria before you run the tests
• Conduct testing under actual or simulated use conditions
• Include software validation where applicable
• Validate any production processes that cannot be fully verified

Both activities need to be traceable back to your design inputs and use needs through a design traceability matrix. This document is the first thing an auditor or reviewer will ask to see.  

Regulatory tip:ÌýThe FDA’s 2023ÌýÌýaligns 21 CFR Part 820 more closely with ISO 13485:2016. If your team has only followed one standard, now isÌýa good timeÌýto close the gaps before your next inspection.ÌýÌý

What Are the Most Common Verification and Validation Mistakes in Medical Device Development?

We see a handful of the same issues across medical device programs, and most of them are preventable with better planning upfront.ÌýÌý

1. Starting Without Clear Design Inputs

If your requirements are vague or incomplete, you cannot verify against them.ÌýVerification is only as strong as the design inputs it references.Ìý

2. Skipping Traceability

If you cannot show a clear link fromÌýuser needÌýto designÌýinput toÌýverification test to validationÌýresult, your regulatory submission is going to have gaps. Build the traceability matrix as you go, not at the end.Ìý

3. Treating Software as an Afterthought

Software used in testing, manufacturing, or as part of the device itself needs to beÌývalidated. This is its own workstream and should be planned for early.Ìý

4. Running Validation on the Wrong Units

FDA requires validation on devices thatÌýrepresentÌýyour final design. Using pre-production prototypes or modified units can invalidate your results.Ìý

5. Underdocumenting the Rationale

It’sÌýnot enough to show that a testÌýhas passed. You need to explain why the method wasÌýappropriate, who performed the test, what equipment was used, and how results were interpreted. Auditors look for substance, not just signatures.ÌýÌý

Need Help with Medical Device Verification or Validation?

At 91³Ô¹Ï Engineering, we have supported medical device development across a wide range of product categories, from Class I to Class III devices, combination products, and software as a medical device (SaMD). We understand what regulators expect, and we know what it takes to build a defensible record.  

Whether you need support building your design controls framework, writing verification and validation protocols, or preparing for FDA inspection or notified body audit, our team can step in wherever you need us.  

Contact us hereÌýtoÌýget started.ÌýÌý