Design verification and design validation (subsections f and g) activities should be considered as mission critical in the pursuit of an effective design and development process. The proverbial rubber meets the road when the actual execution of test protocols commences. The salient concept to remember when working through verification and validation activities is that the test results support the confirmation of the product specification and the adequacy of the requirements delineated within the product specification.

That said, in this edition of Devine Guidance, Dr. D will continue with his dissection of 21 CFR, Part 820; Section 820.30, subsection f (design verification) and subsection g (design validation). In keeping with previous editions of DG, my intent is to educate and share opinions and insight for compliance to the QSR. Dr. D does not believe in presentiment in regards to bad things happening when organizations fail to comply with the regulations. If an organization’s goal is compliance with regulations, then only good can come from practicing what Dr. D preaches.

Warning letter violation
Finding warning letters for violations of 21 CFR, Part 820, section 820.3 is child’s play, due the bountiful amount of warning-letter observations. FDA’s warning-letter database is loaded with violators of the design and development requirement. In this week’s warning letter extraction, the offending medical device manufacturer has attempted to meet some of the design and development requirements; however, there are disconnects between the requirements and the supporting data. Additionally, verification of the requirements is missing. Sometime in the future, Dr. D. will present the ins and outs of responding to Form 483s and warning letters. One very basic key is the providing of objective evidence. In God we trust, all others bring data; the FDA’s policy is quite similar.

Warning letter (February 2010): 1. Failure to establish and maintain adequate procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, and include a mechanism for addressing incomplete, ambiguous, or conflicting requirements, as required by 21 CFR 820.30(c). For example:

a. Section 16.3.2 of the document 102-0083 Rev A, Product Requirements Document PH AED 2 (G3), states that the battery shall be designed to have adequate capacity for a guaranteed three year operating life under normal use conditions. However, the document does not define what constitutes the “operating life under normal conditions.”

We have reviewed your response and have concluded that the adequacy of your response cannot be determined at this time. You indicated that by November 13, 2009, you would update the design input requirements to eliminate conflicting and/or ambiguous language and the battery will be reverified against the revised input documents. You have not, however, provided any evidence of implementation of this corrective action.

b. Section 5.3 of the document DHF-00048-01, G3 AED (b)(4) Battery Product Design Inputs, lists the physical specifications of the battery. According to the specification, operating ambient temperature is specified as 0°C to 50°C. However, the electrical specifications listed in section 5.4 of the document lists the operating temperature as 25°C.

We have reviewed your response and have concluded that the adequacy of your response cannot be determined at this time. You indicated that by November 13, 2009, you would update the design input requirements to eliminate conflicting and/or ambiguous language and the battery will be reverified against the revised input documents. You have not, however, provided any evidence of implementation of this corrective action.

2. Failure to establish and maintain adequate procedures to confirm that design output meets the design input requirements, as required by 21 CFR 820.30(f). For example, section 16.3.1 of the document 102-0083 Rev A, Product Requirements Document PH AED 2 (G3), states that the battery shall be designed to have adequate capacity for 300 shocks (typical). However, no documented verification was performed to ensure such capacity.

We have reviewed your response and have concluded that the adequacy of your response cannot be determined at this time. You indicated that by November 13, 2009, you would update the design input requirements to eliminate conflicting and/or ambiguous language and that as a result you will also reverify the battery against the revised input documents. You have not, however, provided any evidence of implementation of this corrective action.

Quality system regulation – 21 CFR, Part 820

1. QSR – Subpart C Sec. 820.30 Design controls

(a) General.

(1) Each manufacturer of any class III or class II device, and the class I devices listed in paragraph (a)(2) of this section, shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met.
(2) The following class I devices are subject to design controls:
(i) Devices automated with computer software; and
(ii) The devices listed in the chart.

(b) Design and development planning. Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall identify and describe the interfaces with different groups or activities that provide, or result in, input to the design and development process. The plans shall be reviewed, updated, and approved as design and development evolves.

(c) Design input. Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.

(d) Design output. Each manufacturer shall establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements. Design output procedures shall contain or make reference to acceptance criteria and shall ensure that those design outputs that are essential for the proper functioning of the device are identified. Design output shall be documented, reviewed, and approved before release. The approval, including the date and signature of the individual(s) approving the output, shall be documented.

(e) Design review. Each manufacturer shall establish and maintain procedures to ensure that formal documented reviews of the design results are planned and conducted at appropriate stages of the device’s design development. The procedures shall ensure that participants at each design review include representatives of all functions concerned with the design stage being reviewed and an individual(s) who does not have direct responsibility for the design stage being reviewed, as well as any specialists needed. The results of a design review, including identification of the design, the date, and the individual(s) performing the review, shall be documented in the design history file (DHF).

(f) Design verification. Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the DHF.

(g) Design validation. 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 DHF.

(h) Design transfer. Each manufacturer shall establish and maintain procedures to ensure that the device design is correctly translated into production specifications.

(i) Design changes. Each manufacturer shall establish and maintain procedures for the identification, documentation, validation or where appropriate verification, review, and approval of design changes before their implementation.

(j) Design history file. Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part.

Design verification (subsection f)
Design verification activities measure and confirm that design-output requirements meet the design-input requirements that are depicted within the product specification. Test protocols, test reports, procedures, test methods, and all documentation associated with ensuring that design inputs and outputs that support the validity of the product specification are executed and collected as part of design validation. Similar to all of the deliverables delineated within the design and development requirements of the regulation, the DHF becomes the appropriate receptacle for storage. Additionally, all of the documentation, evidence, reports, etc. must be reviewed and approved by the appropriate level of authority, while making sure signatures and dates are included.

Design validation (subsection g)
Design validation, like all of the requirements within the regulation, requires procedures for validating all of the features of the device design. One additional and extremely important requirement is the conditions under which design validations should be executed. For starters, design validation testing needs to occur on units manufactured under normal manufacturing conditions, preferably, (as FDA words it) on the initial production units, lots, or batches. The salient objective of the entire design validation process is to ensure medical devices conform to their intended use. This includes all user needs and intended uses, as defined in the approved market specification.

Once all design validation activities have been completed, can you guess where all of the approved, signed, and dated documentation is stored? Yes, the DHF is the million-dollar response. Just like all of the deliverables required under design and development, granularity in the protocols and accurate reports are important pieces of evidence. Dr. D strongly recommends creating and employing test data sheets to collect test results obtained while executing protocols. Some important elements recommended for inclusion into the data sheets and needed for the reports are:

1. Protocol number;
2. List of test equipment employed, including calibration status;
3. Sample sizes and sample-size rationale;
4. Name of technician or engineer executing a specific test;
5. Signature and date of technician or engineer;
6. Date the test was executed;
7. Noted test anomalies;
8. Clearly defined pass or fail statements;
9. Limits;
10. Part number being tested, including batch; and
11. Other test information deemed relevant by the protocol.

Conclusion 
The primary deliverable and output for design verification and design validation activities is the verification that design output requirements meet design input requirements. A key takeaway from this week’s edition of DG is the overall verification and validation of the information depicted within the product specification and market specification.

At this point of the design and development process, an organization needs to ensure the newly designed medical device meets all of their predetermined requirements, including user and intended use needs. As with all of the requirements, documentation and retention are important actions that are needed to support proof of compliance, aka evidence. The DHF, when employed properly, will become an invaluable tool in supporting claims of compliance.

In closing, thank you again for joining Dr. D and I hope you find value in the guidance provided. Until the next installment, when I continue discussing Section 820.30 Design Controls, subsection (h) design transfer, (i) design history, and (j) the DHF, – cheers from Dr. D. and best wishes for continued professional success.

References:

1. Code of Federal Regulation. (2009, April). Title 21 Part 820: Quality system regulation. Washington, D.C.: U. S. Government Printing Office.
2. Devine. C. (2009, July). Exploring the effectiveness of defensive-receiving inspection for medical device manufacturers: a mixed method study. Published doctoral dissertation. Northcentral University. Prescott Valley, AZ. 
3. FDA – U.S. Food and Drug Administration Website. (2010). Warning letters. Retrieved May 3, 2010, from http://www.fda.gov/ICECI/EnforcementActions/WarningLetters/