1DHF vs DMR vs DHR: the difference.
| Design history file | Device master record | Device history record | |
|---|---|---|---|
| Answers | How was the design developed, verified and changed? | How is this device built, tested, labelled and serviced? | How was this lot or unit built, and was it released correctly? |
| QSR source | 820.30(j) | 820.181 | 820.184 |
| QMSR name | Design and development file, clause 7.3.10 | Medical device file, clause 4.2.3 | Record for each device or batch, clause 7.5.1 |
| How many | One per type; under ISO, per type or family | One per type; under ISO, one or more files per type or family | One per batch, lot or unit |
| Owner and sign-off | Design team; reviews include each function concerned, manufacturing among them; changes approved before implementation | Document control; it must show what is current on the manufacturing floor | Production; the record is verified and approved, and release documented |
The three records hand over to each other:
- Design file. Built from the design plan onwards. Reviews include manufacturing, so outputs are checked as suitable for production before they become production specifications.²
- Design transfer, clause 7.3.8. “The final design output from the design phase, which is maintained or referenced in the design and development file, forms the basis or starting point for the MDF”.³²
- Device file to lot record. Each lot is built to the current device file, and its record shows release requirements were met.³²
- Later changes. A design change goes into the design file, revises the device file and must show in the lot records built after it.²⁴
The design file applies where 820.10(c) requires design controls: class II and III devices and the listed class I devices, including those automated with software.⁵
2What the QMSR did to the three records.
Since 2 February 2026, Part 820 has incorporated ISO 13485:2016 and no longer uses the terms design history file, device master record or device history record. The searchable text of today’s Part 820 contains none of them.⁵ FDA explained why:
“ISO 13485 does not contain requirements for record types specified in the QS regulation, such as quality system record (QSR), DMR, DHF, and DHR. As stated in the QMSR proposed rule, we are not retaining separate requirements for these record types in the QMSR and have eliminated terms associated with these specific record types because we believe the elements that comprise those records are largely required to be documented by ISO 13485”. FDA, QMSR final rule, response to comment 31, 2 February 2024³
3The mapping, element by element.
Both old records were lists of contents. This is where each item now sits.
| Old item | What it covered | Where it is now | Source |
|---|---|---|---|
| DMR (a) | Device specifications, drawings, software | MDF: specifications for product | 4.2.3² |
| DMR (b) | Production process and environment | MDF: manufacturing, packaging, storage, handling and distribution | 4.2.3² |
| DMR (c) | QA procedures, acceptance criteria | MDF: procedures for measuring and monitoring | 4.2.3² |
| DMR (d) | Packaging and labelling specifications | MDF: labelling and packaging; FDA’s labelling controls | 4.2.3;² 820.45⁵ |
| DMR (e) | Installation and servicing | MDF: installation and servicing, as appropriate | 4.2.3² |
| New | Not in the DMR | MDF: general description and intended use | 4.2.3² |
| DHR (a) | Dates of manufacture | Not in clause 7.5.1 as MDSAP summarises it, but still on MDSAP’s audit list for each batch record, and required in Brazil | Task 17² |
| DHR (b) | Quantity manufactured | Device or batch record: amount manufactured | 7.5.1² |
| DHR (c) | Quantity released | Device or batch record: amount approved for distribution | 7.5.1² |
| DHR (d) | Acceptance records | Evidence that release requirements were met | 8.2.6² |
| DHR (e) | Labels and labelling used | Labelling release and inspection results documented; label and labelling used still expected | 820.45(b), (c);⁵ comment 64³ |
| DHR (f) | UDI and control numbers | UDI recorded for each device or batch; traceability | 820.35(c);⁵ 7.5.9.1² |
Two differences matter in practice. Clause 7.3.10 names design change records outright, where 820.30(j) covered them only as records showing the design was developed in accordance with “the requirements of this part”, so a change made after transfer belongs in the design file as well as in the device file it alters.²¹ And on labelling, FDA told a commenter that it “continues to expect that manufacturers will retain records of labeling operations to include the primary identification label and/labeling used for each production unit, lot, or batch record.”³ Recording only that labels were checked is not enough.
4Medical device file template.
An index that contains or references each item meets clause 4.2.3; the documents can stay where they are.²
| Section | Contents | Requirement |
|---|---|---|
| 1. Scope | Device type or family, models and variants covered | 4.2.3² |
| 2. Description | General description and intended use or purpose | 4.2.3² |
| 3. Labelling | Labels, instructions for use, UDI label format | 4.2.3;² 820.45⁵ |
| 4. Product | Drawings, bill of materials, component and software specifications | 4.2.3² |
| 5. Manufacturing | Process specifications, work instructions, equipment, environment | 4.2.3² |
| 6. Packaging and distribution | Packaging, storage, handling and distribution specifications | 4.2.3² |
| 7. Measuring and monitoring | Inspection and test procedures, acceptance criteria | 4.2.3² |
| 8. Installation | Requirements, where the device needs them | 4.2.3² |
| 9. Servicing | Procedures, set up to capture what 820.35(b) requires in service records | 4.2.3;² 820.35(b)⁵ |
| 10. Regulatory | UDI assignment, the marketing authorisation, other markets’ requirements | 4.2.3;² 820.10(b)(1)⁵ |
| 11. Design link | The design and development file that supplied the final outputs | Comment 31³ |
5Example: one device’s three records.
This example is invented. PX-27 is a class II syringe pump made in lots, with one design file, one device file and a record for each lot.
| Record | Entry for PX-27 |
|---|---|
| Design file DDF-PX27 | Plan, inputs, outputs, reviews, verification, validation, transfer, and change DCR-26-118: firmware 3.2.0 to 3.2.1, approved at a design review on 2 September 2026. |
| Device file MDF-PX27 rev F | The index above. Revision F, effective 21 September 2026, adds firmware 3.2.1 to section 4 and updated test procedure TP-PX27-07 to section 7. |
| Lot 26-0412, identity | Built to MDF-PX27 rev F, 5 to 9 October 2026. Units PX27-2604121 to PX27-2604240, each recorded with the device identifier and serial number in its UDI. |
| Lot 26-0412, quantities | Manufactured 120. Final test to TP-PX27-07: 117 passed first time, 3 failed the occlusion alarm check. NC-26-311: 2 reworked and passed retest, 1 scrapped. Approved for distribution 119. |
| Lot 26-0412, firmware | Version 3.2.1 loaded and verified on all 120 units, with DCR-26-118 referenced. |
| Lot 26-0412, labelling | Label LBL-PX27 rev D and instructions IFU-PX27 rev C used; one printed label kept. Label stock examined for UDI, storage and handling instructions before release; each unit’s label inspected before use; results signed. |
| Lot 26-0412, release | QA reviewed and approved the record on 14 October 2026. |
6What to rename and what to keep.
- Old records stay as they are. At FDA’s April 2026 town hall, its presenter Karen Masley-Joseph said manufacturers “do not need to revise or recreate records that were created before February 2, 2026”, and need not remove terms such as design history file from them, but should plan for any gap found.⁶ Investigators may still review them; FDA suggests a comparative analysis showing they meet the QMSR.⁷
- New procedures map the names. Call the files what you like, but require what clauses 4.2.3, 7.3.10 and 7.5.1 and Part 820’s additions require, and state which old record each file replaces.³⁵
- Gaps to look for. A device file with no description or intended use; a design file with no post-transfer changes; a lot record without the UDI, its dates of manufacture (on MDSAP’s audit list; required in Brazil) or the labelling actually used; labelling inspections with no documented result.²⁵³
- Brazil. Where Brazil is in an MDSAP audit’s scope, the device history record must also include or refer to components used and special process parameters, among other items, under RDC ANVISA 665/2022, Art. 40.²
- Contract design. Where the design was done under contract, FDA expects the manufacturer to maintain, or have reasonable access to, copies of the design and development file.⁸
- Combination products. A drug-device combination product made under a drug CGMP operating system, the streamlined route in 21 CFR 4.4(b)(1), must meet clause 7.3, so it needs a design and development file; the route does not name clauses 4.2.3 or 7.5.1.⁹ See combination products under Part 4.
7What investigators and auditors read.
Since 2 February 2026 FDA inspects against Compliance Program 7382.850, which replaced QSIT.⁷⁸ It covers the medical device file under management oversight, design and development files under design and development, and clause 7.5.1 with 820.35 and 820.45 under production. Investigators are told to check that labels carry a UDI “in conformance with the Medical Device File (MDF)” and to “Verify the UDI is recorded for the medical device or batch of medical devices.”⁸
Design coverage has limits. FDA reviews design records once the device is marketed or after a step such as an IDE or 510(k) submission, and only for design work after 1 June 1997. Where a manufacturer has made no design changes since then, or has no reviewable design project, investigators limit coverage to its design change control procedures.⁸ MDSAP auditors, by contrast, review at least one design and development file and its medical device file at every audit: “A minimum of one review of a design and development file and related medical device file should be undertaken per audit”. The task numbers here come from audit model AU P0002.009 of 6 August 2024, whose United States checks cite old sections, such as 820.120 and 820.184 in Task 17; read those as 820.45 and 820.35(c). MDSAP has since published revision .011, dated 3 August 2026, so check task numbers against it.²⁵¹⁰
“your firm was unable to produce any records during the inspection demonstrating that any of your six marketed devices were developed in accordance with Clause 7.3, No design and development files have been maintained for your six products cleared under K223431, K193155, K171750, K012547, K131202, or K901471.” Nipro Renal Solutions USA, Corporation, warning letter, dated 16 July 2026¹¹
Nipro’s response committed to a “DHF Gap Assessment and Reconstruction Program”.¹¹ The old name was not the problem; the missing records were.
“ECO 25-039 (effective June 23, 2025) documents a WoundPro+ firmware update from revision (b)(4) to (b)(4). No batch record or other record demonstrating implementation of this change was provided upon request to confirm the update was implemented.” Lion Street Medical, d/b/a Pensar Medical LLC, warning letter, 21 August 2026⁴
That finding is cited under clause 7.3.9, design changes: the change record and the production record have to meet.⁴
8How it runs in Seal.
In Seal, an electronic device history record is built around the actual serial or lot as work happens: components, inspections, labels, software, exceptions and release. Device master data is held as executable configuration, so each serial keeps the revision it was built to, and labels, UDI and firmware come from approved state. Rework is a controlled branch that keeps the original failed state, and an engineering change identifies the open orders, inventory, labels and released populations it affects before it takes effect.
For design control, each design input links to its outputs, verification, validation and reviews, and the traceability matrix is a view of those links. A requirement with no linked test is listed as a gap, and the design file is organised from records kept throughout development rather than assembled before an audit.
References
- 121 CFR Part 820 as in force on 1 February 2026, sections 820.30(j), 820.181, 820.184 and 820.186, eCFR point-in-time. https:/
/ www. ecfr. gov/ on/ 2026- 02- 01/ title- 21/ chapter- I/ subchapter- H/ part- 820 (read 8 November 2026) - 2MDSAP AU P0002.009, Audit Approach, quoting ISO 13485:2016 clauses 4.2.3 and 7.3.10, with management Task 8, design Tasks 13, 14 and 16, production Tasks 16 and 17 (including Brazil’s requirements under RDC ANVISA 665/2022, Art. 40) and the technical documentation section, FDA, revision of 6 August 2024. https:/
/ www. fda. gov/ media/ 166672/ download (read 8 November 2026) - 3Medical Devices; Quality System Regulation Amendments, final rule, 89 FR 7496, responses to comments 31 (89 FR 7507), 63 and 64 (89 FR 7516), FDA, 2 February 2024. https:/
/ www. govinfo. gov/ content/ pkg/ FR- 2024- 02- 02/ html/ 2024- 01709. htm (read 8 November 2026) - 4Lion Street Medical, d/b/a Pensar Medical LLC, warning letter, MARCS-CMS 733015, FDA, 21 August 2026. https:/
/ www. fda. gov/ inspections- compliance- enforcement- and- criminal- investigations/ warning- letters/ lion- street- medical- dba- pensar- medical- llc- 733015- 08212026 (read 8 November 2026) - 521 CFR Part 820, Quality Management System Regulation, sections 820.3, 820.10, 820.35 and 820.45, eCFR, full text searched. https:/
/ www. ecfr. gov/ current/ title- 21/ chapter- I/ subchapter- H/ part- 820 (read 8 November 2026) - 6FDA’s Quality Management System Regulation (QMSR): Medical Device Risk-Based Inspections, CDRH town hall transcript, FDA, 1 April 2026. https:/
/ www. fda. gov/ media/ 191960/ download (read 8 November 2026) - 7Quality Management System Regulation: Frequently Asked Questions, update note and questions 7 and 9, FDA. https:/
/ www. fda. gov/ medical- devices/ quality- management- system- regulation- qmsr/ quality- management- system- regulation- frequently- asked- questions (read 8 November 2026) - 8Compliance Program 7382.850, Medical Device Manufacturers, special instructions concerning design and development, sections on contract design and UDI, and Attachment A, FDA, implemented 2 February 2026. https:/
/ www. fda. gov/ media/ 80195/ download (read 8 November 2026) - 921 CFR 4.4, How can I comply with these current good manufacturing practice requirements for a co-packaged or single-entity combination product, eCFR. https:/
/ www. ecfr. gov/ current/ title- 21/ section- 4. 4 (read 8 November 2026) - 10Audit Approach, MDSAP AU P0002.011, Medical Device Single Audit Program, 3 August 2026. https:/
/ www. mdsap. global/ documents/ library/ audit- approach (read 8 November 2026) - 11Nipro Renal Solutions USA, Corporation, warning letter, MARCS-CMS 732874, FDA, dated 16 July 2026, issued 24 July 2026. https:/
/ www. fda. gov/ inspections- compliance- enforcement- and- criminal- investigations/ warning- letters/ nipro- renal- solutions- usa- corporation- 732874- 07242026 (read 8 November 2026)
AQuestions and answers
Can we keep calling it a design history file?
FDA removed the term because ISO 13485 does not use it, and told manufacturers they need not strip it from records made before February 2026. What an investigator checks is whether the file contains or references the records ISO 13485 clause 7.3.10 requires, including design changes. If your procedures keep the old names, state in them which clause each file meets, so nobody has to guess where the design history went.
Is EU MDR technical documentation the same as the medical device file?
No, but they overlap. The medical device file in ISO 13485 must show conformity to the standard and compliance with applicable regulatory requirements, so for a device sold in the EU it can index the MDR technical documentation. That documentation follows Annexes II and III of the MDR: description and specification, information supplied by the manufacturer, design and manufacturing, safety and performance requirements, benefit-risk and risk management, verification and validation, and post-market surveillance.
Can design and device history records be fully electronic?
Yes. In the QMSR final rule FDA said manufacturers can choose electronic records and electronic methods for denoting approval, and that its focus is whether the substance of the requirements is met, not the physicality of the record or signature. Where ISO 13485 says a record is approved, FDA reads that as signed and dated, so an electronic approval has to show who approved and when. Records kept electronically to meet FDA requirements also fall under 21 CFR Part 11, which sets the controls that make electronic records and signatures trustworthy.
How long must device records be kept under the QMSR?
ISO 13485, as FDA now enforces it, asks for records to be kept for at least the lifetime of the device, and not less than two years from product release. Other regulations can require longer: the EU MDR, for example, sets 10 years after the last device is placed on the market for technical documentation, and 15 for implantable devices.
Is a device history record the same as a batch record?
Close. Under the old Quality System Regulation, the device history record held the production history of each batch, lot or unit. FDA now says many of those requirements are largely required in the medical device or batch record of ISO 13485 clause 7.5.1, which records the amount manufactured and approved for distribution and is verified and approved. A drug batch production record under 21 CFR 211.188 is a different requirement.