Design History File (DHF)

The Design History File (DHF) is a compilation of documents to show that a medical device was properly designed and developed by following specific design control steps. To achieve this, a DHF describes the design and development activities in great detail.

FDA requirements

According to the Code of Federal Regulations Title 21 (FDA 21 CFR), Subchapter H – Medical Devices, Part 820 – Quality System Regulation, Subpart C – Design Controls, Section 820, the U.S. Food & Drug Administration (FDA) states the following about a DHF:

(j) 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.

ISO Requirements

According to the ISO 13485:2016 standard on Medical devices – Quality management systems — Requirements for regulatory purposes, there are no specific requirements for a DHF; however, ISO Clause 7.3.10 mandates the medical device manufacturer to fulfill similar requirements of what the FDA requires for a DHF. Therefore, this ISO mandate can be considered equal to the FDA requirement.

What are design controls? And how does the DHF establish the design control process?

FDA Section 820 .30 requires that all manufacturers of Class II and Class III devices, as well as those of some Class I devices (1) establish and maintain procedures to control the medical device’s design, and (2) ensure that all requirements are met as specified in the design. Hence, the DHF has to define all design elements during the product development stage. Further, the DHF needs to include sub-sections that indicate the different phases of the design process. The design control phases below show examples of documents and records applicable to each phase; this will help you understand which documents are required during each step:

Design and development planning

This includes a plan for your design so that your medical device can be developed in accordance with it. Flow charts and Gantt charts can prove helpful for this step.

Design input

This step includes established design inputs that address the intended use and user needs of the medical device. It also includes procedures on how to establish design inputs.

Design output

This includes procedures on how to define and document design outputs. Design outputs provide device performance that is compliant with the acceptance criteria that were defined during the last design input step.

Design review

This step includes procedures regarding managing all documents related to design reviews and the design review itself.

Design verification

This includes a document that defines your design validation process and the approved results of your design validation.

Design validation

This step includes procedures for design validation and the results of your design validation. Design validation document shows that your design specification meets the user’s needs and requirements, for instance, a validation report.

Design transfer

This includes documents for product specifications that are developed in compliance with this part and a description of the process used. This step ensures that the established design is properly and effectively transferred into the product.

Design changes

Every DHF includes a document for design change in case of any changes needed relating to medical devices. Changes can be conducted using a simple change control request form or a change control management system.

Design history file

The DHF is one of the design controls; however, it also plays a role to maintain records of all other design control parameters as a final step for the information generated by all other design controls.

Common pitfalls when compiling the DHF

Tackling the design control audits without any findings is not easy. However, it depends on how you understand and apply the key steps. Organizations can make mistakes, and those mistakes do not come cheap. Plus, it will be time-consuming to fix them. Here are the most common pitfalls of a DHF.

• • Not having a DHF when designing

Your DHF should contain all documents that are created during the product development phase of your new medical device. But it is crucial to generate those documents while you are designing the product, not after. Often, organizations rush to move the design control steps to get ready for mass production and enter the market as early as possible. That typically means they hope to compile the DHF later on, which can be due to a lack of understanding of what DHF outputs are required.

• • A disorganized DHF

This is as crucial as not having it at the right time. As you go through the design control steps, you will record the outputs of each design control step. Even if you do everything else as required, if you do not gather and organize the outputs, you will lose track of it all. This can happen more often to organizations that still maintain a paper-based quality management system (QMS): Missing files, plans, and reports without a signature, overdue actions – they all can lead to a possible finding if one of them disclose during an audit or inspection. A disorganized document management system can make it difficult to control, track, maintain, or manage changes and revisions. Scilife Document Control centralizes and categorizes all your company documents, so you can stop worrying about what’s where, what needs to be updated or approved, and who has access to what.

• • Including unnecessary documents

Making a bigger file than needed is exactly that – unnecessary. When starting, you may think that including as many files as possible in the DHF is a good idea. But keep in mind that you will keep DHF throughout the lifecycle of the product. Therefore, maintaining a file full of unnecessary documents will become more and more difficult, while also increasing the risk of being questioned by auditors. Auditors can take a bloated DHF as a sign of you not having enough knowledge or not having fully understood the idea of a DHF.

• • Authorization of compiling and maintaining the DHF

If you don’t have a digital document management system, you are likely to face problems when compiling and maintaining the DHF. Unmanaged documents – such as uncontrolled, outdated e-mail printouts, or a shared folder with read-and-write access – are bad signs of an ineffective document management system. This can lead to exponentially bigger problems and critical findings, rendering your DHF non-compliant.

• • No traceability to outputs

If outputs of the design control elements are not well documented, you do not have a proper DHF. The following step would be impossible, which is creating your DMR!