DHF vs DMR vs DHR: What Changed Under the FDA QMSR

On February 2, 2026, the Design History File (DHF), the Device Master Record (DMR), and the Device History Record (DHR) stopped being regulatory terms. All three had been defined in the Quality System Regulation (QSR), the U.S. Food and Drug Administration (FDA) rule that governed device quality systems for nearly thirty years. That day the FDA replaced the QSR with the Quality Management System Regulation (QMSR), and the QMSR does not use any of the three names. The QMSR amended Part 820 of Title 21 of the Code of Federal Regulations (CFR) instead of creating a new part, so the top-level citation your procedures already carry has not changed.

Losing the names did not remove the requirements. Nearly every element those three files held still has to exist, most of it under ISO 13485:2016, the medical device quality management standard from the International Organization for Standardization (ISO). The QMSR adopts that standard by reference, so its text now carries the force of US regulation, and the requirements the standard does not cover stay in 21 CFR Part 820. For a team whose records already satisfied the QSR, the evidence you produce is almost certainly still the right evidence, but it is still wise to confirm that the existing records align with the new QMSR requirements. The work ahead is writing down which ISO record each of your internal files now answers to.

This guide covers what FDA removed and what replaced it, what each record holds, where each now lives in ISO 13485, how the three connect under inspection, and how to keep all three retrievable.

What FDA Removed and What Replaced It

FDA eliminated the three record terms without eliminating the records. In its response to comments on the final rule, the agency described itself as not retaining separate requirements for these record types, because ISO 13485:2016 already documents most of the same elements. The two-year transition ran from publication on February 2, 2024.

Inspections changed on the same date, so terminology and method shifted together. FDA stopped using the Quality System Inspection Technique (QSIT) and moved to Compliance Program 7382.850, a risk-based process organized around the ISO 13485 structure instead of the older subsystem checklist.

Some record requirements stayed in the CFR instead of moving to ISO 13485, and 21 CFR 820.35 is the one to know. Titled control of records, it keeps complaint records, servicing activity records, and the requirement to record a unique device identifier (UDI) for each device or batch on top of ISO 13485 Clause 7.5.1.

The regulatory vocabulary is out of date, so any procedure citing the old design control, master record, or history record sections now points at text FDA has marked reserved. What those procedures point to has not changed, though each one is worth confirming against the QMSR before an inspection.

DHF vs DMR vs DHR: How the Three Records Differ

Each record answers a different question about the same device. The DHF shows how the device was designed, the DMR defines how to build it, and the DHR proves that a particular batch was built to that definition. Under the QSR all three were compilations, not single documents, so each could hold its records or point to where they were controlled.

What Goes Into Each Record

These are the legacy requirements, and most quality teams still work from them because ISO 13485 expects the same content under different headings:

DHF elements: The design and development plan, design inputs traced from user needs and intended use, design outputs, design review records, verification and validation evidence, design transfer records, and design changes with their review and approval. Section 820.30 required a DHF for each type of device.

DMR elements: Device specifications for drawings, composition, formulation, components, and software, plus production process specifications for equipment, methods, procedures, and environment. The rest covered quality assurance procedures including acceptance criteria and the equipment used, packaging and labeling procedures, and installation, maintenance, and servicing procedures. Section 820.181 required one DMR per device type, approved under document control.

DHR elements: Dates of manufacture, quantity manufactured, quantity released for distribution, and acceptance records demonstrating manufacture per the DMR. It also had to carry the primary identification label and labeling for each production unit, plus any UDI or universal product code with other device identifications and control numbers.

The DHF and DMR lists overlap on purpose. Device specifications originate as design outputs inside the DHF and reappear as DMR content, as do packaging, labeling, and acceptance criteria, so teams reference one controlled record from both places. Because each file leans on references instead of copies, a stale reference fails an inspection exactly as a missing record does. Our guide to what belongs in a DHF covers the design side of that boundary.

The Records Side by Side

This table compares the three on the dimensions that matter most in an inspection.

| Aspect | DHF | DMR | DHR | | Core question | Was the design developed per the approved plan? | How must the device be built? | Was this batch built per the DMR? | | Primary focus | Design and development history | Manufacturing specifications | Production evidence | | Lifecycle stage | Design and development | Design transfer into manufacturing | Production | | How many exist | One per device type | One per device type | One per batch, lot, or unit |

The row on how many exist is the one most teams get wrong. Identical wording covered the DHF and the DMR, one for each type of device, so only the DHR multiplies, once for every batch, lot, or unit released.

Where Each Record Now Lives in ISO 13485

ISO 13485 does not use the terms DHF, DMR, or DHR, but the underlying record requirements are largely addressed through corresponding ISO 13485 record structures.

| Legacy FDA term | ISO 13485:2016 record | What that record holds | | DHF | Design and development file, Clause 7.3.10 | Records showing design and development conformed to plan and to requirements, held or referenced in one place | | DMR | Medical Device File, Clause 4.2.3 | Product specifications, manufacturing and monitoring procedures, and the packaging, labeling, installation, and servicing requirements current on the floor | | DHR | Record for each device or batch | Evidence that a specific device or batch was produced and verified against the approved specifications, plus the UDI recorded for it |

Moving to the ISO record names is a translation exercise more than a rebuild. A team with ISO 13485 quality management processes already in place is mostly renaming and reindexing.

How the Three Records Link to Each Other

Investigators examine the chain between the records, and those connections carry more weight than any single file’s contents. The first connection is design transfer, and FDA now describes it in ISO terms. Final design output held or referenced in the design and development file becomes the starting point for the Medical Device File. That is what design transfer into production specifications produces, and a requirement pulled from one side should reconcile with the specification on the other.

The second connection runs from the DMR’s specifications to batch evidence, and it fails most visibly. Robbins Instruments offered its invoices as DHRs, and FDA found they carried none of the required elements, including manufacture dates, quantities, acceptance records, and production-unit labeling. A batch record that can’t demonstrate manufacture per the DMR proves nothing about conformance.

The third connection runs straight from the DHF to the DHR, skipping the DMR. A verification method defined during design review should surface as a recorded result on the unit, batch, or lot it was meant to prove, and an investigator can check that link without assuming the specifications carried it across. That walk depends on a traceability matrix linking needs to verification staying current as the design changes.

Keeping All Three Records Audit-Ready Under the QMSR

A complete record set and an inspection-ready one are not the same thing, and retrieval speed is the difference. Legacy 820.180(b) set retention at the design and expected life of the device, never less than two years from commercial release. That expectation now sits with 21 CFR 820.35 and ISO 13485’s control-of-records clause. Evidence you can’t retrieve on demand counts for nothing regardless of how long you kept it.

Two patterns account for most of what goes wrong between the three record sets:

Evidence split across tools nobody reconciles: When design inputs live in one system, test results in another, and production records in a third, nobody can state which version governed a build without rebuilding it by hand. Change control run across spreadsheets and shared folders produces superseded versions that still look current.

Traceability that thins at the design-to-production boundary: Where links between design inputs, outputs, and production specifications are incomplete, there is no fast way to show an investigator that a requirement was built and verified. The weakness stays invisible until an investigator asks and nobody can produce the link.

Both have structural fixes short of rebuilding the quality system. One controlled repository that both DHF and DMR views reference removes the duplicate-copy problem, and a DMR index held as a controlled document makes completeness checkable. Applying baseline control at each milestone makes the governing version of any record a lookup instead of an argument.

How Jama Connect Supports DHF and Design Traceability

Design evidence assembled in the weeks before a submission is evidence nobody trusts, because every requirement that changed since the last baseline puts the compilation in question. Jama Connect® is a web-based requirements management and traceability platform with a pre-built medical device framework aligned to the design controls workflow. It holds traceability from user needs through design inputs and outputs into verification and validation as those items change. Baselines capture the versions of selected items and their relationships at a milestone, preserving that historical snapshot as the project continues to change.

A DHF built that way stays current instead of being assembled before each submission. Review Center runs structured design reviews with electronic signatures for FDA 21 CFR Part 11, the rule covering electronic records and signatures, and design history files export from live project data. Document control for the DMR and batch records for the DHR belong in a quality management system, and Jama Connect integrates with one instead of replacing it. A quality lead can then answer the investigator’s first question, which is whether a requirement was verified and where the evidence sits.

Map Your Records to the QMSR Before Your Next Inspection

Inspections under Compliance Program 7382.850 follow risk instead of a subsystem checklist, so the record an investigator asks for first is harder to predict. That raises the value of retrieval over presentation, and makes the links between the three records worth auditing first.

If assembling design history evidence still takes your team weeks, you can start a free 30-day trial and see how the traceability holds up against a design change.

Frequently Asked Questions About DHF, DMR, and DHR

Is a DHF the same as a technical file under EU MDR?

A DHF and a technical file are different documents with different jobs. Technical documentation under Annexes II and III of the European Union Medical Device Regulation (EU MDR) is a conformity package required for every device on the European market other than custom-made devices. It carries clinical evaluation and post-market surveillance content that has no DHF counterpart, and the DHF feeds into it as a subset. Operationally it behaves more like a submission package than an internal medical device design controls record.

Who is responsible for maintaining the DHF, DMR, and DHR?

The manufacturer holds the obligation even when different functions maintain the records day to day. Design teams typically build the DHF alongside design control and risk management activity, manufacturing engineering and quality own the DMR through document control, and production staff complete each DHR. Investigators look for a named owner and an approval trail on every record, and split ownership without a defined boundary is a common finding.

Do records created under the QSR still count under the QMSR?

Yes. FDA required compliance with the QSR up to February 2, 2026 and with the QMSR from that date forward, so records created under the older rule stand on their own terms. Corrective actions taken now have to satisfy the newer rule, and teams preparing for the QMSR most often discover at that point that their procedures still cite reserved sections.

Can one system manage all three records?

Rarely, because the three records sit in different systems at most companies. Requirements management platforms hold the DHF design control content and its traceability, an electronic quality management system handles DMR document control and DHR batch records, and product lifecycle management systems carry bills of materials to manufacturing. Make the boundaries deliberate and confirm the integrations with quality management systems preserve the links, because an investigator walking the chain doesn’t care which system owns which piece.

This article was authored by Tom Rish and published on August 20, 2026.