Understanding FDA Medical Device Development Requirements: DHF, DMR, DHR

DHF, DMR, DHRDHF, DMR, DHR… to the uninitiated they might sound like out-of-town furniture stores or airport codes for exotic destinations but they are, in fact, key acronyms in the world of medical device regulation.

DHF, DMR, DHR. What do they mean?

Good question. They are all abbreviations used by the FDA in their medical device quality regulation. DHF stands for Design History File, DMR stands for Device Master Record, and DHR stands for Device History Record. 

Download the eBook: Building a Design History File with Cognidox

But, what are they for?

They are the required collections of documents that medical device developers must assemble and make available to auditors to prove compliance, gain FDA approval, and market their devices in the US.

What’s the difference between the DHF, DMR and DHR? 

The Device Master Record (DMR) can be thought of as the definitive instruction manual for the compliant manufacture of your medical device, while the Design History File (DHF) is the complete record of the way that instruction manual was designed and compiled in the first place. The Device History Record (DHR), on the other hand, is the demonstrable proof that you have followed that instruction manual as you have manufactured your device.

DMR (Device Master Record)

DHF (Design History File)

DHR (Device History Record)

An ‘instruction manual’ for manufacturing your medical device

Proof the ‘instruction manual’   was compiled correctly

Evidence you have followed those instructions correctly

  Includes:

  • Design specifications
  • BOMs
  • Production Processes
  • Equipment specifications
  • Packaging and labelling specifications
  • QA procedures
  • Maintenance and servicing procedures
  • Acceptance Criteria

  Includes:

  • Design and development plans
  • User Requirements
  • Design inputs
  • Design outputs
  • Design review records
  • V&V requirements
  • Design verification results
  • Change control & CAPA records

  Includes

  • Acceptance records
  • Product/component IDs
  • Material Lots
  • Production records

What is the Design History File (DHF)?

The Design History File is a repository for all the records that demonstrate your medical device was designed and developed in accordance with an approved design plan.

The DHF can be either a collection of the actual paper documents generated throughout a product design and development process or a central index of documents and their storage location within a digital DMS (document management system).

As the name suggests, the DHF is focused on the history of the design, ensuring it was carried out according to the FDA regulations. The requirement is found in (21 CFR Part 820.30)

“Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plans and the requirements of this part.”

ISO 13485:2016 refers to this requirement as well, making explicit reference to ‘a design and development file’ that must be created for each medical device.

Importantly, ISO notes that the DHF should record details of all the changes made to the design during the planning and development process.

“The organization shall maintain a design and development file for each medical device type or medical device family. This file shall include or reference records generated to demonstrate conformity to the requirements for design and development and records for design and development changes.”

Tracking the history of change requests as well as the details of their approval, implementation, and review is one of the key objectives of regulation in this sector. After all, most faults with a manufactured device can be traced back to a failure of the change control process in its conception and design. The self-policing of these standards through better documentation and process implementation is an essential part of the FDA’s push for a more proactive approach to quality management.

To this end, the DHF should contain:

  • The design and development plan that specified design tasks and deliverables
  • Documentation which proves the design was carried out according to the design plan
  • Activities of the different phases of the specific design process
  • Documentation of design reviews
  • Approved design input and output documents
  • Validation documentation
  • Copies of controlled design documents and change control records

What is the Device Master Record (DMR)?

If the DHR shows in detail how the final ‘instruction manual’ for the device was compiled, then the Device Master Record is the instruction manual itself. 

In other words, it contains all the information needed to produce the device safely, in accordance with the design and the regulation that covers it.

Section 820.181 of the FDA QSR is quite specific about what the device master record should contain. It includes:

  • Device specifications
  • Production process specifications
  • QA procedures and specifications 
  • Acceptance criteria
  • Packaging and labelling specifications
  • Details for installation, maintenance, servicing procedures and methods

What is the Device History Record (DHR)?

The DHR is the final proof that you have used the ‘instruction manual’ (DMR) and followed the instructions it contains to manufacture the device correctly.

The FDA specifies that your Device History Record must include:

  • A date of manufacture for each batch, lot or unit
  • The quantity you have manufactured
  • Quantity released for distribution
  • Labeling used for each production unit
  • Any UDI, UPC, or other identification used

The DHR must also include your acceptance records, which show that you have followed and implemented all of the processes outlined in the DMR in a compliant way.

What’s the best way to build your DHF, DMR and DHR?

‘Backsolving’ many of these document requirements can be difficult or even impossible for developers. Retrospectively pulling together the right files and grouping them in different digital locations for review can take a long time, ultimately leading to confusion and dangerous duplication. 

This is a particular problem when the files themselves change as you evolve your processes and implement corrective actions. The FDA need the DHF and the DMR to show the latest, approved versions of all the documents you use to design, build and product manage your device, plus the history of all your decision making all in one place.

To meet these demands choose an eDMS (electronic document management system) that lets the same files exist and be updated simultaneously in different parts of the system.  

Choose an eDMS that lets you:

  • Define the contents of these critical files at the start of your project, 
  • Automatically populate them with approved content as your project progresses
  • Update them, subject to required version and change controls
  • Make a full audit history of every document available in each file
  • Make the latest approved version of each file (DMF, DMR or DHR) available to auditors - on demand

Conclusion 

Each of the three Ds of medical device development has a different function within the regulatory scheme of the FDA. They are outputs that, taken together, prove complete compliance in each phase of the development and manufacturing process

Using the right DMS will allow you to digitise the production and audit of these three critical review items.  It will save you time, money and stress as you design, manufacture, and manage your device in the future.

New call-to-actionLast updated on 01/06/2022

Tags: Medical Device Development, FDA Compliance

Joe Byrne

Written by Joe Byrne

Joe Byrne is the CEO of Cognidox. With a career spanning medical device start-ups and fortune 500 companies, Joe has over 25 years of experience in the medical device and high-tech product development industries. With extensive experience in scaling businesses, process improvement, quality, medical devices and product development, Joe is a regular contributor to the Cognidox DMS Insights blog where he shares expertise on scaling and streamlining the entire product development cycle, empowering enterprises to achieve governance, compliance, and rigour.

Related Posts

What’s the best eQMS software for medical device developers in 2025?

There are many eQMS platforms out there that have been helping medical device developers bring ...

A Guide to Compiling a DHF for Medical Device Development

The FDA’s new QMSR is dropping the reference to the DHF (Design History File) when it takes effect ...

Demystifying Medical Device Audits: Requirements, Process, and Impact

Medical device audits can be a source of stress for developers and manufacturers. But what exactly ...

What are the FDA's requirements for CAPA (Corrective and Preventive Action)

Having a repeatable procedure for Corrective and Preventive Action (CAPA) is a key FDA requirement ...

Understanding FDA 21 CFR Part 11: A Guide for Life Science Developers

WTH is FDA 21 CFR Part 11? That’s a question many life science developers wanting to access the US ...

5 Challenges in Building a Pharmacovigilance System Master File

Managing the integrity and accessibility of a PSMF (Pharmacovigilance System Master File) is a key ...