The design file that has to answer to two regulators

Ask a US-based design engineer for the Design History File and an EU-focused colleague for the technical documentation, and until recently they'd hand over two differently organized binders built from mostly the same underlying records. Since February 2, 2026 the US side of that binder doesn't carry that name at all. FDA's Quality Management System Regulation reserved 21 CFR 820.30 outright; design control now runs through 820.10(c), which requires conformance to ISO 13485:2016 Clause 7.3, and the record set the standard calls for — a design and development file for each device type or family, defined at Clause 7.3.10 — is what practitioners still mean when they say DHF. The obligation didn't change. The name, and the clause that governs its structure, did.

That renaming is a small, mechanical fact, and also a useful one, because it exposes something that was already true before the QMSR took effect: the file was never organized around one question. It has always had to answer two.

Same records, organized around different questions

ISO 13485:2016 Clause 7.3.10 organizes the design and development file around your process: the plan, the inputs, the outputs, the reviews, the verification and validation activities, the transfer, the changes — records demonstrating that what you built matches what you said you'd build, in the order you said you'd build it. It is a file that answers did you follow your own plan?

EU MDR 2017/745 Annex II organizes technical documentation around a different question: does this specific device meet the general safety and performance requirements set out in Annex I? Its sections run through device description, information supplied by the manufacturer, design and manufacturing information, and — the part that has no clean equivalent in Clause 7.3 — a documented justification, verification and validation of the solutions adopted against each applicable GSPR, plus the benefit-risk analysis and risk management file. It is a file that answers can you prove, requirement by requirement, that this device is safe?

Where the two structures actually diverge

Most of the underlying evidence overlaps — the same verification test report can satisfy both files. The divergence is in what has to be indexed explicitly. Annex II expects a requirement-by-requirement crosswalk: each applicable GSPR mapped to the specific evidence that satisfies it. Clause 7.3.10 doesn't ask for that enumerated matrix; it asks for the process trail. A design and development file built only to 7.3.10 can be complete by FDA's structure and still hand a notified body an unmapped pile of otherwise-adequate evidence. A technical file built only to Annex II can carry a thorough GSPR matrix and still lack the traceable plan-to-output chain a QMSR-era inspection looks for.

What an index has to do that neither file does alone

The artifact that actually closes this gap isn't a third copy of the evidence — it's a crosswalk document: one axis listing each 7.3.10 design-and-development-file stage, the other listing each applicable Annex II / Annex I requirement, both pointing at the same underlying record locations. Built once, it lets a team maintain one evidence set and demonstrate it satisfies two differently shaped regulatory questions, instead of quietly maintaining two overlapping files that drift apart the first time either regulation is revised. That drift risk is not hypothetical — both sides of this comparison moved within the last two years, which is exactly the kind of source movement a mapped resource has to watch for, not just document once and forget.

Building this like everything else on the shelf

A design-and-development-file index built this way — Clause 7.3.10 stages cross-mapped to Annex II sections, each row citing its source and revision — is previewed in the launch catalog. If your team already maintains a working crosswalk between the two files, the shelf would rather refine ours against yours than publish a second-best version; send it over.