A device master record (DMR) is the complete recipe for building a medical device: the single, controlled set of documents and specifications that says exactly how a finished device is designed, produced, packaged, labeled, installed, and serviced. If the Design History File proves you designed the device correctly, the device master record proves you can build it the same way, every time. It is one of the most frequently misunderstood records in a medical device quality system — and one auditors reach for early.

This guide explains what a device master record is in plain English, what it must contain, how it differs from the DHF and the DHR, what changed when the FDA’s Quality Management System Regulation (QMSR) took effect on 2 February 2026, and how to keep a DMR audit-ready without drowning in binders.

What is a Device Master Record (DMR)?

Historically, the device master record is defined in the U.S. FDA’s Quality System Regulation at 21 CFR 820.181 as a compilation of records containing the procedures and specifications for a finished device. Think of it as the manufacturing “master file” — not the parts themselves, and not the records of any one build, but the authoritative instructions and specifications that every build must follow.

Two clarifications solve most of the confusion up front:

• A DMR is usually not one document. It is an index that points to controlled documents — drawings, specifications, work instructions, inspection criteria, labeling — each maintained under normal document control. The DMR ties them together for one device or device family.
• A DMR is a living, controlled record, not a one-time deliverable. When a design change is approved, the DMR must reflect it — that link between change control and the DMR is exactly what auditors test.

DMR vs. DHF vs. DHR: the records people mix up

Three records share similar initials and are constantly confused. The cleanest way to remember them is by the question each one answers:

• DHF — Design History File (design history file): “Did we design it right?” The history of the design and development effort, showing you followed your design controls. Created once per design, then largely static.
• DMR — Device Master Record (this record): “How do we build it?” The current recipe and specifications for producing the device. Living; updated with every approved design change.
• DHR — Device History Record (device history record): “Did we actually build this one right?” The production record proving a specific lot or unit was made according to the DMR. One per lot/unit.

In one sentence: the DHF is the design story, the DMR is the recipe, and the DHR is the proof you followed the recipe for a given batch. The DMR sits in the middle — it is what the DHR is checked against, and it inherits every approved change that flows out of the DHF.

What goes in a Device Master Record

Under 21 CFR 820.181, a device master record must include, or refer to the location of, the following for each type of device:

• Device specifications — drawings, composition, formulation, component specifications, and software specifications.
• Production process specifications — the equipment specifications, production methods, procedures, and production environment specifications.
• Quality assurance procedures and specifications — acceptance criteria and the quality assurance equipment to be used.
• Packaging and labeling specifications — including methods and processes used.
• Installation, maintenance, and servicing procedures and methods — where applicable to the device.

Notice what a DMR is not: it is not the executed build records (those are the DHR), and it is not the design rationale (that is the DHF). It is the current, released set of instructions and acceptance criteria that manufacturing and QA work from today.

What the regulations require — and what changed under the QMSR

This is where a lot of teams are out of date. On 2 February 2026, the FDA’s Quality System Regulation (21 CFR Part 820) was superseded by the Quality Management System Regulation (QMSR), which incorporates ISO 13485:2016 by reference. ISO 13485 does not use the phrase “device master record.” Instead, the equivalent concept lives in clause 4.2.3, the “medical device file,” which requires manufacturers to establish and maintain a file for each device type or family containing (or referencing) the device description and specifications, manufacturing and QA procedures, and installation and servicing procedures where applicable.

The practical takeaways:

• The term may shift from “device master record” to “medical device file” in QMSR-aligned systems, but the substance is the same: a controlled index of everything needed to make and support the device.
• If you sell in the U.S. and elsewhere, you were likely already maintaining an ISO 13485 medical device file and a Part 820 DMR. The QMSR harmonizes these, so a single, well-structured file can now satisfy both worlds.
• For teams building software as a medical device, the DMR/medical device file still applies — the “production specifications” become your build, configuration, and release specifications.

For a fuller picture of how the QMSR reshapes document control obligations, see our guide to medical device document control under ISO 13485, Part 11, and the QMSR.

Who needs a device master record, and when

Any manufacturer of a finished medical device intended for the U.S. market needs a DMR (or its QMSR “medical device file” equivalent) for each device type before commercial production. You should have a defined DMR structure in place:

• Before your first production build — the DMR is what the build is executed against, and what the resulting DHR is verified against.
• As part of design transfer — when a design leaves development and enters manufacturing, the outputs from your design history file become the specifications compiled into the DMR. A clean design transfer is essentially “the DHF outputs became a controlled DMR.”
• When you assemble a regulatory submission — a coherent DMR makes building a 510(k) or other premarket submission far less painful, because your specifications and procedures are already organized and current.

Common DMR audit findings

Auditors and FDA investigators see the same DMR problems repeatedly. The most common:

• The DMR doesn’t match the current design. A change was approved, the drawing was updated, but the DMR index still points to the superseded revision. This is the single most frequent finding, and it is really a change-control-to-DMR linkage failure.
• No single, authoritative index. Specifications exist, but scattered across shared drives, email, and individual engineers’ folders, with no controlled list proving what the complete, released set is.
• Missing elements. Labeling or servicing specifications are omitted for a device that clearly requires them.
• Uncontrolled copies. Manufacturing works from a printed or local copy that has drifted from the released version.
• No traceability to the DHR. You can’t cleanly show that a given lot’s device history record was checked against the DMR revision in force at the time of manufacture.

Every one of these is a symptom of the same root cause: the DMR being treated as a static binder rather than a live, controlled index wired to change control.

How QMS software keeps your DMR audit-ready

A binder or a shared drive can technically hold a DMR, but it can’t keep it correct — because nothing forces the index to move when a document is revised. Purpose-built document control software closes that gap:

• The DMR as a live index. Instead of a static list, the DMR references controlled documents by their current released revision, so when a drawing or specification is revised through change control, the DMR always points to the right version — no manual re-indexing.
• Change control wired to the record. An approved design change updates the affected documents and the DMR together, closing the “DMR doesn’t match the current design” finding at its source.
• Training tied to release. When a production specification changes, the people who build to it can be automatically re-assigned the read-and-understand training for the new revision — by role, department, or document type — so the shop floor never works from a version they were never trained on.
• Traceability across the trio. Because the DHF outputs, the DMR index, and each DHR live in one connected system, you can show an auditor the straight line from design to recipe to build in minutes, not days.
• One tenant, one source of truth. For medical device teams, keeping each project’s records isolated and controlled — rather than smeared across generic file storage — is what makes a DMR defensible. It is the same discipline behind a well-run ISO 13485 quality management system.

The goal isn’t more software for its own sake. It’s that the recipe for your device stays correct, current, and provable — automatically — so that “does the DMR match the design?” is never an uncomfortable question in an audit.

Frequently asked questions

What is a device master record (DMR)?

A device master record is the complete, controlled set of documents and specifications describing how a medical device is designed, produced, packaged, labeled, installed, and serviced. Defined in 21 CFR 820.181, it is essentially the authoritative “recipe” every production build must follow — usually maintained as a controlled index that points to the current released revision of each underlying document.

What is the difference between a DMR and a DHR?

The device master record (DMR) is the recipe — the instructions and specifications for building the device. The device history record (DHR) is the proof — the production record showing that a specific lot or unit was actually built according to the DMR. There is one DMR per device type, and one DHR per lot or unit.

Is the DMR the same as the ISO 13485 medical device file?

In substance, yes. ISO 13485:2016 clause 4.2.3 requires a “medical device file” containing (or referencing) the device description, specifications, manufacturing and QA procedures, and installation and servicing procedures. That is the same concept as the FDA’s device master record, under a different name.

Does the QMSR eliminate the device master record?

No — it renames and harmonizes it. When the FDA’s Quality Management System Regulation (QMSR) took effect on 2 February 2026, it incorporated ISO 13485 by reference, so QMSR-aligned systems typically use the ISO term “medical device file” in place of “device master record.” The requirement to maintain a controlled, current file of everything needed to make and support the device remains.

What must a device master record contain?

Per 21 CFR 820.181: device specifications (drawings, composition, component and software specs); production process specifications (equipment, methods, environment); quality assurance procedures and acceptance criteria; packaging and labeling specifications; and installation, maintenance, and servicing procedures where applicable.