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 in 2026. But that doesn’t mean the requirement is being dropped. Here’s what you need to know about the DHF and its ongoing importance in FDA compliance.

What is a Design History File (DHF)

The DHF is formal documentation currently specified by the FDA that must be prepared for each medical product, medical device or diagnostic your business develops and manufactures. The DHF can be either a collection of physical or digital documents generated in a product development process - or an index of documents and their storage location. The DHF is referenced as a requirement for medical device developers in FDA 21 CFR Part 820.30.

Defining the DHF

The FDA defines the DHF as follows:

FDA 21 CFR Part 820.30

"Design history file. 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 plan and the requirements of this part."

Hang on! Isn’t CFR Part 820 being replaced with the new QMSR?

Yes, it is. The QMSR is the new Quality Management System Regulation for medical devices that will harmonise the ISO 13485:2016 standard with FDA 21 CFR Part 820 from 2026.

And as the DHF is a requirement of FDA 21 CFR Part 820, it seems the references to the DHF will be dropped from the regulation.

But that doesn’t mean the requirement has disappeared. Because ISO 13485:2016 pretty much specifies the same thing in section 7.3.10.

ISO 7.3.10 Design and development files

"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."

DHF, DMR and DHR. Demystifying FDA medical device development requirements

So, you’ll still need to collate and publish a DHF for the FDA?

Whatever you call it (and many will refer to it as the DHF for years to come), the regulator will still demand to see the same collection of documents that demonstrate you have controlled your design and development process in the required way.

A DHF Checklist: what are the required contents of the DHF?

• Detailed design and development plans specifying design tasks and deliverables
• Approved design input documents
• Approved design output documentation
• Documents covering design reviews conducted
• Verification and validation documentation
• Copies of controlled design documents
• Design change rationale and records
• Documentation demonstrating the design was developed according to the approved design plan and regulatory requirements

The DHF should also provide a complete record of the following:

• Initial sketches and prototypes
• Material selection reasoning
• Testing protocols and results
• Failures and design iterations
• Preclinical work
• Validation and verification activities

The DHF records the way you have controlled your design and development process

Design controls describe an iterative, phase gated design process. They ensure regular reviews of a project’s progress against inputs like user needs, technical specifications and regulatory standards. They provide for the verification of designs against captured design requirements, and the validation of the finished product against user needs.

Common challenges of DHF compilation:

Many startups and SMEs are so focused on the design and development of their product that they only start thinking about how to meet the DHF requirements at the end of the project. At that point, though, trying to retrospectively piece together the necessary documentation can be almost impossible.

Indeed, the FDA say that gaps and omissions in the record of the design control process (and by extension the DHF) is a common cause of organisations failing audits and delaying their own paths to market.

If you don’t use a single dedicated digital platform to create and manage all your documents throughout a medical product design and development process - there’s a high chance that you won’t have everything you need to produce the DHF at the end.

These are common problems faced by organisations trying to put together a Design History File:

1. Missing documents and records

Documents that have been misfiled or otherwise mislaid can present a huge challenge to medical device developers as they attempt to pull together a DHF. This can happen where filing structures have sprawled across multiple platforms over time, and naming conventions are not consistent or adhered to properly throughout a process.

2. Documents and records without auditable version histories

Being able to link to and see a final, approved and date stamped ‘issue’ of a document is key to delivering a DHF. Using a document management system that does not automatically discriminate between ‘drafts’ and ‘issues’ of quality documentation can lead to confusion and misunderstandings about the history of changes made to a file and what represents the final and complete version. Having to trawl through multiple, mislabelled iterations of documents to demonstrate the history of its evolution is a time consuming and error prone process.

3. Missing review and approval signatures on documents

In regulated industries being able to absolutely prove when and by whom documents have been signed off is a requirement. Printed out and signed off paper documents are the way some organisations record these final approvals, but paper has a habit of going missing and can be challenging to digitise and retrospectively incorporate into a digital document management system. Read our blog for more information about integrating e-signatures into your FDA compliance documentation.

Choosing the right digital tools to meet the DHF challenge

A digital document management system (DMS) which allows you to map out and link to all the documentary requirements of each phase of a project within a single digital view is an excellent way to meet the requirements of the DHF.

Behind this digital view can be links to the documents themselves with a full, auditable history of each document.

These kind of DMS can help you define the necessary documents for an entire design and development process as templates that are then completed as you work through a required sequence of phase gates.

They can help you set up automated work-flows for their completion and approval by required stakeholders. With the ability to date and time stamp approvals as well as collect digital signatures, the right DMS can help your DHF prove that each step of a med tech project has been delivered in a compliant way.

The DHF as an organisational tool

The Design History File, therefore, can become not just the repository for all your design and development documentation, but the organisational tool that helps you manage its assembly. It can help you keep records of why, when and how design changes are made in real time.

In fact, Design History Files should be ‘living documents’ in just this way. They are not a bunch of files to be archived and forgotten about until an auditor turns up. As your product goes into production and is then subject to CAPA requests and further updates - the processes by which the need for future changes are documented and then implemented should continue to be recorded within the DHF.

Conclusion

The new QMSR may be dropping references to the DHF by name from 2026, but the requirement to document the design history of your device will remain.

If you continue to treat this Design History File as an integral part of your design and development process from the beginning, then these requirements will be easier to deliver at the end of the project and as the product changes and evolves.

At the same time, your approach to implementing and documenting the proper design controls can simply become ‘the way you do things’. In this way a DHF can be much more than a static record of what has gone before, it can become an easily repeatable template for future success.

Blog post updated on 17/09/2024