The Importance of a Well-Structured Design History File

A Design History File (DHF) is the collection of records that documents the complete design and development history of a medical device. It demonstrates that the device was designed in accordance with an approved design plan and that all applicable design controls were applied from initial concept through to production transfer. For medical device manufacturers subject to the FDA’s Quality Management System Regulation (QMSR), maintaining a DHF is a legal requirement. For manufacturers seeking ISO 13485 certification or EU market access under MDR 2017/745, the equivalent technical documentation obligations carry the same weight.

A well-structured DHF is not an administrative obligation that manufacturers fulfill once and file away. It is a living record that evolves with the device — capturing design inputs and outputs, verification and validation activities, risk management decisions, design reviews, and change history as they occur throughout the development process. A DHF that is incomplete, disorganized, or assembled retrospectively before an audit is both a regulatory risk and an engineering risk: it cannot reliably reconstruct the decisions that shaped the final design, and it cannot demonstrate that those decisions were made systematically.

This article covers what a DHF must contain, the regulatory frameworks that require it, the specific ISO 13485 and QMSR requirements that govern its structure, the connection to ISO 14971 risk management, common DHF failures and how to prevent them, and how eLeaP’s design and development management system supports DHF maintenance throughout the product lifecycle.

What Is a Design History File?

Definition and Regulatory Basis

The Design History File is the term used in QMSR — the FDA’s Quality Management System Regulation (21 CFR Part 820, effective February 2, 2026) — for the structured compilation of records that demonstrates a device was developed in accordance with the approved design plan. QMSR incorporates ISO 13485:2016 by reference, and ISO 13485 uses the equivalent term Technical File or, specifically within Section 7.3, refers to the design and development records that must be maintained. The DHF terminology is most familiar to US-market device manufacturers, while the EU equivalent under MDR 2017/745 Article 10(4) and Annex II refers to technical documentation; both require substantially the same underlying records.

The DHF is distinguished from two related but distinct records. The Device Master Record (DMR) — or Medical Device File in ISO 13485 terminology (Clause 4.2.3) — contains the specifications and procedures required to manufacture the device after it is released to production. The Device History Record (DHR) documents the production history of each finished device lot or unit. The DHF is the upstream record: it documents how the design was developed and approved, not how the device is manufactured or what was manufactured.

The DHF as a Living Document

A DHF is not assembled at the end of development. It is maintained throughout the development process, with records added as design activities are completed. An FDA investigator reviewing a DHF for a recently cleared device should be able to trace the complete development history chronologically — from the initial design plan through successive design reviews to the final validation and design transfer — because the records were captured as those activities occurred.

When a DHF is assembled retrospectively, it typically reveals gaps: design decisions that were made verbally and never documented, verification tests that were run informally and not formally recorded, design review meetings whose outcomes were not captured in meeting records, and risk assessments that were updated but whose prior versions were not retained. These gaps are both a compliance deficiency and a loss of institutional knowledge about why the design took its final form.

Core Purpose of a DHF in Medical Device Development

The DHF serves four primary functions in a medical device quality management system.

Regulatory compliance demonstration. QMSR and ISO 13485 Section 7.3 require that design and development activities be documented in a manner that demonstrates design controls were applied. The DHF is the record that makes this demonstration possible. During an FDA inspection or a notified body audit, the DHF is the primary evidence source for the design control requirements.

Product safety and efficacy assurance. The DHF documents that the device was designed to meet user needs and intended uses, that its performance was verified against specifications, and that it was validated against the conditions of actual use. This documentation chain is what allows regulatory reviewers to assess whether a device is safe and effective before it reaches patients.

Audit readiness. A well-organized DHF makes regulatory inspections and third-party audits manageable. Investigators and auditors can navigate the DHF to trace a design input through to the verification or validation activity that confirmed it was met, or to follow a risk control measure through from its identification in a risk analysis to its implementation in the design and its verification in testing. When the DHF is disorganized or incomplete, this traceability breaks down and the audit becomes a document retrieval exercise under time pressure.

Change control and post-market support. When a device requires a design change — whether in response to a field complaint, a CAPA investigation, a material change, or a regulatory requirement — the DHF provides the baseline against which the change is assessed. Change control for a design modification cannot be properly scoped without understanding what the original design was and why it was designed that way. A complete DHF makes post-market change control faster and more accurate.

Key Components of a Well-Structured Design History File

Design and Development Plan

The design and development plan is the foundational document of the DHF. It establishes the structure of the development project: the project phases or stages, the design controls activities required at each stage, the organizational responsibilities for each activity, the review points at which design progress will be formally assessed, and the interfaces between design and development teams. For medical devices, the plan must be appropriate to the complexity and risk classification of the device being developed.

The design and development plan is not a fixed document created at project initiation and never revisited. It should be updated as the project evolves — when phases are added, when scope changes, when resources change, or when design review findings require significant rework. Each revision of the plan should be version-controlled and retained in the DHF.

Design Inputs

Design inputs are the physical and performance requirements for the device that form the basis for design. They include user needs translated into engineering requirements, performance specifications derived from intended use and use environment, safety requirements, regulatory requirements applicable to the device type, and standards the device must conform to. Under QMSR and ISO 13485 Section 7.3.3, design inputs must be documented in a form that allows verification — that is, each input must be specific enough that a test, analysis, inspection, or demonstration can be used to confirm that the design output satisfies it.

Incomplete or ambiguous design inputs are a leading source of design control deficiencies. An input stated as ‘the device shall be easy to use’ cannot be verified. An input stated as ‘the device shall be operable by a trained nurse using one hand in 30 seconds or less, as confirmed by a simulated use study’ can be. The design inputs section of the DHF should demonstrate that all inputs were reviewed for completeness and adequacy before the design moved into the detailed development phase.

Design Outputs

Design outputs are the results of the design and development process — the documents, specifications, drawings, software, and procedures that define the device and enable its manufacture. Under QMSR and ISO 13485 Section 7.3.4, design outputs must be expressed in a form that allows verification against design inputs, must identify characteristics of the design that are essential for the safe and proper functioning of the device, and must be reviewed and approved before release.

The connection between design inputs and design outputs must be explicit in the DHF. The underlying regulatory obligation — under both QMSR and ISO 13485 Section 7.3 — is bidirectional traceability: objective evidence that each design input is addressed by a design output and that each output has been verified or validated. A traceability matrix mapping each design input to the design output that addresses it and to the verification or validation activity that confirms the output satisfies the input is the most widely used practical tool for documenting this traceability and is universally recognized by FDA investigators and notified body auditors as the demonstration of record. A DHF that contains design inputs and design outputs but no evidence that they are linked does not satisfy the design control requirement regardless of how it is organized.

Design Verification and Validation

Design verification and design validation are distinct activities with distinct documentation requirements, and a DHF that conflates them creates a significant compliance gap.

Design verification confirms that each design output meets its corresponding design input. Verification is performed against specifications — it answers the question ‘Did we build the design right?’ Verification methods include analysis, inspection, testing, and demonstration, depending on the nature of the requirement being verified. Each verification activity must be documented with a protocol specifying the method, the acceptance criteria, and the conditions under which the test will be performed, and a report recording the results and confirming whether the acceptance criteria were met.

Design validation confirms that the finished device meets the user needs and intended uses from which the design inputs were derived. Validation is performed under actual or simulated use conditions — it answers the question ‘Did we build the right design?’ For medical devices, design validation includes clinical evaluation, usability testing, and performance testing under conditions that represent the actual use environment. Design validation must be completed before device submission to regulatory authorities and must include testing of the production-equivalent device, not just a prototype.

Risk Management Documentation

ISO 14971:2019 is the governing standard for risk management in medical device development. It requires that manufacturers establish and document a risk management process covering the entire product lifecycle — from design concept through to post-market — and maintain a risk management file for each device that captures the risk analysis, risk evaluation, risk control measures, and residual risk assessment.

The risk management file is typically maintained as a component of the DHF or with explicit cross-references connecting the two. For DHF purposes, the critical connections are between risk control measures identified in the risk analysis and the design outputs that implement those measures, and between risk control verification and the design verification activities that confirm the risk controls are effective. A DHF that contains verification and validation records but cannot demonstrate their connection to the risk management analysis is missing the clinical justification for why those tests were performed.

ISO 14971 defines the risk management process framework — risk analysis, risk evaluation, risk control, and residual risk assessment — but does not mandate specific analytical tools by name. FMEA (Failure Modes and Effects Analysis) is the most widely used industry methodology applied to satisfy the risk estimation and risk control requirements of ISO 14971; its technical methodology is detailed in IEC 60812, with implementation guidance for medical devices in ISO/TR 24971. In practice, design FMEA is used to analyze potential failure modes in the device design and their effects on safety, while process FMEA analyzes manufacturing process steps for failure modes that could affect device quality. Both types, when used, should be documented in the risk management file with explicit connections to the risk controls implemented in the design and to the design verification activities that confirm those controls are effective.

Design Reviews

Design reviews are formal, documented evaluations of the design at defined stages in the development process. Under QMSR and ISO 13485 Section 7.3.5, design reviews must include representatives of all functions concerned with the design stage being reviewed and must be recorded. The record of each design review must identify the design being reviewed, the participants, any problems identified, and the actions required.

Design reviews serve a quality gate function: they are the structured opportunity for the design team and key stakeholders to assess whether the design is ready to advance to the next phase before resources are committed to that phase. A design review that identifies no issues is either a very well-developed design or a review that was conducted superficially — and the DHF should contain enough evidence to distinguish between the two.

Design Changes and Change History

Design changes that occur after the initial design approval must be evaluated, reviewed, and approved before implementation. Under QMSR and ISO 13485 Section 7.3.9, design changes must be identified and records maintained. The impact of each change on the device’s safety, performance, and regulatory status must be assessed, and the change must go through an appropriate level of verification and validation before the changed design is released.

The DHF must contain a complete change history for the device, from initial design through all approved modifications. Each change record should identify what changed, why it changed, how the impact was assessed, what verification or validation was performed on the changed design, and who approved the change. A DHF that cannot reconstruct the change history of a device leaves open the question of whether each change was properly evaluated — a question that arises with particular force when a field complaint is traced to a design modification.

Regulatory Frameworks Governing the DHF

QMSR — Medical Device Manufacturers in the United States

The Quality Management System Regulation (QMSR), which amended 21 CFR Part 820 effective February 2, 2026, incorporated ISO 13485:2016 by reference as the governing quality management standard for medical device manufacturers regulated by the FDA. The DHF requirement under QMSR is grounded in ISO 13485 Section 7.3, which requires that design and development records be maintained to demonstrate that design inputs have been met and that the design and development process resulted in a product that is safe and effective for its intended use.

Under QMSR, FDA investigators examining design controls will assess whether the DHF demonstrates that each element of the design control process was applied: whether design inputs were established and reviewed, whether design outputs are traceable to design inputs, whether verification and validation were performed and recorded, whether design reviews occurred and were documented, and whether design changes were controlled and evaluated. A DHF that is structurally complete but lacks the traceability links between these elements does not satisfy the design control requirement.

ISO 13485 Section 7.3 — Medical Device QMS Standard

ISO 13485 Section 7.3 covers design and development in detail, with subsections addressing design and development planning (7.3.2), inputs (7.3.3), outputs (7.3.4), review (7.3.5), verification (7.3.6), validation (7.3.7), transfer (7.3.8), changes (7.3.9), and the design and development file (7.3.10). Section 7.3.10 specifically requires that each manufacturer maintain a design and development file for each medical device or medical device family — the ISO equivalent of the DHF.

The ISO 13485 design and development file must include or reference records generated to demonstrate conformance to the requirements for design and development, and records of design and development changes. ISO 13485 uses ‘design and development file’ rather than ‘design history file,’ but the required content is substantially equivalent. Manufacturers seeking ISO 13485 certification should ensure their DHF structure maps to the Section 7.3 requirements explicitly, with traceability between the DHF contents and the specific subsections they satisfy.

A practical note on terminology for practitioners transitioning to QMSR: the terms “Design History File” and “Device Master Record” do not appear in the text of QMSR as it was finalized, because QMSR incorporated ISO 13485:2016 by reference and adopted ISO 13485 terminology. The regulatory terms of record are now “design and development file” (ISO 13485 Section 7.3.10) and “Medical Device File” (ISO 13485 Section 4.2.3). For FDA inspections under QMSR, investigators will be evaluating compliance with ISO 13485 requirements, not with the legacy section-by-section structure of the prior Quality System Regulation. Manufacturers should ensure that their internal procedures, training materials, and quality records use the ISO 13485 terminology — or at minimum cross-reference it — so that investigators can navigate directly to the relevant records without a terminology translation exercise.

EU MDR 2017/745 — European Market Technical Documentation

EU MDR 2017/745 Article 10(9) requires that manufacturers of CE-marked medical devices in the European Union put in place, document, implement, maintain, keep up to date, and continually improve a quality management system that covers, among other things, design and development planning, execution, and documentation. Article 10(4) specifically requires that manufacturers draw up and keep up to date technical documentation for each device. Annex II of EU MDR 2017/745 specifies the technical documentation requirements, which include device description and specification, design and manufacturing information, general safety and performance requirements, benefit-risk analysis, and post-market data. While the MDR does not use the term ‘Design History File,’ the technical documentation requirements under Annex II encompass the same categories of records.

For manufacturers seeking CE marking under EU MDR, the DHF maintained under QMSR or ISO 13485 serves as the foundation for the technical documentation package submitted to a notified body for conformity assessment. The key difference is that EU MDR technical documentation places additional emphasis on clinical evaluation — specifically the Clinical Evaluation Report required under MDR Article 61 and Annex XIV — which must demonstrate clinical safety and performance based on clinical data rather than solely on bench and simulated use testing.

How to Create and Maintain a Design History File

Starting the DHF at Project Initiation

The DHF should be established as a controlled record at the beginning of the design and development project, before design activities begin. The initial DHF entry is typically the approved design and development plan, which establishes the project scope, phases, design control activities, and responsibilities. Starting the DHF at project initiation rather than assembling it later ensures that records are captured as they are generated and that the DHF reflects the actual development history rather than a reconstruction.

Maintaining Traceability Throughout Development

The DHF’s value as a compliance demonstration depends on the traceability it provides between design elements. A traceability matrix maintained throughout the project — mapping design inputs to design outputs to verification activities to validation activities — is the most practical mechanism for ensuring that this traceability exists in the DHF. The matrix should be updated as design inputs are added or revised, as design outputs are generated, and as verification and validation activities are completed.

Traceability gaps discovered during DHF review before a regulatory submission or an audit are recoverable — the development team can trace the connection and document it. Traceability gaps discovered by an FDA investigator or a notified body auditor during an active inspection are not recoverable in the same way and typically result in observations, findings, or requests for additional information that delay the regulatory action.

Version Control and Change Management

Every document in the DHF must be version-controlled — each revision must carry a version identifier, an effective date, and a description of the change made. When a design document is revised, the prior version must be retained in the DHF with its revision history, not replaced. The DHF must be able to reconstruct the state of the design at any point in the development process, which requires that superseded document versions be accessible alongside the current versions.

Design changes after initial design approval must go through the change control process, with the DHF updated to include the change record, the impact assessment, the verification or validation performed on the changed design, and the approval of the change. A DHF in which the current design documents do not match each other because changes were made without updating all affected documents — and without a change record — is a significant compliance deficiency and an engineering risk.

Using a QMS Platform to Manage DHF Documentation

Managing a DHF in a shared drive, in email attachments, or across multiple disconnected systems introduces version control risks, traceability gaps, and audit readiness failures that are structural rather than individual — they arise from the architecture of the documentation system, not from any particular person’s failure to follow procedure. A QMS platform designed for medical device development manages the DHF as a structured, version-controlled record within the quality management system, with design control workflows that enforce the required activities and capture the required records as they are generated.

eLeaP’s design and development management module maintains the DHF within the same platform as the organization’s CAPA records, supplier quality records, and document control system. Design inputs link to design outputs. Verification protocols link to verification reports. Risk management records connect to design controls. When a design change is initiated, the change record connects to the affected DHF documents and to the CAPA or field complaint that prompted the change. The DHF is accessible as a navigable record — not a folder of files — supporting both day-to-day development management and inspection readiness.

Design Transfer: The Bridge Between DHF and Production

Design transfer — governed by ISO 13485 Section 7.3.8 — is the formal process of confirming that the design outputs are suitable for use in manufacturing before the device transitions from development to commercial production. The DHF must document that design transfer activities were completed: that design outputs were verified as reproducible in the full production environment and that any issues identified during transfer — tooling changes, process parameter adjustments, material substitutions — were evaluated through the change control process and resolved before commercial distribution.  Design transfer is not a single event at the end of development. For complex devices, transfer activities may be iterative, with engineering builds, pilot production runs, and process validation activities all generating DHF records. Each transfer activity that identifies a gap between the development design and the production process requires a change record in the DHF. The design transfer section of the DHF should demonstrate not just that transfer was declared complete, but that it was executed systematically and that any departures from the development design were evaluated and controlled before the final transferred design was released.

Software as a Medical Device and IEC 62304 Integration

For medical devices that include software — whether as an integral component of a hardware device or as Software as a Medical Device (SaMD) — the design and development file must incorporate the software lifecycle documentation required by IEC 62304, the standard for medical device software lifecycle processes. IEC 62304 documentation outputs that must integrate with the DHF include the software development plan, the software requirements specification (which maps to the software design inputs), the software architecture description, the software detailed design documentation, software unit test records, software integration test records, software system test records, and the software problem resolution records (defect tracking).  The software safety class assigned to the device software under IEC 62304 — Class A (no injury or damage), Class B (non-serious injury), or Class C (serious injury or death) — determines the rigor of the required documentation and the scope of the software verification and validation activities. Class C software requires the most extensive documentation, including full software unit verification records and documented software architecture reviews. For SaMD and software-dominant devices, the IEC 62304 documentation is typically the largest component of the design and development file by volume, and integrating it with the hardware design controls and the ISO 14971 risk management file in a coherent DHF structure is one of the primary DHF management challenges in modern medical device development.

Common DHF Failures and How to Prevent Them

Incomplete Documentation

The most common DHF deficiency observed in FDA inspections and ISO 13485 audits is incomplete documentation: design activities that occurred but were not recorded, or were recorded informally in meeting notes or emails that were never incorporated into the controlled DHF. Every design control activity — every design review, every verification test, every risk assessment update, every design change — must produce a controlled record that is incorporated into the DHF. Informal records are not DHF records.

Prevention requires establishing the DHF workflow at project initiation and enforcing it throughout development. Design teams working on accelerated timelines are most likely to defer documentation of design activities, creating a documentation debt that is typically larger and more consequential than the team expects. The discipline of capturing design control records as activities occur — not after the project is completed — is the single most important practice for maintaining a DHF that will withstand regulatory review.

Missing or Broken Traceability

A DHF that contains all required records but cannot demonstrate traceability between them fails to satisfy the design control requirement as effectively as a DHF with missing records. FDA investigators reviewing design controls will trace specific design inputs through to the verification activities that confirmed them and to the risk controls that address risks associated with those inputs. If those connections are not explicitly documented in the DHF — in a traceability matrix, in the design output documents, or in the verification records — the investigator cannot confirm that the design control process was applied systematically.

Prevention requires explicit traceability documentation rather than assumed traceability. Saying that a design output ‘addresses’ a design input is not traceability; a traceability matrix entry that maps the specific input to the specific output and identifies the verification test protocol and report that confirm the connection is traceability. The traceability matrix is a living document that must be maintained throughout development.

Failure to Control Design Changes

Design changes that are implemented without change control records in the DHF are a serious compliance deficiency. Changes made informally — because a component was substituted due to supply chain issues, because a test result was slightly out of specification and the engineer revised the specification rather than investigating the failure, or because a software update changed device behavior without a formal change request — leave the DHF in a state where the documents do not accurately reflect the device as it is manufactured and tested.

Prevention requires a change control culture that treats every modification to a controlled DHF document as a change control event. The change control threshold for DHF documents should be defined in the design and development procedures and should be conservative — it is better to process a minor change through formal change control than to determine after the fact that an undocumented change was significant.

Retrospective Assembly

A DHF assembled in the weeks before a regulatory submission or an audit by gathering documents from various team members’ computers and shared drives is not a controlled DHF — it is a document collection. The problems that retrospective assembly creates are predictable: version conflicts between documents that were individually updated but not reconciled, missing records that existed only in the memories of team members who have moved on, and inconsistencies between documents that were drafted independently and never formally reviewed against each other.

The only effective prevention is establishing the DHF as a controlled system from project initiation and maintaining it throughout development. A QMS platform that enforces document control for DHF records — requiring that all design control records be captured in the system as they are generated, with version control and approval workflows — makes retrospective assembly structurally impossible.

The Benefits of a Well-Structured Design History File

A comprehensive DHF that was maintained throughout development — rather than assembled before a regulatory submission — provides benefits that extend beyond compliance.

Faster regulatory submissions. A well-structured DHF with explicit traceability between design controls elements supports faster preparation of regulatory submissions. The design dossier or 510(k) substantially draws on DHF content; a DHF that is already organized around the required elements requires less compilation work than a DHF that must be reorganized for submission.

Reduced inspection risk. FDA investigators and notified body auditors completing design control reviews against a well-structured DHF spend less time searching for documents and more time evaluating their content. A DHF that is demonstrably complete and traceable reduces the likelihood of observations and findings related to design control documentation.

More effective design changes. When a post-market design change is required — whether for a CAPA, a field complaint response, or a planned product improvement — a complete DHF makes the change control process faster and more accurate. The change team can identify all design documents affected by the change, assess the impact against the original design inputs and risk controls, and scope the verification and validation required for the changed design without reconstructing the original development history.

Knowledge retention. Design teams change over time. Engineers leave, contractors rotate off, and institutional knowledge about why specific design decisions were made can be lost entirely. A DHF that captures not just what was decided but why — through design review records, change records that document the rationale for each modification, and verification records that show which tests were run and what they found — preserves the design rationale in a form that supports the device throughout its entire market life.

Conclusion

A well-structured Design History File is the foundational compliance record for any medical device manufacturer subject to QMSR, ISO 13485, or EU MDR requirements. Its value is not realized by assembling documents before a regulatory submission — it is realized by maintaining a controlled, traceable, and complete record of design and development activities as they occur throughout the product’s development. The DHF that withstands a rigorous FDA inspection or notified body audit is the DHF that was maintained with the same rigor during development that the inspection will evaluate.

The common failures — incomplete documentation, missing traceability, uncontrolled design changes, retrospective assembly — are structural problems that arise from treating the DHF as a documentation obligation rather than as a quality system tool. Addressing them requires DHF workflows embedded in the development process from project initiation, with version-controlled document management and audit trails that capture the development history as it occurs.

eLeaP’s design and development management module supports DHF maintenance throughout the device lifecycle — from design plan to design transfer to post-market change control — within the same validated platform as the organization’s quality management and training systems. For more information, visit quality.eleapsoftware.com/medical-device-qms/.