The Design History File (DHF) is a collection of documents that outlines the design history of a medical device.
A DHF is one of the first documents that a regulatory body such as the FDA inspects for accrediting purposes.
The primary function of the DHF is to provide documented evidence that the device’s design phase is following the approved design plan and the component serves the user needs for which it is developed.
In this article, you will learn:
- What Is a Design History File (DHF)?
- How Does Design History File (DHF) Differs From Device Master Record (DMR), and Device History Record (DHR)?
- Design History File (DHF) Requirements
- What Must the Design History File (DHF) Include?
- Software to Manage Your Medical Device DHF
What Is a Design History File (DHF)?
A Design History File (DHF) shows the design history of a medical device.
It is used to provide evidence that all the design control procedures were appropriately applied and documented. Additionally, the design phase is as per the approved design plan.
It includes all the stages and processes through which a medical device’s design phase evolves and finalizes. A DHF is a regulatory requirement and must consist of user-focused attributes and requirements to fulfill user needs and expectations.
For example, a DHF for a medical device can include design inputs during a design plan. The design input can be a competitor analysis or the user experience from a similar product or job role.
A well-organized Design History File (DHF) is mandatory for medical device manufacturers for designing a product that best fits the end user’s requirement. Additionally, DHF is part of Premarket Notification – US FDA 510(k) by the manufacturers, requiring the manufacturers to notify FDA about their product at least 90 days in advance.
Consider using QMS software to maintain traceability of your Design History File (DHF) and manage your 510K submissions with ease.
How Does Design History File (DHF) Differs From Device Master Record (DMR), and Device History Record (DHR)?
DHF, DMR, and DHR are three major terms associated with medical devices and are sometimes confused with each other.
In reality, these terms are not similar and represent different product life cycle stages.
Design History File (DHF) represents all the steps and processes carried out during the design phase and acts as a basic guideline for developing a product. It could contain:
- User requirement specifications
- System architecture
- Software architecture
- Component drawings
- Risk analysis and risk assessments
- System tests
- Component tests
- Validation activities
Device Master Record (DMR) includes all the information necessary for manufacturing the designed product. It consists of design requirements and the production process. It also includes the equipment detail and the acceptance criteria, for example:
- Process and instrumentation (P&I) diagram
- Material of construction details
- Components details
- Manufacturing details
- Packaging details
- Shelf-life details
Device History Record (DHR) represents the production process of medical devices and must demonstrate the fulfillment of the Device Master Record (DMR). DHR is generally record-keeping and serves to track the production process. The DHR should be maintained for every lot or batch of a given medical device.
Examples of documents and records that could be included in a Device History Record (DHR) are:
- Production records, including manufacturing date
- Quantity manufactured
- Quantity released for distribution
- Acceptance records
- Non-conformance report in case of non-conformances or any abnormalities identified during the production process
- Lot number
- Serial number
By using the QMS software solution you can maintain the Design History File (DHF), Device Master Record (DMR), Device History Record (DHR) structure and have the same record reside in multiple structures (DHF, DMR, DHR) at the same time.
You can also easily make “snapshots” of your DHF and save all records at a given point in time to a Document Collection. Subsequently, you can export and share your DHF with relevant external agencies.
Design History File (DHF) Requirements
The following are some of the key requirements of the DHF that medical device organizations should take into account.
FDA Requirement
The Design History File (DHF) is one of the essential documents inspected by FDA inspectors during their audits. If DHF does not conform to the requirements, the FDA will re-inspect until the conditions have been met.
Some important requirements as per the FDA 21 CFR Part 820.30, subsection (j), regarding Design History File (DHF), are the following:
- The manufacturer should maintain a Design History File (DHF) for every type of medical device. However, it is not necessary to keep DHF for every device.
- The DHF should contain an approved Design Plan.
- The DHF should contain every document showing conformity with the approved design plan. The DHF can also refer to the original document if originals are not included.
ISO Requirement
There is no specific requirement of the Design History File in the international Society of Organization (ISO).
However, clause 7.3.10, “Design and development files” of the ISO 13485:2016, can be considered equivalent to the DHF.
Similarly to the FDA, this clause also requires the medical device manufacturer to:
- Develop design parameters (design plan) for every medical device type
- It should include all documents conforming to design requirements
Clause 7.3.10, “Design and development files” of the ISO 13485:2016 states 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.”
What Must the Design History File (DHF) Include?
The Design History File (DHF) must contain all the design elements during the product development stage. The DHF has been divided into sub-sections indicating different phases of a design process.
Below you can see design control phases and examples of documents and records applicable to each phase.
Design and Development Planning: Plans to ensure appropriate design development, with clear responsibilities. Before its application, the plan must be reviewed and approved.
During this phase flow diagrams or Gantt charts could be useful.
Design Input: The user requirements, forming the building block of a device design.
This could be, for example, software functional specifications.
Design Output: Document showing the device performance according to acceptance criteria laid down during the design Input phase.
This could include, for instance, drawing indicating device dimensions, connecting ports, and power outlet.
Design Review: Documented reviews of the design plan by all the functional representatives.
Design Verification: Documented evidence that device output meets the design input specification.
For example, Certificates for the material of construction.
Design Validation: Document showing that design specification meets the user’s needs and requirements.
An example is the validation report.
Design Transfer: It ensures that the design is accurately and effectively transferred into the product.
Design Changes: The appropriate procedure for a design change before its implementation.
A good example could be the Change Control Request form. It is a building block of the whole change management process.
Recommended Reading: Design Controls for Medical Devices
Design History File (DHF) for Software-Based Devices
For software devices and the hardware that incorporates the software, the requirements for the content of premarket submissions are laid down in the FDA document known as “Content of the Premarket Submissions for Software Contained in Medical Devices”.
This document applies to each software device delivered to the end-user, whether factory-installed, or through a third-party vendor, or upgraded version.
However, this guidance does not apply to the software that is not intended for use as a medical device.
For software, additionally, the following documents are also required:
- Level of Concern: It includes three levels, namely major, moderate, or minor. It indicates the software device’s effects on patients or operators.
- Software Description: Detailed software description including programming language, hardware platform, operating system (if applicable), use of Off-the-Shelf software (if applicable).
- Device Hazard Analysis: It includes any hazard associated with software or hardware device application. It should consist of Hazard identification, Cause, Severity, Control Method, Corrective measures, and Control Verification.
- Software Requirements Specification: It includes requirements for software to be installed appropriately, such as Hardware Requirements, Programming Language Requirements, and Interface Requirements.
- Architecture Design Chart: Description of the relationship between functional units in the form of a flow chart.
- Software Design Specification: It includes a detailed description of how the requirements of Software Requirements Specification are implemented.
- Additional documents include Traceability Analysis, Software Development Environment Description, and Verification and Validation Documentation, Revision Level History, and Unresolved Anomalies (Bugs or Defects).
Software to Manage Your Medical Device DHF
Often the manufacturers are overwhelmed by device design control challenges and overlook the necessary documentation, leading to missing documents and signatures. On the other hand, the regulatory bodies start with DHF to inspect and see whether the device manufacturers have the expertise to manufacture the device.
Digital tools, such as quality management software, are a worthwhile investment to help you ensure that inspections go smoothly.
A QMS software effectively streamlines the DHF and helps to maintain documentation during every stage of product development. From the initial design phase to final product approval, it can help prepare you to tackle challenges such as missing documents, review and approval signatures, and references between the necessary documents.
SimplerQMS provides you with tools to accelerate your product development following compliance requirements for life science organizations. The design control software module enables you to link the design and development documentation of each phase to its respective component. Design History File (DHF), Device Master Record (DMR), and Technical File (TF) can be easily maintained and sorted based on each product. SimplerQMS also allows the documentation to store in a single, centralized cloud-based system so that you can work location independently and access your documentation wherever required.
SimplerQMS allows you to concentrate more on design rather than spending time on planning documentation.
Final Thoughts
Design History File (DHF) inspection is the first step in the accreditation process, and for its success, it must be prepared and maintained from the very beginning.
Digital tools are an effective and proven way to deal with all the requirements of a DHF.
Although not a regulatory requirement, regulatory bodies also focus on and encourage the usage of digital tools such as SimplerQMS for DHF from preparation to final approval.
If you are interested to learn more about how our eQMS for medical device companies can help you with the creation and maintenance of your DHF, we advise booking a live demo to see SimplerQMS in action and have a discussion with our experts.
