ISO 13485 kept the DHR; it just calls it a batch record

This blog has already traced what happened to the device master record and the design history file when the Quality Management System Regulation retired both terms in February 2026 — their content split unevenly across ISO 13485's own clauses, not deleted. The device history record went through the same retirement, and it is worth separating from the other two, because a DHR was never a planning document the way a DMR or a DHF was. It is evidence, produced after the fact, that one specific batch, lot, or unit was actually built the way the other two records said it would be. Losing track of where that evidence now lives is a different failure than losing track of a design rationale.

A production record, not a design record

Old 820.184 required a device history record for each unit, lot, or batch, demonstrating that the device was manufactured in accordance with the device master record — the dates of manufacture, the quantity made, the quantity released for distribution, the acceptance records showing it met the DMR's own specification, and the primary identification label and labeling actually used on that production run. Nothing in that list is a design decision. It is the paper trail a specific batch leaves behind, built to let an investigator or an internal team trace a unit already in the field back to exactly how and when it was made.

820.184 is reserved; the duty moved to Clause 7.5.1

The QMSR's final rule reserves old 820.184 outright, alongside 820.181's device master record and 820.30(j)'s design history file content, as part of incorporating ISO 13485:2016 into Part 820 by reference. The DHR's own content didn't travel into Clause 4.2.3's medical device file the way most of the DMR's content did; a medical device file is itself a specification, not a batch-by-batch production log. It lands instead at the close of Clause 7.5.1, General requirements for production and service provision, which requires the organization to maintain records for each batch of medical devices that provide traceability and identify the quantity manufactured and the quantity approved for distribution — verified and approved before the batch is released.

The label changed; the traceability test didn't

Read side by side, Clause 7.5.1's closing paragraph and old 820.184 are asking the same question in different words: can this specific batch be traced back to proof that it was made correctly, and forward to how much of it actually shipped. ISO 13485 doesn't reproduce 820.184's own itemized list — dates of manufacture and label used, named individually — but a quality system that can't answer the traceability and quantity question Clause 7.5.1 actually asks has not satisfied the clause just because it stopped calling the record a DHR. The content test is closer to unchanged than the vocabulary suggests.

What FDA still asks for on top of the clause

The QMSR's own retained additions bear on this record too, not just on labeling and complaints. Section 820.35, the FDA-specific supplement layered on top of ISO 13485, reaches into traceability and unique device identification — a production record missing the UDI tied to a given batch is missing something Clause 7.5.1 alone never asked for, but 820.35 does. A batch record built to the standard's own clause and stopped there has answered ISO 13485's question without answering Part 820's.

Retention runs through the same clock as everything else

A device history record doesn't carry its own separate retention rule apart from the rest of the quality system. It retains under the same Clause 4.2.5 floor this blog has already covered for every other QMSR record — the organization's own defined device lifetime, or two years from release, whichever is longer. A batch record scoped only to production sign-off and discarded once a device clears its warranty period is very likely falling short of the same lifetime-based floor a design file or a complaint record already has to meet.

Where this meets the file

A production-record template built around Clause 7.5.1's own traceability and quantity requirement, cross-checked against Section 820.35's UDI addition, and mapped explicitly back to the retired 820.184 so a transition audit can show where each old requirement actually landed, is previewed in the launch catalog. If your program's batch records trace this differently, the shelf takes that correction directly.