Design Validation is the process of confirming, through objective evidence, that a finished medical device meets defined user needs and intended uses under actual or simulated use conditions. It answers a single question: did we build the right device? It uses production-equivalent units and typically involves representative users in the environment where the device will be used.
What is Design Validation?
Design Validation sits near the end of the design controls process, after design verification has confirmed that design outputs meet design inputs. Verification checks that the device was built correctly against its specifications, while validation checks that those specifications were the right ones for the people who will actually use the device.
The distinction matters in practice. A device can pass every verification test and still fail validation if the original requirements miss how a clinician holds it, how an alarm is perceived in a noisy ICU, or how a patient reads a display at home. Validation is performed on initial production units, lots, or their equivalents, under defined operating conditions, and the results feed the Design History File (DHF).
Why Design Validation matters in medical device development
The stakes are direct. A validation gap can put a device on the market that works as specified but fails the user, and that is a patient safety issue, not a paperwork issue.
Regulators treat it as a gate. Under FDA 21 CFR Part 820.30(g), design validation is a required element of design controls, and ISO 13485:2016 clause 7.3.7 requires it before release for use. Auditors routinely sample validation records, and weak ones are a common Form 483 and nonconformity finding. Under EU MDR 2017/745, clinical evaluation links to validation evidence in the technical documentation.
Timing drives cost. Problems caught during validation are expensive; problems caught after launch trigger field corrections, complaints, and possible recalls. Late-stage failures also delay 510(k) clearance or CE marking, which pushes back revenue. Strong validation early is one of the cheaper insurance policies in the whole program.
How the Design Validation process works
Validation follows planning, execution, and documentation, all traceable back to the original user needs. The typical sequence:
- Define user needs and intended use. These come from user research, the intended-use statement, and the use environment. They are the benchmark validation measures against which they must be specific and measurable.
- Write the validation plan. Identify what will be tested, acceptance criteria, the production-equivalent units to be used, sample sizes with statistical rationale, and the methods.
- Run validation activities. This often combines simulated-use testing, clinical evaluation, and human factors or usability studies. Usability validation follows IEC 62366-1 and addresses use-related risks identified in the risk file.
- Confirm risk controls. Validation links to ISO 14971 risk management; it confirms that risk control measures perform as intended in real use and have not introduced new hazards.
- Document and review. Record results, deviations, and conclusions, then close the loop in the DHF. Any failure routes through change control and may trigger re-validation.
Software devices add IEC 62304 lifecycle considerations, and electrical devices bring in IEC 60601-1 for basic safety and essential performance. Validation pulls evidence from across these activities rather than replacing them.
Common challenges and best practices
The most frequent mistake is treating validation as a repeat of verification. Teams re-run bench tests on the final build, call it validation, and skip the user. That does not satisfy 820.30(g) and rarely survives an audit.
Vague user needs are the second trap. If a need reads “the device shall be easy to use,” there is nothing to validate against. Good teams write needs that name the user, the task, the environment, and a measurable outcome.
A few habits separate clean validation from painful validation:
- Build a traceability matrix early, linking user needs to validation activities, so gaps surface before the units are built, not after.
- Use genuinely representative users and a realistic environment; engineers standing in for nurses will mask real use errors.
- Lock the design before validating. Validating a moving target guarantees rework.
- Plan sample sizes with a statistical basis you can defend to an auditor.
How SJML helps with Design Validation
Syrma Johari MedTech (SJML) is an end-to-end medical device CDMO that carries programs from concept and feasibility through architecture, design, verification, and design transfer. Validation activities draw on in-house labs for electrical safety and IEC 60601 testing, EMC, reliability, and environmental and endurance testing, with risk management to ISO 14971 and usability engineering to IEC 62366 built into the workflow. Phase-gate program management and change control keep validation evidence traceable in the Design History File across Class I, II, and III devices. SJML’s QARA team supports the regulatory side, from design controls documentation to FDA and EU MDR submissions.
Talk to SJML’s engineering team →
Frequently asked questions
Verification confirms the device meets its design specifications: did we build it correctly? Validation confirms the device meets user needs and intended use: did we build the right device? Verification uses bench tests against design outputs. Validation uses production-equivalent units, representative users, and real or simulated use conditions. Both are required under FDA 21 CFR Part 820.30 and ISO 13485.
Design validation happens late in design controls, after design verification and before design transfer to production. It must use initial production units, lots, or their equivalents, because validating an engineering prototype does not represent what the user will actually receive. Validation results are reviewed at a design review and recorded in the Design History File.
Yes. Usability or human factors validation is a core part of design validation for most devices, following IEC 62366-1. It confirms that representative users can complete tasks safely and that use-related risks identified in the ISO 14971 risk file are controlled. FDA expects human factors validation for devices with use-related risk.
The main ones are FDA 21 CFR Part 820.30(g) and ISO 13485:2016 clause 7.3.7 for the requirement itself, ISO 14971 for risk linkage, IEC 62366-1 for usability, and EU MDR 2017/745 for the European technical documentation. Software adds IEC 62304, and electromedical devices add IEC 60601-1.
Related terms
- Design Verification
- Design Controls
- Design History File (DHF)
- Usability Engineering (IEC 62366)
- Risk Management (ISO 14971)
