Design Verification is the documented process of confirming, through objective evidence, that a medical device’s design outputs meet its specified design inputs. It answers a single question: did we build the device right? Methods include testing, inspection, analysis, and comparison, and the activity is required by FDA 21 CFR 820.30 and ISO 13485.
What is Design Verification?
Design Verification sits inside the design controls phase, after design inputs are defined and design outputs are produced. Design inputs are the requirements a device must meet. Design outputs are the drawings, specifications, code, and other deliverables that describe the finished device. Verification checks that each output satisfies its matching input.
Teams pair it with design validation, but the two answer different questions. Verification asks whether the device meets its specifications. Validation asks whether the device meets user needs and intended use. You verify against requirements; you validate against reality.
Why Design Verification matters in medical device development
For a regulated device, unverified design outputs are a direct path to a nonconforming product reaching patients. A blood pressure monitor that reads outside its stated accuracy, or an infusion pump whose alarm fails below a set threshold, can cause harm that traces straight back to a missing verification test.
Regulators treat verification as a check on the design history. FDA investigators review verification records during inspections, and gaps are a common source of Form 483 observations. Under EU MDR 2017/745, verification evidence feeds the technical documentation that a notified body assesses before CE marking. Weak records delay submissions and push back launch dates.
Cost matters too. Catching a requirement failure during verification is far cheaper than finding it after design transfer, tooling, or market release, where the fix can mean recall and rework.
How Design Verification works
Verification follows a structured loop tied to the design controls in FDA 21 CFR 820.30 and clause 7.3 of ISO 13485. A typical flow:
- Trace each design input to a verification method. Every requirement needs a defined way to confirm it: test, inspection, analysis, or comparison to a proven design.
- Write a verification protocol. Document the method, acceptance criteria, sample size, and equipment before running anything.
- Execute and record. Run the protocol on production-equivalent units, capturing raw data and calibrated equipment IDs.
- Analyze against acceptance criteria. Compare measured results to the input requirement and document any deviations.
- Maintain the trace matrix. A requirements traceability matrix links each input to its output, verification activity, and result, so nothing slips through.
Specific standards shape the methods. IEC 60601-1 governs electrical safety and essential performance for electromechanical devices, and IEC 60601-1-2 covers electromagnetic compatibility. Software devices follow IEC 62304, where verification spans unit, integration, and system testing tied to software requirements. Risk controls identified under ISO 14971 must themselves be verified, closing the loop between the risk file and the test record.
Verification output becomes part of the Design History File (DHF), the record proving the design was developed under control.
Common challenges and best practices
The most frequent failure is poor traceability. When inputs are vague (“the device shall be reliable”), no test can verify them. Good inputs are specific, measurable, and testable from the start.
A second trap is verifying the wrong units. Testing engineering prototypes that differ from production builds can pass a protocol that the real device would fail. Use production-equivalent units and document their configuration.
Teams also skip verifying risk controls. If ISO 14971 analysis calls for a mitigation, that mitigation needs its own verification evidence. Build the traceability matrix early and keep it live. Define acceptance criteria before testing, not after seeing results, and size samples with a documented statistical rationale.
How SJML helps with Design Verification
SJML supports Design Verification as part of end-to-end medical device engineering. Its teams trace design inputs to outputs across mechanical, electronics, embedded, and software disciplines, and run verification under ISO 13485 design controls with risk management to ISO 14971 built in. In-house labs handle electrical safety and IEC 60601 testing, EMC, reliability, and environmental and endurance testing, so verification activities stay close to the design work rather than scattered across vendors. Phase-gate program management and change control keep the traceability and Design History File audit-ready through development and design transfer.
Talk to SJML’s engineering team →
Frequently asked questions
Verification confirms that design outputs meet design inputs: did we build the device right? Validation confirms the finished device meets user needs and intended use: did we build the right device? Verification uses testing, inspection, and analysis against specifications. Validation involves the device in actual or simulated use. Both are required under FDA 21 CFR 820.30.
Yes. FDA 21 CFR Part 820.30(f) requires design verification for Class II and most Class III devices, and many Class I devices subject to design controls. Verification must confirm design outputs meet design inputs, with results, methods, the date, and the individuals performing it recorded in the Design History File.
Core documents include the verification plan, test protocols with predefined acceptance criteria, executed protocols with raw data, a verification report summarizing results, and a requirements traceability matrix linking each design input to its verification activity. These records live in the Design History File and support both FDA inspections and EU MDR technical documentation.
Design verification occurs after design outputs are produced and before design validation and design transfer. It runs during the design and development phase, once design inputs are locked and the design is mature enough to test against them. Verification of any later design changes continues through the product’s life under change control.
Related terms
- Design Validation
- Design Controls
- Design History File (DHF)
- Risk Management (ISO 14971)
- Design Transfer
