The DHF under MDR: stop treating it as paperwork, make it the device story

A tidy Design History File (DHF) isn't an audit prop; it's the single-document story of how your device became safe enough to put on the market. I say this as someone who has rewritten several Technical Files at 02:00 before notified-body audits and who now prefers to prevent panic rather than manage it.

Under EU MDR the term "DHF" is American — the MDR expects a Technical Documentation (Annex II) or a Design Dossier (Annex III) depending on classification — but the principles are the same as FDA’s DHF and ISO 13485 Section 7.3 / 21 CFR 820.30. Per Article 10(9) your QMS must include adequate design and development processes; in practice this means the documentation must tell a coherent, traceable story from user needs to verification, validation and design transfer.

How I map the "DHF" to MDR requirements

I start by treating Annex II as a checklist with narrative. Annex II prescribes what the Technical Documentation should contain; Annex III applies for higher-risk devices (Design Dossier). The core mapping I use:

• User needs / Intended purpose -> design inputs (requirements)


• Design outputs -> drawings, software baselines, BOMs


• Risk management file (ISO 14971) linked to design artefacts


• Verification and validation reports (including clinical/bench evidence)


• Design reviews and records of decisions


• Design changes and design transfer evidence

I explicitly link each design input to at least one design output, verification activity, and risk control. That traceability — the thing auditors ask for first — lives in a traceability matrix or, better, a connected workflow inside the eQMS so it's not a static spreadsheet.

Practical structure I use (what works in audits)

I keep the Technical File modular and searchable. Each module is short, purposeful and contains links to evidence rather than copies of everything.

• Cover page: device ID, version history, regulatory status (class, notified body)


• Executive summary: intended use, key safety/performance claims, clinical strategy


• Requirements and architecture: user needs, design inputs, system architecture diagram


• Risk management: current risk file, FMEA summaries tied to design items


• Verification & validation: test plans, protocols, reports; trace to requirements


• Software: versioned source, cyber-security considerations, SOW/SDLC evidence


• Design reviews & minutes: attendees, decision log, open actions


• Design transfer: manufacturing instructions, acceptance criteria, supplier approvals


• Change control log: design changes, rationale, verification of change


• Annex: supplier evidence, biocompatibility, sterility, labelling drafts

I keep the "decision log" visible — auditors want to see why choices were made, not just what the final spec is.

The small practices that save hours

• Single source of truth: put links to live artefacts in the file. If a test report updates, the link points to the current approved report and the change history is auditable.


• Version strategy: snapshot a "release bundle" for each design freeze and reference that bundle in the Technical File. No one wants to hunt through 12 Jira tickets to reconstruct a released build.


• Integrate risk and design: every verified requirement should reference the risk controls that neutralise it. This is Annex II thinking brought to life.


• Use change impact mapping: when an engineer proposes a change, the map shows affected requirements, tests and labels. That reduces unnecessary CAPAs and surfaces needed verifications immediately.


• Design review cadence: short, focused reviews with a strict agenda. Capture action owners and due dates in the same system so follow-up is automatic.

Common audit traps (seen repeatedly)

• Missing linkage between requirements and tests. Auditors ask "how do you know you met the requirement?" — they expect a test or reasoning.


• Design transfer without objective evidence: having manufacturing drawings is fine, but you must show acceptance criteria and evidence of a pilot run or verification.


• Risk file updated after verification. If you only adjust risk severity after tests, you invited the question "did you design to that risk level in the first place?"


• Copy-paste reports with no signature or approval dates. Approval timestamps matter — they show the decision chronology.


• Treating the Technical File as static. MDR wants a living documentation set that reflects the current state of the device on the market.

Where tools matter (no vendor-speak, just practitioner needs)

You don't need fancy AI promises; you need features that make compliance usable:

• Traceability that links requirements, risks, tests, and CAPAs in one place


• Change impact mapping that surfaces downstream effects of a design change


• Connected workflow so design reviews trigger actions, and actions feed into automated CAPAs if needed


• Reviewability and audit trail: who approved what, when, and evidence attached

To be fair, an eQMS doesn't replace engineering judgment — but it reduces the paperwork friction so engineers actually keep records current.

Final checklist before you call your notified body

• Can you show the design story from user need to verification for any claimed feature?


• Is each design change justified, risk-assessed and re-verified?


• Are software baselines and release notes clearly tied to the tested build?


• Is the design transfer documented with acceptance criteria and evidence?


• Can you produce a release bundle (versioned snapshot) within 30 minutes?

Design controls under MDR are fundamentally about traceability and decision evidence. Granted, the paperwork is non-trivial, but when you make the Technical File the device’s narrative rather than an afterthought, audits become questions about engineering choices, not forensic reconstructions.

How do you keep your design documentation current when development cycles are short and engineers resist admin work?