DHRDevice History Record

A Device History Record (DHR) is the compilation of records that contains the production history of a finished medical device. For each unit, lot or batch of finished devices, the manufacturer must maintain a DHR that demonstrates the device was manufactured in accordance with the Device Master Record (DMR) and the requirements of the Quality System Regulation. The DHR is the per-build evidence that proves the master design and process were actually executed.

The DHR is required by 21 CFR 820.184 under the legacy Quality System Regulation, and, in substance, by ISO 13485:2016 clauses 4.2.5 and 7.5.1 under the QMSR that the FDA adopted in 2024 (88 FR 4252) and that takes effect in February 2026. EU MDR Annex IX requires the same artefact under a different name; UK MHRA, Health Canada and PMDA all expect the equivalent record. The artefact is universal across medical-device regulation; only the labelling changes.

820.184 lists the minimum the DHR must contain. Every DHR must demonstrate, at minimum:

1. The dates of manufacture.
2. The quantity manufactured.
3. The quantity released for distribution.
4. The acceptance records which demonstrate the device is manufactured in accordance with the DMR.
5. The primary identification label and labelling used for each production unit.
6. Any unique device identifier (UDI) or universal product code (UPC), and any other device identification(s) and control number(s) used.

The DHR is not the place where the DMR lives — the DMR is the master, the DHR is the evidence that this batch was made to that master. The two are linked but distinct. An inspector pulling a serial number from a complaint expects to follow it to the DHR; the DHR shows them the lot, the lot points back to the DMR version in force, and the cleanroom records, the in-process inspections, the labelling reconciliation, the operator signatures all live under the DHR.

The three Device records under 21 CFR 820 cover three different phases of a device's life and are not interchangeable.

The mnemonic: design (DHF) → master (DMR) → build (DHR). Or: how was it designed, how is it supposed to be made, how was this particular unit made.

On 2 February 2024 the FDA finalised the Quality Management System Regulation (QMSR, 89 FR 7496), which replaces most of 21 CFR 820 with a by-reference adoption of ISO 13485:2016. The transition date is 2 February 2026. The QMSR removes the explicit DHR requirement at 820.184 but retains the substance by pointing to ISO 13485 clauses 4.2.5 (control of records) and 7.5.1 (control of production and service provision).

What changes: the term 'Device History Record' is no longer in the regulatory text. What does not change: the manufacturer still has to maintain per-unit, per-lot or per-batch records demonstrating conformance to the DMR. ISO 13485 calls these 'records of the production and service provision' rather than 'DHR'. Inspectors continue to ask for them by their substance, not by their name, and most manufacturers continue to call them DHRs internally.

What you should change in your QMS: update SOPs to reference the new clauses; ensure your record-retention SOP cites ISO 13485 4.2.5 in addition to 820.184; and verify your eDHR system can produce per-lot reports satisfying both 820.184 (until February 2026) and ISO 13485 (from February 2026 onward). A system that hard-codes the legacy clauses will need rework.

820.184(d) requires 'the acceptance records which demonstrate the device is manufactured in accordance with the DMR'. This is the largest section of any defensible DHR. Acceptance records are the in-process inspections, the final inspections, the test results, the verifications and the validations that prove each step of the DMR's process was performed and passed.

820.80 governs acceptance activities and applies to incoming, in-process and finished devices. Each acceptance activity must be documented, must include the date performed, must identify the individual or equipment that performed the acceptance, and must reference the equipment used. The DHR is where these documents accumulate for one lot.

Critical acceptance attributes — those that affect safety or essential performance — typically require independent verification per 820.80 and ISO 13485 7.5.6. The DHR records both the performer and the verifier, with two distinct e-signatures, and the audit trail captures any attempt at self-verification.

820.184(e) requires the primary identification label and labelling used for each production unit to be in the DHR. This is a literal requirement: a specimen of every label applied to the device, retained in the record. For sterile packaging, the sterile seal label, the inner pouch label, the outer carton label and the shelf-pack label are all in scope. Labelling drift is a major source of recalls — a wrong revision of a label travelling out the door is what 820.184(e) is intended to prevent.

820.184(f) extends this to the UDI, the universal product code, and any device identifier or control number used. The UDI itself is a regulated artefact under 21 CFR 830; the DHR shows the UDI that was applied to each unit in the batch, the lot identifier (production identifier) it incorporated, and the data sent to the GUDID for that DI. For Class II devices the DHR ties to lot; for Class III devices the DHR may tie to individual serial number.

EU MDR Article 27 mandates the equivalent — a Basic UDI-DI registered in EUDAMED and a UDI on each device that traces back to the production record. Practically the DHR captures both UDI systems for any device shipping into both the US and the EU.

When a complaint comes in, 820.198 requires the manufacturer to investigate, to evaluate, and to decide whether the complaint represents an event reportable under MDR (Medical Device Reporting, 21 CFR 803). The DHR is the primary investigation evidence. The investigator pulls the serial or lot, opens the DHR, and reconstructs how that unit was built — the materials lots, the operators, the equipment, the inspections that passed, the deviations that were closed. A DHR that does not allow this reconstruction makes 820.198 impossible to satisfy.

Recalls are the same problem at scale. 21 CFR 7 and 21 CFR 806 govern recall and corrections. When a recall is initiated, the manufacturer must produce a list of affected units within hours, which means querying every DHR for a material lot, a cleanroom session, an operator, a sub-assembly batch. An eDHR system makes this a query; a paper DHR makes it a manual file-room exercise that can take days.

1. DHR exists but does not include acceptance records — 820.184(d) finding.
2. Label specimens missing or wrong revision — 820.184(e) finding, often recall-grade.
3. UDI capture inconsistent across units in the same lot — 820.184(f) and 21 CFR 830 finding.
4. DHR rendered from live DMR rather than from the DMR version in force at the time of build — accurate-reproduction rule broken.
5. Operator signatures captured as initials only, not as Part 11 e-signatures — 820.70(i) and Part 11 finding combined.
6. Cannot reconstruct the build chain for a single serial number from the DHR — 820.198 complaint handling impossible.
7. Deviations recorded outside the DHR — investigation chain broken, 820.100 CAPA traceability fails.
8. Retention purges the audit trail after the rendered PDF is archived — record-of-record argument fails.

In V5, discrete tenants operate on the same execution model as process tenants but with industry-aware terminology and structure. The work order corresponds to a build, the operation corresponds to an inspection or assembly step, and the work-order-level snapshot of the DMR plays the role the MMR snapshot plays in pharma.

• DMR snapshot at work-order release means a mid-build DMR revision can never silently change the structure of the DHR for an in-flight build.
• Per-unit serial capture and per-lot batch capture are first-class. UDI generation and GS1-128 label output integrate with the work order so the DHR carries the exact labels applied.
• Acceptance records — in-process inspections, final inspections, verifications — are kiosk-captured with photos and two-component e-signatures where required.
• Critical-step independent verification is enforced at the database tier: the verifier user_id cannot equal the performer user_id, and the audit trail records the attempt.
• Deviations raised from the kiosk generate a deviation record linked into the DHR view; the DHR cannot be released for distribution while a major deviation is open.
• The DHR view exposes per-lot and per-serial drill-down; complaint investigators can move from a serial number to the build chain in seconds.
• On release, V5 emits a regulated-report PDF of the DHR. The PDF is the rendering; the record of record is the structured data and its audit trail, retained for the full retention period.

See below for the regulator-grade answers to the questions buyers ask most often when evaluating an eDHR.