DMRDevice Master Record

A Device Master Record (DMR) is the compilation of records containing the procedures and specifications for a finished medical device. The DMR defines what the device is, what it is made of, how it is to be manufactured, how it is to be inspected, how it is to be packaged and labelled, and how it is to be installed and serviced. Every Device History Record for the device must demonstrate that the unit was manufactured in accordance with the DMR — the DMR is the master against which compliance is measured.

The DMR is required by 21 CFR 820.181 under the legacy Quality System Regulation, and, in substance, by ISO 13485 clause 4.2.3 under the harmonised QMSR effective February 2026. The artefact has parallels in every device regime worldwide — EU MDR Annex II requires the equivalent technical documentation, Health Canada's MDR requires the device design and manufacturing information, and PMDA in Japan requires the device master file. The DMR concept is universal; only the name and the precise content list differ.

820.181 enumerates the contents the DMR must include or reference. The regulation deliberately allows the DMR to be a virtual record — the DMR can reference documents held elsewhere in the QMS rather than physically containing them, provided the references are unambiguous and the referenced documents are themselves under document control.

1. (a) Device specifications including appropriate drawings, composition, formulation, component specifications, and software specifications.
2. (b) Production process specifications including the appropriate equipment specifications, production methods, production procedures, and production environment specifications.
3. (c) Quality assurance procedures and specifications including acceptance criteria and the quality assurance equipment to be used.
4. (d) Packaging and labelling specifications, including methods and processes used.
5. (e) Installation, maintenance, and servicing procedures and methods.

820.181 also requires the DMR to be 'prepared and approved in accordance with 820.40' — the document control clause. That means every DMR document must be reviewed and approved by a designated individual prior to issuance, must carry the date and identity of the approver, must be available at all points of use, must be replaced (not merely superseded) when revised, and must have its prior version archived.

The three Device records under 21 CFR 820 cover three different phases of a device's life. They are not interchangeable, and conflating them is the most common Part 820 finding among first-time manufacturers.

Conceptually: the DHF proves the design is right, the DMR specifies the design, and the DHR proves a specific build conformed to the DMR. The three files reference each other: every DMR carries the DHF transfer milestone it descends from; every DHR carries the DMR version in force at the time of build.

820.181 lists the categories; the structure within each category is up to the manufacturer. A defensible DMR organises the content into the following sections, each independently version-controlled and each cross-referenced from the master DMR index.

1. Device identity and intended use

Device name, model, configuration, classification (Class I/II/III, FDA product code, EU MDR class and rule), intended use statement, indications for use, contraindications, and reference to the cleared submission (510(k), De Novo, PMA, MDR CE certificate).

2. Device specifications

Engineering drawings, bill of materials, component specifications, materials of construction (with biocompatibility evaluation reference), software specifications and software level of concern, accessories and compatible devices, performance specifications.

3. Production process specifications

Process flow diagram, work instructions for each operation, equipment specifications (with calibration requirements), production environment specifications (cleanroom class, controlled humidity, temperature), validated process parameters with their tolerances.

4. Quality assurance procedures and acceptance criteria

Incoming inspection plan, in-process inspection plan, finished-device inspection plan, sampling plans (ANSI Z1.4 / ISO 2859 if applicable), acceptance criteria for each inspection, equipment used for inspection, calibration of inspection equipment.

5. Packaging and labelling specifications

Packaging components, packaging configuration, sterile barrier specification (where applicable), packaging validation reference, label specifications including the UDI format, multi-language labelling matrix, IFU specifications, sterilisation labelling.

6. Installation, maintenance, and service procedures

Installation procedures (where the device is installed by the manufacturer or a service organisation), preventive maintenance schedules, service procedures, replacement parts specifications, calibration procedures for installed devices.

7. Document control header

DMR version, effective date, approval signatures, supersession reference to the prior version, the change-control number that authorised this revision, the design-change record that drove the revision (where applicable).

820.40 governs document control and applies to every DMR document. Two procedural requirements drive most DMR change-control workflows: (a) documents must be reviewed and approved by a designated individual prior to issuance; (b) document changes must be reviewed and approved by an individual in the same function as performed the original review (unless specifically designated otherwise), and the approved changes must be communicated to the appropriate personnel in a timely manner.

Practical change control on a DMR proceeds in five stages: (1) change request raised with rationale and impact assessment; (2) cross-functional review (engineering, quality, regulatory, sometimes clinical); (3) approval by the same function (or escalated function) that approved the original; (4) execution of the change (drafting the new DMR version); (5) effective date and supersession of the old version. The change must also evaluate whether the change requires a new regulatory submission under 21 CFR 807.81(a)(3) for 510(k) devices or under the equivalent EU MDR significant-change rules.

Design changes (820.30(i)) and document changes (820.40) interlock for DMR revisions. A design change that affects a DMR document creates both a design-change record (in the DHF) and a document-control record (against the DMR). Failing to keep these synchronised is a common audit finding — the DHF says the change happened, but the DMR document was never reissued, so the production process and the DHR continue to reference the old specification.

820.184(d) requires the DHR to include 'the acceptance records which demonstrate the device is manufactured in accordance with the DMR'. The phrase 'the DMR' is contextual — it means the DMR version that was in force at the time of build, not the DMR version current at the time the DHR is reviewed. A revision to the DMR after a batch has started must not silently change what the batch's DHR claims to demonstrate.

The architectural solution mirrors the MMR/BMR snapshot pattern in pharma. At work-order release, the DMR is snapshotted into an immutable column on the work order; the DHR renders against the snapshot for the life of the batch. The live DMR can be revised in parallel without affecting open builds, and the DHR can be reconstructed years later in the exact form it carried at the time of release.

The QMSR (89 FR 7496, effective February 2026) replaces most of 21 CFR 820 with by-reference adoption of ISO 13485:2016. The term 'Device Master Record' is removed from the regulatory text; the substance is preserved by reference to ISO 13485 clause 4.2.3 ('medical device file') and clause 7.5.1 (control of production and service provision). The artefact is the same; the name in the regulation shifts.

What you should change: update QMS procedures to reference clause 4.2.3 in addition to (or instead of) 820.181; confirm that the medical device file content matches ISO 13485's enumeration (which is broadly equivalent but uses different language); and ensure DMR change control references the document-control clauses of ISO 13485 (4.2.4, 4.2.5) as well as 820.40 during the transition period. Manufacturers typically continue to call the artefact a DMR internally because the term is universally understood by their staff and their auditors.

1. DMR exists but does not include or unambiguously reference all 820.181(a) through (e) categories — incomplete-DMR finding.
2. DMR references are stale — the referenced drawing has been revised and the DMR points to the old revision.
3. DMR change control does not require the same approval function as the original — 820.40(b) finding.
4. DHR renders against the live DMR rather than against a snapshot — accurate-reproduction rule broken in practice.
5. Design changes recorded in the DHF without a paired DMR document revision — production drifts from the design.
6. DMR is held in a document management system that does not enforce supersession — the old version remains accessible at points of use.
7. Packaging and labelling specifications maintained in a separate artwork system not under DMR change control — labelling drift becomes possible.
8. Software specifications (for SiMD or SaMD) maintained in source control without DMR references — IEC 62304 integration broken.

In V5, discrete tenants use the same approved-formula primitive as process tenants but with industry-aware terminology — the formula is the DMR, the work order is the build, and the kiosk captures the per-step evidence that accumulates into the DHR.

• DMR approval requires two distinct e-signatures (preparer + independent reviewer); the constraint that the users must differ is enforced at the database tier, not just in the UI.
• Once approved, the DMR record is immutable. UPDATE and DELETE are denied by RLS. Any change must create a new version which itself must be approved.
• DMR documents under 820.181(a) through (e) are held as structured records with explicit version chains and document-control references; the DMR index lists every document and its current effective version.
• On work-order release, V5 copies the full approved DMR into work_orders.dmr_snapshot (the discrete-industry shape of the MMR-snapshot model). The DHR is rendered against the snapshot for the life of the build.
• Change-control records reference both the source DMR version and the target DMR version, with an impact assessment, a rationale, and the regulatory-submission evaluation (510(k) significant-change check, EU MDR significant-change rules).
• Design changes flowing from the DHF land as paired change-control records on the DMR; the DMR cannot drift silently from the DHF.
• Old DMR versions are retained for the full retention period required by the predicate rule; they remain queryable but locked.

See below for the regulator-grade answers to the questions buyers ask most often when designing their DMR programme.