Regulatory glossary

Design History File (DHF): What It Is After the QMSR

A Design History File is the compilation of records showing that a device was designed according to its approved design plan and the design control requirements. It is the evidence that the design process actually happened, in the order it was supposed to, with the reviews it was supposed to have.

One thing changed recently and most material online has not caught up with it.

The term is no longer in the regulation

Under the old Quality System Regulation, the DHF was required by 21 CFR 820.30(j). Since 2 February 2026, Part 820 has been the QMSR and incorporates ISO 13485:2016 by reference rather than stating requirements in its own words. ISO 13485 does not use the phrase "design history file". It requires a design and development file under clause 7.3.10.

Three acronyms moved at once:

The obligation did not change. You still have to hold records demonstrating the design was developed under control. What changed is the name and the clause you cite.

Practically: keep calling it the DHF internally if your team knows the term. What matters is that the file satisfies clause 7.3.10 and that your procedures point at the right clause. Renaming every document at once creates traceability gaps and buys nothing.

DHF, DMR and DHR

The three get confused constantly. The distinction is time.

• DHF is the past: how the device came to be designed. Design inputs, outputs, reviews, verification, validation, transfer, changes.
• DMR is the present: how to build it. Specifications, production processes, quality assurance procedures, packaging and labelling, installation and servicing.
• DHR is a specific past event: how one particular unit or batch was actually built.

A useful test. If a record tells you why the device is the way it is, it belongs in the DHF. If it tells you how to make the device, it belongs in the DMR. If it tells you what happened when you made one, it is a DHR.

What the file contains

The file does not have to physically hold every document. It can be an index that points at where each record lives, which is how most electronic systems do it. It does have to make the design history reconstructible.

Typically:

• The design and development plan, and its revisions.
• Design inputs: user needs, intended use, requirements, applicable standards, and the review that found them adequate.
• Design outputs: specifications, drawings, software, labelling, and the acceptance criteria they were checked against.
• Design review records: who attended, what was decided, including an independent reviewer for each review.
• Verification: evidence that outputs meet inputs.
• Validation: evidence that the device meets user needs and intended use, under actual or simulated use conditions, on initial production units.
• Design transfer: evidence the design was correctly translated into production specifications.
• Design changes: identification, documentation, validation, review and approval before implementation.
• Risk management records, linking to ISO 14971.

Where DHFs fail an inspection

• Reconstructed after the fact. A file assembled at the end of the project from memory tells an investigator the design controls were not operating during the design.
• Reviews without an independent reviewer. Each design review has to include someone with no direct responsibility for the stage being reviewed. Absent attendance records, the review is unevidenced.
• Verification confused with validation. Verification asks whether you built the thing right. Validation asks whether you built the right thing. A file with only the first is missing half its evidence.
• Design changes made without going back through review. A change after design transfer still needs the full cycle.
• Traceability gaps. An input with no corresponding output, or an output with no verification, is the single easiest finding for an investigator to spot.
• Stale citations. Procedures pointing at "820.30(j)" after February 2026.