A design history file is the compiled record of how your medical device was designed — the evidence that development followed a controlled process rather than converging by trial and error. It is required for devices subject to design controls, and it is the first thing an FDA investigator asks for during a design control inspection. The file is not a report written at the end of the project. It is a compilation of records created as the work happened, and reconstructing it retroactively is both far more expensive and visibly obvious to an auditor.

This article is general engineering education, not regulatory or legal advice. Projects House is an engineering firm; confirm your specific obligations with qualified regulatory counsel.

What the DHF is for

The regulation's purpose is straightforward: a device is safe and effective because it was developed under control, and the file demonstrates that control. It should let a competent stranger reconstruct why the device is the way it is — what needs it addresses, what requirements were derived, what alternatives were considered, what risks were identified and how they were controlled, what changed and why, and what evidence shows the finished device meets the original need.

That last purpose matters internally too. Teams turn over. Three years after launch, when a supplier discontinues a component, the DHF is what tells the next engineer why the original part was chosen and what has to be re-verified.

What belongs in the file

The regulation does not dictate a table of contents, but a defensible file contains records covering each design control element:

  • Design and development plan — phases, deliverables, responsibilities, and review points, revised as the project evolves.
  • User needs — the clinical and user requirements the device exists to satisfy, with their sources.
  • Design inputs — the engineering requirements derived from those needs, written so each is objectively verifiable, plus the applicable standards and regulatory requirements.
  • Design outputs — drawings, specifications, software source and build records, bills of material, labeling, packaging, and acceptance criteria. Structuring these well starts with a solid bill of materials.
  • Design reviews — minutes, attendees including an independent reviewer, decisions, and action items with closure.
  • Verification records — protocols, raw data, and reports proving outputs meet inputs.
  • Validation records — usability, simulated or actual use, clinical evidence where required, and software validation. The distinction is covered in verification versus validation.
  • Risk management file — hazard analysis, risk controls, verification of control effectiveness, and the overall benefit-risk conclusion, per ISO 14971.
  • Design transfer records — evidence the design was correctly translated into production specifications and processes.
  • Design change records — every change after the design was under control, with its rationale, impact assessment, and re-verification.
  • Traceability matrix — the thread linking each user need to a requirement, to an output, to the test that verified it, and to any associated risk control.

The traceability matrix is the single most useful document in the set. It is also the one most often missing, and the one an auditor uses to find every gap in ten minutes.

DHF, DMR, DHR — three files, one common confusion

  • DHF (design history file) — how the device was designed. Historical, per design project. Grows during development, then only through design changes.
  • DMR (device master record) — how the device is built. The current recipe: specifications, drawings, process instructions, quality procedures, packaging and labeling. Forward-looking and always current.
  • DHR (device history record) — how a specific lot was actually built. Production records, in-process results, test data, and release documentation for units that shipped.

A useful mental model: the DHF is why the recipe is what it is, the DMR is the recipe, and the DHR is what happened the day you cooked. Under ISO 13485 the equivalent concepts appear as the design and development file and the medical device file — see ISO 13485 requirements.

The expensive mistake: documenting at the end

The most common failure pattern in first-time device programs is engineering first and documenting later. It fails for concrete reasons:

  • Verification tests run before requirements were formalized rarely map cleanly onto them, so tests get repeated.
  • Design review records cannot be created after the fact without fabricating them, which is a serious finding.
  • Decision rationale is genuinely lost. Nobody remembers why a wall thickness was increased two years ago.
  • Retrofitting a file typically costs a multiple of what maintaining it would have cost, and it delays submission at exactly the point where delay is most painful.

The alternative is not heavier process, it is lighter and continuous: a requirements document that exists from the start, review minutes taken in the meeting, protocols written before tests, and changes captured through a simple controlled route like the one in the engineering change order process.

How much work is it, really?

For a low-risk Class I or a straightforward Class II device, this is a meaningful but manageable overhead — a real fraction of engineering effort, not a doubling. For higher-risk devices with software and clinical evidence, documentation becomes a major line item in its own right, and how it maps to your submission depends on your classification and pathway; see FDA medical device classes.

Tooling ranges from a controlled folder structure with a spreadsheet traceability matrix — entirely acceptable for a small program, provided version control is real — to dedicated electronic quality management systems that link requirements, risks, and tests automatically. Start proportionate. An over-specified system nobody follows is worse than a simple one that is actually maintained.

How Projects House approaches it

We set up the requirements document, risk file, and traceability matrix in the first phase of a device project, then let them grow with the design instead of chasing them at the end. More on this area is collected on our medical device development page.

Set the file up before the engineering starts

If you are beginning a device program — or discovering mid-project that the documentation trail is thinner than it should be — send us the details through the contact form and we will map out what your file needs to contain.