The DHF is the documentary proof that your device was designed correctly. An incomplete DHF is both a regulatory citation and a product liability exposure. Here is how to build one that holds up.
The Design History File (DHF) is the documentary record that proves a medical device was designed correctly — covering design inputs, outputs, verification, validation, design reviews, and design transfer. Under 21 CFR Part 820.30(j), every design-responsible manufacturer must maintain a DHF for each device type. The most common DHF 483 observation is "inadequate design validation" — validation conducted under conditions that don't represent actual use, or against acceptance criteria defined after test results were already known.
The Design History File is the documentary record that demonstrates a medical device was designed and developed in accordance with the design plan and in conformance with specified design requirements. Under 21 CFR Part 820.30(j), every manufacturer who has design responsibility for a device subject to the Quality System Regulation must maintain a DHF for each type of device.
The DHF is not a product specification file. It is a developmental history — a record of the decisions, evidence, and activities through which the device design was established, verified, validated, and transferred to manufacturing. The Device Master Record (DMR) describes how the device is made. The DHF explains how the design was developed and proven adequate before production began.
The regulatory rationale is straightforward. A device that causes patient harm may trigger FDA investigation. In that investigation, the FDA will examine the design controls documentation to determine whether the manufacturer had evidence that the design was safe and effective before the device was manufactured and distributed. An adequate DHF demonstrates that the design process was systematic, that risks were identified and addressed, that the design was verified against its specifications, and that it was validated against user needs. An inadequate DHF raises the question of whether the manufacturer knew, or should have known, about design vulnerabilities before the device reached patients.
Beyond regulatory exposure, the DHF has operational value. A complete DHF makes design changes safer — engineers modifying a design can understand what was already evaluated and why specific decisions were made. It makes post-market surveillance more effective — when field issues surface, the DHF provides the context to determine whether the issue was a known risk, an undetected risk, or a manufacturing deviation.
FDA's design controls regulation establishes a framework of seven inter-related activities that must be documented in the DHF:
Design planning (820.30(b)). Each manufacturer must establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. Plans must be updated as design and development evolve. The planning documentation answers: who is doing what, by when, and with what authority?
Design inputs (820.30(c)). The requirements that the device must meet — physical characteristics, performance requirements, safety requirements, regulatory requirements, standards compliance requirements, and user needs translated into product specifications. Design inputs must be documented, reviewed, and approved. Ambiguous design inputs lead to designs that cannot be definitively verified.
Design outputs (820.30(d)). The results of the design and development process — drawings, specifications, software code, manufacturing procedures — that collectively define the device and how it is made. Design outputs must meet design input requirements. They form the basis of the Device Master Record.
Design review (820.30(e)). Formal documented reviews of design results at appropriate phases of development. Reviews must include representatives of all functions concerned with the design stage being reviewed, and must include an individual who does not have direct responsibility for the design stage. Design reviews ensure that problems are identified early, while they are still relatively inexpensive to address.
Design verification (820.30(f)). Confirmation by examination and provision of objective evidence that design output meets design input requirements. Verification answers: does the design meet the specifications? Verification testing, analysis, inspection, and modeling all generate verification evidence.
Design validation (820.30(g)). Establishing by objective evidence that device specifications conform with user needs and intended use(s). Validation answers: does the device actually work correctly for its intended use? Validation requires testing under actual or simulated use conditions. Where possible, validation should be performed under conditions that represent the actual use environment — not controlled laboratory conditions that do not reflect clinical reality.
Design transfer (820.30(h)). Ensuring that the device design is correctly translated into production specifications. Design transfer is the bridge between the DHF and the DMR. It must be documented and verified.
The DHF must contain, or reference the location of, all records necessary to demonstrate that the design was developed in accordance with the design plan and the design controls requirements.
A complete DHF typically includes:
Design plan and project history. The project plan, meeting records, and project history showing how the design progressed from initiation to design transfer.
Design input requirements document. The formally approved document defining all design requirements — performance, safety, regulatory, usability, and manufacturability requirements.
Risk management file. ISO 14971 risk analysis, FMEA, hazard identification, and risk control documentation. The 2024 revision to 21 CFR Part 820 increased alignment with ISO 13485, which explicitly references ISO 14971. FDA expects systematic risk management documented in the DHF.
Design output documents. Drawings, specifications, software design documents, and other design outputs, referenced to specific design input requirements.
Verification protocols and reports. Documented test protocols (before testing begins) and reports (after testing is completed) for each verification test. The protocol must specify the test method, acceptance criteria, and sample requirements before testing begins. A report written to match a pre-existing test result is not verification — it is documentation of an undocumented test.
Validation protocols and reports. Documented validation protocols and reports, including clinical evaluation or clinical study documentation where required. For devices subject to 510(k) or PMA requirements, substantial equivalence or safety and effectiveness data from the regulatory submission is typically part of the DHF.
Design review records. Minutes and records from each formal design review, including attendees, items reviewed, issues identified, and decisions made.
Design transfer documentation. Records demonstrating that the device design was correctly translated to production — comparison of design outputs to the finalized Device Master Record, production trial results, and the documented transfer approval.
Design change history. Records of all design changes, including the change description, rationale, impact assessment, re-verification or re-validation performed, and approval.
Verification and validation are frequently conflated in device development, and the confusion produces DHF gaps that attract 483 observations.
Verification answers the question: "Did we build the device right?" It compares outputs to inputs — it tests whether the device meets its specifications.
Validation answers the question: "Did we build the right device?" It compares the device to user needs and intended use — it tests whether the device works correctly for the people who will use it, under the conditions in which they will use it.
A device can pass all verification testing (it meets every specification) while failing validation (it does not actually work well in clinical use). This happens when the design inputs inadequately captured user needs — when specifications were written without sufficient understanding of the use environment.
The DHF must contain evidence of both. A DHF with comprehensive verification but minimal validation documentation will receive a 483 observation regardless of the quality of the verification evidence.
For verification: each specification in the design inputs must be traceable to at least one verification test that confirmed it was met. A gap in this traceability matrix — a specification with no verification evidence — is a finding.
For validation: the validation must be conducted under simulated or actual use conditions with a representative user population. Laboratory testing by engineers is not user validation. Usability studies, clinical simulations, or clinical investigations with intended users are.
After design transfer, any change to the device design must be controlled through a documented design change process. This is one of the most frequently cited areas in medical device 483 observations.
Design change control under 820.30(i) requires: identifying the change, documenting the rationale, assessing the impact on existing design inputs and outputs, determining whether re-verification or re-validation is required, and approving and implementing the change through a controlled process.
The impact assessment is the critical step that is most often inadequately performed. A change to one design parameter can affect other parameters in non-obvious ways. A material substitution that meets the mechanical specification may change biocompatibility status. A dimensional change that is within tolerance may affect the device's performance in a specific use scenario that was validated but is not covered by routine testing.
The impact assessment must be conducted by qualified personnel with sufficient design knowledge to identify these non-obvious effects. It must be documented. And it must result in a determination — documented with justification — of what re-verification or re-validation is required before the changed device can be distributed.
Implementing a design change, shipping the changed device, and retroactively completing the change documentation is a significant regulatory exposure. FDA's expectation is that the design change process is prospective, not retrospective.
Inadequate design validation. The most common DHF-related observation. Validation testing conducted under conditions that do not represent actual use, by users who are not representative of the intended user population, or against acceptance criteria defined after the test results were known.
Design inputs not meeting requirements of 820.30(c). Vague or incomplete design input documents. "The device shall be easy to use" is not a design input — it is an aspiration. "Task completion rate in simulated use study shall be 95 percent or greater" is a design input.
No traceability between design inputs, design outputs, and verification. The FDA expects to be able to trace every design requirement from the input document through the verification test that confirmed it was met, to the design output that implements it.
Design reviews not including required participants. Design reviews missing the independent reviewer requirement, or reviews where the required functions were not represented.
Design changes implemented without documented change control. Changes found in the Device Master Record that are not reflected in the design change history — indicating that changes were implemented without going through the formal process.
DHF not maintained at a defined location. The DHF must be maintained and its location documented. A DHF scattered across multiple systems, drives, and filing cabinets without a defined structure and index is not maintained adequately.
A DHF that is difficult to navigate is as problematic as an incomplete one. During an FDA inspection, the investigator will ask to see the DHF and will ask specific questions: "Show me the verification evidence for the biocompatibility requirements." "Show me the validation study that covered the intended use in pediatric patients." If finding the relevant records requires an extended search, the investigation extends. If they cannot be found at all, the absence is treated as absence of evidence.
Effective DHF organization:
Single location with clear structure. Whether physical, electronic, or hybrid, the DHF should have a defined top-level index that allows navigation to any required section. The index should reference the 820.30 requirements explicitly — every inspecting investigator works from the same framework.
Living index. The DHF index should be updated as new records are added. A DHF that grows without index updates becomes increasingly difficult to navigate.
Record completeness matrix. For each 820.30 requirement, document what records exist and where they are located. Gaps in this matrix are gaps in the DHF. Identifying them internally, before an inspection, is significantly preferable to having them identified by FDA.
Revision traceability. For documents that have been revised — design inputs, specifications, validation protocols — the DHF should preserve the history of revisions and the rationale for changes. The current version alone does not tell the developmental story.
Coplain helps medical device manufacturers build controlled, compliant design documentation and work instructions. Try it free at coplain.com.
Coplain turns any work instruction into a print-ready, audit-proof job aid in minutes.
Try Coplain free →AS9100 Rev D Documentation Checklist: 12 Items Auditors Check First
Most audit failures aren't about process gaps. They're about documentation that doesn't reflect reality. Here's the checklist we wish existed before our first Rev D audit.
6 min readCOMPLIANCEFDA 21 CFR Part 820 Documentation Requirements: What Trips Up Manufacturers
Warning letters. 483 observations. Consent decrees. Most FDA enforcement actions have one thing in common: inadequate documentation. Here's what the agency actually looks for.
10 min readCOMPLIANCEISO 9001:2015 Documentation Guide: What You Actually Need vs What You Think
The 2015 revision eliminated the quality manual requirement and six mandatory procedures. What it added is more demanding. Here's what actually changed — and what your registrar looks for during surveillance.
7 min readCOPLAIN PLATFORM
See every tool that turns complex work instructions into floor-ready documents.