A Design History File (DHF) is the controlled compilation of records that proves a device was designed, reviewed, verified and transferred to production per an approved design plan under FDA design-control requirements (21 CFR 820.30) and the QMSR. The real compliance test is traceability: can an investigator follow a straight line from user need to design input, to verification evidence, to an approved change? If your design plan is current, start a traceability matrix today.
TL;DR:
- For existing files, map each legacy 21 CFR 820.30 artifact to ISO 13485 Clause 7.3; FDA does not require a full rewrite.
- Keep design evidence in the DHF, build specifications in the DMR, and production records in the DHR; cite shared records instead of copying them.
- Record review participants, findings, and dispositions, and document whether each design change requires renewed verification or validation; signatures alone do not show the decision.
- Include requirement and output identifiers, acceptance criteria, test methods, report references, and risk control links; software test records should identify the validated build or release.
Table of Contents
- What a design history file is and how the QMSR aligns with prior expectations
- DHF vs DMR vs DHR: who owns which records and why it matters
- Required contents of a DHF: a concise checklist
- How to build or remediate a DHF without starting over
- Traceability and V&V: the audit trail inspectors expect
- Inspection readiness under QMSR: what FDA will review
- Tools that help assemble audit-ready DHF evidence
- What we have learned about building a defensible DHF
- How QA-Report helps with audit-ready DHF evidence
- FAQ
- Sources
What a design history file is and how the QMSR aligns with prior expectations
A DHF exists to prove one thing: that a finished device meets user needs and its own design inputs, and that every decision along the way is documented and defensible. The regulatory foundation has not shifted so much as it has been renamed and consolidated. The Quality Management System Regulation (QMSR) took effect on February 2, 2026, and it incorporates ISO 13485:2016 by reference, which means Clause 7.3 design-and-development requirements now sit alongside, rather than replace, the structure most teams already know from 21 CFR 820.30.
For manufacturers of Class II, Class III, and certain Class I devices, that incorporation is not optional. We think the most useful way to read the transition is as a mapping exercise, not a demolition project. FDA's own transition materials frame QMSR largely as terminological continuity: the file your team built under 820.30 still does the job, provided it can be cross-walked to the equivalent QMSR/ISO 13485 clause.
Practical continuity steps:
- Pull your existing DHF index and note which section of 820.30 each artifact originally satisfied.
- Map each artifact to its corresponding ISO 13485 Clause 7.3 sub-clause.
- Flag gaps where QMSR language (for example, around design and development planning or risk management linkage) asks for something your legacy file does not clearly show.
- Prioritize remediation by device risk class and by how close the product is to its next design change or audit.
A deeper comparison of legacy ISO 13485 documentation structures against the incorporated QMSR text is available in our ISO 13485 documentation guide, which is useful groundwork before you start reclassifying individual records.
DHF vs DMR vs DHR: who owns which records and why it matters
Confusing these three files is one of the most common findings we see discussed in quality circles, and it is avoidable once the boundaries are clear.
- Design History File (DHF): the evidence trail of how the device was designed, reviewed, verified, validated, and transferred, built around the design plan required under 820.30 and QMSR's design-and-development clauses.
- Device Master Record (DMR): the current specifications for the finished device, including drawings, specifications, production procedures, and quality assurance procedures, essentially the "how to build it" reference derived from the DHF's approved outputs.
- Device History Record (DHR): the record of a specific unit or batch actually produced, including dates, quantities, and acceptance records, proving that a given production run followed the DMR.
The practical distinction is temporal and functional: the DHF documents the design process itself, the DMR documents the frozen specification that results from it, and the DHR documents that a real unit matched that specification. A verification protocol belongs in the DHF; the approved drawing it produced belongs in the DMR; the inspection record confirming a specific lot met that drawing belongs in the DHR. When records legitimately serve two purposes, index and cross-reference rather than duplicate; a copied document that drifts out of sync during a revision is a worse audit finding than a clean reference. Our Device History Record compliance guide walks through how DHR evidence should be organized once a design transfers to production.
Required contents of a DHF: a concise checklist
QMSR and 21 CFR 820.30 point to the same core elements, and the design-and-development presentation FDA published alongside QMSR lists them explicitly as required artifacts tied to traceability expectations. Use this sequence to audit what your file already contains.
- Design and development plan, approved and kept current as the project evolves.
- User needs and design inputs, each with a stated acceptance criterion, not just a general goal.
- Design outputs, including drawings, specifications, and software, that can be traced back to a specific input.
- Design review records, naming participants, findings, and a clear disposition, not a signature alone.
- Verification protocols and reports, confirming outputs meet inputs.
- Validation protocols and reports, confirming the device meets user needs under actual or simulated use conditions.
- Software validation records, when applicable, including requirements-based test cases and traceability to the build or release.
- Design transfer evidence, showing production is capable of consistently building the approved design.
- Change control records, with re-verification or re-validation documented whenever a change touches a validated output.
- Traceability artifacts, mapping requirements to tests and to risk-control measures.
Pro Tip: Treat design review minutes as evidence, not a formality: a checklist with signatures and no documented findings or disposition is one of the weaker artifacts in a DHF, according to FDA guidance on review documentation.
Gaps most often appear at steps 4 and 9. A review that happened but was not minuted with disposition, or a change that was implemented without a documented re-verification decision, are the two findings that recur most in DHF discussions.
How to build or remediate a DHF without starting over
Most teams do not need to rebuild a DHF from scratch; they need a disciplined sequence and consistent metadata.
- Confirm the design and development plan is approved and reflects the actual project scope.
- Capture user needs and design inputs with measurable acceptance criteria attached to each.
- Produce and baseline design outputs, linking each one to the input it satisfies.
- Hold and document design reviews at defined milestones, recording participants and disposition.
- Execute verification and validation, storing protocols and reports alongside the outputs they test.
- Complete design transfer, documenting that production can reliably reproduce the design.
- Control every subsequent change, with re-verification or re-validation triggered where warranted.
For document location, teams generally choose between a single consolidated file and an indexed reference structure pointing to records stored elsewhere. A single file is easier for a small-device program; an indexed structure scales better for complex or software-driven devices with many contributing records, and it is usually what auditors prefer when the index itself is clean and current.
Essential metadata to apply consistently:
- A unique design project or device identifier.
- Dates for creation, review, and approval of each record.
- Named approvers, not roles alone.
- Change IDs that link a revision to the review and re-verification that justified it.
For legacy files, the remediation checklist is short: locate the plan, confirm inputs have acceptance criteria, confirm reviews show disposition, confirm V&V reports reference the inputs they tested, and confirm every change has a linked re-verification decision. Our revision control implementation guide covers the versioning fields that make this kind of audit faster to repeat.
Traceability and V&V: the audit trail inspectors expect
A traceability matrix is the single artifact that most reduces review time, because it lets an inspector follow the engineering argument without hunting across files. At minimum, it should include: requirement ID, design output ID, verification or validation method, acceptance criteria, the V&V report reference, and the corresponding risk-control ID from your risk management file.
Traceability matrices with these columns are the most-cited helpful artifact during FDA inspections, according to FDA's design-and-development materials, because they let reviewers verify coverage without reconstructing the logic themselves.
Common gaps and fixes:
- Missing acceptance criteria on inputs: rewrite inputs as testable statements before verification begins, not after.
- Unsigned or undated review dispositions: require disposition fields as a mandatory part of the review template, not an optional note.
- Orphaned V&V reports: every report should cite the requirement ID it addresses, not just a general device description.
- Risk controls with no linked verification: cross-reference risk management outputs directly into the traceability matrix rather than keeping them in a separate, unlinked file.
For software-driven devices, link requirements-based test cases to the specific build or release they validated, and keep release notes alongside the validation report. A broken link here, where a report references an earlier build than what shipped, is one of the fastest ways to undermine an otherwise solid file.
Inspection readiness under QMSR: what FDA will review
QMSR replaced the QSIT inspection model with an updated compliance program, and the QMSR FAQ confirms that inspectors may review records created before the February 2, 2026 effective date. FDA recommends a comparative analysis, not a reset, so legacy documentation does not need to be rewritten, only demonstrably mapped to current clauses.
Expect reviewers to focus on:
- Design review documentation, specifically participants, findings, and disposition.
- Change control records, with re-verification or re-validation evidence where applicable.
- Verification and validation completeness, tied clearly to design inputs.
- Traceability between requirements, outputs, V&V, and risk controls.
- Software validation artifacts, where the device includes software.
- Design transfer records showing production readiness.
Pro Tip: Build your reviewer packet before you are asked for it: an index page, the traceability matrix, the comparative mapping from legacy records to QMSR clauses, and the most recent design review minutes cover most of what an investigator asks for first.
A short reconciliation checklist before any inspection: confirm the design plan is current, confirm every open change has a documented disposition, confirm the traceability matrix has no blank V&V or risk-control columns, and confirm software validation reports reference the shipped build. Our guide to inspection documentation best practices covers packet assembly in more depth, including how to organize supporting evidence for a reviewer who has limited time on-site.
Tools that help assemble audit-ready DHF evidence
Design history files draw on evidence created well outside the DHF itself, including measurement data, inspection reports, and production route records, which is where a connected inspection platform earns its place.
- Ballooned drawings linked directly to measured results give you an auditable chain from design output to verification data, satisfying the traceability expectations QMSR reviewers look for.
- First Article Inspection and CMM data import turn raw measurement sets into inspection-ready PDFs that can be dropped straight into a V&V evidence package.
- Integrated production records, including route cards and batch tracking, document design transfer and give reviewers a clear link between the approved design and what actually ran on the floor.
- A built-in 3D CAD viewer lets reviewers check ballooned dimensions against the actual STEP or IGES model rather than a flat drawing alone, which is useful when design outputs include complex geometry; teams documenting more elaborate visual evidence sometimes also turn to specialized 3D visualization resources for product documentation support.
What we have learned about building a defensible DHF
The DHF that survives an audit is not the thickest one. It is the one where every claim has a traceable answer, where a reviewer never has to ask "where is the evidence for this," because the link is already there. Volume is not the goal; a clear argument is.
Document contemporaneously. A design review minuted two weeks later, reconstructed from memory, reads differently than one captured the same day, and reviewers notice the difference. Cross-functional reviews, where quality, engineering, and regulatory each weigh in, also tend to surface gaps that a single discipline misses, which strengthens the file before an inspector ever sees it.
— Michael Chen
How QA-Report helps with audit-ready DHF evidence
We built our platform to close the gap between measurement data and the evidence a DHF needs to show. Our measurement wizard links ballooned drawing dimensions directly to measured results and automatically flags out-of-tolerance deviations, so verification evidence stays tied to the design output it tests from the moment it is captured.
- CMM data import and automatic ballooning turn raw inspection data into audit-ready PDF reports quickly.
- An integrated MES layer documents production route cards and batch history, supporting design transfer evidence with records tied to the same platform.
- Cloud and on-premise deployment options cover teams in regulated industries needing data confidentiality controls.
You can review tutorials and sample exports in our video gallery or see current plans and pricing on our pricing page.
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.
FAQ
What is the purpose of a Design History File?
The compiled evidence trail covers planning, inputs, outputs, reviews, verification, validation, and transfer required under 21 CFR 820.30 and the QMSR.
What is the difference between DMR and DHR?
The Device Master Record (DMR) holds the current approved specifications for building a device, while the Device History Record (DHR) documents that a specific production unit or batch actually matched those specifications. The DHF, by contrast, documents the design process that produced the DMR in the first place.
Does the 2026 QMSR require rebuilding existing DHFs?
No. FDA's transition guidance frames the QMSR largely as continuity with prior design-control expectations, and recommends a comparative mapping of legacy records to the incorporated ISO 13485 clauses rather than a full rewrite. Inspectors may review records created before the February 2, 2026 effective date.
What does a traceability matrix need to include?
At minimum, it should link each requirement ID to its design output, verification or validation method, acceptance criteria, the related V&V report, and the corresponding risk-control ID. This structure is the artifact most cited as helpful during FDA inspections of design-and-development files.
Can software tools help assemble DHF evidence?
Yes. Platforms that link measurement data, ballooned drawings, and production records to a central traceability structure make it faster to produce audit-ready evidence packages, which is the kind of use case our CMM inspection software is built around.