Introduction
If you make FDA-regulated devices, an auditor will ask for your Design History File before they ask for almost anything else. It's the first place they look to see whether your design process actually happened the way your procedures say it should.
Many quality teams struggle here because DHF, DMR, and DHR get tangled together in daily use. That confusion is getting worse now that the FDA's Quality Management System Regulation (QMSR) folds these terms into ISO 13485 language, effective February 2, 2026.
This guide breaks down what a DHF actually is, what belongs in it, how it differs from a DMR and DHR, what the QMSR transition changes (and what it doesn't), and the mistakes that turn a routine audit into a Form 483.
Key Takeaways
- A DHF proves design followed the approved plan under 21 CFR 820.30 (ISO 13485 Clause 7.3 under QMSR)
- DHF = design history; DMR = build instructions; DHR = what was actually built
- QMSR retires the legacy terms on February 2, 2026 — the evidence requirements stay the same
- Update the DHF continuously so file gaps don’t become your most common audit findings
What Is a Design History File (DHF)?
A Design History File is the compiled record proving your device was developed per your design plan and FDA's design control requirements. The FDA has described it plainly: a DHF is "a compilation of records which describes the design history of a finished device."
The regulatory text itself, under 21 CFR 820.30(j), is specific about the obligation:
"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."
That phrase, establish and maintain, creates two distinct duties. That split traces to the design control authority Congress created under the Safe Medical Devices Act of 1990. It splits into two separate obligations:
- Establishing means defining and documenting your design process before you build anything
- Maintaining means reviewing, approving, and updating that documentation as the design actually evolves
One DHF Per Device Type
You need a separate DHF for each device type or family, not one blended file covering your entire product line. A device family sharing common design characteristics can share a file, but mixing unrelated device types into a single record makes traceability nearly impossible to demonstrate later.
Build It Live, Not After the Fact
The biggest trap teams fall into: waiting until submission time to assemble the DHF retroactively. A DHF should grow as design and development happens, not reconstructed from memory, emails, and old file shares once the auditor is already scheduled.
A living DHF delivers more than compliance:
- Preserves requirements traceability across the full design lifecycle
- Documents change control history with clear approval records
- Keeps critical design rationale in-house when engineers leave
What Should a DHF Include?
Think of the DHF as a chronological record of every major design decision, tied back to the plan that authorized it. Here's what to capture, in the order it typically occurs.
At project kickoff:
- Design and development plan (responsibilities, interfaces, review points)
- Documented user needs
- Design inputs addressing intended use and patient/user requirements
During development:
- Design outputs (specifications, drawings, and software requirements) that trace directly back to their originating inputs
- A traceability matrix linking requirements, risks, tests, and releases (even a simple spreadsheet works, as long as it's current)
Design review records: Each record should include:
- Review date
- Attendees, including at least one independent reviewer
- Version of the design under review
- Decisions made and resulting actions
Verification and validation:
- Protocols and results showing outputs meet inputs (verification)
- Protocols and results showing the device meets user needs under actual or simulated use conditions (validation)
- Risk management documentation linked to ISO 14971 (validation is where risk analysis usually folds in)
Later in the lifecycle:
- Design transfer evidence showing the design was correctly translated into production specifications
- Design change and deviation records, each with documented approval
One shortcut worth knowing: your DHF can reference records instead of duplicating them. If a specification already lives in your Design Master Record (DMR), point to it rather than copy-pasting it into two places. Duplication creates version-control headaches you don't need.
DHF vs. DMR vs. DHR: Understanding the Differences
Here's the mnemonic that makes this stick: the design goes in a file (DHF), the device gets a master recipe (DMR), and every unit built gets its own production record (DHR).
| Record | What It Proves | Scope | Key Contents |
|---|---|---|---|
| DHF | Design was developed correctly | Per device type | Design plan, inputs, outputs, reviews, V&V results, transfer evidence |
| DMR | How to build the device | Per device type | Device specs, production process specs, QA acceptance criteria, packaging/labeling specs, servicing procedures |
| DHR | The device was actually built to spec | Per batch, lot, or unit | Manufacture dates, quantities produced/released, acceptance records, UDI/identification data |
Each record maps to a specific FDA rule: DHF under 21 CFR 820.30, DMR under 21 CFR 820.181, and DHR under 21 CFR 820.184. The DHR must show the finished device conforms to the DMR.
The relationship is sequential. Design history leads to build instructions, which lead to a device history. Miss one link, and you've broken the chain an auditor needs to see:
- No DHF? You can't prove the design was ever validated.
- No DMR? Your DHR has nothing to be measured against.
- No DHR? You can't prove a single unit actually matches either document.
Together, all three prove complete compliance across a device's lifecycle — not just at launch, but for every unit that ships afterward.
How the FDA's QMSR Changes DHF Requirements
Starting February 2, 2026, the FDA's Quality Management System Regulation replaces the legacy Quality System Regulation and incorporates ISO 13485:2016 by reference. This is the change reshaping how quality teams talk about design records.
Here's the part that catches people off guard: the terms DHF, DMR, and DHR disappear from the regulation text entirely. ISO 13485 uses different language to describe overlapping content — "design and development file" and "medical device file" instead.
No need to panic. The FDA has been clear that record-keeping obligations aren't going anywhere. The same underlying elements remain required — just organized under ISO 13485 Clause 4.2 and Clause 7 instead of the old 820.30/820.181/820.184 structure.
Quick Terminology Crosswalk
| Legacy Term | QMSR/ISO 13485 Equivalent |
|---|---|
| DHF | Design and Development File (Clause 7.3.10) |
| DMR | Medical Device File (Clause 4.2.3) |
| DHR | Production and acceptance records under record controls (Clause 7.5.1) |
If your team already maintains a clean DHF today, you're not starting over. You're relabeling and reorganizing existing evidence to match a different clause structure. It's a mapping exercise, not a rebuild.
Common DHF Mistakes and How to Stay Audit-Ready
Design control failures show up in FDA inspection data more often than most teams expect. In FDA's fiscal year 2017 inspection report, design control observations accounted for 455 of 3,519 total Part 820 findings, or 13% of everything cited that year, making it the third most common category of quality system deficiency.
The recurring failure patterns rarely change:
- No DHF at all for a device type that requires one
- Chaotic, unorganized documentation with no clear index or structure
- Irrelevant files cluttering the record, burying the evidence that actually matters
- An unmaintained DHF that stopped updating after the initial design freeze
- Weak traceability back to the DMR, leaving auditors unable to connect design intent to production reality
Building Better Habits
- Build the DHF concurrently with the design process, not after submission deadlines force a scramble
- Enforce version and change control so only approved, current documents populate the record: no draft specs, no superseded revisions mixed in
- Run periodic retrieval drills. Pick a random requirement and pull its full evidence chain, from input through validation, to confirm the trail holds up
Those habits depend on controlled documents you can trust under pressure. QMS Learning's Document Management System keeps one live revision per controlled document, an append-only revision history, and read-and-understand acknowledgments by person and version. That way a design-control procedure three revisions out of date does not land in an audit packet by mistake.
The Medical Device & Life Sciences QMS pathway (pilot Q3 2026) covers ISO 13485, FDA 21 CFR Part 820, and ISO 14971. The AI Workbench, trained on those frameworks, can help draft DHF entries and flag design-related gaps before an auditor does.
Founder Will Trikha shaped both from two decades writing and closing audit findings on the aerospace and defense floor, where "objective evidence" leaves little room for shortcuts.
Frequently Asked Questions
What is the difference between DMR and DHF?
A DHF documents how a device was designed and validated. A DMR defines the specifications and procedures needed to actually manufacture it. One proves design history; the other is the build instructions.
What is the difference between DHF and DHR?
The DHF is the history of the design process. The DHR is the history of the manufactured device, including production dates, quantities, and acceptance records for specific units or batches.
What should a medical device file include?
Under ISO 13485 and QMSR, the Medical Device File bundles content that was historically split across the DHF, DMR, and DHR. It ties design, specifications, and production evidence to a device type or family.
How do I check if a device is FDA cleared?
Search the FDA's public 510(k) Premarket Notification database or the PMA database by device name or company name. Both are searchable at no cost directly on FDA's website.
How long must a Design History File be retained?
Retain the DHF for the expected life of the device, with a minimum of at least two years from commercial release under legacy FDA rules. Confirm current requirements against active FDA and ISO 13485 guidance, since minimums vary by device type.
Is a DHF required for Class I medical devices?
Most Class I devices are exempt from design controls entirely. However, a specific list of Class I device types — including certain software-driven devices, tracheobronchial suction catheters, and radionuclide applicators — are named exceptions and do require a DHF.
