Technical file, DHF, DMR: untangled.

Each one answers a different question.

The confusion clears up the moment you stop thinking of these as four binders and start thinking of them as four questions:

• The EU technical file — "Why does this device conform?" A conformity argument defined by MDR Annexes II and III, addressed to a notified body or competent authority. It includes the GSPR matrix, the clinical evaluation, the risk file and the V&V evidence.
• The Design History File (DHF) — "How was this device designed?" The FDA design-controls record: plans, inputs, outputs, reviews, verification, validation, transfer and changes — the history that shows the design process was controlled.
• The Device Master Record (DMR) — "How do you build one?" The recipe: specifications, drawings, software releases, production and process specs, labeling, packaging, acceptance criteria.
• The Device History Record (DHR) — "How was this unit built?" The per-unit or per-batch production record proving each device was made according to the DMR.

The comparison in one table.

Note what's absent from the table: any document that exists in both jurisdictions. The EU has no DHF; the US has no technical file. What both regulators share is the evidence underneath.

Since February 2026, the US names changed too.

The FDA QMSR retired DHF, DMR and DHR as regulatory terms when it rebuilt Part 820 on ISO 13485:2016. The records live on under the standard's vocabulary: the design and development file (clause 7.3.10) carries the DHF's content, the medical device file (clause 4.2.3) carries the DMR's, and the production-records requirements carry the DHR's.

Two practical consequences. First, you don't have to rename anything — FDA has said the old structures remain acceptable — but your quality manual should map your structure to the ISO 13485 clauses, because that's the language inspectors now cite. Second, for teams serving both markets the renaming is good news: the US record-keeping vocabulary is now the same ISO 13485 vocabulary your EU QMS already uses.

The overlap is the point.

Lay the artefacts over each other and the same records appear in all of them:

• Requirements and design outputs — design inputs/outputs in the DHF sense; design information under MDR Annex II §3; the spec layer of the medical device file.
• The ISO 14971 risk management file — one file, cited by the technical file (Annex II §5), threaded through design controls, hooked into the QMSR via ISO 13485.
• Verification and validation evidence — DHF verification/validation records and the substance of MDR Annex II §6.
• Labeling and IFU — Annex II §2 for the EU; DMR content plus § 820.45 label inspection for the US.

That overlap is roughly 80% of the total volume. The remaining 20% is jurisdiction-specific assembly: the GSPR matrix and clinical evaluation structured for the MDR; the FD&C Act hooks (Part 803 complaint linkage, UDI records) for the US.

Maintain records once. Assemble views per regulator.

1. Organise by record type, not by regulator. One requirements baseline, one risk file, one V&V evidence set, one labeling set — each under document control with stable IDs and versions.
2. Treat the technical file and the design file as views. Each is an index that cites controlled records at specific versions. The EU index follows Annex II; the US mapping follows ISO 13485's clauses. Neither should ever contain a copy of a record that lives elsewhere.
3. Keep the indexes versioned too. When a cited record changes, the views that cite it are stale until re-checked. That re-checking — not writing the original documents — is the recurring cost of dual-market documentation, and the thing most worth automating.
4. Watch the seams. The findings that hurt are cross-document: an IFU claim the clinical evaluation doesn't support, a risk control no test verifies. Both regulators read across documents; your maintenance routine should too.

Common questions.