The DHF lost its name, not its importance
When FDA’s Quality Management System Regulation (QMSR) took effect on February 2, 2026, the phrase “design history file” disappeared from 21 CFR Part 820. As King & Spalding summarized, “FDA’s regulations no longer refer to Design History Files, Device Master Records, or Device History Records” (King & Spalding).
The evidence did not disappear. Design and development is now one of six areas FDA investigators examine in every inspection, and failing to control design is listed as a finding that can trigger official action. Meanwhile, FDA’s own reviewers use agentic AI to work through submissions faster.
This guide explains what your design file must contain under QMSR, what has changed in inspections, and what to look for in design history file software in 2026.
For what changed when the QMSR replaced the DHF with the design and development file, see Design History File (DHF) Under the QMSR: What It Is, What Changed and How to Review It.
What replaced the DHF under QMSR
In the QMSR final rule, FDA explained that it “eliminated terms associated with these specific record types because we believe the elements that comprise those records are largely required to be documented by ISO 13485” (Federal Register). The old record types now map to ISO 13485:2016 files:
| QSR term (pre-2026) | QMSR / ISO 13485:2016 equivalent | What it must hold |
|---|---|---|
| Design History File (DHF) | Design and development file (clause 7.3.10) | All records needed to show compliance with design and development requirements, including the plan and procedures |
| Device Master Record (DMR) | Medical device file (clause 4.2.3) | Device description, specifications, production, labeling and servicing information |
| Design controls (§ 820.30) | Design and development (clause 7.3 and subclauses) | Planning, inputs, outputs, review, verification, validation, transfer, changes |
FDA states that, “consistent with the former DHF, Clause 7.3.10 requires the design and development file to contain or reference all the records necessary to establish compliance with design and development requirements” (Federal Register).
Who must comply. Under § 820.10(c), manufacturers of class II and class III devices, and certain class I devices, must meet clause 7.3. The class I list includes “Devices automated with computer software,” so software-driven class I products are in scope.
The term lives on in practice. FDA’s guidance on premarket submissions for device software functions notes that QMSR “does not utilize certain terms, such as ‘Design Controls,’” yet still tells sponsors to document design information “internally via the DHF for the device” (FDA). Most teams will keep calling it the DHF. What matters is that the file is complete, traceable and mapped to clause 7.3.
2026 trends shaping design file expectations
Design and development is inspected every time
FDA’s new Compliance Program 7382.850 “organizes the QMSR requirements into 6 QMS Areas and 4 Other Applicable FDA Requirements,” and design and development is one of the six (FDA CP 7382.850). Under Model 1 inspections, investigators examine at least one element in every area. For PMA devices, the program tells investigators to “maintain or have readily accessible copies of the design and development file.”
The stakes are explicit. The program lists “Failure to control the design and development of product” as a Situation 1 finding that can support an Official Action Indicated classification (Ropes & Gray).
Design controls remain a top enforcement issue
In FY2025, design control deficiencies under § 820.30 ranked second in medical device warning letters with 25 citations, just behind CAPA (ECA Academy). Hogan Lovells adds that “Design control violations are increasingly tied to 510(k) discrepancies” (Hogan Lovells), so gaps between what you submitted and what your design file shows are a growing risk.
Submissions are structured, and FDA reads with AI
All 510(k) and De Novo submissions must now use FDA’s eSTAR template unless exempted (FDA eSTAR). On the agency side, FDA rolled out “agentic AI capabilities for all agency employees” in December 2025, for tasks including “pre-market reviews, review validation, post-market surveillance” (FDA). Inconsistencies between your submission and your design file are easier to spot than ever.
Quality teams can validate AI tools proportionately
FDA’s Computer Software Assurance guidance, updated February 3, 2026, says its risk-based approach applies to “artificial intelligence/machine learning tools, and cloud computing when used as part of production or the quality management system” (FDA CSA guidance). An IQVIA white paper for QA/RA leaders stresses that “A human-in-the-loop approach is essential to safeguard the quality and accuracy of QMS and RIM activities” (IQVIA).
6 capabilities design history file software needs
- Clause 7.3 structure. The file should be organized around ISO 13485 clause 7.3 (planning, inputs, outputs, review, verification, validation, transfer, changes), with each record tagged to its subclause. This makes the design and development file easy to hand over and easy to audit.
- Live traceability. User needs, design inputs, outputs, verification, validation and risk controls should be linked records, not a matrix rebuilt in a spreadsheet before each audit. When one input changes, you should see every affected output and test.
- Risk integration. Each hazard and risk control should link to the design outputs and verification that address it. Inspectors now use risk to decide what to examine, so a risk file kept separately from the design file is a weak point.
- Change control with impact assessment. CP 7382.850 treats change control as its own area, and King & Spalding notes the design finding includes “not adequately evaluating changes” (King & Spalding). Software should capture the rationale, affected records and re-verification decision for every change.
- Submission consistency checks. Your 510(k) or De Novo content must match the design file. Look for tools that compare eSTAR content against design records and flag mismatches before FDA does.
- Retrieval in minutes. For PMA inspections, investigators expect the design and development file to be readily accessible. Search, export and a clear index of the file are basic requirements, not extras.
Evaluation checklist for DHF software vendors
| Evaluation area | Ask the vendor | Red flag |
|---|---|---|
| Regulatory mapping | Show records tagged to ISO 13485 clause 7.3 subclauses and § 820.10(c) | Folder structure copied from § 820.30 with new labels |
| Traceability | Change one design input live; show every linked output, test and risk control | Traceability matrix exported from a spreadsheet |
| Risk linkage | Show a hazard linked to the outputs and verification that control it | Risk file stored as a separate attachment |
| Change control | Show impact assessment and re-verification decision for a design change | Free-text change notes only |
| Submission alignment | Can the tool compare eSTAR sections with design records? | No way to check submission vs. file |
| AI review | When AI flags a gap, does it cite the record and requirement? Can a reviewer accept or reject it? | Scores without citations |
| Validation | What CSA-aligned validation evidence do you provide? | ”Pre-validated” with no traceable evidence |
| Data integrity | Audit trails, e-signatures and role controls | Records editable without history |
A practical test: pick one released product and ask each vendor to produce its complete design and development file, with traceability, in under an hour.
Where AI DHF review fits
Most design files were built under QSR, often across years and several tools. The hard part in 2026 is not storing them; it is reading them. Teams need to confirm that every input has a verified output, that risk controls are traced, and that the file matches what was submitted.
AI document review handles that reading at scale:
- Gap analysis against clause 7.3. Assess existing design files against ISO 13485 design and development requirements and get a prioritized list of missing or weak evidence.
- Traceability checks. Flag inputs without verification, outputs without inputs and risk controls without evidence of effectiveness.
- Submission consistency. Compare design records with submission content and highlight discrepancies.
- Evidence-backed findings. Every flag should cite the passage and the requirement, so engineers can verify it quickly. Your team makes the final call.
Check one design file before an investigator does. AskDona assesses regulatory documents against the requirements you choose and shows the evidence behind every finding. Run a sample regulatory document assessment.
FAQ
Does FDA still require a design history file? Not by that name. QMSR requires a design and development file under ISO 13485 clause 7.3.10, which FDA describes as “consistent with the former DHF” (Federal Register).
Which devices need design controls under QMSR? Class II and class III devices, plus listed class I devices including those “automated with computer software” (eCFR § 820.10(c)).
Do we need to rename our existing DHFs? No renaming is required. FDA’s own software guidance still refers to the DHF (FDA). Focus on whether the content meets clause 7.3.
How often are design controls cited? In FY2025, design controls were the second most-cited issue in device warning letters, with 25 citations (ECA Academy).
Can we use AI to review design files? Yes, with validation proportionate to risk. FDA’s updated CSA guidance covers AI/ML tools used as part of the quality management system (FDA).
References
All pages opened and checked by October 9, 2026.
| Source | Type | Date | Used for |
|---|---|---|---|
| Federal Register: QMSR final rule (2024-01709) | Regulator | Feb 2, 2024 | DHF/DMR terms dropped, clause 7.3.10 |
| eCFR: 21 CFR Part 820 | Regulation text | Current | § 820.10(c) scope |
| FDA: Compliance Program 7382.850 | Regulator | Feb 2, 2026 | Six QMS areas, design file access |
| FDA: Premarket Submissions for Device Software Functions | Regulator guidance | Jun 14, 2023 (QMSR notes added) | DHF term still used |
| FDA: CSA for Production and QMS Software | Regulator guidance | Feb 3, 2026 | AI/ML tools in scope |
| FDA: Agentic AI deployment | Regulator press release | Dec 1, 2025 | FDA’s AI use in reviews |
| FDA: eSTAR Program | Regulator | Current | eSTAR mandatory |
| King & Spalding: The QMSR Goes Live | Law firm | Feb 3, 2026 | Terminology, change evaluation |
| Ropes & Gray: A QMSR State of Mind | Law firm | Feb 2026 | Situation 1 design finding |
| ECA Academy: FY2025 device warning letter statistics | Industry analysis | FY2025 | Design controls ranked #2 |
| Hogan Lovells: FDA device inspections in 2025 | Law firm | Sep 18, 2025 | 510(k) link |
| IQVIA: Establishing AI in MedTech | Industry white paper | 2025 | Human-in-the-loop |