Product Development
The design history file is the document that demonstrates FDA design controls were followed throughout development. A DHF that is incomplete, disorganized, or that doesn't trace from user needs through validation is a finding in essentially every FDA device inspection and a source of Additional Information requests in 510(k) and PMA reviews.
Assess Your DHFDHF Architecture
Under 21 CFR 820.30(j), the design history file must contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of the design controls regulation. In practice, FDA investigators walk through the DHF looking for specific evidence at each design control stage: is there a design plan that governed development? Are design inputs documented and approved before outputs were generated? Do outputs demonstrate they meet inputs? Are design reviews documented with participants and issues raised? Is verification documented with protocols, results, and pass/fail determination? Is validation documented with a protocol that tested real-world use?
The most common DHF deficiencies we see in pre-submission assessments are: inputs that were written after the design was frozen (identifiable by document dates), undated or undocumented design reviews, verification reports that don't reference the protocols they executed, and validation that tests the device in a lab condition that doesn't represent actual use. Each of these patterns tells the same story: design controls were followed in form but not in substance, and the DHF was assembled to look complete rather than to document a controlled development process.
A DHF gap assessment systematically reviews the existing design history against 21 CFR 820.30 requirements and FDA's inspection expectations. The output is a gap list with three categories: documents that exist and are compliant, documents that exist but have identifiable deficiencies that need remediation, and documents that don't exist and need to be created. The gap list is prioritized by regulatory risk and submission impact, and a remediation plan is developed that is achievable within the submission timeline.
Gap remediation is not about backdating or falsifying records — it is about creating contemporaneous documentation that explains what occurred during development and provides the evidence that existed but was never formally captured. Interview-based reconstruction of design decisions, signed attestations of engineering processes that weren't documented in real time, and supplemental test protocols that re-run already-completed tests under controlled conditions are all legitimate remediation approaches. What is not legitimate is creating documents that purport to be from an earlier date when they weren't. We guide companies through the ethical and regulatory boundaries of DHF remediation.
For companies starting a new development program, DHF architecture design at the outset prevents the remediation problem entirely. The DHF architecture defines: the folder structure, the document naming convention, the required documents at each design control stage, the approval workflow for each document type, and the traceability matrix structure. When this architecture is in place before development begins, each development activity produces documents that go directly into the DHF in the right place with the right content — and the design history is complete by the time the submission is filed.
Get Started
The design history file is the most-inspected document in a device facility audit. We build and remediate DHFs to the standard FDA reviewers and investigators actually apply.