DHF, DMR, and DHR: Essential Medical Device Documentation Guide

Why DHF, DMR, and DHR Matter

Medical device documentation is not administrative overhead. It is the regulatory and operational backbone of every device on the market. The Device History File (DHF), Device Master Record (DMR), and Device History Record (DHR) form a triad that captures how a device was designed, how it should be manufactured, and how each unit was actually produced. Misunderstanding their purpose, confusing their contents, or failing to maintain them are among the most frequent causes of FDA warning letters, 483 observations, and failed audits.

These three document sets are required by the FDA's Quality System Regulation (21 CFR Part 820) and have direct equivalents in ISO 13485:2016 and the EU MDR technical documentation requirements. If you manufacture medical devices for any regulated market, you must understand what each one contains, who is responsible for it, and how they relate to each other.

This guide covers every aspect of DHF, DMR, and DHR documentation — from regulatory basis and detailed contents to lifecycle flow, common deficiencies, the QMSR transition, and practical implementation strategies.

Definitions: What Are DHF, DMR, and DHR?

Before diving into details, here are the precise definitions. These are not interchangeable, and confusing them is a red flag during any audit.

Device History File (DHF)

The DHF is the complete compilation of records that describes the design history of a finished device. It documents every decision, analysis, test, review, and change that occurred during the design and development process. The DHF tells the story of how the device went from concept to a design that is ready for manufacturing.

Regulatory basis: 21 CFR 820.30(j) (Design Controls) and 21 CFR 820.181 (Device History File — note: despite the name overlap, 820.181 in the pre-QMSR regulation actually defines the DHF as the design history record).

In plain terms: The DHF answers the question: How and why was this device designed this way?

Device Master Record (DMR)

The DMR is the complete collection of records that contains the procedures and specifications for a finished device. It is the definitive reference for how to manufacture the device correctly every time. Think of it as the "recipe" — all the instructions, specifications, drawings, and procedures needed to produce, test, package, label, and service the device.

Regulatory basis: 21 CFR 820.181 (Device Master Record).

In plain terms: The DMR answers the question: What are the exact instructions for manufacturing this device?

Device History Record (DHR)

The DHR is the compilation of records containing the complete production history of a finished device. Each production run (or lot, or individual unit for certain devices) gets its own DHR. It is the objective evidence that a specific batch or unit was manufactured according to the DMR.

Regulatory basis: 21 CFR 820.184 (Device History Record).

In plain terms: The DHR answers the question: Was this specific unit or batch actually manufactured according to the instructions?

Key takeaway: The DHF documents the design. The DMR documents the manufacturing instructions. The DHR documents what actually happened during manufacturing. Design feeds instructions; instructions guide production; production records prove compliance.

A simple analogy: Think of it like a recipe. The DHF is your recipe development notebook — how you created and tested the recipe. The DMR is the final approved recipe — the exact instructions to follow every time. The DHR is the baking log for each batch — proof that you followed the recipe and the results were acceptable.

Device Class Applicability

Before proceeding, it is important to clarify which devices require these documentation sets. Not every device class carries the same obligations.

Design controls (and therefore the DHF) are required for:

• Class II devices — All Class II devices are subject to design controls under 21 CFR 820.30.
• Class III devices — All Class III devices are subject to design controls.
• Class I devices with software — Any Class I device that includes software or firmware is subject to design controls, even though most Class I devices are exempt.

DMR and DHR requirements apply to all device classes. Even Class I exempt devices that are not subject to design controls must maintain a DMR (manufacturing instructions) and generate DHRs (production records). The exemption from design controls does not exempt a manufacturer from maintaining controlled manufacturing documentation and production records.

This distinction matters: if you manufacture a Class I device without software, you do not need a DHF, but you still need a DMR and DHRs. If your Class I device contains software, you need all three.

Practical note: When in doubt, apply design controls. The cost of maintaining a DHF for a device that technically does not require one is negligible compared to the cost of an FDA observation for failing to apply design controls to a device that does require them. Many quality professionals recommend applying design controls to all devices regardless of classification as a matter of good practice.

The Regulatory Basis

FDA Quality System Regulation (21 CFR Part 820)

The FDA's QSR, codified in 21 CFR Part 820, has historically been the primary US regulation requiring DHF, DMR, and DHR documentation. The specific sections are:

Document	CFR Section	Title	Core Requirement
DHF	21 CFR 820.30(j)	Design History File	Establish and maintain a DHF for each type of device; shall contain or reference records necessary to demonstrate the design was developed in accordance with the approved design plan and Part 820 requirements
DMR	21 CFR 820.181	Device Master Record	Maintain DMRs that include or refer to the location of device specifications, production process specifications, quality assurance procedures, packaging and labeling specifications, and installation and servicing procedures
DHR	21 CFR 820.184	Device History Record	Maintain DHRs for each batch, lot, or unit; shall include dates of manufacture, quantity manufactured, quantity released for distribution, acceptance records, primary identification label and labeling used, and any device identification and control numbers

Section 820.186 (Quality System Record) is a related but separate requirement that covers the quality system-level documentation (quality manual, procedures, work instructions) that are not device-specific but underpin all three documents above.

QMSR Transition: What Has Changed

The FDA finalized the Quality Management System Regulation (QMSR) in January 2025, harmonizing 21 CFR Part 820 with ISO 13485:2016. The compliance date was February 2, 2026, and the QMSR is now in effect. Under the QMSR, the FDA incorporates ISO 13485:2016 by reference rather than maintaining a separate set of requirements. All FDA-regulated medical device manufacturers must now comply with the QMSR framework.

What does this mean for DHF, DMR, and DHR?

DHF under QMSR: ISO 13485:2016 Section 7.3.10 requires a "design and development file" for each medical device type or medical device family. The requirements are functionally equivalent to the DHF. The term "DHF" does not appear in ISO 13485, but the content requirements align closely. Under the QMSR, you must maintain a design and development file per ISO 13485 Section 7.3.10.

DMR under QMSR: ISO 13485 does not use the term "Device Master Record." Instead, the equivalent requirements are distributed across multiple sections — particularly Section 4.2.3 (control of documents), Section 7.1 (planning of product realization), Section 7.5.1 (control of production and service provision), and Section 7.5.6 (validation of processes for production and service provision). The QMSR retains the DMR concept by incorporating a supplemental requirement: manufacturers must still maintain a DMR (or equivalent compilation) that includes or references device specifications, production process specifications, quality assurance procedures and specifications, and packaging and labeling specifications. This is one area where the FDA added US-specific requirements on top of ISO 13485.

DHR under QMSR: Similarly, ISO 13485 does not have a single "Device History Record" concept. The equivalent requirements appear in Section 7.5.1 (production records), Section 8.2.4 (monitoring and measurement of product), and Section 7.5.9 (traceability). The QMSR retains a supplemental DHR requirement, mandating that each manufacturer maintain production records that demonstrate each finished device was manufactured in accordance with the DMR or equivalent.

Key takeaway: The QMSR does not eliminate the need for DHF, DMR, or DHR documentation. It reframes the requirements through the lens of ISO 13485:2016 while retaining supplemental requirements specific to DMR and DHR. Organizations already compliant with both the old QSR and ISO 13485 have found the transition manageable. Those who operated solely under the old QSR language need to map their documentation to ISO 13485 structure.

QMSR New Terminology: MDF, DDF, and the Crosswalk

With the QMSR now in effect, the industry is adopting new terminology aligned with ISO 13485. While many professionals still use the legacy QSR terms in everyday conversation, the official regulatory language has shifted. Understanding the crosswalk between old and new terms is essential for compliance, audit preparation, and communicating with regulators.

The two most significant terminology changes are:

• DDF (Design and Development File) replaces DHF. The DDF is defined by ISO 13485 Section 7.3.10 and serves the identical purpose — documenting the complete design history of a device.
• MDF (Medical Device File) replaces DMR. The MDF is a broader concept drawn from ISO 13485 Sections 4.2.3, 7.1, and 7.5.1 that encompasses all documentation required to demonstrate conformity and control manufacturing of a device.

The following crosswalk table maps the complete terminology transition:

Legacy QSR Term	New QMSR / ISO 13485 Term	ISO 13485 Clause	Notes
DHF (Design History File)	DDF (Design and Development File)	7.3.10	Direct replacement; same content requirements
DMR (Device Master Record)	MDF (Medical Device File)	4.2.3, 7.1, 7.5.1	MDF encompasses device specifications, production specs, and QA procedures
DHR (Device History Record)	Production Records / Batch Records	7.5.1, 7.5.9	No single ISO 13485 equivalent term; FDA retains supplemental DHR requirement
QSR (Quality System Record)	QMS Documentation	4.2.1, 4.2.2	Quality manual, policies, procedures, and records

What this means in practice: You do not need to rename your existing documents overnight. The FDA has stated that maintaining documentation that satisfies the substantive requirements is what matters, not the labels on your file folders. However, you should:

• Update your quality manual and SOPs to reference the QMSR and ISO 13485 terminology
• Ensure your internal audit checklists reflect the new clause references
• Train your team on the new terms so they can respond appropriately during FDA inspections
• Consider updating your document management system taxonomy during your next planned revision cycle

Practical note: During the transition period, auditors and inspectors may use either set of terms. A quality professional who says "DHF" and one who says "DDF" are talking about the same thing. The substance has not changed — only the regulatory framework and vocabulary around it.

ISO 13485:2016 Equivalents

For all organizations operating under ISO 13485 — which now includes all FDA-regulated manufacturers under the QMSR — the mapping is as follows:

FDA Concept	ISO 13485:2016 Equivalent	Key Sections
DHF	Design and development file	7.3.10
DMR	Product realization documentation (distributed)	4.2.3, 7.1, 7.5.1, 7.5.6
DHR	Production records / traceability records	7.5.1, 7.5.9, 8.2.4
QSR (Quality System Record)	Quality management system documentation	4.2.1, 4.2.2

ISO 13485 Section 7.3.10 states: "The organization shall maintain a design and development file for each medical device type or medical device family. This file shall include or reference records generated to demonstrate conformity to the requirements for design and development and records for design and development changes."

This is the DHF equivalent. The language is broader than the FDA's original 820.30(j) but the intent is identical: maintain a complete record of the design and development process.

EU MDR Technical Documentation (Annex II and III)

The European Medical Device Regulation (EU 2017/745) takes a different structural approach but covers the same ground. Under the EU MDR, manufacturers must maintain technical documentation as described in Annex II and Annex III.

Annex II — Technical Documentation covers:

• Device description and specification (including variants and accessories)
• Information supplied by the manufacturer (labeling, IFU)
• Design and manufacturing information
• General safety and performance requirements (GSPR) checklist
• Benefit-risk analysis and risk management
• Product verification and validation (including clinical evaluation)

Annex III — Technical Documentation on Post-Market Surveillance covers:

• Post-market surveillance plan
• Post-market surveillance report or periodic safety update report (PSUR)
• Post-market clinical follow-up (PMCF)

The mapping to FDA DHF/DMR/DHR concepts:

EU MDR Annex II Section	FDA Equivalent
Design and manufacturing information	DHF (design history) + DMR (manufacturing instructions)
Product verification and validation	DHF (V&V records)
Device description and specification	DMR (device specifications)
Manufacturing process information	DMR (process specifications)
Production batch records	DHR
Benefit-risk analysis	DHF (risk management file)

Key takeaway: The EU MDR technical documentation file is a superset that encompasses elements of DHF, DMR, and DHR plus additional requirements (clinical evaluation, GSPR mapping, post-market surveillance) that have no direct equivalent in the FDA's document triad. Organizations selling into both the US and EU markets typically maintain the DHF/DMR/DHR structure and then map or cross-reference to Annex II/III requirements for CE marking.

Detailed Contents of Each Document

Device History File (DHF) — Contents

The DHF must contain or reference every record generated during the design and development of the device. A complete DHF typically includes:

Design Planning

• Design and development plan (per 21 CFR 820.30(b) / ISO 13485 Section 7.3.2)
• Project timeline and milestones
• Resource allocation
• Design review schedule

Design Inputs

• User needs documentation
• Design input requirements (functional, performance, safety, regulatory, usability)
• Applicable standards and guidance documents identified
• Input review and approval records

Design Outputs

• Device specifications (mechanical, electrical, software, materials)
• Engineering drawings and CAD files (or references to controlled locations)
• Software architecture and detailed design documents
• Bill of materials (BOM)
• Output review and approval records demonstrating outputs meet inputs

Design Reviews

• Formal design review meeting minutes
• Attendees (including independent reviewers)
• Action items and their resolution
• Decisions made at each review stage

Design Verification

• Verification protocols and reports
• Test data demonstrating design outputs meet design input requirements
• Bench testing, analytical testing, simulated-use testing results
• Software verification reports (per IEC 62304 if applicable)
• Electrical safety testing (per IEC 60601-1 if applicable)

Design Validation

• Validation protocols and reports
• Clinical evaluation data or clinical study results
• Usability validation / human factors validation (per IEC 62366-1)
• Biocompatibility evaluation (per ISO 10993 series)
• Sterilization validation (per ISO 11135, ISO 11137, ISO 17665 as applicable)
• Shelf life / packaging validation (per ASTM F2097, ASTM D4169, ISO 11607)
• Software validation reports
• Evidence that device meets user needs and intended uses

Risk Management

• Risk management file (per ISO 14971)
• Hazard analysis, risk estimation, risk evaluation, risk control records
• Residual risk evaluation
• Risk-benefit analysis
• Production and post-production risk review

Design Transfer

• Design transfer plan
• Records demonstrating the design was correctly translated to production specifications
• Process validation records (IQ/OQ/PQ)
• Evidence that the DMR is complete and that production can replicate the design as intended

Design Changes

• All design change requests and approvals
• Impact assessments for each change
• Re-verification and re-validation records as needed
• Updated risk analysis for each change

Regulatory Submissions

• Copies of or references to 510(k), De Novo, PMA, or other regulatory submissions
• Correspondence with regulatory bodies
• Clearance or approval letters

Practical note: The DHF does not need to physically contain every document. It can reference controlled documents stored in a document management system, engineering data management system, or electronic quality management system (eQMS). What matters is that an auditor can follow the references and locate every record.

Device Master Record (DMR) — Contents

The DMR is the authoritative source for "how to build this device." Per 21 CFR 820.181, it must include or refer to the location of:

Device Specifications

• Finished device specifications (form, fit, function)
• Engineering drawings with revision control
• Bill of materials (BOM) with approved suppliers and specifications for each component and raw material
• Software specifications (version, configuration)
• Biocompatibility requirements for materials
• Performance specifications and acceptance criteria

Production Process Specifications

• Manufacturing process flow diagrams
• Work instructions for each manufacturing step
• Process parameters and tolerances
• Equipment specifications and calibration requirements
• Environment controls (cleanroom class, temperature, humidity)
• Special process validation records (welding, soldering, sealing, sterilization)
• In-process inspection and test procedures
• Rework and reprocessing procedures

Quality Assurance Procedures and Specifications

• Incoming inspection procedures for components and raw materials
• In-process inspection procedures
• Final inspection and test procedures (with acceptance criteria)
• Sampling plans (referencing ANSI/ASQ Z1.4 or other statistical basis)
• Calibration procedures for test and measurement equipment
• Nonconforming product procedures (as they relate to production)
• Statistical techniques used for acceptance activities

Packaging and Labeling Specifications

• Packaging specifications (materials, configuration, sterile barrier system if applicable)
• Labeling content and format (per 21 CFR Part 801 and applicable international requirements)
• Label artwork and templates with revision control
• Instructions for use (IFU)
• Unique Device Identification (UDI) requirements (per 21 CFR Part 830)
• Packaging validation references (ISO 11607)

Installation and Servicing Procedures (if applicable)

• Installation procedures and acceptance criteria
• Installation qualification requirements
• Service manuals and maintenance schedules
• Field service procedures
• Calibration requirements for installed devices
• Complaint handling procedures specific to field issues

Practical note: The DMR is a living document set. Every engineering change order (ECO) that affects any DMR component must go through the change control process, and the DMR must always reflect the current approved revision. An outdated DMR is a citable deficiency. Many companies maintain a DMR index — a controlled document that lists every document included in the DMR and its current revision number, making it straightforward to verify completeness during audits.

Device History Record (DHR) — Contents

The DHR is the production record for a specific lot, batch, or unit. Per 21 CFR 820.184, each DHR must include:

Production Identification

• Device name and model number
• Lot number, batch number, or serial number
• Date(s) of manufacture
• Quantity manufactured
• Quantity released for distribution
• Quantity rejected, scrapped, or placed on hold

Manufacturing Records

• Completed batch production records (traveler, router, or equivalent)
• Evidence that each manufacturing step was performed per the DMR
• Operator signatures or electronic approvals at each step
• Process parameter recordings (time, temperature, pressure, etc.)
• In-process inspection and test results
• Equipment identification used (linking to calibration records)

Acceptance Records

• Incoming material inspection results (with lot traceability to suppliers)
• In-process test results demonstrating compliance with acceptance criteria
• Final inspection and test results
• Acceptance or rejection decisions with signature and date
• Sampling records (if applicable)
• Any test data, charts, or recordings generated during production

Labeling and Packaging

• Primary identification label(s) used for each production unit
• Copy of or reference to labeling used (including IFU version)
• UDI information applied
• Packaging inspection records
• Sterile barrier integrity records (if applicable)

Device Identification and Control

• UDI-DI and UDI-PI information
• Traceability records linking finished device to component lots and raw material lots
• Any unique device identifiers or control numbers used

Deviations and Nonconformances

• Any deviations from the DMR that occurred during production
• Nonconformance reports associated with the production run
• Disposition decisions (use as is, rework, scrap)
• CAPA references if a nonconformance triggered corrective action

Environmental and Sterilization Records (if applicable)

• Environmental monitoring data for the production period
• Sterilization records (cycle parameters, biological indicator results, chemical indicator results)
• Sterility assurance records

Practical note: The DHR serves as the definitive evidence that a specific unit or lot was manufactured correctly. During a recall investigation, product complaint analysis, or FDA inspection, the DHR is the first place investigators look. Incomplete DHRs — missing signatures, missing test results, undocumented deviations — are among the most commonly cited 483 observations.

DHF vs. DMR vs. DHR: Comparison

The following table summarizes the critical differences:

Attribute	DHF	DMR	DHR
Full name	Device History File	Device Master Record	Device History Record
Purpose	Document the design history	Define how to manufacture	Record what happened in production
Answers the question	How was this device designed?	How should this device be built?	Was this batch/unit built correctly?
Scope	One per device type/family	One per device type/model	One per lot/batch/unit
Created during	Design and development	Design transfer (populated throughout development, finalized at transfer)	Manufacturing / production
Primary owner	R&D / Engineering	Quality / Manufacturing Engineering	Manufacturing / Production
Regulatory basis (QSR)	21 CFR 820.30(j)	21 CFR 820.181	21 CFR 820.184
ISO 13485 equivalent	Design and development file (7.3.10)	Distributed across 4.2.3, 7.1, 7.5.1, 7.5.6	Production records (7.5.1, 7.5.9, 8.2.4)
Frequency of creation	Once per device design	Once per device (updated via change control)	Every production run
Volume	Typically one large file or collection	One controlled set per device	Hundreds or thousands per year for high-volume devices
Static or dynamic	Grows during development, then relatively static post-transfer (updated for design changes)	Living document set, updated via ECOs	Created fresh for each production run
Key risk if missing	Cannot demonstrate design was properly controlled	Cannot demonstrate manufacturing is controlled and repeatable	Cannot demonstrate a specific unit was manufactured correctly

The Lifecycle Flow: How DHF, DMR, and DHR Connect

Understanding the temporal relationship between these three documents is essential. They are not independent — they form a chain.

Phase 1: Design and Development (DHF)

The process begins with design and development. As the engineering team works through design controls — defining inputs, generating outputs, conducting reviews, performing verification and validation, and managing risk — every record goes into the DHF. The DHF grows throughout the design phase.

At each design review gate, the DHF should demonstrate that the preceding phase was completed satisfactorily. By the time the team reaches design validation, the DHF contains the complete evidentiary record that the device meets user needs and intended uses.

Phase 2: Design Transfer (DHF to DMR)

Design transfer is the critical bridge between development and manufacturing. During design transfer, the design outputs documented in the DHF are translated into production specifications, work instructions, test procedures, and quality requirements — all of which become part of the DMR.

The design transfer process must ensure that:

• Every design output has a corresponding manufacturing specification or instruction in the DMR
• Production processes can consistently reproduce the design as validated
• Process validations (IQ/OQ/PQ) are complete for any special processes
• Quality assurance procedures and acceptance criteria are defined and documented
• Training requirements for production personnel are identified and fulfilled

The DHF should contain the design transfer plan and evidence that transfer was completed successfully. The DMR should be complete and approved before routine manufacturing begins.

Phase 3: Production (DMR to DHR)

Once the DMR is established, manufacturing uses it as the definitive instruction set. Every production run follows the DMR and generates a DHR as objective evidence of compliance.

The DHR for each lot or batch should demonstrate, point by point, that the production team followed the DMR. Test results in the DHR should correspond to acceptance criteria defined in the DMR. Any deviation from the DMR should be documented in the DHR along with the disposition decision.

Phase 4: Post-Market Changes (Updating All Three)

When a design change is needed post-market — whether driven by a CAPA, customer feedback, regulatory change, or product improvement — the cycle repeats in miniature:

1. The change is evaluated and documented through design controls (updating the DHF)
2. Affected DMR documents are revised through change control
3. Subsequent production runs generate DHRs against the updated DMR

This lifecycle never truly ends. As long as the device is on the market, the DHF may receive design change records, the DMR will be updated as processes evolve, and DHRs will be generated with every production run.

Key takeaway: The lifecycle flow is linear at a high level — DHF feeds DMR, DMR guides DHR — but in practice it is iterative. Design changes, CAPAs, and process improvements create feedback loops that touch all three documents. A mature quality system manages these interactions through integrated change control.

Traceability Matrix Example

One of the most powerful tools for connecting the DHF, DMR, and DHR is a requirements traceability matrix. This matrix demonstrates that every user need is addressed through the entire lifecycle — from design input through production acceptance. Below is a concrete example for a hypothetical cardiac monitoring device.

User Need	Design Input (DHF)	Design Output (DHF)	Verification Test (DHF)	DMR Specification	DHR Acceptance Record
Clinician needs heart rate accuracy within ±2 BPM	DI-001: Heart rate measurement accuracy shall be ±2 BPM for rates 40–200 BPM	DO-001: Signal processing algorithm v3.2; ECG front-end circuit design rev C	VER-001: Bench test of 150 units against reference monitor, all within ±1.8 BPM	SPC-001 Rev C: Final test procedure FTP-100, acceptance criterion ±2 BPM	DHR Lot 2026-0142: FTP-100 results — all 500 units passed, range ±0.9 to ±1.7 BPM
Device must operate for 72 hours on a single battery charge	DI-002: Battery life shall be ≥72 hours continuous monitoring	DO-002: 3.7V 2000mAh Li-ion battery; power management IC design rev B	VER-002: 10 units tested under worst-case load, minimum recorded life 78.3 hours	SPC-002 Rev B: Battery cell incoming spec BAT-200, runtime test procedure FTP-101, acceptance ≥72 hrs	DHR Lot 2026-0142: FTP-101 sample (n=13 per AQL), minimum 76.1 hours — passed
Device must be safe for patients with sensitive skin	DI-003: All patient-contacting materials shall be biocompatible per ISO 10993-5 and 10993-10	DO-003: Medical-grade silicone housing (USP Class VI); hypoallergenic adhesive electrode	VER-003: Cytotoxicity and irritation testing per ISO 10993-5/10 — passed	SPC-003 Rev A: Material spec MAT-300 (silicone supplier X, lot acceptance per CoA); adhesive spec MAT-301	DHR Lot 2026-0142: Incoming inspection MAT-300 CoA verified; MAT-301 CoA verified
Clinician needs audible alarm for critical heart rates	DI-004: Audible alarm shall sound within 5 seconds when HR <40 or >180 BPM	DO-004: Alarm logic module v2.1; piezo speaker spec SPK-100	VER-004: Simulated arrhythmia input, 30 trials — all alarms triggered within 2.8 seconds	SPC-004 Rev B: Functional test procedure FTP-102, acceptance ≤5 sec alarm response	DHR Lot 2026-0142: FTP-102 results — all units triggered within 3.1 seconds — passed
Device data must be exportable to hospital EMR	DI-005: Device shall support HL7 FHIR data export via Bluetooth LE	DO-005: BLE module spec; FHIR resource mapping document; data export firmware v1.4	VER-005: Interoperability test with 3 major EMR systems — all data transmitted and parsed correctly	SPC-005 Rev A: Connectivity test procedure FTP-103, acceptance = successful FHIR bundle transmission	DHR Lot 2026-0142: FTP-103 firmware verification v1.4 confirmed; BLE pairing test passed

This matrix serves multiple purposes:

• During design (DHF): Confirms every user need has a corresponding design input, every input has a design output, and every output has been verified
• During design transfer (DHF to DMR): Confirms every verified output has a corresponding manufacturing specification and test procedure
• During production (DHR): Confirms every DMR acceptance criterion was tested and the results were recorded
• During audits: Provides a single document an auditor can follow to trace any requirement from origin to production evidence

Practical note: Maintain the traceability matrix as a controlled document within the DHF. Update it whenever design inputs change, new verification tests are added, or DMR specifications are revised. Many eQMS platforms offer built-in traceability matrix features that automatically link requirements to test records.

Common FDA 483 Observations and Warning Letter Citations

FDA inspectors routinely cite deficiencies related to DHF, DMR, and DHR. Understanding the most common observations helps you prioritize compliance efforts.

DHF-Related Observations

• Incomplete or missing design reviews: Failure to conduct design reviews at defined stages, or design review records that lack evidence of independent review, action item follow-up, or formal approval
• Inadequate design verification or validation: Testing that does not fully cover design input requirements, or validation conducted on non-production equivalent devices
• Missing or incomplete risk management files: Risk analysis that does not address all identified hazards, missing risk control verification, or no evidence that residual risk is acceptable
• Design inputs not traceable to outputs: No clear mapping between what the device is supposed to do (inputs) and how the design achieves it (outputs)
• Design transfer not documented: No evidence that the design was systematically translated to production specifications, or design transfer performed without a plan

DMR-Related Observations

• DMR does not include all required elements: Missing packaging specifications, missing labeling specifications, or missing installation/servicing procedures for devices that require them
• DMR not current: Production occurring against outdated specifications because change orders were not processed, or the DMR index does not reflect the latest approved revisions
• Procedures not adequate: Work instructions that lack sufficient detail for consistent manufacturing, or acceptance criteria that are vague or subjective
• No DMR index or equivalent: No mechanism to verify completeness of the DMR or to confirm that all documents within it are at the correct revision

DHR-Related Observations

• Incomplete production records: Missing signatures at manufacturing steps, missing date stamps, or missing test results
• Acceptance activities not documented: Final release of product without documented evidence of passing all required inspections and tests
• Deviations not documented: Production deviations from the DMR that were not formally documented and dispositioned
• Traceability gaps: Inability to trace a finished device back to component lots, raw material lots, or production equipment
• DHR does not demonstrate conformance to DMR: The records in the DHR do not map to the requirements in the DMR, or there is no mechanism to verify that every DMR requirement was satisfied during production

Warning: The single most common documentation-related 483 observation across all FDA medical device inspections is some variation of: "Procedures are not followed." This manifests in DHRs that do not match the DMR — steps skipped, parameters not recorded, acceptance criteria not met but product released anyway. This observation alone accounts for a substantial percentage of warning letters.

Ownership, Roles, and Responsibilities

Clear ownership prevents gaps. The following table outlines typical responsibilities — note that titles vary by organization, but the functional responsibilities should be explicitly assigned.

Responsibility	DHF	DMR	DHR
Creates	R&D / Design Engineering	Manufacturing Engineering + Quality	Production / Manufacturing
Reviews	Cross-functional design review team	Quality Assurance, Regulatory	Quality Assurance
Approves	Design authority (typically VP of Engineering or equivalent)	Quality management, Manufacturing management	Quality Assurance (lot/batch release)
Maintains	R&D / Document Control	Document Control / Quality	Document Control / Manufacturing
Archives	Document Control	Document Control	Document Control
Uses for audits	R&D + Quality (during design audits)	Quality + Manufacturing (during process audits)	Quality + Manufacturing (during production audits, complaint investigations, recalls)

Best Practices for Organization, Storage, and Retrieval

Structural Organization

DHF organization: Structure the DHF to mirror the design control process. Common approaches include:

• Organize by design control phase (planning, inputs, outputs, reviews, verification, validation, transfer)
• Organize by subsystem or module (mechanical, electrical, software, packaging)
• Hybrid approach: phase-based top level with subsystem-based sub-folders

Whichever structure you choose, maintain a DHF index that lists every document, its revision, and its location. This index should be a controlled document.

DMR organization: Structure the DMR by document type, mirroring the regulatory requirements:

• Device specifications section
• Production process specifications section
• Quality assurance procedures and specifications section
• Packaging and labeling specifications section
• Installation and servicing section (if applicable)

Maintain a DMR index as a controlled document. This index is the single most useful audit preparation tool — it allows you to verify completeness in minutes.

DHR organization: Standardize the DHR template so every production run generates records in the same order and format. A typical DHR package includes:

• Cover page with lot/batch identification, date range, quantities
• Batch production record (traveler) with step-by-step sign-offs
• In-process inspection records
• Final inspection and test records
• Component and material traceability records
• Labeling reconciliation records
• Deviation and nonconformance records (if any)
• Release authorization

Retention Periods

Regulatory requirements dictate minimum retention periods:

Jurisdiction	Requirement	Minimum Retention
FDA (21 CFR 820.180)	All quality system records	Duration of the design and expected commercial life of the device, but not less than 2 years from date of release
ISO 13485:2016 (4.2.5)	Quality management system records	At least the lifetime of the device as defined by the organization, but not less than 2 years from product release
EU MDR (Article 10(8))	Technical documentation	At least 10 years after the last device is placed on the market (15 years for implantable devices)

Practical note: Many companies default to 10 years or the expected lifetime of the device plus 5 years, whichever is longer. For implantable devices, 15 to 20 years is common. The cost of retaining records is low compared to the risk of being unable to produce them during a regulatory inquiry or litigation.

Indexing and Retrieval

An auditor may ask to see the design verification records for a specific design input, the sterilization validation records from the DMR, or the DHR for a specific lot number involved in a complaint. Retrieval time matters — fumbling through disorganized files for hours during an FDA inspection creates a negative impression that is difficult to recover from.

Best practices for retrieval:

• Maintain a cross-reference matrix linking design inputs to verification records (DHF)
• Maintain a DMR index with document numbers, titles, and current revision levels
• Maintain a searchable DHR log with lot/batch numbers, dates, and disposition status
• Implement naming conventions that embed meaningful metadata (device name, document type, revision)
• Conduct periodic self-audits to verify that records are findable and complete

Electronic vs. Paper-Based Documentation Systems

Paper-Based Systems

Paper-based DHF, DMR, and DHR systems are still permitted and still in use, particularly at smaller manufacturers. They work, but they carry significant operational disadvantages:

• Storage: Physical records require space, environmental controls, and protection from damage
• Retrieval: Finding a specific record requires manual search through filing systems
• Version control: Ensuring that only current-revision documents are in use requires manual processes (stamp and retrieve obsolete copies, distribute current copies)
• Integrity: Paper records can be lost, damaged, altered, or misfiled
• Concurrent access: Only one person can review a physical record at a time
• Audit readiness: Presenting paper DHFs and DHRs during audits is time-consuming

Paper systems are not inherently non-compliant, but they require disciplined procedures for document control, and they scale poorly.

Electronic Systems (eQMS)

Electronic Quality Management Systems have become the standard for most manufacturers above startup stage. The benefits for DHF/DMR/DHR management are substantial:

• Version control: Automatic revision management with full audit trails
• Access control: Role-based permissions ensuring only authorized personnel can modify records
• Searchability: Instant retrieval of any document by number, title, keyword, or metadata
• Electronic signatures: 21 CFR Part 11 compliant electronic signatures replace wet signatures
• Concurrent access: Multiple users can review records simultaneously
• Automated workflows: Review and approval routing, overdue notifications, periodic review reminders
• Integration: Linking DHF records to DMR documents to DHR batch records within a single system
• Backup and disaster recovery: Automated backups prevent data loss

Common eQMS platforms used in the medical device industry include MasterControl, Greenlight Guru (purpose-built for medical devices with DHF/DMR/DHR workflows), Qualio, Veeva Vault, Arena (PTC), and Dot Compliance. Enterprise manufacturers may use SAP or Oracle with quality management modules.

21 CFR Part 11 Compliance

If you maintain electronic records that are required by predicate rules (such as 21 CFR Part 820), those records must comply with 21 CFR Part 11 requirements for electronic records and electronic signatures. Key requirements include:

• Validation of the electronic system
• Ability to generate accurate and complete copies of records
• Protection of records to enable retrieval throughout the retention period
• Limiting system access to authorized individuals
• Secure, computer-generated, time-stamped audit trails
• Operational system checks to enforce sequencing of events
• Authority checks to ensure only authorized individuals sign records
• Electronic signatures that are unique to one individual and not reused

Key takeaway: Whether you use paper or electronic systems, the content requirements are identical. Electronic systems reduce operational risk and improve efficiency but introduce their own compliance requirements (Part 11, computer system validation). The choice between paper and electronic is a business decision, not a regulatory one — but the industry has overwhelmingly moved toward electronic systems, and auditors increasingly expect them.

Practical Implementation Tips

Starting From Scratch

If you are building your DHF/DMR/DHR framework for the first time, follow this sequence:

1. Define your document control process first. Before creating any DHF, DMR, or DHR content, establish procedures for document creation, review, approval, revision, distribution, and archival. This is foundational — everything else depends on controlled documents.

2. Create DHF/DMR/DHR templates. Standardized templates ensure consistency across device families and make it easier for teams to know what goes where. Include checklists of required contents based on the regulatory requirements outlined in this guide.

3. Build the DHF as you develop the device. Do not try to reconstruct the DHF after development is complete. Populate it in real time as design activities are performed. Retrofitting a DHF is painful, error-prone, and often results in gaps that auditors will find.

4. Establish the DMR during design transfer. As design outputs are translated into production specifications, build the DMR concurrently. Use the DMR index template to track completeness. Do not release the device for production until the DMR is complete and approved.

5. Pilot the DHR with initial production runs. Use the first few production runs to validate that the DHR template captures all necessary information and that operators can complete it in practice. Adjust based on feedback before scaling to full production.

6. Cross-reference liberally. Build traceability links between the three documents. Design inputs in the DHF should trace forward to specifications in the DMR. Production parameters in the DHR should trace back to requirements in the DMR. This cross-referencing is not optional — it is how you demonstrate the system works as intended.

Maintaining and Updating

• Change control is non-negotiable. Every change to the DHF (design changes) or DMR (process changes, specification changes) must go through formal change control with impact assessment, approval, and verification of implementation.
• Periodic review the DMR. Even without changes, periodically review the DMR to ensure it remains accurate and complete. Many companies include DMR review in their annual management review or internal audit program.
• Archive DHRs systematically. High-volume manufacturers generate thousands of DHRs per year. Implement a systematic archival process with clear identification, indexing, and retrieval capability.
• Train your teams. Manufacturing operators, quality inspectors, and engineers all interact with these documents differently. Ensure each group understands which documents they own, how to complete records correctly, and what constitutes a compliant record.

Common Pitfalls to Avoid

• Treating the DHF as a dumping ground. The DHF should be organized and indexed, not a disorganized collection of every email, meeting note, and draft ever generated during development. Include records that demonstrate compliance with design controls — not everything.
• Confusing the DMR with the DHF. The DMR contains the current approved instructions for manufacturing. The DHF contains the history of how the design was developed. A device specification in the DMR may have gone through 15 revisions during development — the DHF contains the history of those revisions, while the DMR contains only the current approved version.
• Releasing product without complete DHRs. Under time pressure, companies sometimes release product before the DHR is fully completed and reviewed. This is a serious compliance violation. No product should leave your facility without a completed, reviewed, and approved DHR.
• Not linking DHRs to specific DMR revisions. The DHR should reference the specific revision of each DMR document that was in effect during production. If the DMR was at revision C when a lot was produced, the DHR should reflect that. This is critical for investigating complaints and conducting recalls.
• Ignoring electronic record requirements. If you maintain electronic DHF, DMR, or DHR records, you must comply with 21 CFR Part 11. Using an unvalidated spreadsheet as your DHR system is a citable deficiency.

Software and SaMD Documentation

Software-based medical devices and Software as a Medical Device (SaMD) present unique documentation challenges that do not map neatly onto the traditional hardware-centric DHF/DMR/DHR model. As software becomes an increasingly dominant category — and with the QMSR now recognizing IEC 62304 as a foundational standard — understanding how these documentation frameworks apply to software is essential.

How DHF/DDF Requirements Apply to Software Devices

For software medical devices, the DHF (or DDF under QMSR terminology) must incorporate the full software development lifecycle as defined by IEC 62304. The design control process maps to software development activities, but with additional specificity.

Software-specific DHF/DDF contents include:

• Software Requirements Specification (SRS): The complete set of functional, performance, interface, and safety requirements for the software system. This serves as the software-specific design input and must be traceable to user needs and system-level design inputs.
• Software Architecture Design: High-level architecture documents describing software items, modules, interfaces, and their relationships. This includes decisions about software safety classification (IEC 62304 Class A, B, or C) for each software item.
• Detailed Software Design: Module-level design documentation, data flow diagrams, state machines, API specifications, and database schemas. The level of detail required scales with the software safety classification.
• SOUP Analysis (Software of Unknown Provenance): A complete inventory of all third-party libraries, open-source components, and off-the-shelf software used in the device. Each SOUP item must be documented with its version, known anomalies, functional and performance requirements it must satisfy, and the rationale for its selection. This is a frequently cited gap in software DHFs.
• Unresolved Anomalies List: A documented, risk-evaluated list of all known software bugs that remain unresolved at the time of release. Each anomaly must be assessed for patient safety impact and accepted through a formal risk evaluation. IEC 62304 Section 9.8 requires this, and auditors specifically look for it.
• Software Verification Records: Unit test results, integration test results, static analysis reports, code review records, and regression test results. These correspond to design verification activities.
• Software Validation Records: System-level testing against the SRS, usability validation, and clinical workflow validation. These correspond to design validation activities.
• Software Configuration Management Records: Version control history, branch and merge records, build environment documentation, and release notes.

DHR and Production Records for SaMD

Traditional manufacturing produces physical units on a production line. SaMD "manufacturing" is fundamentally different — the production event is a software deployment, release, or distribution. This difference requires a rethinking of what the DHR captures.

SaMD production records should include:

• Deployment as a production event: Each software release, cloud deployment, or app store publication should be treated as a production event that generates a DHR-equivalent record. Document the date and time of deployment, the environment deployed to (production, staging), and the personnel who authorized the release.
• Version and build capture: The DHR must unambiguously identify the exact software version released. Record the version number, build number, commit hash, and build timestamp. For cloud-hosted SaMD, include the infrastructure configuration (server versions, container images, database versions) at the time of deployment.
• Software Bill of Materials (SBOM): Each release should include a frozen SBOM that lists every component, library, and dependency included in the build, along with their exact versions. The SBOM serves the same traceability function as a hardware BOM and component lot records in a traditional DHR. It is also increasingly required for cybersecurity compliance.
• Release testing evidence: Records of final verification and validation tests executed against the release candidate. Include pass/fail results, test environment details, and tester identification.
• Rollback and incident records: If a deployment is rolled back, that event and its rationale must be documented as a deviation in the production record, just as a manufacturing deviation would be documented in a hardware DHR.

AI/ML-Specific Documentation Considerations

Devices incorporating artificial intelligence or machine learning introduce additional documentation requirements that extend the DHF/DDF and DHR frameworks.

DHF/DDF additions for AI/ML:

• Dataset versioning and documentation: Training, validation, and test datasets must be version-controlled and documented with the same rigor as source code. Record the data sources, collection methodology, inclusion/exclusion criteria, demographics and representativeness analysis, labeling methodology, and ground truth definitions.
• Model validation artifacts: Document model architecture, hyperparameters, training procedures, performance metrics across relevant subgroups, and the statistical methodology used for validation. Include evidence that the model performs within acceptable limits across clinically relevant populations and use conditions.
• Predetermined Change Control Plan (PCCP): For devices intended to learn and adapt, document the PCCP per FDA guidance. This includes the description of anticipated modifications, the algorithm change protocol, and the impact assessment methodology.
• Monitoring and performance records: Post-deployment model performance monitoring data — including drift detection, real-world performance metrics, and retraining triggers — should be captured as part of ongoing production records.

Practical note: Software documentation requirements are evolving rapidly. The FDA's guidance on AI/ML-based SaMD, IEC 62304, and the forthcoming IEC 81001-5-1 (health software security) all inform what belongs in the DHF/DDF and DHR for software devices. Organizations developing software medical devices should build their documentation framework to accommodate these standards from the start rather than retrofitting compliance later.

Audit Preparation Checklist

Before any regulatory inspection or notified body audit, verify the following:

DHF readiness:

• DHF index is current and lists all documents with correct revision levels
• Design input-to-output traceability matrix is complete
• All design reviews are documented with attendees, minutes, and action item resolution
• Verification and validation records cover all design inputs
• Risk management file is current and complete
• Design transfer records demonstrate successful transfer to production

DMR readiness:

• DMR index is current and lists all documents with correct revision levels
• All referenced documents are at the current approved revision
• Work instructions are clear, detailed, and match actual production practices
• Acceptance criteria are objective and measurable
• Labeling specifications match actual labels in use
• Packaging specifications match actual packaging configuration

DHR readiness:

• Recent DHRs are complete with all required signatures, dates, and test results
• DHRs reference correct DMR revision levels
• Deviations and nonconformances are documented and dispositioned
• Traceability records link finished devices to component lots
• A sample DHR can be retrieved within minutes for any given lot number

Frequently Asked Questions

What is the difference between a DHF and a DMR?

The DHF (Design History File) documents how and why the device was designed — it contains the complete record of the design and development process, including user needs, design inputs and outputs, verification and validation results, risk management records, and design reviews. The DMR (Device Master Record) documents how to manufacture the device — it contains the current approved specifications, work instructions, test procedures, and quality requirements needed to produce the device consistently. The DHF tells the story of development; the DMR is the production playbook. A useful way to remember the distinction: the DHF looks backward at the design journey, while the DMR looks forward at every future production run.

Does a Class I device need a DHF?

Most Class I devices do not require a DHF because they are exempt from design controls under 21 CFR 820.30. However, there is an important exception: any Class I device that includes software or firmware is subject to design controls and therefore requires a DHF. Additionally, all Class I devices — even those exempt from design controls — must still maintain a DMR and generate DHRs. Some manufacturers choose to maintain a DHF for Class I devices voluntarily as a best practice, as it provides documented evidence of design intent that can be valuable during complaint investigations or product liability situations.

What is the difference between a DDF and a DHF?

A DDF (Design and Development File) and a DHF (Design History File) are functionally the same thing under different regulatory vocabularies. The DHF is the term from the legacy FDA Quality System Regulation (21 CFR Part 820). The DDF is the term used in ISO 13485:2016 Section 7.3.10. With the QMSR now in effect, the DDF is the officially recognized term in the harmonized regulatory framework. The content requirements are identical — both must contain or reference all records demonstrating that the device was designed and developed in accordance with the applicable requirements.

How long must you retain a DHR?

Under FDA regulations (21 CFR 820.180), quality system records — including DHRs — must be retained for a period equivalent to the design and expected commercial life of the device, but not less than two years from the date of release for commercial distribution. ISO 13485 Section 4.2.5 requires retention for at least the lifetime of the device as defined by the organization, but not less than two years from product release. The EU MDR (Article 10(8)) requires at least 10 years after the last device is placed on the market, or 15 years for implantable devices. In practice, most manufacturers retain DHRs for 10 years or the expected device lifetime plus 5 years, whichever is longer, to satisfy all applicable jurisdictions and to protect against product liability claims.

Can DHF, DMR, and DHR be electronic?

Yes. There is no regulatory requirement for these records to be on paper. Electronic records are fully acceptable and have become the industry standard. However, if you maintain electronic records that are required by FDA predicate rules (which DHF, DMR, and DHR records are), those records must comply with 21 CFR Part 11 requirements for electronic records and electronic signatures. This means the electronic system must be validated, must maintain secure audit trails, must enforce access controls, and must use electronic signatures that are unique, attributable, and non-repudiable. Most modern eQMS platforms are designed with Part 11 compliance in mind.

What happens during an FDA inspection related to these files?

During an FDA inspection, investigators will typically request to see all three document sets. For the DHF, they may ask to trace a specific design input through verification and validation, or they may review design review records and risk management files. For the DMR, they will verify that manufacturing specifications are current, complete, and match actual production practices. For the DHR, they will often select specific lot or batch numbers — frequently those associated with complaints or adverse events — and review the complete production record for evidence of compliance with the DMR. Investigators also test retrieval capability: if you cannot locate a requested DHR within a reasonable timeframe, that itself becomes a concern. Common findings include missing signatures, incomplete test records, undocumented deviations, and DHRs that do not reference the correct DMR revision.

What changed under the QMSR?

The QMSR, which took effect on February 2, 2026, replaced the standalone FDA Quality System Regulation with a framework that incorporates ISO 13485:2016 by reference. The fundamental requirements for design documentation, manufacturing instructions, and production records remain intact. The key changes are terminological and structural: the DHF is now formally the DDF (Design and Development File) per ISO 13485 Section 7.3.10, the DMR aligns with the MDF (Medical Device File) concept, and the DHR aligns with production and batch records under ISO 13485 Sections 7.5.1 and 7.5.9. The FDA retained supplemental requirements for DMR and DHR documentation that go beyond what ISO 13485 alone requires. Organizations that were already dual-compliant with the old QSR and ISO 13485 experienced minimal disruption. Those operating only under the old QSR framework needed to map their documentation systems to ISO 13485 clause structure.

Who is responsible for maintaining the DMR?

The DMR is typically owned by Manufacturing Engineering in collaboration with Quality Assurance, though the exact organizational assignment varies by company. What matters is that ownership is explicitly defined and that a clear change control process governs all DMR updates. Any change to the DMR — whether a specification update, a process parameter revision, or a labeling change — must go through formal change control with impact assessment, review, and approval by authorized personnel. Document Control is usually responsible for the administrative management of the DMR (version control, distribution, archival), while the technical content is owned by the relevant functional groups (engineering for specifications, quality for test procedures, regulatory for labeling).

Can the DHF, DMR, and DHR be combined into one system?

They can coexist within a single document management or eQMS platform, and they should be cross-referenced. However, they serve fundamentally different purposes and should be maintained as distinct collections. Combining them into a single undifferentiated file defeats the purpose and makes retrieval and auditing more difficult.

Do I need a separate DHF for each variant of my device?

Not necessarily. If device variants share a common design history and the differences are minor, a single DHF for the device family is acceptable, provided that variant-specific design activities are clearly identified within it. ISO 13485 uses the phrase "each medical device type or medical device family" — the definition of a family is yours to establish, but it should be documented and defensible.

How does the DHF relate to the Technical File for CE marking?

The DHF contributes to the Technical File but does not replace it. The EU MDR Technical Documentation (Annex II) requires information that goes beyond design history — including clinical evaluation, GSPR mapping, post-market surveillance planning, and more. The DHF typically forms the design and verification/validation portion of the Technical File.

What happens to the DHF after design transfer?

The DHF does not close or become inactive after design transfer. Any subsequent design changes to the device generate additional DHF records. The DHF remains a living record of the device's complete design history for the entire time it is on the market.

Is a DHR required for every single unit?

For most devices, DHRs are maintained per lot or batch rather than per individual unit. However, for high-risk devices such as custom implants, combination products, or devices manufactured in very low volumes, unit-level DHRs may be necessary to ensure full traceability. The level of DHR granularity should be defined in your quality system based on risk, regulatory requirements, and traceability needs.

Who is responsible for approving the release of a DHR?

Typically, Quality Assurance performs the final review and release of the DHR. The person authorizing release should be independent of production and should verify that all acceptance criteria were met, all deviations were dispositioned, and the DHR is complete. This authority should be defined in your quality system procedures.

What is the difference between a DHR and a batch record?

The terms are often used interchangeably, and in many organizations they refer to the same document set. Under FDA terminology, the DHR is the official term defined in 21 CFR 820.184. In pharmaceutical and some international medical device contexts, "batch record" is the more common term. Under the QMSR and ISO 13485, "production records" and "batch records" are the preferred terminology. Regardless of the label, the content requirements are the same: a complete record demonstrating that a specific lot or batch was manufactured in accordance with the approved specifications and procedures.

Conclusion

The DHF, DMR, and DHR are not bureaucratic formalities. They are the documentary evidence that your device was designed under controlled conditions, that manufacturing instructions are complete and current, and that each unit shipped to customers was built correctly. They are what stands between your organization and an FDA warning letter, a failed audit, or a product liability claim without documentation to support your defense.

Getting these documents right requires investment — in templates, systems, training, and organizational discipline. But the cost of getting them wrong is orders of magnitude higher. Every recalled device, every complaint investigation, and every regulatory inspection will trace back to these records. Build them correctly from the start, maintain them rigorously, and ensure every member of your organization understands their role in the system.

The QMSR has not changed this reality. It has harmonized the language and aligned the requirements with ISO 13485, but the fundamental obligations remain: document the design, define the manufacturing instructions, and record every production run. DHF, DMR, and DHR — whether you call them DDF, MDF, and production records under the new terminology — are here to stay.