Everything you need to know about Design History Files (DHF)

One of the most important things a medical device company can do to help bring products to market quickly is to stay organized. If your team isn't organized, you risk hurting product quality, not passing an audit and slowing production. Proper documentation is vital to organization, and, during the product design phase, that means creating and maintaining your Design History File (DHF).

What is a Design History File?

A DHF is a record of all the actions and steps involved in designing a medical device. The documentation that comes out of design control procedures is collectively called the “Design History File” or DHF.

Design Controls

Prior to starting development, manufacturers must develop a design controls process. Design Controls refer to actions taken by a manufacturer to control the design and development of a new medical device. Under a robust design controls process, the initial device that was intended to be designed should match the final design without any variation (unless documented).

Design controls processes must be completed according to the requirements outlined in the FDA’s 21 CFR Part 820.30 and ISO 13485:2016. Most manufacturers develop a set of procedures on how to follow design controls and how to document decision making throughout the development process. 

DHFs and audit readiness

During an FDA audit, the auditor will examine each medical device’s DHF. The auditor reviews these documents to ensure the device was developed through a design controls process. Additionally, the auditor will review internal procedures to ensure they meet FDA regulations. A DHF and fully documented procedures provide the FDA with the assurance that the device was developed properly and is safe for market. 

Note: Each device needs its own DHF and each DHF will be revised during any changes to the design. A DHF can be an actual file that contains each needed component or, with an eQMS for medical device companies, it can be a document that has a link to each part.

What should be in a DHF?

For a DHF to be comprehensive, there are certain components that must be included. These are:

Design Plan

A Design Plan is an overview for the medical device design and product development that outlines all activities necessary to conceptualize and create the proposed product. The Design Plan will specify details like who is responsible for implementing each step and the order of implementation. Additionally, the Design Plan will describe how the responsible parties will interact throughout the design process and when they will meet. 

User needs

User needs refers to the parameters a user needs for a device to be successful in the market. User needs can come from end users, regulators, and manufacturers’ desires. Typically user needs are more broad and the specifics feed into the design inputs. For example, a User Need could be “designed for use in pediatrics.” To meet that User Need, the manufacturer will develop a series of design inputs that will make the user need “pediatric use” possible.

Design inputs

Design inputs are specific physical requirements for the device. The DHF must include documentation that lists all of the design inputs. Design inputs are developed from user needs and the intended use of the device. In the pediatric example, design inputs to meet the user need for pediatric use could include specifications for a smaller patient, color choices to make the device more appealing to children, or weigh less than 3 pounds to be easily held by children. 

Design outputs

The outcome of a Design Input is the Design Output. In the pediatric example, a Design Output from the Design Input to make a lighter design could be to utilize plastic components. The Design Output would be all the components that are plastic to help ensure the device remains lightweight. The design outputs tell the story of how to make the device. Eventually the design outputs become the basis for the Device Master Record (DMR). The DMR is used to transition the device to a manufacturing floor..

Design review

Throughout the design process, a group of cross-functional stakeholders will need to meet to review the DHF. These meetings are called design reviews. They must be documented with minutes recorded. In this meeting, the stakeholders will review the design and make a decision about moving forward with the development of the product. The decision must be documented as part of the DHF.

Design verification

Design verification refers to all testing done to ensure that the design inputs meet the design outputs. All parameters identified in the design inputs must be tested to ensure they are met by the design outputs. In the pediatric example, the design verification might be a test that weighs the pediatric device. The acceptance criteria could be “the product must weigh less than 3 pounds.” The design is verified if all design inputs are met by the design outputs. The technician who performs the testing must document when the testing was performed, what methods were used, and the results.

Design validation

Design validation refers to all testing done to ensure the user needs are met by the final finished medical device. This type of testing will prove that the intended use is appropriate and there is a clinical use for the device. In the pediatric example, the design validation would test whether the device can be used for pediatric patients. Design validation is often animal testing or human clinical trials.

Design transfer

Design transfer outlines how the designed device is translated into production specifications. Some manufacturers use a design transfer checklist to ensure they’re capturing all steps for design transfer to production.

Design changes

Medical devices iterate and change throughout their lifecycle. The FDA and other regulators are aware and recognize that medical devices will go through changes. All design changes must be documented using a design change process and documented the rationale for the change.

Design History File vs. Device Master Record vs. Device History Record

Design History Files, Device Master Records (DMR), and Device History Records sound similar, but are separate forms of documentation that represent different stages of the medical device development process.

The DHF and DMR are like a medical device recipe and contain all of the information that’s needed to actually make the device. The DHF contains all of the specifications, materials, and data of the finished medical device. During development, all documentation about design is stored within the DHF. The DMR identifies the manufacturing steps and processes used to make the device. Once design outputs are being evaluated, documentation is stored within the DMR.

The Device History Record (DHR) keeps the records of production. The DHR contains documentation of every batch, lot, and unit made, as well as the date and time of manufacturing. The DHR includes each device that was made according to the DMR. If a customer complaint comes in, manufacturers use the DHR to determine what batch was affected and will alert other customers if it affects the batch.

DHFs for software in medical devices

The FDA recognizes that software in medical devices and as a medical device (such as firmware controlling a device, standalone software applications, and software installed on a computer) cannot always follow the traditional medical device regulatory pathways and DHF structure. 

For software in medical devices and as a medical device, DHF documentation will need to include the following:

Level of concern

Level of concern is an FDA term that defines the risk associated with the software. There are three levels of concern: major, minor and moderate. Manufacturers must determine the device's level and document the justification for level of concern. The FDA provides guides and definitions to guide manufacturers through this exercise. 

Software-related documentation

Software-related documentation includes the design of the device, how to implement that design, how the device was tested, how any potential hazards were identified, risk management practices, and provides traceability.

Device hazard analysis

Device hazard analysis refers to a software-related risk documentation. This document includes all software or hardware hazards, including how severe those hazards are and any mitigations that were taken.

Software requirements specification

This document is very similar to the design inputs document, but for software. The software requirements specifications define the requirements for installing the software properly and using the software. This could include hardware requirements, programming language, software performance, and other requirements. The level of detail required in this document is dependent on the level of concern.

Architecture design chart

If your device is a minor concern, no documentation is needed here. For moderate- and major-concern devices, you’ll need detailed diagrams and/or flowcharts of the functional units and software modules.

Software design specification

Again, for minor-concern devices, there are no requirements needed. Moderate- and major-concern devices will need to submit how the software requirements’ specifications are implemented.

Traceability analysis 

Because every input requirement and specification of a medical device requires an output, the FDA requires documented traceability between the requirements and outputs. The FDA recommends showing this through a matrix with line items.

Software development environment description

This is a requirement only for moderate- or major-concern devices. Software development environment is a “summary of the software development life cycle plan,” according to the FDA. With major-concern devices, an annotated list of control documents created during the development process and a list of coding standards will be included in this document.

Verification and Validation (V&V) documentation

All software related devices will need to have documented protocols with identified pass/fail criteria and corresponding reports. For devices with moderate and major levels, it’s recommended to list all V&V activities, results, and pass/fail criteria. In addition, the traceability analysis must identify how these are linked to the design requirements.

Revision level history

You can log revision level history as a line item sheet that outlines each revision to the software during development and include the date, version number, and description of the changes.

Unresolved anomalies

Manufacturers must document all unresolved software anomalies only for devices with moderate and major levels of concern. Indicate each activity, the impact to device performance, and the timeframe for correcting the problem. The FDA recommends an explanation for how each anomaly could impact the device’s effectiveness and safety.

Of note, the FDA points out that “software not covered by this guidance includes software designed for manufacturing or other process-control functions, but not intended for use as a device.”

How to prepare your DHF for an FDA Audit

Manufacturers who don’t maintain their documentation properly are unprepared for an audit. Poor documentation practices typically result in longer audits, with more findings, and a poor relationship with FDA. All of these things can be costly and resource intensive.

To be audit-ready when the FDA comes to visit, start the documentation process early. Begin preparing the design history file early in the design process to ensure it is accurate and captures all design discussions.

Create procedures that identify how to document design and development activities. Utilize forms or templates to ensure DHF harmony between other devices in the portfolio. Procedures, work instructions, forms, and templates are all good ways to standardize documentation activities and ensure they are part of the company’s culture. 

Keep your DHF organized with an eQMS

Finally, one of the most effective ways to prevent having to scramble during an FDA inspection, is to utilize digital documentation methods for the DHF, DMR, and DHR. Using a paper-based system is cumbersome, and it takes longer to locate documentation. Storing your DHF and other documents in a cloud-based quality management system (eQMS) means everything will be in one place, organized, and easy to update.

An eQMS can help you maintain documentation at all phases of the design process, providing traceability between input requirements and output results. With features like document templates and revision control, you’ll be able to see how your documentation changes over time and easily identify when updates are made.

By using a quality management system designed purpose-built for medical device companies, manufacturers can store and maintain DHFs in software designed with regulatory compliance top of mind. Qualio’s quality management platform is made to scale with medical device startups and has built-in features and templates to help manage and accelerate the product development process.

Need more help? Qualio’s experts are available to consult through Qualio Plus. Contact us today for a free demo.