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.