DHF. DMR. DHR.
It’s bad enough that medical device product development has a whole slew of new terms to learn as part of design controls, but to make matters worse, there are three different terms that seem to have basically the same acronyms.
Just by changing a letter, you can go from DHF to DMR to DHR.
To make matters worse, these three terms have a lot of similarities.
No wonder it’s hard to figure out what documents belong where.
Let’s start at the beginning.
DHF – Design History File
The DHF is the design history file.
As you go through the design and development process for your medical device, the documentation that you create is going to be contained here.
According to the FDA, 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 (21 CFR Part 820.30). Each manufacturer shall establish and maintain a DHF for each type of device.
The actual idea of the DHF is fairly straightforward. In practice, that can be a bit of a challenge if you don’t compile it as you go.
You need to include or provide a reference to all of the records related to the activities you did during the design and development process.
That means you need all of the user needs and design inputs you came up with at the start of the project.
All of the design outputs that you generated to build the device.
All of the design verification and validation protocols and reports.
Plus, all of design reviews that went along with all of that…and don’t forget everything for transferring the device to manufacturing too.
If you’re using a paper-based QMS, you’re going to need to get a really big binder – or two.
Once you’ve gotten all of those documents compiled into your DHF, the next acronym that needs to be tackled is the DMR.
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 shall include, or refer to the location of, the following 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; and
(e) Installation, maintenance, and servicing procedures and methods.
Each manufacturer shall ensure that each DMR is prepared and approved in accordance with 21 CFR Part 820.40.
Some parts of this should sound a lot like what you just got done compiling in the DHF.
The production process specifications were part of the design transfer you did earlier as well.
Even the quality assurance procedures and specifications were created earlier, because those include defining the acceptance criteria which is part of design output.
The good news is that the FDA only requires you to reference the required items, not duplicate them.
If you were really organized in the creation of your DHF, it’s going to be really easy to reference that location in your DMR.
The difference between the DHF and the DMR is in that first letter – design vs. device.
The DHF is focused on the history of the design and ensuring it was done according to the FDA regulations.
The DMR is focused on the device and ensuring you have all of the necessary items 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 actually 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 the FDA, the DHR shall include, or refer to the location of, the following 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; and
(f) Any unique device identifier (UDI) or universal product code (UPC), and any other device identification(s) and control number(s) used.
Each manufacturer shall establish and maintain procedures to ensure that DHR's for each batch, lot, or unit are maintained to demonstrate that the device is manufactured in accordance with the DMR and the requirements of this part.
The device history record is literally the history of the device.
Everything that you complied in the DMR was used to make the device.
The history and information on how you made the device in accordance with the DMR is stored in the DHR. Much like the DHF is the history of the design, the DHR is the history of the device.
DHF vs. DMR vs. DHR
While these three acronyms can see confusing and easily interchangeable when you first hear them, if you look at the actual terms, they’re surprisingly descriptive.
DHF - Design History File
DMR - Device Master Record
DHR - Device History Record
You start with the history of the design, which leads to the record of how to build and test the device, which leads to the history of the device you actually made.
If you’re like me, the part you mix up the most is when the D stands for design vs. device.
I keep them straight by remembering that I need a file for the design and a record of the device.
When I see the R at the end, I know it’s device related.
Hopefully that simple trick will help clear up any lingering confusion.
Written by Jesseca Lyons
Jesseca Lyons is a Customer Success Expert at greenlight.guru and a Mechanical Engineer by trade who loves working with cross functional teams, including both engineering and non-engineering disciplines. She’s spent most of her career gathering and defining requirements for new product design and development in the medical device industry. She believes the best part of being an engineer and working at greenlight.guru is that she can use her skills to help customers and make a positive impact in their lives. Click here to get our actionable medical device content delivered right to your inbox 1x per week.