---
title: The Design History File (DHF): Documenting Your Development Story Under MDR
description: The Design History File documents your medical device development story. MDR does not use the term but ISO 13485 clause 7.3 requires exactly this. Here is how to build one.
authors: Tibor Zechmeister, Felix Lenhard
category: Quality Management Under MDR
primary_keyword: Design History File MDR
canonical_url: https://zechmeister-solutions.com/en/blog/design-history-file-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# The Design History File (DHF): Documenting Your Development Story Under MDR

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **The Design History File (DHF) is a term from the US FDA Quality System Regulation (21 CFR 820.30), not from the MDR. The MDR does not use the phrase anywhere in its text. The equivalent obligation under Regulation (EU) 2017/745 lives in MDR Article 10(9), which requires a quality management system covering product realisation including design and development — operationalised through clause 7.3 of EN ISO 13485:2016+A11:2021. What the FDA calls a DHF, the MDR world calls the design and development file, the output of ISO 13485 clause 7.3. They describe the same artefact in two regulatory dialects: the structured record of how a device was designed, reviewed, verified, validated, transferred to production, and changed over its lifecycle. If you are certifying in Europe, build the ISO 13485 clause 7.3 file. If you use the "DHF" label because your team is bilingual across FDA and MDR, use it — just know which regulation is actually governing you.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- "Design History File" is FDA terminology from 21 CFR 820.30(j). The MDR does not use the term. The equivalent under MDR is the design and development file — the output of EN ISO 13485:2016+A11:2021 clause 7.3.
- MDR Article 10(9) is the legal obligation to run a QMS that covers product realisation, including design and development. EN ISO 13485:2016+A11:2021 clause 7.3 gives presumption of conformity with that obligation for the design and development part.
- Clause 7.3 of EN ISO 13485:2016+A11:2021 is structured in sub-clauses 7.3.1 through 7.3.10: planning, inputs, outputs, review, verification, validation, transfer, change control, and the design and development file as the master record.
- The design and development file is not a standalone binder. Its outputs feed directly into the technical documentation required under MDR Annex II — particularly sections 3 (design and manufacturing information), 4 (GSPR conformity), 5 (risk management), and 6 (verification and validation).
- A clean clause 7.3 file is built in real time, as the project runs. A reconstructed one after the fact is the most expensive and least credible kind of documentation a startup can produce.

---

## Two development files, two fates

A three-person startup in Lower Austria walked into its first MDR audit with a design and development file that would fit on a single shelf. Nothing extra. The structure followed clause 7.3 of EN ISO 13485:2016+A11:2021 exactly. Design planning was one document, dated early in the project and updated as the plan changed. Inputs were traceable to the intended purpose and to risk management. Outputs were under document control. Every design review had minutes. Verification and validation records pointed back to specific inputs. The design transfer to production was recorded. The change log was live. The auditor opened the file, asked to trace one requirement end-to-end, and got an answer in minutes. The audit closed with zero non-conformities on the design side.

In the same quarter, a different company — based in Graz — was still not on the market. The product could have shipped in 2020. The design file had been built with maximum caution: every possible document, every conceivable review, every belt-and-braces sign-off procedure. Thousands of pages. Every change produced a cascade of updates across linked documents that took weeks to push through. Every review cycle added more structure than it removed friction. The design file became so heavy that the team stopped making design changes — because each change meant another paperwork sprint. The product had been regulatory-ready on paper for years. It had not been commercially ready, because the discipline of the file had swallowed the discipline of the product.

Same regulation. Same standard. Two opposite failure surfaces. The first company built a disciplined minimum. The second built a disciplined maximum and was drowned by it. The design and development file is the place where this choice shows up most clearly, because it is the record of a process that runs for the entire life of the device.

## Where the term "Design History File" comes from

The phrase "Design History File" has a specific legal origin. It appears in the United States in 21 CFR 820.30(j), the Design Controls section of the FDA Quality System Regulation. The FDA defines the DHF as a compilation of records which describes the design history of a finished device. Everything a US manufacturer does under 21 CFR 820.30 — design planning, inputs, outputs, review, verification, validation, transfer, changes — feeds into the DHF as the master record.

The MDR does not use the term "Design History File" anywhere in Regulation (EU) 2017/745. Not in the articles. Not in the annexes. The MDR has no clause called "design controls" by that name either. What the MDR does is require, under Article 10(9), that every manufacturer establish a QMS covering product realisation, including design and development. The standard that gives presumption of conformity with that QMS obligation is EN ISO 13485:2016+A11:2021, and it is in clause 7.3 of that standard that the structure equivalent to FDA design controls is specified.

The two systems describe almost the same artefact. The FDA DHF and the EN ISO 13485:2016+A11:2021 clause 7.3 design and development file are substantially aligned — this is deliberate. ISO 13485 was written to be a global standard that works for both FDA and EU regulatory systems, which is why a manufacturer certified under EN ISO 13485:2016+A11:2021 is already most of the way toward FDA design controls compliance and vice versa.

The reason teams use the phrase "DHF" in European MDR contexts is mostly pragmatic. Many startups hire regulatory people who worked in US MedTech first. Many tools, templates, and training courses use FDA language. "DHF" is shorter than "the design and development file output of ISO 13485 clause 7.3." It gets the point across. The risk is that using FDA language can blur which regulation is actually governing your device. If you are placing the device on the EU market, the Regulation that governs you is the MDR, and the standard you conform to is EN ISO 13485:2016+A11:2021. The DHF label is shorthand. The underlying obligation is MDR Article 10(9).

## What EN ISO 13485:2016+A11:2021 clause 7.3 actually requires

Clause 7.3 of EN ISO 13485:2016+A11:2021 is the design and development section. It is organised into sub-clauses that correspond to the phases of a design project. A startup that builds its design file against these sub-clauses ends up with exactly what the MDR needs — because clause 7.3 is the structure that provides presumption of conformity with the design and development portion of MDR Article 10(9).

The sub-clauses cover planning, inputs, outputs, review, verification, validation, transfer, change control, and the design and development file as the master record that ties them together. Each one produces specific records. Each one has to be genuinely done — not templated and forgotten. Together, they are the structure of a credible design history under MDR.

### 7.3.1 — General and 7.3.2 — Design and development planning

The general clause establishes that the organisation must document procedures for design and development and apply them. The planning sub-clause requires a design and development plan for each project. The plan identifies the stages of the project, the review, verification, validation and transfer activities at each stage, the responsibilities and authorities, the methods for ensuring traceability, and the resources needed. The plan is a living document. It is updated as the project progresses and the updates are controlled.

Startups often skip the plan because it feels bureaucratic. Writing a one-page honest plan at the start is ten times faster than reconstructing a plausible plan at the end, and the reconstruction is visible to any competent auditor.

### 7.3.3 — Design and development inputs

The inputs are the functional, performance, usability, safety, regulatory, and other requirements the device must meet. They have to be traceable to the intended purpose, to the applicable General Safety and Performance Requirements in Annex I of the MDR, to the applicable harmonised standards, and to the risk management outputs. Inputs are reviewed for adequacy — they must be complete, unambiguous, verifiable, and not conflict with each other. The input set is approved before design work proceeds in earnest.

This is the sub-clause where most downstream problems are born. Sloppy inputs produce unverifiable outputs, untestable verification protocols, and a risk file that drifts away from the design.

### 7.3.4 — Design and development outputs

The outputs are the design information that allows the device to be produced, verified, and used safely. Drawings, specifications, software source and binaries, manufacturing instructions, labelling, IFU content, service and maintenance information. Outputs must be in a form suitable for verification against inputs and must be approved before release. Outputs that are critical to the safe use of the device must be identified explicitly.

Every output traces back to at least one input. If an output exists that traces to nothing, either an input is missing or the output is not needed. Both are worth fixing.

### 7.3.5 — Design and development review

At planned stages, systematic reviews of the design are conducted. Reviewers evaluate the ability of the design results to meet the requirements, identify any problems, and propose necessary actions. Records of the reviews and their outcomes are maintained. Reviewers include representatives of functions concerned with the stage being reviewed, but crucially, at least one reviewer who is independent of the work being reviewed. That independence matters to the auditor.

### 7.3.6 — Design and development verification

Verification confirms that the design outputs meet the design inputs. This is the engineering question: did we build the device right, against the specification? Verification activities are planned, executed, and recorded. Where the intended use requires the device to be connected to or interact with other devices, verification includes confirmation that the design outputs meet the inputs when so connected or interfaced.

### 7.3.7 — Design and development validation

Validation confirms that the finished device meets the user needs and intended use. This is the clinical and usability question: did we build the right device, for the real use? Validation is performed on representative product — the released or production-equivalent device, not an early prototype. Validation records are maintained. For medical devices, clinical evaluation (under MDR Article 61 and Annex XIV) feeds into validation, because the demonstration that the device performs in its intended clinical context is itself part of the validation case.

### 7.3.8 — Design and development transfer

Transfer is the hand-off from design to manufacturing. The design outputs are confirmed as suitable for manufacturing before they become production specifications, and the results and conclusions of the transfer are recorded. This sub-clause is small in the standard and huge in practice. A design that works in the lab but has not been transferred cleanly produces manufacturing problems, complaints, and CAPA findings long after launch. Transfer is where the design file closes the loop with the production process.

### 7.3.9 — Control of design and development changes

Changes to the design are identified, reviewed, verified, validated as appropriate, and approved before implementation. The review of changes includes evaluation of the effect of the changes on constituent parts and on product already delivered. Change records — what changed, why, who approved, what evidence supports the change — are maintained. Under MDR, significant design changes can also trigger additional Notified Body involvement depending on the conformity assessment route. The change log is the lifeblood of a living design file.

### 7.3.10 — Design and development files

This is the sub-clause that explicitly names what a US team would call the DHF. EN ISO 13485:2016+A11:2021 clause 7.3.10 requires that the organisation maintain a design and development file for each medical device type or medical device family. The file contains or references the records generated to demonstrate conformity to the requirements for design and development and the records for design and development changes. This file IS the MDR-world equivalent of the DHF. It is not called that in the standard, but clause 7.3.10 is where the master record obligation lives.

## How the design and development file feeds MDR Annex II

The design and development file is not the technical documentation. It is the engine that produces large parts of the technical documentation required under MDR Annex II.

Annex II of Regulation (EU) 2017/745 specifies what the technical documentation must contain. Several sections of Annex II are fed almost entirely by clause 7.3 outputs. Section 3 of Annex II (design and manufacturing information) is populated by the design outputs and the design transfer records. Section 4 (the GSPR checklist against Annex I) is populated by the traceability between design inputs, design outputs, verification results, and the applicable General Safety and Performance Requirements. Section 5 (benefit-risk analysis and risk management) is populated by the risk file that clause 7.3 integrates with at inputs, outputs, and change control. Section 6 (product verification and validation) is populated directly by the verification and validation records from 7.3.6 and 7.3.7.

If the clause 7.3 file is clean, Annex II assembles itself. The technical documentation becomes a re-presentation of design records in the shape Annex II requires, with the GSPR checklist as the connective tissue. If the clause 7.3 file is messy, Annex II has to be reconstructed in parallel and the two files drift apart. Drift is where audit findings live. See post 201 on technical documentation under MDR and post 202 on the Annex II section-by-section structure for how the Annex II file takes its shape from these inputs.

## How a startup team should actually organise this

Three-person companies can run a fully compliant clause 7.3 file. Fifty-person companies can drown in one. The difference is not team size. It is discipline about what belongs and what does not.

Start with one folder structure that mirrors clause 7.3 sub-clauses. Planning, inputs, outputs, reviews, verification, validation, transfer, changes, and the master file index. Every document goes in the folder that matches the sub-clause it serves. Document control (per EN ISO 13485:2016+A11:2021 clause 4.2.4) runs on every document in the folder from day one. Every document has an owner, a version, and an approval state.

Write the design and development plan in the first week of regulated development, even if it is one page. Update it deliberately whenever the project changes. Build the input list next, traced to intended purpose, GSPR applicability, and risk management outputs. Review the inputs for completeness before investing in major design work. Generate outputs against the inputs in the normal course of engineering work, and record them as outputs — not just as engineering artefacts that happen to exist in a repo. Run design reviews on a real cadence, with at least one independent reviewer, and keep the minutes. Verify against inputs when outputs are mature. Validate against user needs on production-representative device. Record the transfer to manufacturing. Control every design change through the same loop. Maintain the master file index so someone unfamiliar with your team could navigate the file in under a minute. For the full operational playbook of building the file on week one, see post 204.

This is not more work than the Graz pattern. It is less work, done in the right order, with fewer documents that each carry their weight. See posts 290 through 297 in this cluster for the deep dives into each individual sub-clause — planning, inputs, outputs, reviews, verification, validation, transfer, and change control.

## Common gaps and failure modes

Across startup audits we have seen, the same design-file gaps recur. A plan that was written once and never updated as the project changed. Inputs that are not traceable to the intended purpose or to GSPR items. Outputs that drifted from the input specification without a change record. Design reviews with no independent reviewer, or with minutes that read as formalities. Verification protocols that test what was easy to test rather than what the inputs required. Validation performed on prototypes rather than on production-representative devices. A transfer step that never happened explicitly — engineering simply started producing units and the production specification was the engineering repo as it stood that week. Change logs that fell behind the real engineering work. A master file index that does not exist, leaving the auditor to assemble the design history from what the team can find in the moment.

None of these is exotic. Each of them is avoidable with a clause 7.3 file built in real time against the structure in the standard.

## The Subtract to Ship angle on design files

Subtract to Ship for the design and development file is straightforward in principle and hard in practice. Every document in the file must satisfy a clause 7.3 sub-clause, and through that clause, an MDR Article 10(9) obligation. If it does not, it comes out. Every review that is held must serve a planned stage in the design plan. Every change recorded must reflect a real change to the design, not paperwork theatre. Every document that does not earn its place by traceability to clause 7.3 or to an MDR requirement is cut.

The Graz over-documentation pattern is what happens when this discipline is missing. The team equates more documents with more rigour, adds everything anyone asks for, and ends up with a design file that is paralysed by its own weight. The Lower Austria three-person pattern is what happens when the discipline is present. The file is small, every document earns its place, the team can update it quickly, and the design itself stays moveable. Both teams were running EN ISO 13485:2016+A11:2021. One used it as a tool. The other let it become an obstacle. See post 065 for the general Subtract to Ship framework and post 280 on building a lean QMS for how the same discipline applies across the broader QMS.

## Reality Check — Where do you stand?

1. Can you point to clause 7.3 of EN ISO 13485:2016+A11:2021 and name each of its sub-clauses, and for each one show where in your design file the corresponding records live?
2. Does your design and development plan reflect the current project, or is it the version from the first month, unchanged since?
3. Can you trace one design output through to the input it satisfies, the verification that confirms it, the validation where relevant, and the GSPR item in Annex I it contributes to?
4. Do your design reviews have genuinely independent reviewers, or are the "independent" reviewers people adjacent to the work who signed as a formality?
5. Was your validation performed on production-representative product, or on early prototypes that were never the thing you actually ship?
6. Does your change control capture every substantive design change in real time, or do changes get reconstructed into the file in batches before audits?
7. If you use the term "DHF" in your team, does everyone understand that the MDR obligation is MDR Article 10(9) and the standard is EN ISO 13485:2016+A11:2021 clause 7.3, and that "DHF" is FDA shorthand being borrowed?
8. Could a competent outsider open your design file today and, using only the clause 7.3 structure as a map, find the planning, inputs, outputs, reviews, verification, validation, transfer, and change records without asking your team any questions?

Any "not yet" answer is a place to start work before the next audit window.

## Frequently Asked Questions

**Does the MDR require a Design History File?**
The MDR does not use the term "Design History File" anywhere in Regulation (EU) 2017/745. The MDR requires a QMS under Article 10(9) that covers design and development as part of product realisation. The harmonised standard that provides presumption of conformity with this obligation is EN ISO 13485:2016+A11:2021, and clause 7.3 of that standard specifies the design and development file that serves the same function as the FDA DHF.

**Are the FDA DHF and the ISO 13485 clause 7.3 file the same thing?**
They are substantially aligned but not literally identical. Both are master records of the design history — planning, inputs, outputs, reviews, verification, validation, transfer, and changes. ISO 13485 clause 7.3 was written to harmonise with FDA design controls in 21 CFR 820.30, which is why manufacturers certified to EN ISO 13485:2016+A11:2021 are most of the way to FDA design controls compliance. Small wording differences exist. A team operating in both jurisdictions typically maintains one design file structured to satisfy both regulations.

**If I call our file a "DHF" in our European QMS, is that a problem?**
Not a problem in itself, as long as the underlying file satisfies EN ISO 13485:2016+A11:2021 clause 7.3 and everyone on the team understands that MDR Article 10(9) is the legal obligation. Notified Bodies are used to seeing FDA-style terminology in files from US-origin companies. The label matters less than whether the file meets the standard and traces to the Regulation.

**Where in MDR Annex II does the design and development file end up?**
The outputs of clause 7.3 feed Annex II section 3 (design and manufacturing information), section 4 (the GSPR checklist), section 5 (benefit-risk analysis and risk management), and section 6 (product verification and validation). A clean clause 7.3 file makes Annex II straightforward to assemble. See post 201 on technical documentation under MDR and post 202 on the Annex II section-by-section structure.

**Can a three-person startup really maintain a compliant clause 7.3 file?**
Yes. We have seen it close out first audits with zero non-conformities. The discipline required is not headcount — it is building the file in real time, in the structure clause 7.3 specifies, with document control from day one, and resisting the urge to add documents that do not earn their place. Three disciplined people routinely outperform thirty who are assembling the file retrospectively.

**How long must the design and development file be kept?**
The file is part of the technical documentation under Article 10(8) of Regulation (EU) 2017/745, which requires manufacturers to keep technical documentation available for at least 10 years after the last device has been placed on the market. For implantable devices, the period is at least 15 years. Superseded versions are retained within that window under the document control procedure.

## Related reading

- [What Is a Quality Management System for Medical Devices?](/blog/what-is-quality-management-system-medical-devices) — the pillar post for the Quality Management Under MDR cluster and the home of the Article 10(9) obligation this post sits inside.
- [Technical Documentation Under MDR](/blog/technical-documentation-under-mdr) — how the design and development file feeds Annex II.
- [MDR Annex II Structure, Section by Section](/blog/mdr-annex-ii-structure) — the Annex II shape that consumes the clause 7.3 outputs.
- [How to Build Technical Documentation From Day One](/blog/build-technical-documentation-from-day-one) — the first-week playbook that pairs with starting the clause 7.3 file early.
- [How to Build a Lean QMS for an MDR Startup](/blog/build-lean-qms-mdr-startup) — the broader QMS context this design-controls cluster sits inside.
- [Design and Development Planning Under MDR](/blog/design-development-planning-mdr) — deep dive on clause 7.3.2.
- [Design Inputs Under MDR](/blog/design-inputs-mdr) — deep dive on clause 7.3.3.
- [Design Outputs Under MDR](/blog/design-outputs-mdr) — deep dive on clause 7.3.4.
- [Design Reviews Under MDR](/blog/design-reviews-mdr) — deep dive on clause 7.3.5.
- [Design Verification Under MDR](/blog/design-verification-mdr) — deep dive on clause 7.3.6.
- [Design Validation Under MDR](/blog/design-validation-mdr) — deep dive on clause 7.3.7.
- [Design Transfer Under MDR](/blog/design-transfer-mdr) — deep dive on clause 7.3.8.
- [Design Change Control Under MDR](/blog/design-change-control-mdr) — deep dive on clause 7.3.9.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology the design-file discipline in this post applies.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(9) (quality management system obligation), Annex II (technical documentation). Official Journal L 117, 5.5.2017.
2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes, clause 7.3 (Design and development), sub-clauses 7.3.1 through 7.3.10.
3. US Code of Federal Regulations, Title 21, Part 820.30 (Design Controls), including 820.30(j) (Design History File). Cited for terminology origin only — the FDA QSR is not the governing law for devices placed on the EU market under MDR.

---

*This post is part of the Quality Management Under MDR cluster in the Subtract to Ship: MDR blog, linking up to the QMS pillar at post 276. Authored by Tibor Zechmeister and Felix Lenhard. The MDR is the North Star. EN ISO 13485:2016+A11:2021 is the tool. "Design History File" is a label borrowed from FDA land — useful shorthand, never the legal basis. The legal basis in Europe is MDR Article 10(9), and the structured file that satisfies it is the one clause 7.3 tells you how to build.*

---

*This post is part of the [Quality Management Under MDR](https://zechmeister-solutions.com/en/blog/category/quality-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*