DHFDesign History File

A Design History File (DHF) is the compilation of records that describes the design history of a finished medical device. It includes every record produced during design and development — the design inputs, the design outputs, the design reviews, the verification and validation records, the design changes, and the design transfer evidence. The DHF answers the question 'how was this device designed, and how do we know the design satisfies the user's needs and the intended use?'.

The DHF is required by 21 CFR 820.30(j) under the legacy QSR and by ISO 13485 clauses 4.2.3 and 7.3.10 under the harmonised QMSR. The artefact applies to all Class II and Class III devices and to a defined subset of Class I devices listed in 820.30(a)(2). Most Class I devices are exempt from design controls but not from any other Part 820 requirement; a manufacturer of an exempt device should still maintain design records under the QMS even if they are not formally a DHF.

820.30 has eleven sub-paragraphs covering the entire design-control framework. The DHF (subparagraph j) is the file in which the evidence accumulates; the other sub-paragraphs define the activities whose evidence ends up in the DHF.

1. 820.30(a) — General. Scope of design controls.
2. 820.30(b) — Design and development planning. The plan that governs the activity.
3. 820.30(c) — Design input. The user needs and intended uses translated into requirements.
4. 820.30(d) — Design output. The specifications that emerge from design.
5. 820.30(e) — Design review. Formal documented reviews of the design results.
6. 820.30(f) — Design verification. Confirmation that design output meets design input.
7. 820.30(g) — Design validation. Confirmation that the device meets user needs and intended uses.
8. 820.30(h) — Design transfer. Translation of the design into production specifications (the DMR).
9. 820.30(i) — Design changes. Identification, documentation, validation and approval of changes.
10. 820.30(j) — Design history file. The compilation of all the above.

The DHF is not itself a procedure; it is a file whose contents are produced by the procedures defined under 820.30(b) through (i). A manufacturer with a DHF that is just a folder of unsigned drafts has, in effect, no design controls — the procedures the DHF should evidence have not been performed.

Design inputs (820.30(c)) are the physical and performance requirements of the device. They include the user needs, the intended use, the regulatory requirements, and the standards the device must meet. Inputs must be documented, reviewed, approved by a designated individual, and traceable through the rest of the design process. Ambiguous or incomplete inputs are the most cited 820.30 finding.

Design outputs (820.30(d)) are the specifications produced from the inputs. They include drawings, source code, formulations, work instructions, acceptance criteria, packaging specifications, and labelling. Outputs must be expressed in terms that allow adequate evaluation of conformance to design input requirements. Each output must trace back to one or more inputs; this is the traceability matrix.

The traceability matrix is the spine of the DHF. It shows, for every input, which outputs satisfy it; for every output, which verification activity confirmed it; and for every input, which validation activity confirmed the design as a whole satisfies the user need. An inspector asks for the traceability matrix early; a missing or partial matrix is the strongest signal that the design controls are weak.

Verification (820.30(f)) confirms that the design output meets the design input. Did we build the device right? Verification answers this with bench testing, software unit and integration testing, dimensional inspection, biocompatibility testing, sterilisation validation, and so on. Each verification activity must reference the design output under test, the acceptance criteria from the design input, the method, the results, and the signature of the responsible person.

Validation (820.30(g)) confirms that the device meets the user need and intended use under actual or simulated use conditions. Did we build the right device? Validation typically includes summative usability testing, human factors validation per IEC 62366-1, simulated-use testing, and (where appropriate) clinical evaluation. Validation must be performed on initial production units, units produced under equivalent conditions, or under controlled conditions per 820.30(g).

ISO 14971:2019 governs risk management for medical devices and is incorporated into both the QSR (via 820.30 expectations) and the QMSR (via ISO 13485). Risk management is not a separate file — it is an activity whose outputs live in the DHF. The risk management plan, the hazard analysis, the risk evaluation, the risk control measures, the verification of those measures, and the risk management report all belong in the DHF.

Risk controls become design outputs. A risk control measure such as 'redundant occlusion alarm' becomes a design output (the alarm specification) which traces back through the design input chain to the hazard (occlusion) it controls. The traceability matrix is therefore three-dimensional in practice: inputs ↔ outputs ↔ risks.

ISO 14971:2019 dropped the as-low-as-reasonably-practicable (ALARP) concept and replaced it with reduction of risk as far as possible (AFAP) and a risk-benefit analysis for residual risks. DHFs that still cite ALARP have not been updated to the current standard — an audit finding for the QMS, not the design.

820.30(e) requires formal documented reviews of the design results at appropriate stages of the device's design development. 'Appropriate stages' is deliberately vague — the design plan defines them. Typical stages are inputs-approved, outputs-approved, verification-complete, validation-complete and design-transfer-complete. At each review, the participants, the date, the design under review, the issues identified and the actions assigned must be documented and the document signed by the participants.

Each review must include 'an individual(s) who does not have direct responsibility for the design stage being reviewed' (820.30(e)). The independent reviewer is the equivalent of the second person on a Part 211 approval — they bring a perspective the immediate design team cannot. Inspectors verify the independent reviewer's signature by their role and reporting line.

Design transfer (820.30(h)) is the bridge between the DHF and the DMR. The procedure must ensure that the device design is correctly translated into production specifications. Practically, design transfer is the formal handover from the design team to the manufacturing team, and the artefact it produces is the initial released version of the DMR.

Transfer is not a single event — most modern programmes use a staged transfer (pilot, scale-up, full production) with formal sign-offs at each stage. The DHF holds the evidence of each transfer milestone; the DMR holds the released production specifications that emerged from them. After design transfer is complete, the DMR becomes the production system of record; the DHF continues to live, but is updated only on design changes.

820.30(i) requires the manufacturer to establish procedures for the identification, documentation, validation or verification, review, and approval of design changes before their implementation. Every change to a released design must be documented in the DHF as a design change record, must be reviewed and approved with the same rigour as the original design, and must be evaluated for impact on previously released devices.

Design changes interlock with change control on the DMR (820.40) and on the production process (820.70). A change to a design output that lives in the DMR has to update the DMR; if the change affects the production process it has to go through process change control; and if the change affects regulatory clearance (a 510(k) device whose modifications might require a new submission) it triggers a 21 CFR 807.81(a)(3) evaluation.

1. DHF is a folder of unsigned drafts — the design-control procedures were not performed, only their outputs were collected.
2. Traceability matrix is missing or incomplete — inputs and outputs cannot be tied, 820.30(c)/(d) finding.
3. Design validation performed on engineering units rather than production-equivalent units — 820.30(g) finding.
4. Independent design reviewer is the same person as the design lead — 820.30(e) independence broken.
5. Risk management activities recorded in a separate file with no DHF cross-reference — ISO 14971 integration broken.
6. Design transfer happened informally — no transfer record, no first-released DMR version, no formal handover.
7. Design changes recorded against the DMR but not against the DHF — the DHF becomes a stale snapshot of the initial design.
8. Software design records (architecture, unit tests, integration tests) maintained outside the DHF — IEC 62304 integration broken.

V5's primary regulated-execution surface is post-design-transfer — the DMR, the work order, the DHR. The DHF lives upstream of V5's execution scope, but V5 holds the index and the traceability artefacts that link the DHF to the production records it eventually produces.

• Every released DMR carries a reference to the DHF design-transfer milestone that produced it, with the participants, the date, and the design-review evidence pack attached.
• Design changes that flow into DMR change control create paired DHF change records, so the DHF stays live through the product's commercial life.
• Risk-control design outputs are tagged in the DMR; their corresponding DHR acceptance records (the in-process inspections that verify the control) are linked so an inspector can move from a hazard to a per-unit verification in two clicks.
• For tenants whose primary design system is external (a PLM, a requirements tool), V5 stores the DHF index and the transfer evidence; the source artefacts continue to live in the PLM and are referenced by stable URL.
• DHF retention follows the device's design and expected life under 820.180(c) — V5 retains the index and the transfer evidence for the same period as the DMR and DHR.

See below for the regulator-grade answers to the questions buyers ask most often when scoping their DHF programme.

For any device that contains software — and that is now the overwhelming majority of new market entries — the DHF must reference a parallel IEC 62304 software lifecycle file. IEC 62304:2006/A1:2015 (and the in-progress 2nd Edition) classifies software components by safety class (A, B, C) and prescribes the lifecycle deliverables accordingly. The DHF is incomplete unless every software item it references has a current, signed lifecycle record.

• Software safety classification per item, with rationale documented and reviewed by the design authority.
• Software Development Plan (SDP) — process, deliverables, tooling, configuration management, problem-resolution process.
• Software Requirements Specification (SRS) — derived from system requirements and risk-control measures; class C software requires a more granular SRS than class A.
• Software Architecture (class B+) and Detailed Design (class C only).
• Unit, integration and system test evidence with traceability to requirements and risk-control measures.
• Software configuration management records: every released build identifiable by version, source tagged in version control, build reproducible from tag.
• Software problem-resolution records: every defect found post-release tracked to root cause, fix, regression test, and risk-management update.

The DHF does not need to physically contain the software lifecycle records — they typically live in a software ALM such as Polarion, Jama or Codebeamer, or in a well-disciplined Git repository with linked issue tracker. What the DHF must contain is the explicit reference to those records, their location, their version state at design transfer, and the change-control link that keeps the DHF reference current as the software evolves.

A DHF that stops being updated after design transfer is a DHF that fails audit within the first product-lifecycle cycle. 820.30(j) makes the DHF a living artefact for the life of the device. ISO 13485 §7.3.10 and EU MDR Articles 83–86 close the loop explicitly: post-market surveillance findings must flow back into design and the DHF must reflect every iteration.

1. Complaint trending: complaints classified by failure mode, plotted against time, and reviewed quarterly by the design authority. Statistical signals (a complaint rate per UDI-DI exceeding the threshold) trigger a formal review.
2. MDR / vigilance event review: every reportable adverse event is reviewed for design implications. If the root cause maps to a design input, the DHF is updated with a design-change record.
3. PMCF / clinical follow-up: post-market clinical follow-up data (mandatory for class IIa+ under EU MDR) is summarised in the PSUR/PMCF Evaluation Report and referenced from the DHF.
4. Field-experience design reviews: at least annually for class II+, a structured design review walks the cumulative field experience against the original design inputs. Outcomes are minuted and stored in the DHF.
5. CAPA-driven design changes: every CAPA whose corrective action includes a design change generates a DHF entry, with the CAPA reference and the verification/validation evidence for the change.
6. EUDAMED upload synchronisation: any DHF design-change record that affects the UDI-DI requires a corresponding EUDAMED update. The DHF carries the EUDAMED submission reference.

The DHF and the post-market surveillance file are two ends of a single feedback loop. Treating them as separate ring binders is the most common cause of EU MDR Notified Body findings. In V5, design changes and CAPAs share a unified workflow so that a CAPA whose corrective action is a design change automatically generates the DHF update task with the change-control gating intact.

The Quality Management System Regulation (QMSR), published February 2024 and effective 2 February 2026, replaces 21 CFR 820 with a regulation that incorporates ISO 13485:2016 by reference, with US-specific overlays for complaint files, UDI, labelling and adverse event reporting. The substance of the DHF is preserved, but the terminology, the cross-references, and several procedural details shift.

• The term 'Design History File' no longer appears in the regulatory text. ISO 13485 §7.3.10 requires a 'design and development file' that captures the same evidence; FDA's preamble explicitly confirms equivalence.
• Design controls (820.30) map to ISO 13485 §7.3 (design and development). The structure is largely the same; the principal differences are in vocabulary (e.g., 'design and development planning' replaces 'design plan').
• Design transfer (820.30(h)) is preserved via §7.3.8. The two-step expectation (transfer plan + transfer verification) is unchanged in substance.
• Design changes (820.30(i)) map to §7.3.9. The QMSR continues to require evaluation, verification/validation and approval for every change — the FDA's preamble warns that 'in-process' or 'tweak' changes are still in scope.
• Risk management is now anchored to ISO 14971:2019 by reference, replacing the implicit risk-management expectation in 820.30(g). Every DHF must have a current ISO 14971 Risk Management File.
• Combination products and software-led devices continue to require the additional cGMP overlays in 21 CFR 4 and the software lifecycle records under IEC 62304. The QMSR does not change those.