Verification & Validation
Confirming design outputs meet inputs (V) and that devices meet user needs (V).
Definition
Verification confirms by examination that specified requirements have been fulfilled (did we build the device right?). Validation confirms that requirements for a specific intended use can be consistently fulfilled (did we build the right device?). Verification is usually done through testing, inspection and analysis against design inputs, such as bench tests, software unit and integration tests, and electrical safety testing. Validation checks the finished device, or an equivalent, under actual or simulated use conditions with intended users, and includes software validation, human factors validation and, where needed, clinical evaluation. Both must be planned, use predefined acceptance criteria and be documented.What this means in practice
V&V plans, protocols, and reports are central artifacts in design controls and submissions. Software V&V follows IEC 62304.Examples
- A design team verifies that the output voltage of a power supply in a medical device is within specifications, as defined in the design input requirements.
- A clinical study validates that a new diagnostic device accurately identifies a specific disease in a patient population, fulfilling its intended use.
- Software verification involves unit testing individual modules to ensure they function according to their software requirements specifications.
- •A common pitfall is conflating verification and validation activities, leading to incomplete testing or a failure to address user needs effectively.
- •Another mistake is performing V&V too late in the design process, making it costly and difficult to implement necessary changes.
- •Failure to adequately document V&V activities can result in regulatory non-compliance during audits or submissions.
- •Not considering cybersecurity V&V throughout the product lifecycle can lead to vulnerabilities in connected MedTech devices.
- •Over-reliance on software simulations without sufficient hardware testing for embedded systems is a frequent pitfall in software V&V.
Frequently asked questions
Cross-references
Part of
Related terms
Grouped by themeEditor's picks
· Hand-selected related conceptsQMS Foundations
· From this learning pathCompilation of records describing the design history of a finished device.
Process for receiving, evaluating, and responding to device complaints.
Systematic process to investigate and resolve quality issues and prevent recurrence.
Notice of inspectional observations issued at the conclusion of an FDA inspection.
Software Team Onboarding
· From this learning pathSoftware providing healthcare professionals with knowledge and patient-specific information.
Software not developed for medical device use, or lacking adequate development records, incorporated into a device.
FDA mechanism to pre-authorize specific modifications to AI/ML-enabled devices.
The federal statute that gives FDA explicit premarket authority over cybersecurity for cyber devices.
Where this term appears across MedTech Terms.
- QMS FoundationsLesson 5 of 10
- Software Team OnboardingLesson 6 of 12
Latest in MedTech
Sources
3 sourcesEvery citation below opens the original document. Each is graded against our source-tier hierarchy so you can see what rests on binding law versus commentary.
- 1MDIC Case for QualityTier 4 VerifiedMDICmdic.org
- 2FDA - Quality SystemsTier 2 VerifiedFDAfda.gov
- 3ISO 13485 Standard PageTier 1 VerifiedISOiso.org
Inline markers like [1] jump to the matching reference above.