Design History File (DHF) – Evidence of a Controlled Medical Device Design

This topic is part of the SG Systems Global regulatory glossary series.

Updated October 2025 • Medical Devices • 21 CFR 820 / EU MDR / ISO 13485

A Design History File (DHF) is the curated, traceable body of evidence demonstrating that a medical device was designed, developed, verified, validated, transferred, and changed under a defined quality system. In U.S. regulation, the DHF historically implements design controls (legacy 21 CFR 820.30) and remains the authoritative record set showing that the design input requirements were transformed into a device that meets user needs and intended use. In the EU, the concept is reflected by the technical documentation (MDR Annex II/III) and a design and development file under ISO 13485 clause 7.3. Regardless of geography, the intellectual content is the same: methodical definition of requirements, risk-informed design, controlled verification/validation, proper transfer to manufacturing, and scrupulous change control with maintained traceability to risks, standards, and postmarket information.

“A defensible DHF is not a bookshelf of reports; it is a structured argument, supported by data, that the device you ship will consistently meet user needs, regulatory requirements, and safety expectations.”

1) What It Is

The DHF is a design lifecycle dossier. It does not duplicate every engineering record but references and indexes them so an independent reviewer can reconstruct the logic of the design, test the completeness of controls, and confirm that requirements flowed forward and evidence flowed back. It shows the evolution from user needs and intended use into design inputs (functional, performance, safety, regulatory), then design outputs (drawings, specifications, software items, labeling), with verification that outputs meet inputs, validation that the final device meets user needs, and design transfer to controlled manufacturing (procedures, BOM, routings, inspection). Critically, the DHF documents risk management across the lifecycle and links that risk file to specific mitigations, tests, and residual risk acceptances. It also houses design changes, their rationale, impact analyses, and the re-verification/validation (re-V&V) necessary to maintain state of control.

2) Regulatory Anchors & Scope

In the U.S., the concept is codified in device design controls (historically 21 CFR 820.30). While the FDA has harmonized much of Part 820 with ISO 13485, the regulator continues to expect a comprehensive, navigable record demonstrating design control. ISO 13485 requires documented procedures for design and development planning, inputs/outputs, review, verification, validation (including clinical where applicable), transfer, and changes, with records maintained. In the EU, MDR Annex II/III technical documentation plus the design and development file together satisfy the DHF intent; for software as a medical device, standards such as IEC 62304 (software lifecycle) and IEC 82304-1 (health software) inform the structure of the file. The DHF should cross-reference 21 CFR 803 (MDR), 806 (corrections/removals), and 821 (UDI/traceability) where relevant, because postmarket signals and identification schemes feed back into design changes and labeling.

3) Canonical Contents of a DHF

There is no single mandated table of contents, but most mature DHFs organize into the following sections with a persistent index and configuration table:

• Design & Development Plan. Scope, lifecycle model, responsibilities, milestones, design review gates, and deliverables; interfaces to suppliers and notified body/FDA interactions.
• User Needs & Intended Use. Clinical context, operating environment, usability goals (link to IEC 62366-1 human factors); market and regulatory requirements.
• Design Inputs. Derived, measurable requirements mapped to standards (e.g., IEC 60601-1 safety, EMC, cybersecurity), regulatory constraints, and risk controls; includes software requirements for SaMD.
• Design Outputs. Specifications, drawings, schematics, software items, labeling, packaging, and acceptance criteria; cross-referenced to the BOM and production BMR/DHR templates.
• Design Review Records. Formal, independent reviews at planned stages with minutes, attendees, findings, and dispositions; issues linked to CAPA or change actions as needed.
• Verification Evidence. Protocols and reports demonstrating outputs meet inputs (bench tests, analysis, inspection); includes software verification and unit/integration tests.
• Validation Evidence. Clinical/usability validation where applicable; simulated use, summative usability, validation that the device meets user needs and intended use in the target environment.
• Risk Management File. Hazard analysis (e.g., ISO 14971), FMEA/FTA, risk control measures, verification of controls, residual risk acceptability, risk/benefit rationale, and links to labeling and IFU.
• Design Transfer. Evidence that manufacturing instructions, test methods, and acceptance criteria were successfully implemented (first article, process validation, validation/PPAP equivalents), and that purchasing/specification controls are in place.
• Labeling and IFU. Content, artwork approval history via Approval Workflow; UDI assignments (21 CFR 830), language/market variants, and trace to risk controls and validation claims.
• Change History. Controlled Change Control records with impact assessments, re-V&V, cybersecurity patch strategy (for software), and field action cross-references if applicable.
• Postmarket Design Feedback. Complaint trending, vigilance/MDRs (803), CAPA triggers, and how these inputs update requirements and design controls.

“The organizing principle of a DHF is bidirectional traceability: every requirement is realized and tested; every test traces to a requirement or risk control; every change preserves that network.”

4) Lifecycle Governance & Traceability

A DHF is only as strong as its lifecycle governance. Design activities must be planned; reviews must be independent and documented; verification and validation must be protocol-driven and statistically adequate (AQL and SPC control limits concepts often inform sampling and acceptance). Trace matrices are the primary instrument: one matrix links user needs → inputs → outputs → verification; a second links risk controls → verification → labeling and IFU; for software, a third matrix maps requirements → architecture → unit/integration tests. All matrices are configuration-controlled and updated when changes occur. The DHF should also define records of conferral with manufacturing—i.e., design transfer sign-offs, training records for production, and readiness of incoming inspection—so the downstream eDHR can be executed without ambiguity.

5) Interfaces: DMR, DHR/eDHR, Labeling & UDI

The DHF is distinct from the Device Master Record (DMR) and the Device History Record (DHR), but they are tightly coupled. The DMR is the “how to make and test” packet (procedures, drawings, specifications); the DHR is the lot/unit execution record showing the device was built per the DMR. The DHF shows why the DMR is suitable and how it got there. Labeling and UDI belong in both DHF (as outputs of design and risk controls) and DMR (as controlled masters), while actual label prints and UDI application evidence live in the DHR/eDHR. In integrated systems, Barcode Validation and Dual Verification enforce the connection from design-specified identifiers to executed builds and packaging.

6) Common Failure Modes & How to Avoid Them

• Backfilled files. Building the DHF after development leads to missing rationales and unverifiable linkages. Fix: maintain the DHF contemporaneously with gated reviews.
• Weak requirements. Ambiguous or unmeasurable inputs undermine verification. Fix: enforce SMART requirements and formal requirements reviews.
• Traceability gaps. Tests without a requirement, or requirements without tests. Fix: maintain living trace matrices with e-signature control and audit trails.
• Risk file disconnected. Hazards identified but not implemented as controls or verified. Fix: integrate ISO 14971 activities with design controls and label content.
• Design transfer as a handoff, not a process. Manufacturing learns by trial, creating DHR nonconformances. Fix: plan transfer; include process validation, training, and Component Release readiness.
• Uncontrolled change propagation. Software patch or supplier change without impact assessment on DHF. Fix: formal Change Control with re-V&V triggers and cybersecurity posture.
• Poor labeling governance. IFU/graphics diverge from validated claims. Fix: bind labeling to approved outputs through Approval Workflow and link to risk mitigations.

7) Metrics That Demonstrate Control

• Requirements coverage. % of design inputs with verified outputs; % of risk controls verified.
• Defect discovery profile. Distribution of issues by phase (requirements, verification, validation, transfer)—shifting left over time indicates maturity.
• Re-V&V cycle time. From change proposal to approved evidence; proportion requiring design validation and labeling updates.
• Trace integrity. Number of orphan tests/requirements detected at review gates.
• Postmarket feedback closure. Time from CAPA signal to DHF update; recurrence rate of design-related complaints.

8) How It Relates to V5

V5 by SG Systems Global provides the operational backbone that links DHF intent to execution. In V5 QMS, controlled documents (requirements, protocols, reports) follow role-based Approval Workflows with audit trails and Part 11-compliant e-signatures; trace matrices are maintained as controlled artifacts linked to individual records. In V5 MES, design outputs flow into controlled routing steps and inspection plans; Dual Verification and Barcode Validation enforce correct component and label use at build. In V5 WMS, approved specifications and UDI/label masters guide receiving, status control, and Directed Picking. When a design change is approved, V5 synchronizes training, masters, and effective dates so DHR/eDHR executions reference the correct versions. For management review and audits, V5 renders DHF indexes, link graphs (requirements↔tests↔risks), and evidence packets on demand—critical during notified body surveillance or FDA inspections.

Related Reading
• Regulatory Foundations: 21 CFR 820 | MDR 803 | Corrections/Removals 806 | UDI/Traceability 821
• Quality System Linkages: Change Control | CAPA | Audit Trail (GxP)
• Manufacturing Evidence: BOM | BMR / eDHR | Component Release | CoA

9) FAQ

Q1. Is the DHF the same as the DMR and DHR?
No. The DHF documents design control. The DMR defines how to manufacture and test; the DHR/eDHR proves each unit/lot was built and tested per the DMR. They must be consistent and cross-referenced.

Q2. How much detail should live in the DHF versus being referenced?
The DHF should contain plans, summaries, and conclusions, and reference large data sets and raw test records stored in controlled repositories. What matters is navigability and traceability, not duplication.

Q3. What triggers design re-validation?
Risk-significant changes (requirements, materials, software of unknown provenance, labeling claims), new hazards, or postmarket CAPA signals. Use formal Change Control with impact assessment to plan re-V&V.

Q4. How do usability and human factors fit?
Usability engineering is part of validation; user interface hazards and mitigations live in the risk file and trace to IFU and labeling. Summative studies belong in the DHF validation section.

Q5. Can software teams manage the DHF in code repositories?
Yes, provided Part 11/Annex 11 controls are met: identity, versioning, audit trails, approvals, and preserved context. Many teams link requirements, code, tests, and risks through integrated tools and export controlled records into V5 QMS.