This guide covers what the design history file is, what design history file requirements apply under FDA QMSR and ISO 13485, exactly what it must contain, and how to build one that holds up under inspection.

What Is a Design History File?

A Design History File (DHF) is a structured compilation of records that documents the entire design and development history of a medical device. It is not a single document. It is a file, or a collection of records, that demonstrates your device was designed through a controlled, documented process aligned with your design plan.

The DHF must contain or reference all records necessary to show that design and development were conducted in accordance with your approved design plan and applicable regulatory requirements. Every design decision, every test result, every design review, and every design change must be traceable through the DHF.

FDA described it directly: the DHF captures the history of how your device came to be. If a record does not exist in the DHF, in FDA’s assessment, the activity either did not happen or was not controlled.

Design History File Requirements: What Regulations Say

Design history file requirements come from two sources that now operate in alignment.

Under the FDA’s Quality Management System Regulation (QMSR), effective February 2, 2026, the DHF requirement is carried forward from 21 CFR Part 820.30 and now operates under ISO 13485:2016 Section 7.3.10. The QMSR incorporates ISO 13485 by reference, meaning the standard’s design and development file requirements are now U.S. regulatory requirements.

ISO 13485 Section 7.3.10 states that organizations must maintain a design and development file for each medical device type or device family. The file must include or reference documents generated to demonstrate conformity to design and development requirements, and documents generated during design and development.

Under both frameworks, the DHF must be established at the start of development and maintained throughout. It is not a document created at the end of the design process. It is built in real time as design activities occur.

What the Design History File Must Contain

Design history file requirements specify that the DHF must contain or reference records covering the complete design control lifecycle. The following records are required.

Design and Development Plan

The design plan defines who is responsible for each design phase, the timeline and milestones, the design review points, and the verification and validation activities required. The plan must be established before development begins and updated as the project progresses. The DHF holds each version of the plan with its approval record.

Design Inputs

Design inputs are the functional, performance, safety, usability, and regulatory requirements your device must satisfy. They form the specification baseline against which your verification testing is measured. Every design input must be documented, reviewed, and approved. When an input changes, the change must be controlled and documented in the DHF.

Incomplete or vague design inputs are one of the most common causes of 510(k) additional information requests. FDA expects inputs to be specific, measurable, and traceable to user needs and applicable standards.

Design Outputs

Design outputs are the results of the design process: drawings, specifications, bill of materials, manufacturing instructions, and acceptance criteria. Outputs must meet every design input requirement and must be in a form suitable for manufacturing once transferred.

The DHF must contain the approved design output documents, including version history and approval records for each.

Design Review Records

Formal design reviews must occur at defined stages of development. Each review must have documented attendees, agenda, design status, action items, and outcomes. Design review records confirm that independent evaluation of the design occurred at defined milestones and that issues identified were formally tracked to resolution.

Design Verification Records

Verification confirms that design outputs meet design inputs. It requires documented test protocols written before testing begins, executed test results, and a formal statement of whether each design input was satisfied.

The DHF must contain both the approved protocol and the completed results record for every verification test. Undocumented or informal testing does not satisfy design history file requirements.

Design Validation Records

Validation confirms that the finished device meets the needs of the intended user under actual or simulated use conditions. It is distinct from verification. Verification asks whether you built the design right. Validation asks whether you built the right design.

Validation records in the DHF include usability testing protocols, clinical evaluation documentation, simulated use test results, and the formal validation summary report. All validation must be completed before the design is transferred to production.

Design Transfer Records

Design transfer documents confirm that the design has been correctly translated into production specifications. This includes evidence that production staff can manufacture the device to specification, that production processes are validated where required, and that the Device Master Record (DMR) reflects the completed, validated design.

Design Change Records

Every change to a design input, output, specification, or process after initial approval must go through a controlled change process. The DHF must contain change request records, impact assessments, approval records, and evidence that verification or validation was repeated where required by the change.

Undocumented design changes are one of the highest-risk DHF gaps. An inspector who identifies that a device in the field differs from the validated design without a corresponding change record will treat it as a major quality system nonconformance.

DHF vs DMR vs DHR: Understanding the Difference

Three related terms cause consistent confusion in medical device quality management. Understanding their differences is essential for building a correct documentation structure.

The Design History File (DHF) documents how the device was designed. It covers the design and development process from concept through design transfer. It is the development record.

The Device Master Record (DMR) documents how the device is manufactured. It contains the specifications, procedures, and drawings required to produce the device consistently. It is the production instruction set.

The Device History Record (DHR) documents that a specific production lot or unit was manufactured in accordance with the DMR. It is the production execution record.

These three records are distinct and must be maintained separately. The DHF feeds the DMR at design transfer. The DMR governs the DHR at production. All three are required by FDA QMSR and ISO 13485.

When to Start the Design History File

The DHF must start before design and development activities begin, not after.

This is the most common design history file requirement that teams violate. Many medical device companies, especially startups and early-stage teams, develop their device through informal iterations, generate test data, and then attempt to write DHF documentation after the prototype is working. This approach is not compliant and FDA inspectors recognize it.

A retroactively constructed DHF has no real-time design review records. It has no evidence that verification protocols were written before testing began. It has no audit trail showing when decisions were made and why. These gaps are evident to anyone reviewing the records.

The correct approach: create your design plan on day one. Open your DHF when you write your first design input. Document every review, test, and decision in real time as it happens.

Common Design History File Mistakes

These failures appear consistently across startup and established device company audits and inspections.

Starting the DHF after development is complete. Retroactive documentation creates traceability gaps, inconsistent timestamps, and records that do not accurately reflect the development process. This is the most inspected and most cited DHF failure.

Incomplete design inputs. Vague or incomplete inputs like “device must be safe” or “device must meet applicable standards” are not measurable and cannot be verified. Inputs must be specific, quantified, and tied to user needs or regulatory requirements.

Missing verification protocols. Executing tests without approved written protocols before testing begins means test results are uncontrolled. FDA expects to see that the protocol existed and was approved before the test was run, not written after the results were generated.

Skipping design reviews. Design reviews must be formal, documented, and include independent reviewers who are not directly responsible for the design element under review. Informal team meetings with no records do not satisfy design review requirements.

No change control for design changes. Every change to an input, output, or specification requires a documented change record. Design changes made informally, even minor ones, create audit trail gaps that become inspection findings.

DHF not linked to the risk management file. Risk management records must be integrated with design controls. Your hazard analysis informs design inputs. Your risk controls appear in design outputs. A DHF with no connection to the Risk Register is structurally incomplete under ISO 14971:2019 requirements.

How to Build a Design History File: A Practical Sequence

Building a defensible DHF follows the sequence of design controls activities. The DHF is not something you build separately. It is the output of a properly executed design controls process.

Before development begins: Create and approve your design and development plan. Define inputs for design reviews, verification, and validation. Open the DHF folder or system and begin version-controlling all documents from this point forward.

During design and development: Document every design input as it is defined and approved. Record every design review meeting with attendees, content reviewed, decisions made, and action items assigned. Write verification protocols before testing begins. Execute tests per the approved protocol and record results as they occur. Update the risk management file as design outputs are defined.

Through design verification: Compile all verification test results against their corresponding design inputs. Document any design changes that resulted from verification findings, including impact assessments and re-verification where required.

Through design validation: Document all validation activities, including simulated use testing, usability testing, and clinical evaluations where required. Produce a validation summary that confirms the device meets user needs and intended use requirements.

At design transfer: Document the transfer of design outputs to production. Confirm that all production processes can reproduce the validated device design. Establish the Device Master Record. Record formal transfer approval.

Post-transfer: Maintain the DHF as a controlled, version-tracked record set. Any post-transfer design change requires a change control record that references and updates the DHF.

Managing the Design History File in a Validated eQMS

A DHF managed in a paper binder, a shared folder, or a general-purpose document management system creates immediate design history file requirement gaps. Version control is manual. Approval records exist in email. Timestamps are not tamper-evident. Traceability between design inputs and verification results requires manual cross-referencing.

A validated eQMS purpose-built for medical device quality management solves each of these problems with a connected, traceable record structure.

Cloudtheapp’s Design Controls application manages the full DHF lifecycle in a single platform. Design plans, inputs, outputs, review records, verification protocols and results, validation records, and design change records are all created, approved, and linked within the system. Every record carries a compliant electronic signature and an immutable audit trail. Design inputs link directly to verification results. Risk records link to design outputs. Change records reference the specific DHF sections they affect.

When an FDA inspector or a certification body auditor asks to see your DHF, you produce a complete, traceable, timestamped record set rather than a binder assembled from scattered files and email threads.

For a broader view of how design controls fit into the full QMS structure for medical device startups, see QMS for Medical Device Startups: Building Compliance Infrastructure from Day One.

Conclusion

Design history file requirements are clear: the DHF must be established before development begins, maintained in real time, and contain complete, traceable records across the full design control lifecycle. A DHF built retrospectively, incompletely, or without a validated record management system will not satisfy FDA or ISO 13485 inspection expectations.

The good news is that a well-structured design controls process, executed correctly from day one, produces the DHF as a natural output. The records exist because the work was done in a controlled, documented way. The DHF is simply the organized collection of those records.

If your team is building a Design History File now and needs a validated eQMS platform that manages design controls, risk management, and document control in one connected system, book a free demo of Cloudtheapp and see how quality teams build complete, inspection-ready DHFs without the paper binder.

This post created by and appeared first on Cloudtheapp