Design History File (DHF): What Belongs In It, and What Doesn’t

The Design History File (DHF) is the compilation of records that documents how a medical device was designed — not how it is built, and not proof that a specific unit was built correctly. Those are two different files with two different jobs, and researchers moving from an academic lab into a regulated device program routinely conflate all three. This page is a contents checklist: what has to be in a DHF, what commonly ends up there by mistake, and how it differs from the Device Master Record (DMR) and Device History Record (DHR). For the broader story of how these three record types were renamed under the FDA’s 2026 Quality Management System Regulation (QMSR) transition, see CASRAI’s 21 CFR Part 820 guide — this page assumes that context and focuses on DHF contents specifically.

DHF, DMR, DHR — the three-second version

All three trace back to the legacy 21 CFR 820 design-controls and records subparts. The terms are still what practitioners use day to day, even though the defining sections are now reserved text under the QMSR and the live requirement sits in ISO 13485.

The distinction that matters for an audit: the DHF exists before the device does — it is the record of a design process. The DMR and DHR both exist because of a device — the DMR describes what to build, the DHR proves a particular one was built that way. A DHF that reads like a build log, or a DMR padded with design-review minutes, is a miscategorization an auditor will flag on sight.

What actually belongs in a DHF

The legacy 21 CFR 820.30(a)–(j) design-controls structure still maps directly onto what a DHF has to contain, and ISO 13485 Clause 7.3 organizes the same activities. A complete DHF compiles the record of each of these:

• Design and development plan — scope, responsibilities, interfaces between groups, and how the plan itself gets updated as the project moves.
• Design inputs — the requirements the device has to meet: intended use, user needs, performance and safety requirements, applicable regulatory and standards requirements. Ambiguous or conflicting inputs have to be resolved and documented, not silently dropped.
• Design outputs — specifications, drawings, software, labeling drafts — anything that defines what gets built, expressed so it can be verified against the inputs it’s meant to satisfy.
• Design review records — formal, documented reviews at appropriate stages, with an independent reviewer (someone without direct responsibility for the design stage under review), attendees, dates, and what was decided.
• Design verification records — objective evidence that outputs meet inputs: did we build the device right? Testing, analysis, or inspection tied back to specific input requirements.
• Design validation records — objective evidence the device meets user needs and intended use under actual or simulated use conditions: did we build the right device? This is where human factors and usability engineering evidence lives, and where CASRAI’s IEC 62366-1 guide covers the usability engineering file this section cross-references.
• Design transfer records — evidence the finished design was correctly translated into production specifications. This is the hinge point: design transfer records are the last thing in the DHF and the first thing the DMR is built from.
• Design change records — every change after initial release gets its own trip through review, verification, and validation as warranted, documented in the DHF, not just logged as a DMR revision.
• Risk management file cross-reference — the DHF doesn’t have to duplicate the risk management file; it has to reference it and show that risk control measures verified in the risk file show up as design inputs and outputs. See CASRAI’s ISO 14971 risk management file guide for what that file itself contains.

One point that trips up teams building their first DHF: it does not have to be a single physical binder. FDA’s own design-controls guidance has long treated the DHF as a compilation — an index pointing to where each record actually lives (a document management system, a PLM tool, a lab notebook) is an acceptable and common structure, provided the index itself is maintained and every referenced record is retrievable. What an auditor is checking is completeness and traceability, not filing format.

What does not belong in the DHF — and where it actually goes

The distinction inspectors actually probe first

Three things come up repeatedly in device-quality audits, and all three are really tests of whether the DHF/DMR/DHR boundary is being kept honest rather than blurred:

• Unbroken traceability. Every design input should trace to at least one design output; every design output should trace to verification (and, where it’s a user-facing requirement, validation) evidence. An output with no verification record, or a verification record that doesn’t map back to a stated input, is the single most common finding.
• A real design-transfer boundary. Auditors check whether what the DMR actually specifies matches what the DHF’s final design output says — not an earlier draft, not a later undocumented tweak made on the shop floor.
• Change control after transfer. A design change made after the device is in production still needs its own review/verification/validation trail in the DHF. A DMR revision number bumped with no corresponding DHF entry is a gap, not a shortcut.

Which devices need a DHF at all

Design controls — and therefore a DHF — are class-scoped in the US, not universal. Under legacy 820.10(c) (now incorporated by reference through the QMSR into ISO 13485 Clause 7.3), design controls apply to Class II and Class III devices, Class I devices that are automated with computer software, and five specifically listed Class I devices (tracheobronchial suction catheters, non-powdered surgeon’s gloves, protective restraints, manual radionuclide applicator systems, and manual radionuclide teletherapy sources). Most Class I devices outside that list are exempt from design controls, and therefore don’t require a DHF. See CASRAI’s 21 CFR Part 820 guide for the full subpart-by-subpart QMSR transition detail, and the FDA device classification guide for how a device gets its class in the first place. Software-only products should also check CASRAI’s Software as a Medical Device (SaMD) guide — a SaMD product still needs a DHF; the “design outputs” are just code, architecture, and verification test protocols rather than physical drawings.

Frequently asked questions

Is a DHF required for every medical device?

No. It’s required only for device types within the 820.10(c) / ISO 13485 Clause 7.3 design-controls scope described above — Class II and III devices, software-automated Class I devices, and five named Class I exceptions. A device outside that scope still needs a DMR and DHR, but not a DHF.

Does the DHF have to be one physical file?

No. It can be a compilation held across multiple systems, as long as an index or reference structure ties the pieces together and every referenced record is actually retrievable on demand. What’s checked is completeness and traceability, not a single-binder format.

Is a DHF the same thing as an EU MDR Technical File?

Related but not identical. The EU MDR’s technical documentation (Annex II/III) is broader — it includes the DHF-equivalent design and development evidence but also folds in clinical evaluation, post-market surveillance planning, and labeling in a single dossier structured for CE marking submission. A DHF is the US/ISO 13485 design-history component; the EU technical file is the whole regulatory submission package built partly from it.

Does ISO 13485 require a DHF even if I’m not FDA-regulated?

ISO 13485 Clause 7.3.10 requires design and development files for any organization performing design and development activities, independent of FDA jurisdiction — the “DHF” label is a US-market convention, but the equivalent record is required anywhere ISO 13485 applies and design/development activity is in scope (organizations that only manufacture to another party’s design can justify excluding 7.3 from their QMS).

Does the DHF “close” once the device reaches production?

No. It stays open for the life of the design. Every subsequent design change gets added to it, and it’s retained under the same document-control and record-retention requirements as the rest of the quality system — not archived the moment design transfer happens.

Primary sources

• 21 CFR 820.30 — Design controls (legacy text, now reserved under the QMSR but still the operative structure practitioners reference)
• ISO 13485:2016, Clause 7.3 — Design and development, including 7.3.10, Design and development files
• 21 CFR 820.10(c) — device classes within design-controls scope

Related CASRAI resources

• 21 CFR Part 820: Subpart-by-Subpart Map and QMSR Transition Status
• ISO 13485: Medical Device Quality Management Systems Explained
• ISO 14971: The Risk Management File
• IEC 62366-1: The Usability Engineering Process
• FDA Human Factors and Usability Engineering Guidance
• UDI Medical Device: FDA Unique Device Identifier Requirements
• Software as a Medical Device (SaMD)
• Quality Agreement: What It Is and What FDA Expects
• Laboratory Compliance & Quality pillar