Why Does the FDA Require a Design History File?

Background on Design History File (DHF)

The Design History File (DHF) is the terminology used by the FDA under 21 CFR 820.30(j) to describe the compilation of records demonstrating the design history of a finished medical device. In the context of the ISO 13485:2016 international standard, the DHF is equivalent to what is called the “Design and Development File” referenced in Section 7.3 (Design and Development).

However, there are significant misconceptions regarding the DHF. Many manufacturers incorrectly believe that the FDA prescribes specific requirements regarding the location and organizational structure of the DHF. This is not accurate. The FDA specifies what records must be contained or referenced in the DHF, but it does not mandate a specific physical format or internal organization.

Common Misunderstandings About the DHF

Through extensive consulting experience, the author has encountered numerous recurring misunderstandings about the DHF. These include:

• The DHF must be created to show regulators during inspections
• Manufacturers without a DHF will receive inspection findings
• The DHF is designed to manage revision histories of individual design documents
• Only the latest version of each design document should be registered
• Each design document should be registered individually
• Version numbers (revision history) should be tracked for each design document
• Draft versions of design documents should be registered in the DHF
• All documents must be physically bound in binders
• A separate DHF must be created for each product (all of the above are incorrect)

All of these statements represent misinterpretations of the regulatory requirement. The essential point is that the FDA requires evidence of proper design controls throughout the development process, but the specific method of compilation and organization is flexible, provided all necessary records are accessible and traceable.

The Proper Approach: Organizing Design Outputs by Development Stage

The DHF is fundamentally a collection of records that documents the design development history, not the revision history of individual documents. Rather than tracking every version change of each document, the DHF should capture the outputs produced at each design control phase or stage.

The recommended approach is to establish folders organized by design development stage (for example: Design Input Stage, Design Output Stage, Design Review Stage, Design Verification Stage, Design Validation Stage, Design Transfer Stage). Design documents and records corresponding to each stage are then collected within the appropriate folder. This organizational method provides clear traceability of the design process flow and demonstrates how design requirements evolved through each phase.

A comprehensive DHF should contain or reference records demonstrating that design was developed in accordance with the approved design plan and all applicable regulatory requirements. The DHF is created by collecting outputs as they are produced at each design stage, which effectively creates a snapshot representation of the design at different points in the development timeline. It is important to recognize that the DHF is not organized by tracking individual document versions but rather by capturing the state of the design development at distinct milestones or stage gates.

Why the FDA Requires a Design History File

The FDA mandates the establishment and maintenance of a DHF for each device type for the following critical reasons:

1. To Manage and Preserve Design History

The primary purpose of the DHF is to ensure that manufacturers and regulators can readily access necessary design information whenever required. Without a systematic DHF, design-related documents tend to become scattered across various organizational departments and personal storage locations. For example, the design and development plan might reside with the Chief Engineer, the quality system plan with the Quality Assurance department, and supporting analyses distributed among various personnel. Additionally, design information may be dispersed across individual computers, personal notes, and email systems, making retrieval difficult.

A well-organized DHF centralizes access to all design-related records, enabling efficient retrieval when needed and reducing the risk of critical information being lost, overlooked, or unavailable.

2. To Support Complaint Investigation and Root Cause Analysis

When complaints or adverse events occur—whether involving device failures, repairs, or injuries—manufacturers must be able to rapidly retrieve the appropriate design documentation and manufacturing specifications to conduct an effective investigation. This includes not only the design specifications but also the manufacturing procedures in effect at the time the device was produced.

It is important to recognize that design specifications and manufacturing procedures change over the course of a product’s lifecycle. Devices manufactured five years ago, three years ago, or last month may have been produced under different design and manufacturing specifications. The DHF provides a time-stamped record—essentially a snapshot—of the design and manufacturing specifications in effect for a particular production period, enabling investigators to link a specific device to the correct set of design and manufacturing requirements.

This chronological management of design specifications is essential for proper root cause analysis. Without it, manufacturers cannot determine whether a complaint is related to the original design, to a design modification, or to manufacturing changes.

3. To Demonstrate Compliance with Approved Design Plans

The DHF provides objective evidence that the device design was developed in accordance with the manufacturer’s approved design plan and all applicable regulatory requirements. Design controls are implemented to ensure that devices meet user needs and intended uses with appropriate safety margins and performance characteristics. The DHF serves as the documentary proof that this disciplined design process was followed.

4. To Prevent Loss of Critical Design Records

All design history records are the property of the manufacturing organization. Records should never be considered the personal property of individual engineers or project team members. This principle is foundational to quality management systems. Design records created in laboratory notebooks, during design reviews, or through engineering analysis belong to the company, not to the individual who created them.

When employees transfer between projects, leave the company, or retire, their personal notes and individual files must be transferred to the company’s controlled repository. Design and development managers are responsible for regularly reviewing all design records to ensure they are complete, accurate, and legible. This governance ensures that valuable design knowledge is preserved and remains accessible regardless of personnel changes.

5. To Strengthen Document Control and Organization Practices

Several organizational practices strengthen design controls and help ensure the integrity of the DHF:

• Research laboratory notebooks and design documents are corporate assets, not personal property
• Engineers actively engaged in design projects maintain separate project notebooks, which are periodically submitted to an engineering librarian or equivalent function
• Laboratory notebooks are transferred to the company upon an employee’s departure
• Design and development managers periodically review laboratory notebooks to verify that records are complete, accurate, and legible
• Design record management is integrated into the company’s quality management system

These practices ensure that the DHF remains current, complete, and accessible throughout the product’s lifecycle and beyond.

The DHF as an Index and Reference Tool

An important clarification regarding DHF format: The DHF does not need to be physically bound in binders or stored in a single location. Rather, the DHF functions as an index or reference guide that identifies the location of all design documents and records relevant to the device.

If design documents are maintained in electronic format, the DHF can utilize hyperlinks for direct access to documents. For paper-based records, the DHF can document the physical location—such as the specific storage cabinet, shelf, or archive location—where records can be retrieved. The key objective is enabling rapid and reliable location of necessary design documents when needed, whether for regulatory review, complaint investigation, design transfer, or other purposes.

Modern quality management systems increasingly use electronic document management systems (EDMS) or cloud-based repositories for DHF management. In such systems, the DHF can be structured as a logical organization of references and links within the electronic system, maintaining full traceability while avoiding the need for physical compilation.

Timing of DHF Registration and Design Review Coordination

Design records must be registered into the DHF in an organized and traceable manner. Typically, records are registered following formal approval through design reviews (design review gates) that occur at appropriate stages of device development. The timing and frequency of design reviews should be clearly planned in the design and development plan, aligned with the project’s complexity and risk profile.

Design reviews serve as formal checkpoints where cross-functional teams evaluate whether the design development is proceeding appropriately, whether emerging designs will meet specified requirements, and whether any design deficiencies require correction. The results of these reviews—including identification of design changes, attendees, dates, and decisions—are documented and registered into the DHF.

FDA’s Specific Requirements for DHF Content

According to 21 CFR 820.30, the FDA requires that manufacturers maintain in the DHF—or reference within the DHF—records demonstrating compliance with three fundamental design control elements:

1. Design Review Documentation (21 CFR 820.30(e))

Design review records must document the formal reviews conducted at appropriate stages of device design development. These records must identify the design under review, the date of the review, and the individuals who performed the review. Design reviews must include representatives from all functions concerned with the design stage being reviewed and must include at least one individual who does not have direct responsibility for the design stage being reviewed, ensuring an independent perspective. Specialists with particular expertise may also be included as appropriate.

2. Design Verification Documentation (21 CFR 820.30(f))

Design verification records must demonstrate that design outputs meet design input requirements. Verification activities may include testing (component, integration, and system-level testing), analysis (thermal analysis, worst-case analysis, failure mode analysis), and comparison to previously established designs with successful use histories. The choice of verification methods should be justified based on the design outputs being verified and the technologies employed.

3. Design Validation Documentation (21 CFR 820.30(g))

Design validation records must demonstrate that the finished device, under actual or simulated use conditions, will meet user needs and intended uses. Validation activities may include clinical investigations, clinical trials, clinical evaluations, non-clinical testing in simulated use conditions, review of historical evidence from similar designs, and evaluation of scientific literature. Validation must address the needs of all relevant parties (patients, healthcare providers, other stakeholders) and must be performed for each intended use of the device.

Typical Documents Included in a Complete DHF

While the specific contents of each DHF will vary based on device type, complexity, and risk profile, the following documents are typically included:

Design Planning and Governance:

• Detailed Design and Development Plan defining all design phases, activities, responsibilities, interdepartmental interactions, and expected deliverables
• Approved design and development procedures
• Design plan updates as appropriate during development

Design Input:

• Design input procedures
• Approved Design Input Documentation addressing user needs, intended use(s), performance requirements, safety requirements, standards compliance, and regulatory requirements
• Design trace matrix linking design inputs to design outputs and verification/validation activities
• Risk management plan and initial hazard identification

Design Output:

• Design Output procedures
• Approved Design Output Documentation specifying device characteristics, materials, manufacturing processes, software specifications, labeling, packaging
• Risk analysis and risk assessment results
• Design trace matrix or traceability documentation

Design Review:

• Design Review procedures
• Design Review Records documenting formal reviews at appropriate development stages, including attendees, date, design identification, and review results
• Records of design decisions and approved changes

Design Verification:

• Design Verification procedures and plans
• Verification test protocols and test reports
• Analysis documentation (thermal analysis, FMEA/FTA results, worst-case analysis)
• Verification results and conclusions
• Records of verification for design outputs identified as essential for safe device function

Design Validation:

• Design Validation procedures and plans
• Clinical evaluation records (clinical trials, clinical investigations, or other clinical evidence)
• Non-clinical validation data
• Validation results demonstrating that the device meets user needs and intended uses
• Human factors validation records

Design Transfer:

• Design Transfer procedures
• Manufacturing process specifications
• Quality assurance procedures
• Installation and servicing procedures (if applicable)
• Records confirming successful transfer from design to manufacturing specifications

Design Changes:

• Design Change Control procedures
• Design Change Request documentation
• Change impact assessments
• Design review records for approved changes
• Records demonstrating that design changes were evaluated for potential effects on device safety and performance

Key Principles for Effective DHF Management

Several fundamental principles strengthen DHF management and regulatory compliance:

First, the DHF should capture the design development timeline, not individual document revisions. Each design stage produces deliverables and outputs that are collected in the DHF, creating a chronological record of the design evolution.

Second, the DHF should be accessible and organized in a manner that facilitates rapid retrieval. Whether physical or electronic, the organizational structure should enable efficient location of records needed for regulatory review, complaint investigation, or design change assessment.

Third, the DHF must be maintained throughout the product’s lifecycle. Records must be retained for a period equivalent to the design and expected life of the device, but in no case less than 2 years from the date of commercial release (per 21 CFR 820.20(b)).

Fourth, all personnel responsible for design development should be trained on DHF requirements and procedures. Clear responsibility and accountability for DHF accuracy and completeness should be established.

Finally, the DHF should be regularly audited during internal quality audits to verify that all required records are present, properly approved, and accessible. Any gaps should be identified and corrected promptly.

Alignment with ISO 13485:2016 and Upcoming QMSR Changes

It is important to note that while the FDA uses the terminology “Design History File” in 21 CFR 820.30(j), the ISO 13485:2016 international standard refers to equivalent requirements in Section 7.3 (Design and Development) as the “Design and Development File.” The purpose and content requirements are substantially similar, and manufacturers complying with ISO 13485:2016 typically meet FDA DHF requirements.

In February 2026, the FDA will implement the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 by reference. Under the QMSR, the terminology will shift toward “Design and Development File” rather than “DHF,” though the fundamental concepts and requirements will remain consistent. The QMSR emphasizes the integration of risk management throughout design development and maintains the requirement for comprehensive documentation of all design control phases.

Manufacturers are encouraged to review the QMSR final rule and FDA guidance to ensure that their quality management systems and DHF practices align with these evolving regulatory expectations.

Conclusion

The FDA’s requirement for a Design History File is fundamentally about establishing and maintaining a systematic, organized record of how a medical device was designed. The DHF serves multiple critical purposes: enabling rapid access to design information, supporting complaint investigations, demonstrating regulatory compliance, and preserving institutional knowledge. The DHF is not a compliance burden but rather an essential tool for managing design complexity, supporting continuous improvement, and ensuring that devices are safe, effective, and manufactured consistently throughout their lifecycle.

Success in DHF management depends on understanding that the DHF is an organized compilation of design development outputs—not a collection of individual document revision histories. Manufacturers should organize DHF records by design development stage, ensure accessibility and traceability, and maintain a culture of design control discipline that values complete and accurate documentation as an asset to the organization.