Device Master Record (DMR) – The Authoritative Blueprint for Medical Device Manufacturing

This topic is part of the SG Systems Global regulatory & operations glossary.

Updated November 2025 • 21 CFR 820 / QMSR, ISO 13485, MDR, IVDR • Design, Manufacturing, Quality, Regulatory, IT

The Device Master Record (DMR) is the definitive, approved specification set that tells a manufacturer exactly how a medical device must be built, tested, packaged, labelled and released. Where the Design History File (DHF) tells the story of how the design was developed, the DMR is the end‑state “recipe” of what must be followed in production. For each finished device, there should be one—and only one—controlling DMR; everything the shop floor does is supposed to be a faithful execution of that record.

“If your DHR shows how you actually built it, your DMR is what you promised regulators you would build—every single time.”

1) Where the DMR Sits in the Regulatory Framework

In the US Quality System Regulation, 21 CFR 820 (and its evolution into the Quality Management System Regulation – QMSR), the DMR is a defined requirement. For each type of finished device, manufacturers must maintain a master record containing all information needed to produce that device according to the approved design and regulatory submissions. In practice this requirement is mirrored in ISO 13485 as the set of documented procedures, specifications and records that define product realisation.

European Union regulations (MDR/IVDR) and many other jurisdictions do not always use the term “DMR” explicitly, but require a technical documentation / technical file that includes manufacturing and process information consistent with the intended design. For multinational firms, it is common to treat the DMR as the internal construct that feeds both FDA expectations and global technical documentation, ensuring that what is manufactured is consistent with what was certified or cleared to market.

2) DMR vs DHF vs DHR – Getting the Trio Straight

Confusing the DHF, DMR and DHR is a classic source of inspection pain. The DHF contains design inputs, outputs, risk management and verification/validation evidence showing that the design meets its requirements. The DMR is the distilled “how to make it” package—drawings, specifications, procedures, labels and processes frozen from that design. The DHR is the record for each batch or unit showing that this instance was built according to the DMR (or documenting justified deviations).

During audits, inspectors often pick one marketed device and walk the chain: DHF → DMR → DHR. If the DMR doesn’t match the current design, or the DHR shows assembly sequences, test methods or label sets that don’t exist in the DMR, you’ve just demonstrated that design control, document control and production controls are out of sync. Robust DMR management is therefore critical to keeping this trio coherent over the lifecycle of the device.

3) Core Content of a Device Master Record

Regulations describe the DMR in functional terms rather than prescribing a specific format. Typical content includes device specifications (drawings, materials, performance requirements), bills of materials (BOMs), software configuration where applicable, production process specifications, equipment and environmental requirements, inspection and test procedures, acceptance criteria and post‑processing like cleaning or sterilisation.

The DMR also encompasses packaging specifications, labelling and UDI data, including artwork, logistics identifiers and any language or region‑specific variants. For combination products regulated under 21 CFR Part 4, the DMR must account for both device and drug/biologic aspects, often cross‑referencing pharma batch records, sterilisation specifications and analytical testing instructions defined elsewhere in the QMS.

4) Structure, Modularity and Referenced Documents

In modern organisations, a DMR is rarely a single document. It is a structured set of references into multiple controlled systems: DMS for SOPs and work instructions, PLM or ERP for BOMs, CAD for drawings, label‑management systems for artwork and MES for routings and parameters. The “DMR” then becomes a master index or object that points to the correct versions of each underlying artefact.

Designing the DMR in modular sections—device family, configuration, options, region‑specific labelling—makes it easier to manage variants without uncontrolled duplication. However, the modularisation must not become so complex that operators, engineers or auditors cannot tell which combination is applicable to a given device code. Clear configuration rules, part‑numbering logic and visual configuration matrices all help keep variant explosion under control while preserving a single, auditable master for each device configuration that leaves the plant.

5) Change Control and Configuration Management

Because the DMR defines what is legally on the market, changes to it are inherently high‑impact. BoM updates, drawing revisions, software changes, process tweaks, test‑method revisions and label changes must go through formal change control, including design‑change assessment where appropriate, risk evaluation, validation where needed and regulatory impact checks for MDR/IVDR submissions, 510(k)s, PMAs or technical files.

Configuration management connects DMR versions to DHR entries and to products in the field. For example, an engineering change may introduce a new component or firmware version. The DMR must be updated, and production staged such that DHRs clearly show which units were built under which revision. Field service bulletins, recalls or notifications of change (NOC) to customers all depend on precise traceability between DMR revisions and shipped devices, which is why uncontrolled “local tweaks” in manufacturing are so dangerous.

6) Linking DMRs to Risk Management and ISO 14971

Risk control measures identified in ISO 14971 risk management files have to land somewhere practical; the DMR is one of the main landing zones. Design risk controls become device specifications, manufacturing controls become process parameters and inspection plans, information‑for‑use controls become labelling and Instructions for Use (IFUs).

When the DMR is aligned with the risk file, auditors can trace each risk control from hazard → design decision → specific requirement or process step → objective evidence in the DHR. When the DMR is misaligned, you see orphan risk controls that never made it to production, or production steps with critical importance that are not recognised in the risk file. Mature organisations periodically reconcile DMR content against risk management documentation to ensure the two stay in lockstep as changes accumulate over the product lifecycle.

7) DMRs, Work Instructions and Training

On the shop floor nobody reads the DMR cover‑to‑cover. Operators see work instructions, equipment set‑ups, inspection checklists and labels; supervisors see production routings and material lists. Those visible artefacts are implementation details of the DMR and must be version‑synchronised with it under document control.

Training programmes and the training matrix should reference procedures and instructions that are themselves tied to the DMR. When an SOP or work instruction forming part of the DMR changes, associated training requirements should be triggered automatically. In a digital environment this is easier to manage: a single change order can update the DMR, route linked documents for approval and push training tasks into learning systems; on paper, the risk of “old photocopies in someone’s drawer” is much higher.

8) Digital DMRs, MES and eDHR Integration

Electronic DMRs become most powerful when linked directly to execution systems. In a connected architecture, the DMR is mapped into MES so that routings, work instructions, material lists, parameter limits and electronic signatures in the DHR derive automatically from the approved master.

Systems such as V5 Traceability can use the DMR as the “digital recipe” for every electronic job traveller: which components can be picked, which torque settings are allowed, which tests must be completed, which UDI label is valid for this configuration. Deviations from the DMR become explicit exceptions in the eDHR, requiring justification and approval rather than slipping through as undocumented tribal knowledge on the line. This closes the loop between design, master definition and actual execution in a way that paper DMRs and DHRs never fully achieve.

9) Contract Manufacturers, CMOs and DMR Ownership

When manufacturing is outsourced, questions arise: who owns the DMR, and where does it live? Regulators are clear that the legal manufacturer ultimately owns design and manufacturing responsibility, even if day‑to‑day production is performed by a CMO or EMS partner. That means the DMR must be defined, approved and controlled under the legal manufacturer’s QMS, with controlled copies or subsets provided to partners under quality agreements.

Practically, this may mean that PLM or DMS at the sponsor holds the master DMR, while the CMO’s systems implement mirrored routings, BOMs and work instructions. Change‑control workflows should ensure that any update to the sponsor’s DMR triggers review, impact analysis and controlled implementation at the CMO, with feedback loops to confirm effectiveness. In inspections, regulators will look for evidence that this synchronisation works in reality, not just on paper agreements.

10) Global Variants, UDI and Localisation

Many devices are sold in multiple markets with different languages, labelling requirements, accessories or power configurations. Rather than proliferating entirely separate DMRs, firms often create a base DMR with region‑specific variants for packaging, IFUs and UDI attributes, mapped via configuration rules or separate but related master records.

Global serialisation and UDI schemes, including 21 CFR Part 830 and various national UDI databases, depend on accurate mapping between the device model (as defined by the DMR) and identifiers encoded in labelling and IT systems. Poorly controlled local “adaptations” of packaging and labelling without corresponding DMR updates lead directly to mis‑labelled product, UDI mismatches and regulatory findings.

11) Data Integrity, Document Control and Retention

Because the DMR captures the current, approved definition of a marketed device, it is a primary target for data‑integrity and document‑control expectations. Master records must be protected against unauthorised change, with complete audit trails and clear approval trails. Superseded versions should be archived but not available for routine use; destruction must follow retention requirements linked to product lifetime and regulatory rules.

Electronic systems managing DMRs must be validated under CSV or equivalent, and, where applicable, comply with 21 CFR Part 11 for electronic records and signatures. Hybrid arrangements—where the “real” DMR is partly electronic and partly in binders—are especially vulnerable to inconsistency, because the risk of one set being updated and the other forgotten is high unless controls are exceptionally tight.

12) Audits, Inspections and Common DMR Findings

Typical inspection findings around DMRs include incomplete master records; outdated drawings or specifications; mismatch between the DMR and actual practice observed on the floor; lack of evidence that process changes were fed back into the DMR; and DHRs referencing obsolete instructions or label sets. Another frequent observation is that site‑level documents diverge from centrally controlled corporate DMRs without formal change processes tying them together.

Inspectors often stress‑test DMR robustness by walking through a concrete example: “Show me the master record for this device; show me how this line executes it; show me the last three DHRs and how they demonstrate conformity.” If the DMR is scattered across systems with no clear index, or if operators routinely describe workarounds not captured in the master record, the conclusion is that design and manufacturing are not adequately controlled—regardless of how sophisticated the underlying technology is.

13) Implementation and Remediation Steps

Organisations building or remediating DMRs typically follow a phased approach. First, they inventory devices and families, then identify where master information currently lives—drawings in one repository, BOMs in ERP, SOPs elsewhere. Second, they define a DMR structure and indexing scheme that can reference all these artefacts consistently. Third, they reconcile content, closing gaps and resolving contradictions between documents and actual practice observed on the floor.

Only then does it make sense to automate: mapping DMRs into PLM, ERP, MES and labelling systems; wiring up change‑control and training links; and embedding master‑data checks into release workflows. Attempting to “go digital” before the underlying DMR content is coherent just results in faster propagation of bad data. Regulators are increasingly familiar with these journeys and will look for evidence that remediation is structured, risk‑based and tied to tangible manufacturing and quality improvements, not just new software licences.

14) Operational Role of the DMR Across Systems

Design & Regulatory: The DMR provides the manufacturing‑side detail that supports design dossiers, technical documentation and change notifications. Quality & QMS: It anchors procedures, inspection plans and release criteria in a single, controlled definition. Manufacturing & Supply Chain: BOMs, routings, work centres and inspection points in ERP/MES are direct reflections of the DMR. Traceability & Post‑market: Complaints, investigations, recalls and field actions all rely on being able to reconstruct which DMR version a given unit was built to.

In digitally mature plants, systems like V5 Traceability make the DMR “live”: any attempt to manufacture a device outside its master specification—wrong component, unapproved firmware, outdated label art, skipped test—is blocked at execution time, not discovered weeks later in a paper review. That is the practical difference between having a DMR “on file” and having it actively enforced across design, planning, manufacturing and quality.

15) FAQ

Q1. Is a DMR required for every device, even simple Class I devices?
Yes. Under 21 CFR 820/QMSR, each type of finished device requires a DMR, regardless of class. The complexity and formality of the record can be scaled to risk, but there must still be a defined, controlled set of manufacturing specifications and procedures for the device.

Q2. Can the DMR “live” across different systems or must it be one document?
It can absolutely be distributed. In practice, DMRs are almost always collections of controlled documents and data across PLM, ERP, DMS, MES and labelling systems. The key is that there is a clear indexing structure or master object that identifies which specific versions of those artefacts together constitute the DMR for a given device configuration.

Q3. How does the DMR relate to the EU MDR technical documentation?
The MDR’s technical documentation requirements include information on design, manufacturing processes, validation and quality controls. The DMR provides the internal, operational specification set that should align with and support the manufacturing and process parts of that technical file. Many organisations explicitly map DMR sections to technical‑documentation sections to keep them synchronised.

Q4. What happens if manufacturing practice diverges from the DMR?
Any divergence is evidence that the DMR, document control and production controls are not effective. Short‑term, this typically triggers deviations, investigations and potential product‑impact assessments. Long‑term, it requires systemic CAPA: either bringing practice back into conformance with the DMR, or formally changing the DMR (and associated submissions) to reflect a better way of manufacturing that has been properly evaluated and validated.

Q5. What is a practical first step for DMR remediation?
Start with one high‑risk, high‑volume device. Map where its current “master” information really resides, compare it to the DHF and to actual manufacturing practice, and document gaps. Use that pilot to design a standard DMR structure, indexing approach and change‑control flow that can then be extended to other products. Trying to fix the entire portfolio in one pass usually fails; focused, iterative remediation is more realistic and easier to defend in front of regulators.

Related Reading
• Design & Records: DHF – Design History File | DHR – Device History Record | UDI & Device ID
• Quality & Regulation: 21 CFR 820 | QMSR | ISO 13485 | ISO 14971 | QMS
• Data, Docs & Execution: Document Control | DMS | MES | eBR / eDHR | Data Integrity | Audit Trail
• Suppliers & Outsourcing: SQM | Quality Agreements | NOC