What Is a Design History File (DHF) and Why Your Startup Needs One Now

Most medtech founders discover the DHF requirement the hard way — during a 510(k) review or FDA pre-submission meeting, when they realize their design records do not meet the requirements of 21 CFR Part 820 or the FDA QMSR that replaced it in February 2026. At that point, you are facing months of retroactive documentation work, often on a device that has already gone through significant design changes that were never captured in a controlled record.

This guide explains what the DHF is, what it must contain, the most common mistakes startups make, and how to build a DHF structure that will hold up to a 510(k) review — starting from where you are right now.

What Is a Design History File?

The Design History File is the documented record of the design history of a finished device. Under 21 CFR 820.3(e), the DHF is defined as "a compilation of records which describes the design history of a finished device." It must contain or reference all records necessary to demonstrate that the device was designed in accordance with the approved design plan and applicable regulatory requirements.

Think of the DHF as the biography of your device's design. It does not describe what the device is or how to make it — that is the Device Master Record. The DHF describes the process by which the device became what it is: the inputs that defined it, the outputs that embodied those inputs, the reviews that checked the work, the tests that verified and validated it, and the transfer that moved it from design into production.

The DHF is a living document. It starts at project kickoff and accumulates records throughout the design process. By the time you reach 510(k) submission or market launch, it should be comprehensive enough that an FDA investigator could reconstruct your entire design journey from its contents.

DHF vs. Device Master Record (DMR): The Distinction That Trips Founders

The confusion between DHF and DMR is one of the most common structural mistakes in startup QMS documentation. Many founders conflate the two or attempt to use a single folder structure for both. They are related — the DHF's design transfer records feed directly into the DMR — but they serve fundamentally different purposes and have different regulatory requirements.

See our DHF/DMR module documentation for how Affinity QMS structures both records in a single platform with linked cross-references.

What the DHF Must Contain

Under the FDA QMSR / ISO 13485 framework, your DHF must contain or reference records demonstrating that design controls were applied throughout the design and development process. These are the seven required categories:

• Design inputs — The physical, performance, safety, and regulatory requirements that the device must meet. These form the baseline against which all verification and validation is measured.
• Design outputs — The result of the design effort at each design phase. Drawings, specifications, software, and other documents that define the device. Must be expressed in terms that can be verified.
• Design review records — Formal documented reviews of design results at defined design stages. Must include participants, date, results, and any follow-up actions.
• Design verification records — Objective evidence that the design outputs meet the design inputs. Test reports, inspection records, analyses. Answers: "Did we build it right?"
• Design validation records — Objective evidence that the device meets the intended use and user needs. Clinical data, usability studies, simulated use testing. Answers: "Did we build the right thing?"
• Design transfer documentation — Records demonstrating that device design was correctly translated into production specifications. Critical under QMSR, which strengthened this requirement.
• Design changes — All changes made to the design after initial design outputs, including the rationale for each change, reviews performed, and re-verification or re-validation conducted.

Common DHF Mistakes That Kill 510(k) Submissions

Building a DHF That Survives a 510(k) Review

FDA 510(k) reviewers do not physically review your full DHF — you do not submit the DHF with the 510(k). However, FDA can request DHF records as part of the review process, and the design controls section of the 510(k) essentially summarizes your DHF in structured form. A well-organized DHF makes writing a credible design controls section dramatically easier.

Structure your DHF around the clause organization of FDA QMSR / ISO 13485 Section 7.3. Number your design review records sequentially. Create a traceability matrix that cross-references design inputs to design outputs to verification tests to validation activities. Index every record with a document number, revision level, and approval date. Ensure your risk management file (ISO 14971-structured) is explicitly linked from the DHF index.

When FDA requests DHF records, reviewers want to pull any record and immediately see its relationship to everything else. If your DHF is a disorganized collection of files, the review will surface that immediately.

QMSR's Impact on DHF Structure

The FDA QMSR, effective February 2026, made two DHF-specific changes that medical device startups need to reflect in their records. First, design transfer is now more explicitly required as a formal stage with documented records — not just an informal handoff to manufacturing. Second, risk management documentation (ISO 14971-structured) must be explicitly linked throughout the design control records, not treated as a separate standalone activity.

If you are building your DHF after February 2026, structure it to QMSR from day one. Do not inherit the legacy Part 820 clause numbering that older templates use — FDA reviewers are now expecting the ISO 13485 clause structure.