Design History File (DHF) vs. Device Master Record (DMR) vs. Device History Record (DHR): What's the Difference?

DHF, DMR, and DHR are three record sets that FDA's Quality System Regulation required of every medical device manufacturer, and the industry still often uses the names. The design history file (DHF) records how the device was designed and proves the design followed the plan. The device master record (DMR) is the recipe: every specification, drawing, procedure, and acceptance criterion needed to build, test, package, and service the device. The device history record (DHR) is the proof that each unit or lot was actually built to the DMR. Since February 2, 2026, FDA's Quality Management System Regulation (QMSR) has incorporated ISO 13485:2016 by reference, and the three names no longer appear in 21 CFR Part 820. The records themselves are still required; ISO 13485 calls them the design and development file, the medical device file, and production and traceability records.

What's a Design History File (DHF)?

A design history file (DHF) is the compilation of records that shows how a medical device was designed and that the design followed the approved plan.

As you go through the design and development process for your medical device, the documentation that you create will be contained in your design history file, commonly abbreviated as DHF. 

Under the Quality System Regulation, 21 CFR 820.30(j) defined the DHF as the file that "shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part." That definition is still the clearest statement of what a DHF is for, and ISO 13485:2016 clause 7.3.10 requires the same records as the design and development file.

This means that any material proving your device is compliant should be included in your DHF. Auditors and inspectors will check your DHF to verify compliance, so keeping your design history files well organized in an industry-specific medical device QMS is essential.

As a device maker, you'll need to maintain a separate design history file for each type of device you develop. While this is straightforward in theory, things can get messy if you don't consolidate and organize as you work. 

Trying to build out your DHF after the fact makes organizing your documents harder. Instead, treat your DHF as a living document that you update throughout the design and development process of your device. 

You need to include or provide a reference to all of the records related to the activities that took place during design and development.

What Belongs in the DHF?

Here are the specific documents that you should include in your DHF:

• User needs and design inputs you defined at the start of the project

• Design outputs that you generated to build the device

• Design verification and validation protocols and reports 

• Design reviews associated with user needs, design inputs and outputs, and design verification and validation protocols

• All materials relevant to design transfer into manufacturing

Managing DHF with Paper-based Quality Systems

If you're using a paper-based QMS (quality management system) or "digital paper" approach, maintaining and compiling the DHF is going to be cumbersome. A DHF can take up several binders of physical documents with paper systems, or span hundreds of rows and columns across multiple Excel workbooks with digital paper solutions. Finding any individual document or adding a new one after the fact will be slow and tedious.

These ad hoc systems also make it easy for documents to get lost, duplicated, or mixed up alongside outdated versions. Establishing traceability between documents in a DHF using these legacy systems is not just challenging, it's nearly impossible. Simply put, great companies don't run on spreadsheets.

Managing DHF with Medical Device Quality Systems

A purpose-built QMS solution can save teams a considerable amount of time, serving as the guardrails to prevent mistakes from happening throughout the design and development process.

^{Greenlight Guru QMS Multi-level Design Control Software}

Full traceability of all connections between user needs, design inputs and outputs, verification and validation, and design reviews is simplified with an eQMS that provides a clear, well-designed user interface and experience for teams. 

Digital documents are easy to locate when they're stored within one single source of truth, meaning you get to spend less time searching for them and waste no time duplicating them. The process of accessing and compiling the DHF takes far less effort than it does on paper.

What's a Device Master Record (DMR)?

A device master record (DMR) is the complete set of specifications, procedures, and instructions needed to build, test, package, and service a device. If the DHF is the story of the design, the DMR is the recipe for the product.

According to the FDA, the DMR for each type of device should include or refer to the locations of the following pieces of information:

(a) Device specifications, including appropriate drawings, composition, formulation, component specifications, and software specifications

(b) Production process specifications, including the appropriate equipment specifications, production methods, production procedures, and production environment specifications

(c) Quality assurance procedures and specifications, including acceptance criteria and the quality assurance equipment to be used

(d) Packaging and labeling specifications, including methods and processes used

(e) Installation, maintenance, and servicing procedures and methods

Under the QSR, 21 CFR 820.181 required a DMR for each device type, prepared and approved under document controls. ISO 13485:2016 clause 4.2.3 carries the same requirement forward as the medical device file.

Some parts of this process will sound familiar to what you compiled in your DHF. The device specifications and packaging and labeling specifications, for example, were part of the design outputs you created in that process. 

The production process specifications were part of the design transfer you did earlier as well. Even the quality assurance procedures and specifications were part of the DHF process, because those include your defined acceptance criteria, which is part of design outputs.

The good news is that FDA requires you to only reference the mandated items, not duplicate them. If you've been organized in creating your DHF, you'll be able to easily reference that location in your DMR. 

As you can see, DHF and DMR are similar in many ways, so what's the difference? 

DHF vs. DMR: What's the Difference?

The difference between the DHF and the DMR is in the first letter: design vs. device. 

The design history file (DHF) is focused on capturing the history of the design and ensuring that it was done according to FDA regulation. The device master record (DMR) is focused on building the device and ensuring that all necessary items are included to build, test, package, and service it.

Now that you've designed the device (DHF) and have the recipe to build and test it (DMR), it's time to make the device. That's when the DHR comes into play.

What's a Device History Record (DHR)?

A device history record (DHR) is the production record for a specific unit, lot, or batch. It proves that the device was manufactured according to the DMR, and it is the record a manufacturer pulls first when a complaint or recall investigation starts.

According to FDA, the DHR should include, or refer to the location of, the following pieces of information:

(a) The dates of manufacture

(b) The quantity manufactured

(c) The quantity released for distribution

(d) The acceptance records, which demonstrate the device is manufactured in accordance with the DMR

(e) The primary identification label and labeling used for each production unit

(f) Any unique device identifier (UDI) or universal product code (UPC), and any other device identification(s) and control number(s) used

Manufacturers should establish procedures that maintain the DHRs for each batch, lot, or unit. This demonstrates that the device is manufactured in accordance with the DMR and requirements from FDA.

Think of it this way: the device history record is literally the history of the device. The history and information related to how you made the device, in accordance with the DMR, is stored in the DHR.

Similar to how the DHF is the history of the design, the DHR is the history of the device.

DHF vs. DMR vs. DHR

One DHF and one DMR per device type; one DHR per unit, lot, or batch.

While these three abbreviations may seem confusing when you first hear them, knowing the meaning and purpose of each will help you identify what's needed for these processes:

• DHF: Design History File

• DMR: Device Master Record

• DHR: Device History Record

Thinking of it sequentially is a helpful trick. You start with the history of the design. This leads to the record of how to build and test the device, which then leads to the history of the device you made.

Many people get turned around with whether the "D" stands for "device" or "design." Think of it like this: design goes in a file, but the device has an entire record. If you think of the acronyms in these terms, you'll remember that the "R" at the end is device-related rather than design-related.

What the QMSR changed for the DMR, DHF, and DHR

The Quality Management System Regulation (QMSR) replaced the Quality System Regulation (QSR) on February 2, 2026. It incorporates ISO 13485:2016 by reference, so 21 CFR Part 820 now points to the international standard for medical device quality management systems instead of restating its own requirements.

The Final Rule amending the QSR has been published, and if you read the rule, one thing you may notice is that the terms Device Master Record, Design History File, and Device History Record do not appear in the QMSR. This is because ISO 13485:2016 doesn't use these terms, instead bundling their record-keeping requirements under the umbrella term Medical Device File (MDF). 

FDA removed the DMR, DHF, and DHR terms because, in its words, "the elements that comprise those records are largely required to be documented by ISO 13485, including Clause 4.2 and its subclauses, and Clause 7 and its subclauses." Keeping both sets of names would have been redundant, so only the ISO 13485 terms appear in the QMSR.

What's important to remember here is that this change does not affect the record-keeping that the regulations require. The language is changing, but the requirements for record-keeping in ISO 13485 are substantively similar to those in the QSR, and FDA expects that the regulatory burden will remain essentially the same. 

Many companies still use DMR, DHR, and DHF internally now that the QMSR is in effect. That is fine, as long as your procedures define what each term contains and your team can point an inspector to the matching ISO 13485 records.

To learn more about how QMSR is impacting these terms, read our comprehensive article, QMSR & the End of DMR, DHR, DHF.

DHF, DMR, and DHR: common questions

What is the new term for DHF?

Under ISO 13485:2016, and therefore under FDA's QMSR, the records that made up the design history file live in the design and development file (clause 7.3.10). Many companies keep using "DHF" internally, and that is fine as long as procedures define what it contains.

What is the difference between DHF and DHR?

The DHF is the history of the design: it shows how the device came to be what it is. The DHR is the history of the device: it shows how a specific unit, lot, or batch was built and released. One is created during development, the other during manufacturing.

Do I still need a DHF, DMR, and DHR under QMSR?

You still need the records; you no longer need the names. The QMSR incorporates ISO 13485:2016, which requires the same design, manufacturing, and production evidence under its own terms, and FDA has said it expects the record-keeping burden to stay essentially the same.

Have confidence in your compliance with Greenlight Guru

We wrote this article because staying up-to-date with the latest regulations and best practices in the MedTech industry isn't always an easy task. And at Greenlight Guru, our goal is to help medical device companies stay compliant while getting the highest-quality medical devices to market.

With Greenlight Guru Quality, design controls, the device file, and production records are connected in one purpose-built QMS software aligned with the QMSR, ISO 13485:2016, and ISO 14971:2019, so the traceability an inspector asks for already exists.

Ready to see how Greenlight Guru Quality can help you ensure compliance and make your next audit a breeze? Get your free, personalized demo today →

Looking for a design control solution to help you bring safer medical devices to market faster with less risk?  Click here to get your free demo