How to Build a Submission-Ready Design History File (DHF)

For manufacturers preparing for FDA submissions—and increasingly for companies pursuing multiple global markets—the quality and traceability of design and development documentation can directly affect submission readiness.

What Makes a DHF Submission-Ready?

A submission-ready DHF should allow a regulatory reviewer, auditor, or internal quality team to follow the development of the device without having to reconstruct the story.

The documentation should establish clear relationships among:

• User needs and design inputs
• Design outputs and specifications
• Risk management activities
• Verification and validation
• Software development, where applicable
• Cybersecurity activities, where applicable
• Human Factors and usability engineering
• Design reviews
• Design changes
• Traceability throughout the development lifecycle

The objective is not simply to have the documents. The records need to be complete, controlled, consistent, and connected.

What Should a Submission-Ready DHF Include?

The exact documentation will depend on the device, technology, risk profile, development process, and regulatory pathway. In general, design and development records may include:

• Design and development plans
• User needs and design inputs
• Design outputs and product specifications
• Risk management files and supporting analyses
• Verification protocols and reports
• Validation protocols and reports
• Software lifecycle documentation
• Software verification and validation records
• Cybersecurity documentation
• Human Factors and usability engineering documentation
• Design review records
• Requirements and traceability matrices
• Design transfer documentation
• Design changes, assessments, and approvals
• Supporting records demonstrating appropriate review and authorization

For Software as a Medical Device (SaMD), AI-enabled technologies, and connected medical devices, software lifecycle, cybersecurity, configuration management, and related documentation require particular attention. These activities should be integrated into development—not treated as documentation exercises performed immediately before submission.

Traceability Is the Backbone of a Strong DHF

One of the clearest indicators of design control maturity is traceability.

A well-structured DHF should make it possible to demonstrate the connections between:

User Needs → Design Inputs → Risks → Design Outputs → Verification/Validation → Final Design

For example, teams should be able to answer questions such as:

• Which requirements address an identified risk?
• Which tests demonstrate that a requirement was met?
• Were risk control measures implemented and verified?
• How were verification failures or deviations resolved?
• How did Human Factors findings influence the final design?
• When a requirement changed, what downstream documentation and testing were affected?
• Does the final design remain consistent with the approved requirements and risk management documentation?

When these relationships are difficult to demonstrate, teams can spend significant time reconstructing evidence during submission preparation or responding to regulatory questions.

Good traceability makes the development history easier to understand—and potential gaps easier to identify before submission.

Build the DHF During Development, Not Before Submission

One of the most expensive mistakes a company can make is waiting until submission preparation to determine whether its design documentation is complete.

When documentation is reconstructed retrospectively, common problems emerge:

• Missing or incomplete design reviews
• Requirements without corresponding verification evidence
• Verification testing that cannot be traced to approved requirements
• Risk controls that are not clearly linked to verification activities
• Inconsistent software documentation
• Uncontrolled or conflicting document revisions
• Missing rationale for design changes
• Human Factors activities that were performed too late
• Cybersecurity documentation that was added after core development decisions were made

These gaps are often more difficult—and more expensive—to remediate as a submission deadline approaches.

Operating within a functioning Quality Management System (QMS) early in development helps ensure that design and development evidence is generated, reviewed, approved, and maintained as the product evolves.

DHF Readiness Under FDA's QMSR

The regulatory framework for medical device quality systems in the United States changed significantly when FDA's Quality Management System Regulation (QMSR) became effective on February 2, 2026.

The QMSR incorporates ISO 13485:2016 by reference and further aligns FDA's quality system requirements with the internationally recognized standard.

While manufacturers may continue to use the term Design History File, organizations should recognize that submission readiness is ultimately about more than maintaining a document labeled “DHF.”

The focus should be on maintaining controlled and compliant design and development records that demonstrate the required planning, inputs, outputs, reviews, verification, validation, transfer, risk management, and change activities applicable to the device.

This is especially important for companies pursuing both U.S. and international commercialization strategies, where a well-structured design and development documentation framework can support multiple regulatory pathways.

Common DHF Readiness Gaps

When RQMIS evaluates design and development documentation, common areas requiring attention can include:

• Incomplete requirements traceability
• Missing or inadequately documented design reviews
• Weak integration between risk management and design controls
• Incomplete verification or validation evidence
• Missing or inconsistent software lifecycle documentation
• Human Factors documentation gaps
• Cybersecurity activities introduced too late in development
• Inconsistent document versions or uncontrolled revisions
• Design changes without adequate impact assessments
• Testing that cannot be clearly connected to approved requirements
• Documentation that exists but does not tell a coherent development story

Individually, some of these issues may appear manageable. Collectively, they can create substantial remediation work and affect submission readiness.

A Better Approach: Conduct a DHF Readiness Assessment Early

Companies do not need to wait until the submission is nearly complete to determine whether their design documentation is ready.

A structured DHF readiness assessment can identify potential gaps while there is still time to address them efficiently.

An effective assessment should evaluate:

1. Completeness — Are the expected design and development records present?
2. Traceability — Can requirements, risks, mitigations, and testing be connected?
3. Consistency — Do specifications, risk files, test records, software documentation, and other records agree?
4. Control — Are documents appropriately reviewed, approved, version-controlled, and maintained?
5. Submission Readiness — Can the relevant evidence be efficiently translated into a coherent regulatory submission?

The earlier these questions are answered, the more options a development team has for correcting deficiencies without disrupting submission timelines.

Strong Documentation Supports More Than FDA Submission Readiness

A disciplined approach to design and development documentation provides benefits well beyond a single regulatory submission.

Companies with mature, well-controlled documentation are generally better positioned for:

• Regulatory submission preparation
• Quality system inspections and audits
• Design changes and product updates
• Software and cybersecurity maintenance
• Post-market activities
• International regulatory submissions
• Technology transfer and manufacturing scale-up
• Future product iterations and line extensions

Ultimately, strong design documentation is not paperwork created to satisfy a regulator. It is evidence that the product was developed through a controlled, systematic, and traceable process.

Is Your DHF Ready for Submission?

Discovering design documentation gaps shortly before a regulatory submission can result in costly remediation, additional testing, and avoidable delays.

RQMIS helps medical device, IVD, SaMD, AI-enabled, connected-device, and combination-product companies assess and strengthen their design and development documentation before those gaps become submission problems.

Our regulatory and quality experts can support:

• DHF and design documentation readiness assessments
• DHF remediation
• Design control and QMS implementation
• Requirements and traceability development
• Risk management integration
• Verification and validation documentation
• Software lifecycle and validation documentation
• Medical device cybersecurity documentation
• Human Factors documentation
• FDA and global regulatory submission readiness

Preparing for a submission—or concerned about gaps in your existing DHF?