The Design History File (DHF) in 2026: what QMSR changed

For decades, the Design History File (DHF) was the record a medical device manufacturer maintained to prove a device was developed under a compliant design-control process. As of February 2, 2026, the term has changed — but the requirement behind it has not. This guide explains what the DHF is, what belongs in it, and exactly what the FDA’s QMSR transition did to it.

What the DHF is (and is for)

Under the former Quality System Regulation (21 CFR 820.30), the DHF was the compilation of records describing the design history of a finished device. Its job was singular: demonstrate that the design controls in your plan were actually followed, from design inputs through to a verified, validated, and transferred design.

A complete design record typically contains the design and development plan, design inputs, design outputs, design reviews, verification and validation results, design transfer records, and the full design change history. Read together, those records tell an auditor the story of how a requirement became a safe, effective device.

What QMSR changed in February 2026

On February 2, 2026, the FDA’s Quality Management System Regulation (QMSR) took effect, amending 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. As part of that harmonization, the FDA’s legacy record terms were retired from the regulation text and aligned to ISO terminology:

• Design History File (DHF) → Design and Development File (DDF) — ISO 13485 clause 7.3.10.
• Device Master Record (DMR) → Medical Device File (MDF) — clause 4.2.3.
• Device History Record (DHR) → production and traceability records — clauses 7.5 and 8.2.6.

The critical point: the concepts and obligations did not disappear. The DDF carries the same purpose the DHF did — documented evidence that design and development controls were followed. By satisfying the corresponding ISO 13485 requirements, you satisfy the former DHF requirements. In practice, investigators will now cite ISO clause numbers rather than 820.30, and “Design and Development File (formerly DHF)” remains a perfectly acceptable internal reference during the transition.

Many teams are keeping a crosswalk that maps their legacy DHF/DMR/DHR evidence to the ISO 13485 clauses, so existing documentation maps cleanly without renaming everything overnight.

Traceability is the spine of the file

Whatever you call it, the file only holds up if the records inside it connect. Design inputs must trace to design outputs; outputs must trace to the verification and validation that confirms them; and changes must trace through all of it. That chain is, in effect, a requirements traceability matrix for your device — and it’s the first thing an auditor follows.

This is also where DDFs most often go wrong. When inputs live in one tool, outputs in another, and V&V in a third, the file becomes an assembly job: someone exports and reconciles records near a submission deadline, and any gap or stale link surfaces at the worst possible moment. The QMSR’s closer alignment to ISO 13485 doesn’t reduce that scrutiny — design and development remains a primary focus of FDA inspection.

Keeping the file audit-ready

The stronger approach is to stop treating the design file as a document you assemble and start treating it as a view of connected records that’s always current. When inputs, outputs, risk, and verification live as linked records in one system, the file reflects today’s reality rather than a deadline-day snapshot.

That’s the model TraceUnified is built on: design inputs, architecture, tests, risk, and their verification status as governed records on one traceability graph, with a tamper-evident audit trail and 21 CFR Part 11 electronic signatures throughout. Change one input and every linked output and test flags for re-verification automatically, so the design file — DDF or DHF, by whatever name your QMS uses — stays inspection-ready by default. The quality program is still yours to run; the system is engineered to keep its evidence connected and current.