Difference between DHF DMR and DHR

DHF vs DMR vs DHR: Key Differences Explained

Medical device documentation is full of similar-sounding acronyms, and three of the most common are DHF, DMR, and DHR. Each one covers a different stage of a device's life. The Design History File covers how the device was designed. The Device Master Record covers how it is built and tested. The Device History Record covers how each unit or batch was actually made.

This guide explains what each record contains, how they differ, and how they connect.

A note on terminology: These three terms come from the FDA's former Quality System Regulation (QSR). Since February 2, 2026, the FDA's Quality Management System Regulation (QMSR) has replaced the QSR, and the terms no longer appear in the regulation text. The documentation they describe is still required under ISO 13485 concepts, and most companies still use the familiar names internally. The FAQs at the end explain the modern equivalents.

Difference Between DHF, DMR & DHR

The three records work together but serve different purposes:

• DHF: the story of how the design was developed
• DMR: the instructions and specifications for making the device
• DHR: the proof that a specific batch or unit was made according to those instructions

Design History File (DHF)

The DHF is a compilation of records describing the design history of a finished device. It contains, or points to, the records needed to show that the design was developed in line with the approved design plan and applicable regulatory requirements. It is built during design and development and is closely tied to design controls.

Typical DHF contents include:

• Design and development plan
• Design inputs, user requirements, and system architecture
• Risk management plan and risk file
• Design outputs such as device specifications, drawings, bill of materials, and user manuals
• Verification and validation protocols and reports
• Design reviews, design transfer records, and design change records

Device Master Record (DMR)

The DMR is a compilation of records containing the procedures and specifications for a finished device. It focuses on what is needed to build, test, package, label, and service the device, so that everyone makes it the same way every time.

Typical DMR contents include:

• Device specifications, drawings, compositions, and formulations
• Bill of materials
• Production process specifications and work instructions
• Quality assurance procedures and acceptance criteria
• Packaging and labeling specifications, including the UDI
• Installation, maintenance, and servicing procedures
• User manuals

Device History Record (DHR)

The DHR is a compilation of records documenting the production history of a device. It shows that a specific unit, lot, or batch was made and released in line with the DMR. There is one DHR for each unit or batch, not one per product.

Typical DHR contents include:

• Dates of manufacture
• Quantity manufactured and quantity released for distribution
• Acceptance and inspection results
• The labels and labeling actually used, and the UDI or other device identification and control numbers
• Rework details
• Sterilization details, where applicable

DHF vs DMR vs DHR: Key Differences

The table below shows what each record typically contains. Content varies with the type of device and the processes defined in the quality management system (QMS).

A few points help when reading the table:

• Quality checks: The DMR holds the requirements and acceptance criteria. The DHR holds the actual results for that batch.
• Labels and UDI: The DMR holds the specifications, and the DHR holds the labeling actually used and the identification for that batch.
• Change control: DHR entries should refer to the DMR revision that was in effect when the batch was made, so any change can be traced.

How Are DHF, DMR, and DHR Related?

The three records follow the product from idea to shipped device:

1. DHF (design): The team plans the design, defines requirements, manages risk, and verifies and validates the result.
2. Design transfer: Design outputs become production specifications, and the transfer confirms the design can be manufactured reliably.
3. DMR (specification): The specifications, procedures, and acceptance criteria for making the device are compiled and controlled.
4. DHR (production): For each unit or batch, records are kept to show it was built, inspected, and released according to the DMR.

An analogy is a recipe. The DHF is the development notebook where the recipe was tested and refined. The DMR is the final recipe card everyone follows. The DHR is the log for one particular batch showing what was made, how many, and that it met the standard.

The links also work in reverse for traceability. A problem found in a released batch can be traced from the DHR to the DMR requirements and, if needed, back to the design inputs and risk analysis in the DHF. A design change flows the other way: it is recorded in the DHF, controlled, and reflected in a new DMR revision before it appears in later DHRs.

Frequently Asked Questions About DHF, DMR, and DHR

1. How are DHF, DMR, and DHR maintained during product changes?

Each record is affected differently, and the change control process ties them together.

• DHF (design and development file): Add the change record and everything that supports it: the reason, impact assessment, updated design inputs and outputs, and new verification and validation results. Under ISO 13485 clause 7.3.9, design changes must be identified, reviewed, verified, validated where appropriate, and approved before implementation. The DHF then shows the design's history, including the reasons behind each change.
• DMR (medical device file): Revise the affected specifications, drawings, work instructions, and labeling under controlled document revision, and issue a new revision. Older revisions are kept as history and are no longer used in production.
• DHR (product realization and quality records): These are not rewritten. Each batch or unit record shows which DMR revision was in effect when it was made, and any correction is made by a traceable entry, never by overwriting. A change applies to batches started after its effective date, not to completed ones.

Decide the impact of every change before you release it:

• Risk: Update the ISO 14971 risk file and check whether new hazards or changed risk controls result.
• Software: For device software, follow IEC 62304 change and maintenance activities, including regression analysis and testing.
• User interface: If the interface changes, review your usability engineering file. You may need to repeat formative evaluation, and sometimes summative evaluation, if the change affects safety-related use.
• Regulatory: Decide whether the change needs a new FDA 510(k), or a supplement or notice for a premarket approval (PMA) device. A change in intended use can also change the device's medical device classification. In the EU, significant changes may need notified body review and an update to the clinical evaluation report (CER).
• Labeling and identification: Labeling changes, and any change in version or model, may require a new device identifier or an update to your GUDID record.

2. How does document control apply to DHF, DMR, and DHR?

Document control applies differently to documents and records:

• Controlled documents (DMR and much of the DHF): ISO 13485 clause 4.2.4 requires documents to be approved before issue, reviewed and updated when needed, and shown with a clear revision status. Current versions must be available where work is done, obsolete versions must be kept from unintended use, and changes must be reviewed and approved by the right people.
• Records (DHR and the completed evidence in the DHF): Clause 4.2.5 requires controls for identification, storage, protection, retrieval, retention, and disposition. Records must stay legible and complete, and the retention period should cover at least the lifetime of the device as you define it, and not less than two years from release.
• FDA additions: 21 CFR Part 820, now the QMSR, adds FDA-specific content requirements in section 820.35, including recording the UDI for each device or batch and in complaint and service records.

In practice:

• Keep a single controlled index so the medical device file points to the current revision of each specification.
• Keep the DHF in step with development work, since records built long afterward raise questions about design control.
• Make sure the labeling and UDI in your DMR match what production records show and what your GUDID record lists.
• Apply the same controls to records from suppliers and contractors.

3. What role do DHF, DMR, and DHR play in medical device audits?

They are the main evidence an auditor uses to trace a product from idea to shipped unit.

• FDA inspections: Under the FDA's current inspection process, investigators typically follow a product through design and development, production, and complaints. They check that the design and development file supports the design, that the medical device file defines how it is made, and that a sample of production records shows units were made and released as specified. Management reviews, internal audits, and supplier audit reports are also within reach of investigators now.
• ISO 13485 and MDSAP audits: Auditors look for the same chain, plus procedures showing the records are controlled.
• Submissions: DHF content supports a 510(k) or PMA, and manufacturing information backs a PMA and its inspection. In the EU, DHF evidence feeds the technical documentation and the clinical evaluation report.

Common findings include an out-of-date DMR in use, DHRs with missing signatures or results, a DHF not kept in step with development, and weak traceability. Keep a traceability matrix from requirements to risk controls to tests, and be ready to retrieve any record quickly. For software devices, the same discipline covers IEC 62304 documentation, and for devices with a user interface it covers the usability engineering file, including formative and summative evaluation reports.

4. Can DHF, DMR, and DHR records be maintained electronically?

Yes. Many companies use a PLM or electronic QMS for the DMR and DHF, and a manufacturing execution system for an electronic DHR. The requirements are that the system is controlled and trustworthy:

• 21 CFR Part 11: Where records or signatures are electronic, Part 11 applies. That means validated systems, unique user access, secure computer-generated audit trails, compliant electronic signatures with printed name, date, time, and meaning, and the ability to produce accurate copies for inspection.
• ISO 13485 and the QMSR: Software used in the quality system must be validated for its intended use, using a risk-based approach, and records must remain retrievable for the whole retention period.
• Data integrity: Records should be attributable, legible, contemporaneous, original, and accurate. Plan for backup, recovery, and migration between systems, and control hybrid setups that mix paper and electronic records.
• Vendor oversight: Qualify suppliers of hosted systems and agree responsibilities in writing.

Quality system software is a different matter from device software. IEC 62304 governs the software inside your device, not the tools you use to keep records, so those tools follow risk-based validation instead.