The medical device industry has a lot of acronyms.
The terms DHF, DMR, and DHR (which stand for Design History File, Device Master Record, and Device History Record, respectively) have had associations with design controls for some time now, but the similarity of letters in each respective name is enough to cause ongoing confusion among medical device professionals.
To make matters worse, these three aspects of design controls are quite closely related and share a lot of similarities. We’ve created this article to clarify the differences between DHF, DMR, and DHR. Let’s begin.
For two year's and counting, Greenlight Guru has been named a quality management software Leader according to G2 Crowd, based on high customer satisfaction scores and its large market presence.
DHF – Design History File
DHF stands for design history file.
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.
FDA 21 CFR Part 820.30 has some requirements regarding the DHF:
The design history file 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.
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 (MDQMS) 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.
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.
DMR – Device Master Record
The DMR is the device master record.
Everything you need to know to build and test the device is contained here.
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
Manufacturers have to ensure that they prepare each DMR in accordance with 21 CFR Part 820.40.
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?
Difference Between DHF and DMR
The difference between the DHF and the DMR is in that first letter – design vs. device.
The design history file is focused on capturing the history of the design and ensuring that it was done according to FDA regulation. The device master record 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.
DHR – DEVICE HISTORY RECORD
The DHR is the device history record. Everything you did to make the device is contained here.
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
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.
At Greenlight Guru, we created this article to help medical device companies stay compliant with FDA regulations so they can bring True Quality devices to market faster and improve the lives of patients who use them.
Greenlight Guru is the only quality management software designed specifically for the medical device industry. Our purpose-built platform comes out-of-the-box with automatic audit trails, full traceability between documents, and serves as a single source of truth for the contents of your DMR, DHF, and DHR.
Looking for a design control solution to help you bring safer medical devices to market faster with less risk? Click here to take a quick tour of Greenlight Guru's Medical Device QMS software →