Design History File (DHF) is a compilation of records describing the design history of a finished medical device. Mandated by FDA 21 CFR Part 820.30(j), it shows that a device was developed according to its approved design plan and the design control requirements that apply to it.
What is a Design History File (DHF)?
A Design History File (DHF) is the documented trail of how a medical device moved from concept to a validated, transferable design. It does not hold the design itself. It holds the evidence that the design process happened correctly: plans, inputs, outputs, reviews, verification and validation results, and the record of every change.
The DHF sits inside the design and development phase of the device lifecycle, under an organization’s design controls. It differs from the Device Master Record (DMR), which defines how to build the device, and the Device History Record (DHR), which proves a specific unit was built to that definition. The DHF answers a different question: Was this design developed in a controlled, traceable way?
Why a Design History File (DHF) matters in medical device development
Regulators treat the DHF as primary evidence that design controls were followed. During an FDA inspection or a notified body audit, it is one of the first things reviewers ask to see. Gaps like missing reviews, unsigned approvals, or verification results that do not trace back to inputs show up repeatedly in 483 observations and warning letters.
The stakes are patient safety and market access at once. A weak DHF can delay a 510(k) clearance or a CE marking, force remediation before launch, or surface during a recall investigation. For Class II and Class III devices, scrutiny is heavier. Rebuilding a DHF after the fact is slow, costly, and rarely as clean as building it as you go.
Key components of a Design History File
The DHF compiles records generated across the design control process. It typically includes:
- Design and development plan, with responsibilities, phases, and review points.
- Design inputs: user needs, intended use, performance, safety, and regulatory requirements.
- Design outputs: specifications, drawings, software, and acceptance criteria.
- Design reviews: minutes, attendees, and action items.
- Design verification records confirming outputs meet inputs.
- Design validation records confirming the device meets user needs and intended use.
- Risk management file linkage per ISO 14971.
- Design changes with their review, approval, and traceability.
- Design transfer records showing the design moved correctly into production.
These elements are required under FDA 21 CFR Part 820.30, the design controls clause. Under ISO 13485, the same evidence lives in design and development records (clause 7.3). Under EU MDR 2017/745, it feeds the technical documentation in Annexes II and III. Software devices add IEC 62304 lifecycle records, and usability evidence follows IEC 62366-1. The DHF works best as an index pointing to all of these that stays current as the project runs.
Common challenges and best practices
Teams most often get traceability wrong. Inputs do not map to outputs, outputs do not map to verification, and a reviewer cannot follow the thread from a user need to the test that proves it was met. A requirements traceability matrix solves most of this when maintained from day one rather than assembled at the end.
A second failure is treating the DHF as something you produce after design freeze. By then, reviews have happened informally, the change rationale is lost, and people have moved on. Capture review minutes and change decisions when they happen, not months later.
Other recurring problems include confusing the DHF with the DMR or technical file, leaving design changes undocumented, and storing records in scattered drives with no version control. Good practice is a single controlled location, clear naming, signed approvals, and a named owner. Map the DHF structure to your target regulations early, so one file supports FDA, EU MDR, and other submissions without duplication.
How SJML helps with the Design History File (DHF)
SJML supports the DHF across engineering and regulatory work. Its design and engineering teams run phase-gate development with built-in design controls, design reviews, verification and validation, and structured change control, so the records that make up the DHF are generated as the work happens rather than reconstructed later. Risk management to ISO 14971 and usability engineering to IEC 62366-1 are part of the same flow. On the QARA side, SJML prepares technical files and DHFs and performs DHF remediation for legacy or acquired products, aligned to FDA 21 CFR Part 820, ISO 13485, and EU MDR.
Talk to SJML’s engineering team →
Frequently asked questions
The Design History File (DHF) records how a device was designed and developed. The Device Master Record (DMR) defines how to build it, the specifications, and the recipe. The Device History Record (DHR) proves a specific production unit was actually built to the DMR. In short: DHF covers design, DMR covers the build definition, and DHR covers a built unit.
Yes. FDA 21 CFR Part 820.30(j) requires manufacturers of Class II and Class III devices, and certain Class I devices, to establish and maintain a DHF. It must demonstrate that the device was developed in accordance with the approved design plan and design control requirements. Inspectors review it to confirm design controls were followed.
EU MDR 2017/745 does not use the term “DHF.” It requires technical documentation under Annexes II and III, which captures the same design and development evidence. Many companies maintain one design record set that satisfies both FDA design control expectations and EU MDR technical documentation, avoiding duplicate files.
Start at project kickoff, alongside the design and development plan. The DHF is meant to grow throughout design as records are created: inputs, reviews, verification, validation, and changes. Building it continuously keeps records accurate and review-ready. Assembling it after design freeze risks gaps, lost rationale, and audit findings.
Related terms
- Design Controls
- Device Master Record (DMR)
- Design Verification
- Design Validation
- Risk Management File
