Design Validation

The blog is about design validation to ensure the medical device satisfies defined user needs and intended use or uses. Design validation should be performed on initial production units and under simulated or actual conditions in which the medical device will be used.

Design Project Plan should include planning and scheduling of design validation activities. All planned validation activities must be completed with satisfactory result prior to any device can be delivered to the customers.

Designs are validated according to approved and documented protocols. Project manager should be responsible to establish detail of validation protocols. Validation protocols should specify:

·       Acceptance criteria;

·       Clinical Evaluation;

·       Evaluation of Performance of Medical Device;

·       Operating environment and/or conditions;

·       Modes of use;

·       Testing methods, setup and procedure.

                 

Examples of Design Validation activities for medical devices may include the following:

·       Animal testing.

·       Bench testing.

·       Clinical method evaluations in clinical and nonclinical settings.

·       Clinical studies for product to be marketed in the US that approved by IRB and IDE, or by IRB’s only for non-significant risk devices.

·       Clinical studies for product to be marketed in the EU that approved by Ethics Committees and submitted to Competent Authorities.

·       Literature searches on related medical device.

·       Software Validation to include software validation protocol.

·       User acceptance testing.

·       Review of labels and labeling, packaging, and other historical product information.

·       510(k) or PMA historical database searches.

All design validation activities are always documented in design validation reports. For example, forms, report etc for recording data and reporting results are included in design validation protocols. All design validation records include the date when the validation was carried out and the name of the individual(s) or the third party organization like Contract Research Organization (CRO) performing the validation.

During design validation, when the device does not meet requirements and the design must be modified or corrected, the necessary actions required to correct the problem are documented and their implementation is recorded. This may be in minutes of design reviews, memo, in validation reports and studies, or as notes or mark-ups made directly on design output documents.

Sample of design validation records are:

·       Validation methods and protocols with validation results,

·       Actions necessary to address problems, and their associated reports,

·       Identification of individual(s) or CRO and dates performing validation,

·       Software validation method, protocols and results like reports with a lot of screen shots.

·       All protocols and reports must have their respective unique identities to avoid confusing later.

Irrespective of their nature and format, all design validation records include the date, name of the individual(s) performing the validation, records identity number, actual validation report, memo etc are maintained in the Design History File (DHF).

Reference	Criteria
21 CFR 820.30(g)	Does the company establish and maintain procedures for validating the device design?
21 CFR 820.30(g)	Is design validation performed under defined operating conditions on initial production units, lots, or batches, or their equivalents?
21 CFR 820.30(g)	Does design validation ensure that devices conform to defined user needs and intended uses and include testing of production units under actual or simulated use condition?
21 CFR 820.30(g)	Does design validation include software validation and risk analysis, where appropriate?
21 CFR 820.30(g)	Are results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, documented in the DHF?

Disclaimer: Although the author had exhaustively researched all sources to ensure the accuracy and completeness of the information contained in this blog, but no warranty and fitness is implied. I assumed no responsibility and implied warranty of any kind for errors, inaccuracies, omission, or any inconsistency herein. No liability is assumed for incidental or consequential damages in connection with the use of the information contained herein. Readers should always use their own judgment and review all related regulatory guidelines. Guidelines can change over time.