DHF 101: What is a Design History File and How to Manage Yours

In the world of medical device development, the meticulous documentation of process evidence is key to regulatory compliance and bringing your product to market. That being said, due to its complex nature, many engineering and development teams jump into R&D without thoroughly considering documentation management first. While a lack of proper process evidence is not the only reason failed audits and recalls happen, it is a big one; and not knowing when an unannounced inspection may come can cause dread for even the most seasoned manufacturers. 

The best way to prepare for an inspection is to make sure that your process evidence is always audit-ready. A well-organized Design History File (DHF) goes a long way towards ensuring a smooth audit while preventing unnecessary delays, costly reworks, and recalls in the future.

Read on to learn more about design history files, what they should include, and best practices for putting yours together for a smooth compliance journey.

What is a Design History File (DHF)?

DHF stands for design history file, which can be easily confused with its counterparts the DMR (device master record) and DHR (device history record). To avoid any confusion, let’s start by clarifying what exactly a DHF is!

The DHF is a collection of documents that describe the evolution of a product’s design, as well as all the development activities that took place in the manufacturing of the device. The purpose of the DHF is to demonstrate that the medical device in question was created according to the approved manufacturing plan, and does indeed meet regulatory requirements. All this process evidence is what guarantees the product was created as per established quality standards.

It is one of the first documents that will be requested by a regulatory body like the FDA or ISO in order to check that your device is compliant. In addition, a DHF is required for premarket submissions by manufacturers.

FDA 21 CFR 820.30 requirements for the Design History File

The Design History File (DHF) is one of the first documents an FDA inspector will ask to see during an audit. If the DHF is disorganized or found lacking, it can delay the compliance process and even trigger re-inspection until the file effectively demonstrates that the device meets regulatory requirements.

According to FDA 21 CFR 820.30, sub-section (j): 

“Each manufacturer shall establish and maintain a DHF for each type of medical 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 regulations of this part.”

In other words, you need to create and maintain a DHF for every type of medical device you manufacture, but not every individual device itself, and this file should show that you followed the agreed-upon manufacturing plan and that you successfully met regulatory requirements.

ISO 13485:2016 requirements for the Design History File

Although FDA 21 CFR 820.30 and ISO 13485:2016 are by and large similar in some important aspects, the ISO does not explicitly require a Design History File. However, clause 7.3.10, “Design and development files” of the ISO 13485:2016 explains that:

“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.”

In sum, this clause similarly explains the need for a design history file and can be considered the equivalent to the FDA’s sub-section (j). Also, it’s important to note that the FDA is currently considering converging the requirements of 21CFR820 and ISO 13485. With a few modifications and clarifications, this will result in the creation of FDA QMSR (Quality Management System Regulation) which is expected to take effect one year after the final version is published, foreseeable in late 2022 or 2023.

What does a Design History File (DHF) need to contain?

The DHF should contain all the steps and procedures carried out through the design and development phase in order to manufacture a process. These steps are also known as design controls. 

As such, it doubles as guidance for developing the same or similar products in the future. It is typically divided into subsections with each one being dedicated to a different phase of the design process:

1. Design and development planning: This encompasses all the plans that you draw up to ensure effective development, as well as things like timelines, responsibilities, budgets, and more.
2. Design inputs: This is where user requirements come into play, including all the physical and performance requirements for this type of device.
3. Design outputs: These are all the engineering analysis, drawings, and models showing how the device performs. They should be traceable to design inputs.
4. Design review: This is a formal, documented review of the original design plan by all necessary stakeholders.
5. Design verification: This is evidence that the design outputs meet the design inputs specified earlier on in the process.
6. Design validation: This document, usually in the form of a report, shows that the design specification does indeed fulfill the user needs and requirements identified at the beginning of the project.
7. Design transfer: This demonstrates the transfer of the design onto the production, distribution, and maintenance of the product.
8. Design changes: This section documents the process for identifying and carrying out any necessary changes, and makes a record of them.

Since the DHF is a central repository for all the documentation generated by the design controls (and demonstrates that they were carried out correctly) it needs to be maintained and updated properly throughout the product life cycle. 

Fundamental best practices for assembling your DHF

Start right away and keep it up

Since documentation can be an overwhelming task, some teams postpone assembling the DHF until they’re already designing and developing. By that point, you’re sure to end up leaving something out. 

Start assembling your DHF in pre-design rather than creating it retroactively; adding documents and updating the DHF as you go along will go a long way to making sure it serves as comprehensive process evidence.

If in doubt, document it – but make sure it’s all relevant

The more information, the better. You can include anything from initial sketches to prototypes, testing protocols, and more – it just needs to be relevant.

Sometimes, companies end up including all sorts of information which isn’t actually appropriate and inspectors can pick up on that too, causing unnecessary questions and delays when it comes to audits.

Make everything traceable

A vital component of demonstrating compliance is traceability. Inputs must be traced to outputs and vice versa, change management must be carefully documented so that alterations can be tracked, and testing protocols and results must be traceable too. 

Also, without a comprehensive DHF, you cannot create other key documents for your design controls like your DMR.

Get yourself some tool support

If you’re still using paper-based processes, consumer-grade services, or perhaps legacy solutions, you may struggle to achieve the accuracy and traceability needed to achieve compliance.

A specialized, integrated digital platform will help make sure that all your documentation is organized, up-to-date, and accessible in a centralized repository of information.