Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate. The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the [[Design History File]] (DHF).
!Attention points
The intent of design validation is to make sure that the [[Design Output]] or specificaton complies with the user needs and intended use
Design teams should ensure that design validation includes the following:
* Validation Training
* Validation activities
** Under defined operating conditions
** On initial production units, lots, batches or their equivalents
** Under actial or simulated conditions
** With any software
** With a review of all risk analysis
* Master validation plan which will:
** Establish validation criteria
** Establish validation assumptions and expectations
** Identify validation personnel, their qualifications and responsibilities
** Identify design personnel, their qualifications and responsibilities
* Testing, which requires appropriate testing of
** The finished device
** All user inputs under normal, abnormal and absurd conditions
** Device outputs against expected outputs
** Equipment
** Beta testing or clinical evaluation when appropriate
** Explanations, Corrections and retesting of all unexpected results
* Master validation and test plans should
** Consider any [[Premarket notification]] documentation requirements
** Be formed according to written and approved test plans or protocols
** Ensure identified risks and hazards are fully tested
* Documentation (considered [[Controlled Document]]ation) which records testing:
** Identification of the device
** Methods used in the validation
** Dates
** Names of persons who performed the validation
* Validation review
** Appropriate individuals will review and approve all validation activities, including master validation plan, test plan, test results, and any retesting after corrective actions or changes.
* Software Validation is crucial part of the 510K.
* Software is not equal to System: distinguish System Requirements from Software Requirements
* Software Validation is not equal to Product Validation. SW Validation is covered by Subsystem and System Verification together.
Tue, 04 Sep 2012 07:44:34 GMT
Tue, 04 Sep 2012 07:44:34 GMT
CFR 21-820.30
Design Controls
Quality System Requirements