How to Read a Design History File

A Design History File shows up in two very different moments: when a new hire is handed a product line and told to get familiar with it, and when an FDA investigator asks to see it during an inspection. Both moments reward the same skill — knowing what the file is actually supposed to prove, rather than treating it as a folder of design documents someone assembled once and never opened again.

In brief

A DHF is not a single document. It is a compilation — or an index that references controlled records held elsewhere — that demonstrates the design was developed according to the approved design plan.
Its job is to prove a specific chain: user needs became design inputs, inputs became outputs, and outputs were verified and validated before the design was released.
Verification and validation answer different questions. Verification asks whether the output met the input. Validation asks whether the finished device meets user needs and its intended use.
Under the QMSR’s shift to ISO 13485:2016, the term “DHF” is a holdover convention, not the standard’s own language — the file itself, and what it has to prove, didn’t go anywhere.

What it has to prove, not just what it contains

The old 21 CFR 820.30(j) defined a DHF as a compilation of records describing a device’s design history, and it explicitly allowed the file to reference other documents rather than duplicate them — a distinction worth holding onto, because plenty of people expect a DHF to be one binder and get confused when it is instead an index pointing to a document control system. What matters is not the container but the chain the container has to demonstrate: a design and development plan describing how the project would be run and by whom; design inputs derived from user needs and intended use; design outputs that trace back to those inputs; verification records showing outputs met inputs; validation records showing the finished device meets user needs under actual or simulated use conditions; documented design reviews at defined stages; and any design changes, each with its own justification and, where the change was substantive, its own re-verification or re-validation. The QMSR moved most of this language into ISO 13485:2016’s clause 7.3, which covers design and development files under its own structure rather than 820’s old subpart letters. The clause numbers changed. The chain a reviewer is checking for did not.

Reading one like a reviewer, not the author

Someone who didn’t write the file has to answer a narrower question fast: does the traceability hold end to end? The fastest way in is the traceability matrix, if one exists as its own artifact, or the pattern of cross-references if it doesn’t — find a design input, confirm it maps to at least one output, confirm that output has a verification record, and confirm the intended-use-level requirements were separately validated rather than just verified against a spec. Design reviews are the second thing worth checking, specifically whether they happened at the points the design plan said they would and whether they were signed by someone with the authority to approve moving to the next stage — a review that happened after the fact, or that nobody with real authority attended, is a finding waiting to happen. The third thing is how design changes were handled after initial release: a device that shipped, then changed a material or a software module, needs a documented change record showing what triggered the change, what was reassessed, and whether that reassessment reached back into the risk management file as well as the DHF. A file that looks complete for the original design but goes quiet after the first production run is usually a file nobody has been maintaining, which is its own kind of finding.

Where this goes wrong

Confusing the DHF with the Device Master Record

The DHF is the history of how the design came to be, including the dead ends. The DMR (or its ISO 13485 equivalent) is the current, approved specification for building the device today. Someone asking for one and getting the other will notice quickly, and so will an investigator.

Treating verification and validation as interchangeable

A device can pass every verification test against its own written specs and still fail validation if the specs themselves didn’t capture what users actually needed. Reviewers look for both, separately, on purpose.

Letting the file go quiet after launch

Design controls don’t end at first commercial release. A material substitution, a software patch, or a manufacturing process change to an already-cleared device still needs its own design-change record, with its own justification for what re-verification or re-validation it did or didn’t require.

None of this is exotic once you’ve seen a few files, which is exactly why it disorients people moving from quality into regulatory affairs the least and people arriving from other backgrounds the most. If you’re building a submission rather than auditing an existing product, the same traceability logic is what a reviewer is checking for when they ask how a 510(k) file was assembled in the first place.

Sources & further reading

eCFR — 21 CFR Part 820, design controls and the QMSR’s incorporation of ISO 13485:2016 by reference ecfr.gov
Regulatory Academy — What the QMSR actually changes regulatoryacademy.com
Regulatory Academy — Moving from quality into regulatory affairs regulatoryacademy.com
Regulatory Academy — Building the 510(k) file regulatoryacademy.com

This essay is provided for general educational purposes and reflects the regulatory landscape as of its publication date. It is not legal, regulatory, or career advice.