What is a Design History File (DHF) and What Goes in It

The DHF is the documentary evidence that a medical device was designed and validated in a controlled way. It is the document 21 CFR Part 820.30(j) requires you to maintain for every finished device. An FDA inspector who asks to see your DHF is asking to see proof that your design controls worked: that inputs were defined, that outputs were verified against those inputs, that risks were identified and managed, and that the design was transferred to manufacturing in a controlled state.

If the file is incomplete, it is not just a documentation finding. It raises the question of whether the design process was actually controlled at all. A missing verification record for a design input does not mean the verification was not performed. From a regulatory standpoint, it means the same thing as if it was never performed. What is not documented did not happen.

DHF definition and legal basis

The statutory definition comes from 21 CFR 820.30(j): "Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part."

Two words in that definition carry most of the regulatory weight: "contain or reference." The DHF does not need to hold every document physically within the file itself. It can reference documents stored elsewhere, provided those documents are controlled and retrievable at the time of inspection. If the reference is to a document that cannot be produced, the reference is not equivalent to the record.

ISO 13485:2016 section 7.3 also requires design and development records, making the DHF requirement applicable to manufacturers seeking ISO 13485 certification whether or not they are subject to FDA jurisdiction. For class II and III medical devices sold in the United States, both sets of requirements apply.

The most useful mental model for the DHF is that it is the biography of the device design from concept through design transfer. If someone with no prior knowledge of the device needed to understand how it was designed, what requirements it was designed to meet, how those requirements were verified, and how the production process was established, the DHF should answer every one of those questions without requiring them to interview anyone.

What goes in the DHF

The design and development plan is the first element. It is the roadmap that was established at the beginning of development defining how the design would be conducted: the phases of development, the milestones at which design reviews would be held, the roles and responsibilities of the development team, and the criteria for advancing from one phase to the next. The plan that was approved at the start of development goes in the DHF, along with any approved revisions to the plan made as development proceeded.

Design inputs are the user needs and regulatory requirements that the design must satisfy. They are the requirements the device must meet. Every design input must be complete, unambiguous, and verifiable. "The device shall be comfortable to use" is not a design input. "The device shall require less than 5 N grip force to actuate during normal use" is a design input. If a design input cannot be verified, it should not be a design input. Restate it in measurable terms before it enters the DHF.

Design outputs are the drawings, specifications, software source code, labeling, and any other documentation that defines the finished device. Design outputs must be expressed in terms that can be verified against design inputs. If a design input requires a burst pressure of 450 kPa minimum, the design output is the specification on the relevant drawing stating the wall thickness and material grade that achieves that burst pressure. The link between input and output must be traceable.

Design review records capture who attended each formal design review, when it was held, what was reviewed, what findings were raised during the review, and how each finding was resolved before the project was allowed to proceed to the next phase. The record is not a summary. It is a documented account with named individuals and specific findings. A design review record that says "design was reviewed and approved" with no list of attendees and no finding log is not a compliant design review record.

Design verification records are the test reports, analysis reports, and inspections that demonstrate design outputs meet design inputs. Every design input must have corresponding verification evidence. If the DHF contains 11 design inputs and the verification section contains test reports covering 8 of them, the gap is an automatic finding. The traceability matrix, which maps each design input to its verification method and the report number where the result is recorded, is the tool that makes this traceable. Include it.

Design validation records are different from verification records and the distinction matters. Validation addresses whether the device meets user needs and intended use under actual or simulated use conditions. This includes clinical data, simulated use testing with representative end users, and usability studies. A device can meet all of its design inputs and still fail design validation if the inputs themselves did not capture what the user actually needs. Validation is the test of the requirements, not just the test of the design against the requirements.

Design transfer records document that the design was transferred to manufacturing in a state that can be reproduced consistently. This is where many DHFs have gaps. The design transfer record should include the first article inspection results showing the first production units met design outputs, the process validations that were completed before commercial production, and any design changes made during the transfer process and how they were controlled. If a drawing was revised during transfer because a dimension was not achievable with production tooling, that revision and its verification must be in the DHF.

Design change records cover every engineering change notice or change request raised during the design phase, with traceability back to the design input that was affected by the change and documentation of how the change was verified. Changes made during design development are common. The DHF must show they were controlled, not that they did not happen.

DHF vs DMR vs DHR: what each one is

The three documents are related but serve distinct purposes at different points in the product lifecycle. Confusing them in an audit is a common and avoidable problem.

The DHF is the history of how the device was designed. It is created and built up during development. After design transfer is complete, the DHF is closed and archived. It contains design inputs, design outputs, verification records, validation records, transfer records, and all design change records from the development period. Once closed, the DHF is not modified except to add post-market change records under formal change control.

The DMR, or Device Master Record, is the current approved specification for the device. It contains the current drawings, the current manufacturing procedures, the current quality control specifications, and the current packaging and labeling specifications. The DMR is the recipe. It is a living document that is updated whenever a design or process change is approved under change control. The DMR reflects the state of the device as it is manufactured today.

The DHR, or Device History Record, is the manufacturing record for a specific lot or unit. It proves that a specific batch was manufactured in accordance with the DMR. If the DMR specifies a seal dwell time of 3.0 seconds plus or minus 0.1 seconds, the DHR contains the recorded seal time for each unit or lot. The DHR is generated during manufacturing and is retained as objective evidence that production occurred per the approved specification.

An inspector asking for the DHF wants to see how the device was designed. An inspector asking for the DMR wants to see the current approved specification. An inspector asking for the DHR wants to see the manufacturing record for a specific lot. All three must exist. All three must be controlled. Conflating them in a response to an inspector signals documentation system confusion.

How the DHF is typically organized

Lifecycle-phase organization is the most common and the most auditor-friendly structure. The DHF is divided into sections corresponding to the major phases of development: concept and feasibility, design development, design verification, design validation, and design transfer. Each section contains the records generated during that phase. An inspector working through a phase-based DHF can trace the progression of the design from initial requirements to final transfer without jumping between sections.

Chronological organization is simpler to maintain during development but becomes difficult to navigate as the design evolves over multiple years. When verification testing spans 18 months and produces 40 test reports, a chronological file requires the inspector to search through all records to find the verification evidence for a specific design input. A phase-based structure with a traceability matrix eliminates that search.

What FDA expects to find quickly during an inspection is a clear link between each design input and the verification evidence for it. If an inspector asks "how do you know the device meets requirement 7," the answer should be immediately findable in the DHF: "Design input 7 is on page 3 of the design input document. The verification method is pressure cycle testing per test protocol TP-007. The test report is TR-007, section 4.2, which shows all units passed at a burst pressure of 520 kPa against a minimum requirement of 450 kPa." If that answer requires a 20-minute search through the file, the organization of the DHF is a problem independent of whether the testing was actually done.

Common DHF gaps that become FDA findings

Design verification does not cover all design inputs. This is the most common finding and the most straightforward to identify if a traceability matrix exists. The matrix exposes the gap immediately. Without a matrix, the gap survives multiple internal audits and is found by the FDA inspector during the site visit. Build the traceability matrix at the start of verification, not after.

Design changes made during development were not routed through the formal change control system. During prototyping, a dimension was changed at the bench because the original dimension caused an assembly problem. The engineer updated the CAD model and the working drawing. An engineering change notice was never opened. Six months later, the drawing in the DHF does not match the device that was validated. This is a design control breakdown, not a paperwork issue. The fix requires a retrospective change record, a risk assessment of the change, and verification that the validation remains valid for the revised design.

The risk management file was not updated after design changes. A new design feature was added during the design development phase after the initial FMEA was completed. The risk file was never revised to assess the failure modes introduced by the new feature. Under ISO 14971:2019, risk management is a lifecycle activity. A risk file that was completed at one point and never revised despite design changes is not a risk management file. It is a risk snapshot.

Usability validation was conducted with engineers. The simulated use study involved five engineers who had been working on the device for two years. They completed the tasks correctly and rated the device highly on usability. The problem is that representative end users, defined as people who match the intended use population in training, experience, and expectations, are the required study population. Engineers are not representative end users for a device designed for emergency medical technicians or home patients. The study must be repeated with the correct population before the DHF can be considered complete for a 510(k) submission or PMA.

For help building a compliant DHF structure or auditing an existing one for gaps, see the Aptibot documentation service. For related guides, see the post on process FMEA and process validation for medical devices.