📋 Quick Summary
What goes in a Design History File under FDA 21 CFR 820.30. DHF structure, required records, common gaps, and how to maintain a DHF that passes inspection.
📬 Get daily updates like this in your inbox. Subscribe to RegWatch Daily →
What the DHF Is and What It Must Contain
The Design History File (DHF) is the collection of records describing the design history of a finished device. FDA QSR §820.30(j) requires that each manufacturer establish and maintain a DHF for each type of device. The DHF does not need to be a single physical or electronic folder — it can be a compilation of records maintained in multiple locations, as long as those records are identified, organized, and retrievable as a coherent design history for the device.
The DHF must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design and development plan. This means the DHF must provide a complete, traceable record from the initial design inputs through design output, verification, validation, design review, and design transfer.
FDA §820.30(j) is brief in its description of DHF requirements, but the detailed content requirements flow from the other design control clauses. A complete DHF contains: the design and development plan (§820.30(b)), design input records (§820.30(c)), design output records (§820.30(d)), design review records (§820.30(e)), design verification records (§820.30(f)), design validation records (§820.30(g)), design transfer records (§820.30(h)), and design change records (§820.30(i)).
Under ISO 13485:2016, the equivalent concept is design and development records, required by Clause 7.3.10. The QMSR aligns the DHF requirement with ISO 13485 structure but retains the DHF terminology.
Design Inputs: The First and Most Critical DHF Element
Design inputs are the physical and performance requirements of the device that serve as the basis for device design. FDA §820.30(c) requires that each manufacturer 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.
Incomplete or ambiguous design inputs are the single most common design control deficiency cited in FDA 483 observations. They are also the root cause of a disproportionate share of device failures and recalls — if the specification is wrong or incomplete, the device can meet all its specifications and still fail to meet user needs or cause patient harm.
What design inputs must address: Functional requirements (what the device must do, with measurable parameters and tolerances), performance requirements (accuracy, precision, range, sensitivity), physical requirements (dimensions, weight, geometry driven by intended use), biocompatibility requirements (derived from ISO 10993 analysis for patient-contacting materials), reliability requirements (MTBF, design life, expected number of uses), safety requirements from risk management (specific risk controls that must be incorporated), applicable regulatory and standards requirements (IEC 60601 for electrical safety, ISO 11135 for sterilization, etc.), and packaging and labeling requirements.
Design inputs must be documented in approved records before design work begins. Requirements that are added during development without going through a formal input approval process create a traceability gap in the DHF.
Design Verification and Validation Records
Design verification and validation (V&V) records form the core evidence in the DHF that the device meets its design inputs and user needs. These records are frequently requested by FDA investigators during inspections and are thoroughly reviewed during 510(k) and PMA submissions.
Verification records must demonstrate that design outputs meet design inputs. A complete verification record includes: the test objective linked to the specific design input being verified, the test method (referencing a standard or describing a custom protocol), the acceptance criterion (the numeric or qualitative standard the device must meet), the test results (raw data or summary), and the conclusion (pass or fail against the acceptance criterion). Verification records without explicit linkage to design inputs are incomplete.
Validation records must demonstrate that the device meets user needs and intended use. Design validation must include software validation and risk analysis, where applicable. Validation must be performed under defined use conditions using production-equivalent devices. For usability validation (human factors), FDA expects formal formative and summative usability testing with a representative sample of intended users under conditions that simulate actual use.
Traceability matrix: The DHF should include a design traceability matrix that maps each design input to the design output that satisfies it, and then to the verification or validation activity that confirms the output meets the input. This matrix is the roadmap through the DHF — it demonstrates systematic, complete coverage and allows FDA investigators and auditors to follow the design history without relying on the manufacturer to navigate it.
Get this intelligence in your inbox every morning.
Daily regulatory briefings for QA managers, SaMD teams, and startup RA leads — personalized, actionable, free.
Subscribe Free →Free forever. Unsubscribe anytime.
Design Changes and Post-Market DHF Maintenance
The DHF is a living document. It must be updated throughout the device lifecycle to capture design changes. FDA §820.30(i) requires that design changes be identified, documented, reviewed, and approved before their implementation. The change record and associated documentation (updated design inputs, revised V&V, updated risk management) become part of the DHF.
Design change evaluation: Not every design change requires the same level of documentation and verification. A change to a non-critical packaging material requires a different level of rigor than a change to a device component that contacts blood. FDA's guidance on evaluating design changes for whether a new 510(k) is required (the "significant change" analysis) applies to externally-regulated changes, but internally, your design change procedure should define criteria for evaluating what level of impact assessment, V&V, and risk management review is required for any given change.
Post-market DHF updates: Changes made in response to field complaints, CAPAs, or post-market surveillance findings that result in design or specification changes must also be captured in the DHF. The connection from the CAPA or PMS record to the design change record and the updated DHF should be traceable — FDA investigators will follow this chain during inspections.
DHF organization and accessibility: FDA §820.30(j) requires that the DHF index or be able to be organized to demonstrate that the design was developed in accordance with the plan. The DHF does not need to be a single document, but there must be a defined organizational structure (index, table of contents, or file structure) that allows any DHF record to be located and its relationship to the overall design history to be understood. An unorganized collection of design records without a navigable structure does not satisfy the DHF requirement.
📚 Sources & References
- 📄21 CFR Part 820 §820.30 — Design Controls
- 📄FDA: Design Controls Guidance for Medical Device Manufacturers
- 📄ISO 13485:2016 Clause 7.3 — Design and development
---
Ready to implement this? Download our Design Controls Toolkit — includes all templates, SOPs, and checklists you need.
Get this intelligence in your inbox every morning.
Daily regulatory briefings for QA managers, SaMD teams, and startup RA leads — personalized, actionable, free.
Subscribe Free →Free forever. Unsubscribe anytime.
Get the Design Controls Toolkit — DHF structure template, design input/output traceability matrix, and V&V protocol templates.
Get the Design Controls Toolkit — $247