What is a Design History File in medical devices?

A Design History File is the organized collection of records that proves a medical device was designed and developed according to an approved plan. It includes design plans, inputs, outputs, verification and validation test results, design reviews, transfer records, and change documentation. Under the FDA's QMSR (effective February 2, 2026), the DHF requirement is maintained through ISO 13485:2016 Clause 7.3 and Clause 7.3.10.

What is the difference between a DHF and a DMR?

The DHF (Design History File) documents the design and development process: what requirements the device needed to meet, how it was designed, and how the design was tested. The DMR (Device Master Record) is the complete set of specifications and procedures needed to manufacture the device, created at the end of design transfer. The DHF tells the design story; the DMR is the manufacturing blueprint.

What is the difference between a DHF and a DHR?

The DHF covers the design and development of a device type. The DHR (Device History Record) covers the actual production of specific lots or units: what materials were used, what tests were run, and what results were obtained. Every production run generates a DHR; there is typically one DHF per device type.

Does the QMSR change what goes in the DHF?

The content requirements are substantially preserved. The QMSR (effective February 2, 2026) replaces the explicit DHF requirement from old 21 CFR 820.30(j) with the ISO 13485:2016 Clause 7.3.10 Design and Development File. The practical documentation obligations are nearly identical, though manufacturers should confirm their QMS procedures reference the correct current regulatory basis.

When should you start building the DHF?

The DHF should begin at the start of the design and development phase, ideally when the design plan is approved. Waiting until near-submission to compile a DHF typically means reconstructing records that were not captured contemporaneously, which creates credibility and completeness problems. The goal is a living file, updated in real time as design activities occur.

Is a technical file the same as a DHF?

Not exactly. A Technical File (EU) and a DHF (FDA) serve parallel purposes but have different structural requirements. The EU Technical File under MDR 2017/745 includes clinical evaluation, post-market surveillance planning, and GSPR conformity mapping, which have no direct DHF equivalent. A well-built DHF will provide significant overlap with what the EU Technical File needs, but they require separate organization and some unique EU-specific content.

Does a Class I medical device need a DHF?

Under the QMSR and ISO 13485, design controls apply to devices for which design activities are required. FDA historically exempted most Class I devices from design controls under the QSR, and that exemption framework carries forward under the QMSR: 21 CFR 820.10(c) applies the ISO 13485 Clause 7.3 design and development requirements to Class II, Class III, and a specified list of Class I devices, so most Class I devices remain outside the design and development requirement. ISO 13485 does not make device-class-based exemptions, so if a manufacturer operates under ISO 13485, design controls apply regardless of FDA class.

Medical Device Design History File (DHF): What It Is and What Goes In It

Direct answer: A Design History File (DHF) is the compilation of records that demonstrates your medical device was designed and developed in accordance with your approved design plan. Under the FDA's Quality Management System Regulation (QMSR, effective February 2, 2026), the DHF requirement is carried forward through ISO 13485:2016 Clause 7.3 and the Design and Development File defined in Clause 7.3.10. It includes design plans, inputs, outputs, reviews, verification and validation records, transfer documents, and change history for a specific device type. (As of July 2026.)

A DHF is not a single document. It is an organized collection of records, often spanning thousands of pages, that tells the story of how a device moved from concept to manufactured product. Regulators and auditors use it to answer one question: did you follow your own plan, and does the evidence show it?

Getting the DHF right from the start of development costs relatively little. Reconstructing it under an audit or before a 510(k) submission costs significantly more in time and risk.

What Is the DHF Under the QMSR?

The FDA's legacy Quality System Regulation (QSR) created the DHF requirement under what was 21 CFR 820.30(j). When the QMSR took effect on February 2, 2026, that specific section was reserved. Design and development requirements now live at 21 CFR 820.10(c), which mandates compliance with ISO 13485:2016 Clause 7.3 and its subclauses. (Source: eCFR.)

ISO 13485:2016 Clause 7.3.10 defines the Design and Development File as the record set that must be maintained for each device. The FDA's QMSR final rule preserved the substance of the DHF obligation through this mechanism, so manufacturers still maintain what the industry calls a DHF, now understood in terms of ISO 13485 language.

The practical implication: if your current QMS was built around a DHF, you do not need to rename it. You do need to confirm your DHF contents satisfy ISO 13485 Clause 7.3 subclauses in addition to any FDA-specific requirements that carry forward under the QMSR supplemental provisions.

What Goes in the DHF?

ISO 13485:2016 Clause 7.3 identifies the records that must exist. Organized by function, a complete DHF typically contains:

Design and Development Plan (Clause 7.3.2)

Documentation of the development stages, review points, responsibilities, and interfaces between groups involved in the project. The plan should be updated as the design evolves.

Design Inputs (Clause 7.3.3)

The functional, performance, usability, safety, and regulatory requirements that the device must satisfy. Inputs should be reviewed and approved, with unresolved ambiguities resolved before output work begins.

Design Outputs (Clause 7.3.4)

The drawings, specifications, procedures, and other documents that define the device and its manufacturing and testing requirements. Outputs must be verifiable against inputs.

Design Reviews (Clause 7.3.5)

Formal documented evaluations of the design at planned stages. Reviews include participants who are independent of the function being reviewed, and the results and any required actions are recorded.

Design Verification Records (Clause 7.3.6)

Evidence that design outputs meet design inputs. This is the "did we build it right?" check. Verification is done by methods such as testing, inspection, analysis, or demonstration.

Design Validation Records (Clause 7.3.7)

Evidence that the device, as manufactured, meets the needs of the intended user and intended use under simulated or actual use conditions. This is the "did we build the right thing?" check. Validation must include testing of production-equivalent units.

Design Transfer Records (Clause 7.3.8)

Documentation that design outputs were correctly translated into production specifications. Transfer is the handoff point from development to manufacturing.

Design Change Records (Clause 7.3.9)

Records of all changes during design and development, including the rationale, reviews, verification, and validation activities performed, and approval before implementation.

Risk Management Records

ISO 14971:2019 risk management activities are typically referenced in or linked from the DHF. Risk files are often maintained separately but must be tied to the design record.

DHF vs. DMR vs. DHR: The Three Core Files

These three files are distinct and serve different purposes. Confusing them is one of the more common findings during FDA inspections.

File	Acronym	What It Contains	When It Exists
Design History File	DHF	Records proving the device was designed per an approved plan	Created during development; maintained through the product's commercial life
Device Master Record	DMR	The complete set of specifications and procedures for producing the device (drawings, BOMs, manufacturing SOPs, QC procedures)	Completed at design transfer; controls production
Device History Record	DHR	The record of production for each specific lot or unit (batch records, acceptance test results, labels used)	Created for each production run

Under ISO 13485:2016 language, the equivalent of the DMR is addressed through the Medical Device File concept in Clause 4.2.3. The medical device file is a broader record set that includes or references the device's regulatory information. Manufacturers who operate under both FDA and EU MDR requirements often align their medical device file to satisfy both frameworks simultaneously.

A simple memory anchor: the DHF is the design story. The DMR is the manufacturing blueprint. The DHR is the production proof.

Technical File vs. DHF: The EU MDR Parallel

If you are pursuing CE marking under EU MDR 2017/745 alongside FDA clearance or approval, you will also need a Technical File (Class I) or Technical Documentation (Class IIa, IIb, III). The technical file serves an analogous purpose to the DHF in the EU framework: it demonstrates conformity to the General Safety and Performance Requirements (GSPR) of MDR Annex I.

The overlap is substantial. A well-constructed DHF organized around ISO 13485 Clause 7.3 will supply much of what the EU technical file requires, but the EU documentation has its own structural requirements (Annex II and III of MDR) and typically requires a Summary of Safety and Clinical Performance (SSCP) for Class III and implantable Class IIb devices. Building your DHF with this dual use in mind saves significant rework at the EU filing stage.

DHF Organization and Common Gaps

There is no required folder structure specified by FDA or ISO 13485. In practice, two common approaches are used: a linear chronological file (records added as they are created) and a requirements-mapped file (organized by design control element with sub-sections matching the inputs, outputs, verification, and validation). The requirements-mapped approach tends to be more useful for auditors and inspections.

Common gaps found during FDA inspections and notified-body audits:

Incomplete traceability between design inputs and outputs (reviewers cannot confirm every requirement was addressed)
Validation performed on prototype units rather than production-equivalent devices
Missing review records with no indication of who participated or what decisions were made
Risk management records that are not linked to or referenced from the DHF
Change records that describe what changed but not why, and with no evidence of re-verification or re-validation when required

Where a DHF Sits in the Development Journey

When a device team is building or remediating their DHF, they are also in market: hiring regulatory consultants, evaluating quality management software, and researching submission pathways. The DHF is a foundational record in the broader new product development process, and it draws directly on your design controls, verification and validation, and risk management work. Buzzbox Media helps medical device companies make sure their information reaches buyers who are searching for exactly these topics. See our medical device marketing services for how content strategy and search visibility support your regulatory and commercial goals.