In this article you will learn tips and best practices for creating and maintaining your DHF (i.e., Design History File).
What is a DHF?
DHF is an acronym for design history file. The US FDA is the only country that specifically includes this in medical device regulations (i.e., 21 CFR 820.30j). Other countries simply require that you maintain records of design and development. The DHF is a file, virtual or physical, that includes all the records of your efforts to design and develop a medical device. You could create an index for a DHF that includes all of the most recent versions of the documents pertaining to the design of your device, but that is called a Device Master Record or DMR (i.e., 21 CFR 820.181). Another term for the DMR is “technical file” or “medical device file.” The FDA will be adopting the term “medical device file” as part of the Quality Management System Regulation (QMSR), and the definition for a DHF will become obsolete February 2, 2026.
What’s the difference between a DHF, DMR, and DHR?
The US FDA loves acronyms, but overuse of acronyms leads to confusion. The acronyms DHF, DMR, and DHR are the three most commonly confused acronyms in the medical device industry. One of the simplest solutions is to stop using acronyms and to rename each of these documents so that they are no so confusing. Instead of design history file, or DHF, start referring to this file as a record of new product development. That record consists of thousands of pages covering a year or more of design and development activity by your new product development team. Instead of device master record, or DMR, start referring to this as your medical device file or technical file. Clause 4.2.3 of ISO 13485:2016 is specific to this record. It is intended to be a living document that you will update each time you make a design change. Instead of device history record, or DHR, start referring to this as your batch record or lot record. This is a file containing all of the records, or cross-references to records associated with the manufacturing and inspection of a batch or lot of devices. The batch record or lot record will be reviewed for completeness, accuracy, and to ensure all inspection and testing passed. Often a release checklist is used to ensure consistency of this review, and the checklist will be signed and dated by the person that releases the batch or lot for distribution. For sterile products, this is done after sterilization and sterile product is quarantined until release.
Regulatory Requirements for a Design History File (DHF)
The requirements for a design history file (DHF) are found in 21 CFR 820.30(j):
“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.”
There is also a definition for a DHF found in 21 CFR 820.3(e):
“Design history file (DHF ) means a compilation of records which describes the design history of a finished device.”
The FDA provided an official interpretation of this requirement in the preamble when the QSR was published in 1996. That discussion of the requirement indicated that the DHF is intended to be a repository of the records required to demonstrate compliance with your design plan and your design control procedures. The discussion also indicates that the same DHF may be used for minor variations of a device such as size differences. Most manufacturers will organize the DHF in a binder and organize the binder chronologically to match a design project plan, however, most do not create a DHF template. Meeting minutes from each design meeting are typically included as an appendix to the DHF, while reviewed and approved documents such as the design plan, design inputs, design outputs and records of design reviews typically comprise the bulk of the DHF. Manufacturers also typically will conduct an internal auditor of active DHF binders in order to ensure that design projects are following the approved design plans.
Why you should never use a DHF template
The DHF is is intended to provide evidence of following an approved design plan, but the DHF consists of many records–not just one record. A DHF template could be created to follow a standardized design control process, but most manufacturers write a generic design procedure that allows and encourages the design team to customize the design plan to match the needs of each development project. Therefore, design plans may have different numbers of design reviews and very different testing activities prior to the start of the design transfer process and during design verification and validation.
For a device master record (DMR), I recommend creating a DMR Index using a template that is organized in accordance with an international standard to meet the needs of a DMR and a Technical File. The DMR is a living document that only shows the most current design outputs for a device while a DHF may require repeating various verification and validation testing if the initial design fails to meet acceptance criteria and a design change is required prior to the final design review and approval of commercial release. The need for including this variability eliminates the advantages of a template.
What is the purpose of the DHF?
The purpose of the DHF is to provide objective evidence that the design and development team followed design controls in order to develop a medical device. FDA inspectors review the DHF to make sure that the design process is effective by verifying that known hazards were identified, and appropriate design inputs (i.e., test requirements) were approved. The design specifications should demonstrate that risks were reduced as far as possible by implementing design solutions, protective measures, and by providing warnings and precautions of residual risks to users and patients. Verification of design inputs and validation of user needs comprise the bulk of your DHF in the form of testing protocols and reports. Inspectors will review your design transfer activities to ensure that the output of manufacturing consistently meets your design specifications. Design reviews meeting minutes will be sampled to verify that you included an independent reviewer and the design team completed all activities planned in your design plan. FDA inspectors will verify that your design team has adequate training on design controls and the relates processes. Finally, the FDA will look for justifications and updating of design documentation for the design changes your team made during the design process.
Where should you document design changes?
Product design changes that occur prior to the final design review and approval of commercial release are required for inclusion in the DHF. However, once a product is released the control over design changes should be tighter and regulatory submission of changes may be required. Therefore, I recommend documenting post-market design changes in the DMR Index for a device as part of the revision history. I treat the DMR Index as a controlled document and any post-market design changes are reflected in the revision history with a reference to the design change approval (e.g., ECN 123 – addition of UDI label to product labeling). The other advantage of this approach is that all post-market design changes that must be documented for a design dossier are summarized in the revision history of the DMR Index and the DMR Index will serve as a Technical File/Design Dossier.
Training Webinar
If you are interested in learning more about design history files, we recorded a DHF training webinar. The webinar explains how and when to create a design history file (DHF). After you create a design control procedure, you can show the recording of this webinar to your design and development team to ensure that design and development documentation is compliant and updates are efficiently maintained. We are in the process of updating this webinar and it will be hosted live in September.
Need to listen to DHF Structure recording!
Pingback: Software security, what is the best time to test cybersecurity? Medical Device Academy
Pingback: Design Plan Template- Medical Device Academy with Risk Management Medical Device Academy
Pingback: Procedure template for ISO ISO 13485:2016 quality systems Medical Device Academy
Pingback: Iterative design is real, waterfalls are illusions Medical Device Academy