DHF, DMR, DHR Explained: Design Controls & The New FDA QMSR

When I first started working with medical device design controls, I remember staring at a stack of documents with acronyms that seemed designed to confuse: DHF, DMR, DHR. My manager asked me to "pull the DHR for lot 447 and cross-reference it against the DMR revision B," and I nodded confidently while secretly wondering if I had accidentally joined a secret society with its own cryptic language.

If you have ever felt that same confusion, you are not alone. These three acronyms represent the backbone of FDA design controls, and understanding them is essential for anyone working in medical device development, quality assurance, or regulatory affairs. But here is the challenge: as of February 2, 2026, the regulatory landscape has shifted. The FDA's new Quality Management System Regulation (QMSR) has introduced new terminology—DDF and MDF—that replaces some of these familiar terms while harmonizing U.S. requirements with ISO 13485:2016.

In this comprehensive guide, I will explain what DHF, DMR, and DHR actually mean, how they work together to create traceability throughout the product lifecycle, and what the new QMSR changes mean for your compliance strategy. Whether you are a seasoned quality engineer or just starting your career in medical devices, this article will give you the practical knowledge you need to navigate both the legacy terminology and the new regulatory framework.

The Cake Analogy: Understanding DHF, DMR, and DHR

One of the most effective ways to understand these three document types is to think about baking a cake. This analogy, originally shared by Zeba Pedersen Löwen-Åberg in a LinkedIn discussion about medical device documentation, brilliantly captures the relationship between design, manufacturing, and production records.

DHF = The Definition of the Cake

The Design History File (DHF) is like the definition of what your cake should be. It contains all the design details: What kind of cake is it? Chocolate, vanilla, or red velvet? How many layers should it have? What should the frosting look like? What are the dimensions? Who is it for, and what dietary requirements must it meet?

In medical device terms, the DHF contains everything that defines what your device is and how it should work. It includes design inputs (user needs, regulatory requirements, intended use), design outputs (drawings, specifications, software code), design reviews (formal checkpoints where the design is evaluated), design verification (did we build it right?), and design validation (did we build the right thing?). The DHF answers the fundamental question: "What did we intend to create, and how did we ensure that intention was sound?"

DMR = The Recipe and Materials

The Device Master Record (DMR) is like the recipe for your cake. It tells you exactly what ingredients you need (flour, sugar, eggs, butter), in what quantities, and in what order to combine them. It specifies the baking temperature and time, the equipment needed (mixing bowls, oven, cake pans), and the quality checks to perform along the way (test with a toothpick, ensure the cake springs back when touched).

For medical devices, the DMR contains all the instructions, drawings, and specifications needed to manufacture the device consistently. It includes the device specifications, production process specifications, quality assurance procedures and specifications, packaging and labeling specifications, and installation, maintenance, and servicing procedures. The DMR answers: "How exactly do we build this device so that it meets the design every single time?"

DHR = The Record of What You Actually Baked

The Device History Record (DHR) is like the description of the actual cake you baked. It documents which recipe you used (DMR revision), what ingredients you actually used (lot numbers, supplier information), how long you baked it, what the temperature was, and any deviations or issues that occurred (the oven ran hot, so you adjusted the time). It proves that you followed the recipe and that the resulting cake met your quality standards.

In medical devices, the DHR is created for each batch, lot, or unit produced. It contains the dates of manufacture, quantity manufactured, quantity released for distribution, acceptance records showing the device was manufactured according to the DMR, the primary identification label and labeling used, and any unique device identifier (UDI) information. The DHR answers: "Did we actually build this specific device correctly according to the instructions?"

Deep Dive: The Design History File (DHF)

Let us examine the DHF in greater detail because it is where every medical device journey begins. The DHF is not a single document but rather a collection of records that demonstrates the design was developed in accordance with the approved design plan and the requirements of 21 CFR Part 820.30 (FDA) or Clause 7.3 of ISO 13485:2016.

Components of a Complete DHF

Design Planning (820.30(b)): Every DHF begins with a design plan that describes the design and development activities, assigns responsibilities for those activities, and identifies the interfaces between different groups involved in the design. The plan evolves as the design progresses, but having this roadmap from the start is essential for regulatory compliance.

Design Inputs (820.30(c)): These are the requirements that form the foundation of your design. They include user needs (what the device must do for the patient or healthcare provider), regulatory requirements (FDA regulations, international standards like ISO 13485, EU MDR), risk management outputs (from ISO 14971), and any requirements arising from previous similar designs. Good design inputs are unambiguous, complete, and verifiable. Poorly defined inputs are the root cause of many device failures and regulatory rejections.

Design Outputs (820.30(d)): These are the results of the design effort—drawings, specifications, software code, manufacturing instructions, test methods, and labeling. Each design output must be verified against the corresponding design input to ensure traceability. The outputs must also be reviewed to confirm they meet the input requirements and can be adequately manufactured.

Design Review (820.30(e)): Formal design reviews are systematic examinations of the design to evaluate its adequacy, identify problems, and propose solutions. The FDA requires at least one design review, but most companies conduct multiple reviews at key stages (preliminary design, critical design). Participants must include representatives from all functions concerned with the design stage being reviewed, plus an independent reviewer who was not directly involved in the design.

Design Verification (820.30(f)): This is the process of confirming that design outputs meet design inputs—essentially, "did we build it right?" Verification activities include testing, analysis, and inspection. The DHF must contain verification protocols, test results, and evidence that acceptance criteria were met. For software, this includes unit testing, integration testing, and system testing.

Design Validation (820.30(g)): This confirms that the device meets user needs and intended uses—"did we build the right thing?" Validation must be conducted under defined operating conditions on initial production units or their equivalents. Clinical evaluations, simulated use testing, and comparison to predicate devices (for 510(k) submissions) are common validation methods.

Design Transfer (820.30(h)): This is the process of translating the design into production specifications. The DHF must demonstrate that the design was correctly transferred to manufacturing, that production personnel understood the requirements, and that the manufacturing process could consistently produce devices meeting specifications.

Design Changes (820.30(i)): All changes to the design after initial release must be documented, reviewed, and approved before implementation. The DHF must show that changes were evaluated for their impact on the device, including risk management, and that affected documents were updated.

Design History File Index: A well-organized DHF includes an index that lists all documents, their revision levels, and their locations. This index is invaluable during FDA inspections and for maintaining the file over the device lifecycle.

Deep Dive: The Device Master Record (DMR)

If the DHF represents the design journey, the DMR represents the manufacturing destination. The DMR is the blueprint that ensures every device is built consistently, regardless of who is working on the production line or which shift is operating. FDA regulations at 21 CFR 820.181 specify that each manufacturer must maintain DMRs that include specific types of information.

Components of a Complete DMR

Device Specifications: These are the final, approved specifications that define what the device is and how it performs. They include dimensional drawings, material specifications, electrical/mechanical/software performance criteria, and environmental operating conditions. Device specifications should reference the design outputs from the DHF but represent the "frozen" version approved for production.

Production Process Specifications: These describe how the device is manufactured. They include manufacturing procedures, work instructions, process flow diagrams, equipment specifications, and environmental controls. For complex devices, this may include hundreds of detailed instructions. For software-only devices (SaMD), this includes build procedures, configuration management, and deployment processes.

Quality Assurance Procedures and Specifications: The DMR must include all inspection and testing procedures needed to ensure device quality. This includes incoming material inspection, in-process inspection points, final acceptance testing, and statistical process control methods. Each procedure must specify acceptance criteria, sample sizes (if applicable), and test equipment requirements.

Packaging and Labeling Specifications: Medical device packaging is critical for maintaining sterility (for sterile devices) and ensuring the device arrives undamaged. The DMR includes packaging specifications, labeling content and artwork, and instructions for use (IFU). Labeling must comply with FDA labeling regulations (21 CFR Part 801) and international requirements.

Installation, Maintenance, and Servicing Procedures: For devices that require installation or regular maintenance, the DMR must include procedures that ensure these activities are performed correctly. This is particularly important for complex diagnostic equipment or implanted devices that require periodic follow-up.

DMR Change Control

The DMR is a living document that evolves as manufacturing processes improve, suppliers change, or design changes are implemented. However, changes to the DMR must be controlled through a formal change management process. Each change requires evaluation of impact on risk management, validation or verification of the change, review and approval by appropriate personnel, and update of all affected documents. The DMR itself must indicate the effective date of changes to ensure that production always follows the current approved version.

Deep Dive: The Device History Record (DHR)

While the DHF and DMR define what should happen, the DHR proves what actually happened. The DHR is created for each production batch, lot, or individual device and serves as the traceability record linking the specific device back to the design and manufacturing specifications. FDA regulations at 21 CFR 820.184 specify the minimum contents of DHRs.

Components of a Complete DHR

Dates of Manufacture: The DHR must document when manufacturing began and when it was completed. This is crucial for traceability during recalls or investigations.

Quantity Manufactured: The total number of units produced in the batch must be recorded, along with the quantity released for distribution and the quantity rejected (if any).

Acceptance Records: These demonstrate that the device was manufactured according to the DMR. They include records of inspections and tests performed, test results, acceptance criteria applied, and the identity of personnel performing acceptance activities. Any deviations from the DMR must be documented, justified, and approved.

Primary Identification Label and Labeling: A copy or record of the actual labeling used must be included in the DHR. For devices with unique device identifiers (UDI), the UDI must be recorded.

Unique Device Identifier (UDI): Since the FDA's UDI rule took effect, most devices must bear a UDI that allows traceability from the specific device back to its manufacturing records. The DHR must document the UDI assigned to each device or batch.

Control Numbers: For devices that require traceability (Class II and III devices, implantable devices), the DHR must include control numbers for components, materials, and manufacturing equipment used. This allows investigators to trace potential issues back to specific lots of raw materials or specific pieces of equipment.

DHRs for Software Devices

For software as a medical device (SaMD), the DHR concept adapts to the digital environment. Instead of manufacturing dates, the DHR documents the software build version, the source code control revision numbers, the build environment configuration, and the results of automated testing. The "manufacturing" of software is the build process, and the DHR demonstrates that the build was created from approved source code using approved tools and procedures.

The Traceability Triangle: How DHF, DMR, and DHR Work Together

The true power of these three document types emerges when you understand how they interconnect. Together, they form what I call the "Traceability Triangle"—a closed loop that ensures every device can be traced from design intent through manufacturing to the specific unit delivered to the customer.

The Forward Traceability Path

Forward traceability starts with the DHF and follows through to production. User needs in the DHF become design inputs, which become design outputs, which become device specifications in the DMR. The DMR's production instructions guide the creation of each device, and the DHR proves that those instructions were followed. This path answers: "If we have a user need, can we prove it was implemented in the final device?"

The Backward Traceability Path

Backward traceability starts with a specific device and works back to its design origins. If a customer reports a problem with lot 447, you retrieve the DHR for that lot, which points you to the DMR revision used, which references the design outputs in the DHF, which were based on specific design inputs. This path answers: "Given a specific device with a problem, what were the requirements and design decisions that led to this feature?"

Practical Traceability Workflow Example

Let me walk through a practical example. Imagine you are a quality engineer at a company that manufactures infusion pumps. A customer reports that the alarm volume on their pump is too low to be heard in a noisy ICU environment.

Step 1: Retrieve the DHR - You look up the DHR for the device serial number. It shows that the device was manufactured on March 15, 2026, using DMR revision 4.2, with software version 3.1.5. The DHR shows that all acceptance tests passed, including the alarm sound pressure level test, which showed 65 dB at 1 meter.

Step 2: Review the DMR - You retrieve DMR revision 4.2 and look at the alarm specifications. The device specification calls for alarm volume between 60-70 dB at 1 meter. The production process specification includes a calibration procedure for the audio amplifier. The quality assurance specification requires 100% testing of alarm volume during final acceptance.

Step 3: Examine the DHF - You check the DHF to understand the design rationale. The design inputs include a user need stating "alarms must be audible in typical ICU environments." The design output specifies the 60-70 dB range. Design validation included user testing in simulated ICU environments where 65 dB was deemed adequate. However, the validation report notes that ambient ICU noise was modeled at 55 dB, and some modern ICUs may exceed this level.

Step 4: Determine Action - You now understand that the device meets specifications but the specifications may not adequately address all use environments. You initiate a design change to increase the minimum alarm volume to 75 dB, which requires updating the DHF (design change documentation), the DMR (device specification), and will result in a new DHR for devices manufactured after the change.

This example illustrates how the three documents work together to enable informed decision-making and continuous improvement.

The New FDA QMSR: Terminology Changes Effective February 2026

Now we must address the significant regulatory change that took effect on February 2, 2026. The FDA finalized its transition from the Quality System Regulation (QSR) in 21 CFR Part 820 to the new Quality Management System Regulation (QMSR). This change represents a major harmonization effort, aligning U.S. requirements with ISO 13485:2016. With this change comes new terminology that replaces some of the familiar terms we have been discussing.

Key Terminology Changes

Old Term (QSR)	New Term (QMSR)	ISO 13485 Reference
Design History File (DHF)	Design and Development File (DDF)	Clause 7.3.10
Device Master Record (DMR)	Medical Device File (MDF) - Section	Clause 4.2.3
Device History Record (DHR)	Production and Service Records	Clause 7.5.1, 7.5.3

Understanding the Design and Development File (DDF)

The DDF is the QMSR/ISO 13485 equivalent of the DHF. ISO 13485:2016 Clause 7.3.10 states that "the organization shall establish and maintain a design and development file for each medical device type or medical device family that contains or references records generated to demonstrate conformity to the requirements of design and development planning."

While the name has changed, the content remains essentially the same. The DDF still contains design planning documents, design inputs and outputs, design review records, design verification and validation records, design transfer records, and design change records. However, ISO 13485 places greater emphasis on risk management throughout the design process, requiring that risk management file references be integrated into the DDF.

One key difference is that ISO 13485 does not explicitly require a single consolidated "file" in the same way the FDA did with the DHF. Instead, the DDF can be a collection of documents or references to documents, as long as the organization can demonstrate conformity and traceability. This provides more flexibility in how companies organize their documentation, though most organizations will maintain a DDF structure very similar to their previous DHF.

Understanding the Medical Device File (MDF)

The Medical Device File (MDF) is perhaps the most significant conceptual change. While the DMR was primarily manufacturing-focused, the MDF has a broader scope. ISO 13485:2016 Clause 4.2.3 requires the organization to establish and maintain one or more files containing or referencing documents that demonstrate conformity to regulatory requirements.

The MDF includes what was previously in the DMR (device specifications, production process specifications, quality assurance procedures), but it also explicitly incorporates design and development documentation references, risk management files per ISO 14971, product realization planning, and regulatory submission documentation. The MDF is essentially a master index that ties together all documentation related to a device, creating a more holistic view than the DMR alone.

Importantly, the MDF requirement recognizes that medical device documentation is not just about manufacturing—it is about demonstrating conformity to all applicable regulatory requirements throughout the product lifecycle. This includes post-market surveillance data, vigilance reports, and clinical follow-up information.

Understanding Production and Service Records

Under the QMSR, the specific term "Device History Record" is replaced by the broader concept of "Production and Service Records" as defined in ISO 13485 Clauses 7.5.1 and 7.5.3. These clauses require that the organization maintain records that provide evidence that production and service processes have been carried out as planned.

The records must still demonstrate conformity with product requirements, but ISO 13485 also emphasizes traceability requirements more explicitly than the original QSR. For implantable devices and devices intended for sterile use, the standard requires documented records of the identity of personnel performing production and service activities, the equipment used, and the environmental conditions if relevant.

The transition from DHR to Production Records does not eliminate the requirement for batch records—it simply aligns the terminology with international standards and expands the scope to explicitly include service records for devices that are serviced or repaired.

Practical Compliance: Transitioning from QSR to QMSR

For medical device manufacturers, the transition to QMSR terminology is not merely a matter of updating document titles. It requires a systematic review of quality management system documentation and processes. Here are practical recommendations for managing this transition.

Document Mapping Exercise

Conduct a comprehensive mapping of your current DHF, DMR, and DHR documents to the new DDF, MDF, and Production Records structure. For most companies, the existing documents will largely align with the new requirements, but gaps may exist. Pay particular attention to:

• Risk Management Integration: ISO 13485 requires more explicit integration of risk management (ISO 14971) throughout the design and development process. Ensure your DDF references the risk management file and demonstrates that risk considerations informed design decisions.
• Regulatory Submission Documentation: The MDF explicitly includes regulatory submission documentation, which may not have been formally part of your DMR structure. Ensure 510(k) clearance letters, PMA approvals, or CE certificates are referenced in the MDF.
• Post-Market Data: The broader scope of the MDF includes post-market surveillance information. Consider how you will integrate vigilance reports, complaint data, and clinical follow-up into your device file structure.

Training and Change Management

Your quality and production personnel have used DHF/DMR/DHR terminology for years. The transition to DDF/MDF/Production Records requires training to ensure everyone understands the new terms and, more importantly, that the underlying concepts have not changed. Develop a training program that:

• Explains the rationale for the QMSR transition (global harmonization)
• Maps old terms to new terms with clear equivalencies
• Highlights any actual changes in requirements (not just terminology)
• Updates work instructions and procedures to use the new terminology
• Provides reference cards or quick guides for personnel during the transition period

Dual-Labeling Strategy

During the transition period, consider implementing dual-labeling of documents, showing both the old and new terminology. For example, a document header might read: "Design and Development File (DDF) - Formerly Design History File (DHF)." This approach reduces confusion while personnel adjust to the new terms and maintains clarity for external parties (auditors, inspectors) who may encounter both terminologies.

Regulatory Submissions and Correspondence

When submitting to the FDA or communicating with Notified Bodies, use the terminology appropriate to the context. For FDA submissions under the QMSR, use DDF/MDF terminology. When submitting to European Notified Bodies, ISO 13485 terminology is already expected. If you are submitting to both jurisdictions, you may need to include terminology cross-references or use both terms to ensure clarity.

Scientific and Regulatory Foundations

The requirements we have discussed are not arbitrary—they are based on decades of research into quality management, risk management, and regulatory science. Understanding this foundation helps quality professionals implement these requirements effectively.

ISO 13485:2016 and Quality Management Principles

ISO 13485:2016 is built on eight quality management principles: customer focus, leadership, involvement of people, process approach, system approach to management, continual improvement, factual approach to decision making, and mutually beneficial supplier relationships. The DHF/DDF, DMR/MDF, and DHR/Production Records structure embodies these principles by creating a process-oriented, evidence-based approach to medical device development and manufacturing.

Research in quality management has consistently shown that organizations with well-documented processes and clear traceability experience fewer defects, lower recall rates, and faster time to market. A 2021 analysis of FDA warning letters published in arXiv (Odaibo, 2021) found that inadequate design controls—including incomplete DHFs and inadequate traceability—were among the most common quality system violations cited by FDA inspectors.

Risk Management Integration (ISO 14971)

Modern medical device regulation places risk management at the center of all activities. ISO 14971:2019 provides the framework for identifying hazards, estimating and evaluating risks, controlling risks, and monitoring the effectiveness of risk controls. The DHF/DDF and DMR/MDF must explicitly demonstrate that risk management informed design and manufacturing decisions.

Research by Hunte, Neil, and Fenton (2022) published on arXiv demonstrated that Bayesian network approaches to medical device risk assessment can provide more nuanced risk quantification than traditional methods. Their work supports the ISO 14971 approach of systematic risk analysis and highlights the importance of traceability from risk controls to design outputs and manufacturing controls.

FDA 21 CFR Part 820 and the QMSR

The original QSR was promulgated in 1996 and was based on the FDA's Good Manufacturing Practices (GMP) combined with the international quality standard ISO 9001:1994. The QMSR update represents the first major revision in nearly three decades and brings U.S. requirements into alignment with the current ISO 13485:2016 standard.

This harmonization is significant because it reduces the regulatory burden on companies that market devices globally. Previously, companies often maintained separate quality systems for U.S. and international markets, or they implemented ISO 13485 while also ensuring QSR compliance—a dual burden that added complexity without improving safety.

The QMSR transition was extensively analyzed in a 2024 study by Zhalechian, Saghafian, and Robles published in arXiv, which examined the FDA's 510(k) pathway and the relationship between regulatory clarity and device recalls. Their research supports the FDA's harmonization effort, finding that clearer alignment with international standards can improve both regulatory efficiency and post-market safety outcomes.

Practical Recommendations for Quality Engineers

Having explored the theory and regulations, let us conclude with practical recommendations you can implement immediately in your organization.

Recommendation 1: Audit Your Traceability

Select a recent product and perform a traceability audit. Can you trace from any user need to the specific design output that implements it, to the manufacturing specification, to the production record for a specific device? Identify any gaps in this chain and address them. Strong traceability is the hallmark of a mature quality system.

Recommendation 2: Standardize Your Document Structure

Develop standardized templates and structures for your DHF/DDF, DMR/MDF, and DHR/Production Records. Consistency across products reduces errors, simplifies training, and makes inspections smoother. Your templates should include required elements per the regulations but can also incorporate company-specific best practices.

Recommendation 3: Implement Electronic Systems

If you are still using paper-based systems, consider transitioning to electronic quality management systems (eQMS). Electronic systems provide better searchability, automated workflows, and easier traceability analysis. However, ensure any eQMS implementation includes proper validation (per 21 CFR Part 11 for FDA-regulated devices) and maintains data integrity.

Recommendation 4: Train Cross-Functionally

Design controls and manufacturing documentation are not just quality department responsibilities. Engineers, production personnel, and regulatory staff all play roles. Implement cross-functional training so that everyone understands how their work contributes to the DHF/DDF, DMR/MDF, and DHR/Production Records. This shared understanding improves collaboration and reduces errors.

Recommendation 5: Plan for the Transition

The QMSR transition is not optional—it is required. Develop a transition plan that includes document updates, training, and internal audits to verify compliance with the new requirements. Do not wait until an FDA inspection or Notified Body audit to discover that your documentation still uses outdated terminology or structure.

Recommendation 6: Maintain Regulatory Intelligence

The regulatory landscape continues to evolve. Subscribe to FDA updates, follow ISO/TC 210 (the technical committee responsible for ISO 13485), and participate in industry associations. The organizations that stay ahead of regulatory changes have smoother audits and faster time to market.

Conclusion

The Design History File (now Design and Development File), Device Master Record (now Medical Device File), and Device History Record (now Production and Service Records) form the foundation of medical device quality management. These documents tell the complete story of a medical device—from the initial spark of an idea through design, manufacturing, and delivery to the patient.

The terminology may be changing with the FDA's QMSR implementation, but the fundamental principles remain constant: document your design intent, control your manufacturing processes, and maintain records that prove every device was built correctly. The cake analogy remains apt—the definition, the recipe, and the proof of what was actually baked.

For medical device professionals, mastering these concepts is not just about regulatory compliance—it is about ensuring that every device that reaches a patient is safe, effective, and fit for its intended purpose. The effort you invest in understanding and implementing these requirements translates directly into improved patient outcomes and reduced risk of device failures.

As the industry continues to evolve with new technologies like artificial intelligence, software as a medical device, and personalized medicine, the importance of robust design controls and documentation only increases. The companies that excel at these fundamentals will be best positioned to bring innovative, life-saving technologies to market efficiently and safely.

References and Further Reading

• FDA Quality Management System Regulation (QMSR), 21 CFR Part 820 (Effective February 2, 2026)
• ISO 13485:2016 - Medical devices — Quality management systems — Requirements for regulatory purposes
• ISO 14971:2019 - Medical devices — Application of risk management to medical devices
• FDA Design Control Guidance for Medical Device Manufacturers (March 1997, Updated 2024)
• Odaibo, S.G. (2021). Risk Management of AI/ML Software as a Medical Device (SaMD): On ISO 14971 and Related Standards and Guidances. arXiv:2109.07905 [cs.CY]
• Hunte, J., Neil, M., & Fenton, N. (2022). A hybrid Bayesian network for medical device risk assessment and management. arXiv:2209.03352 [cs.LG]
• Zhalechian, M., Saghafian, S., & Robles, O. (2024). Harmonizing Safety and Speed: A Human-Algorithm Approach to Enhance the FDA's Medical Device Clearance Policy. arXiv:2407.11823 [cs.LG]
• Mercolli, L., Rominger, A., & Shi, K. (2022). Towards Quality Management of Machine Learning Systems for Medical Applications. arXiv:2210.08881 [physics.med-ph]
• Farrington, M. (2024). DeviceBERT: Applied Transfer Learning With Targeted Annotations and Vocabulary Enrichment to Identify Medical Device and Component Terminology in FDA Recall Summaries. arXiv:2406.05307 [cs.CL]