The Design History File (DHF) is one of the most important — and most misunderstood — records in medical device development. It’s the compilation that proves your device was designed the way it was supposed to be: to a plan, against defined requirements, with the reviews, verification, and validation to back it up. If an auditor or the FDA wants to know how your device came to be, the DHF is the answer. Here’s what it is, what goes in it, and how to keep one that survives scrutiny.

What is a Design History File (DHF)?

The FDA defines it precisely. Under the design-control regulation (21 CFR 820.30), the Design History File is “a compilation of records which describes the design history of a finished device.” In plain terms: the DHF is the complete, organized story of your device’s design — the evidence that the finished product was developed in accordance with your design plan and the design-control requirements.

It’s worth being clear that the DHF isn’t one document. It’s a file — a curated collection (or an index pointing to records) that accumulates across the whole development project. With the QMSR now harmonizing the FDA’s quality regulation with ISO 13485, the same evidence lives in what 13485 calls the design and development file (Clause 7.3), but the DHF concept — and the term — is here to stay.

DHF vs. DMR vs. DHR: the three records people confuse

These three acronyms trip up nearly everyone, so here’s the clean distinction — they answer three different questions:

• DHF — Design History File: how the device was designed. The record of the development effort: plan, inputs, outputs, reviews, verification, validation.
• DMR — Device Master Record: how to build the device. The recipe — specifications, drawings, procedures, and criteria for manufacturing it.
• DHR — Device History Record: proof it was built. The production record showing a specific unit or lot was actually manufactured per the DMR.

Design creates the DHF; the DHF informs the DMR; building to the DMR produces the DHR. Three files, one continuous chain of evidence from concept to shipped product.

What goes in a Design History File

A DHF that holds up under audit contains — or indexes — the records generated by your design-control process:

• Design and development plan — the roadmap, responsibilities, and stages.
• Design inputs — the requirements the device must meet (user needs, intended use, performance, safety, regulatory).
• Design outputs — the specifications, drawings, and code that result, traceable back to the inputs.
• Design reviews — the formal, documented reviews at defined stages.
• Design verification — evidence the outputs meet the inputs (“did we design it right?”).
• Design validation — evidence the device meets user needs and intended use (“did we design the right thing?”).
• Design transfer — records showing the design was correctly translated into production.
• Design changes — the controlled record of every change and its review.
• A reference to the risk management file — your ISO 14971 analysis runs alongside design and feeds it.

A well-run DHF usually opens with an index that maps each of these to the actual controlled documents — so a reviewer can navigate the design story without a scavenger hunt.

Why the DHF matters

Two reasons, and both have teeth. First, audits: design controls are among the most heavily scrutinized areas in an FDA inspection or ISO 13485 audit, and the DHF is where the evidence lives. A disorganized or incomplete DHF is a fast route to findings. Second, submissions: a 510(k) or technical file draws directly from the DHF — the design inputs, verification, validation, and risk records you assemble for the file are the same ones the DHF holds. Build the DHF well as you go, and your submission is a collation exercise; build it badly, and it’s an archaeology project.

The same is true whether you make a physical device or software as a medical device — the design history has to be controlled and provable either way.

How to keep a DHF audit-ready

The hard part isn’t knowing what belongs in a DHF — it’s that the DHF is a living compilation that accumulates across months of development, scattered across reviews, tests, and revisions. Kept by hand in folders and spreadsheets, it drifts out of date and turns into a pre-audit scramble.

The durable fix is to treat every DHF record as a controlled document from the first design input. TLM carries a native DHF flag on controlled documents, so a document tagged as part of the Design History File counts toward it automatically, at its current released revision — and medical device document control, design records, and the risk file live in one place. Readiness is computed from the register, not rebuilt in a spreadsheet before every audit. The DHF stops being a project you assemble under pressure and becomes a byproduct of running design controls properly.

See a design-controlled DHF on your own process → Book a 20-minute walkthrough.

Frequently asked questions

What is a Design History File (DHF)?
A Design History File is a compilation of records that describes the design history of a finished medical device. Required by the FDA’s design-control regulation (21 CFR 820.30), it demonstrates the device was developed in accordance with the design plan and design-control requirements — the organized evidence of how the device was designed.

What’s the difference between a DHF, DMR, and DHR?
They answer three questions. The DHF (Design History File) shows how the device was designed. The DMR (Device Master Record) is the recipe for building it. The DHR (Device History Record) proves a specific unit or lot was actually built to the DMR. Design produces the DHF, which informs the DMR, and building to the DMR produces the DHR.

What does a DHF contain?
The records from your design-control process: the design and development plan, design inputs, design outputs, design reviews, verification, validation, design transfer, and design changes — plus a reference to the risk management file. A good DHF opens with an index mapping each element to the actual controlled documents.

Is a Design History File required by the FDA?
Yes, for devices subject to design controls. 21 CFR 820.30(j) requires manufacturers to establish and maintain a DHF for each type of device. Under the QMSR, which harmonizes the FDA regulation with ISO 13485, the same evidence lives in the design and development file (ISO 13485 Clause 7.3).

Does the DHF still exist under the QMSR and ISO 13485?
Yes. The QMSR (effective February 2, 2026) incorporates ISO 13485, where the equivalent is the design and development file under Clause 7.3. The specific term ‘DHF’ comes from the FDA regulation and remains in common use; the underlying requirement to compile and maintain design-history evidence is unchanged.