Device History Record (DHR) – Proof of Conforming Manufacture

This topic is part of the SG Systems Global regulatory glossary series.

Updated October 2025 • Medical Devices • 21 CFR 820 / ISO 13485 / EU MDR

A Device History Record (DHR) is the executed, time-stamped set of manufacturing and quality records demonstrating that each batch/lot or unit of a medical device was built, inspected, labeled, and released in accordance with the Device Master Record (DMR) and the manufacturer’s quality system. Where production is electronic, the term eDHR is common—emphasizing Part 11-compliant identity, audit trails, and e-signatures. The DHR is the operational mirror of the Design History File (DHF): the DHF argues that the design is suitable; the DHR proves that the device you shipped was made to that design—every time.

“A defensible DHR is a chain of attributable facts—who did what, when, on which device—with objective evidence that each step matched the DMR and that nonconformances were controlled before release.”

1) What It Is

The DHR is not a single form but a curated dossier of executed instructions and results for a production batch or serialised unit. It contains the bill of materials actually used, component acceptance status, critical process parameters, in-process and final inspection records, labeling evidence (including UDI), and the formal release decision by Quality. The purpose is traceability and proof of conforming manufacture: if an adverse event, complaint, or recall occurs, the DHR allows rapid backward/forward tracing—what parts went into which units and what tests were passed or failed.

2) Regulatory Anchors & Scope

Under legacy 21 CFR 820 (Quality System Regulation), manufacturers must maintain DHRs that “demonstrate the device is manufactured in accordance with the DMR and the requirements of this part.” ISO 13485 requires records of production and service provision, identification and traceability, and release. In the EU, MDR requires technical documentation and production records adequate for postmarket surveillance and vigilance. Across jurisdictions, the DHR also interfaces with UDI (21 CFR 830) and, where applicable, implant or life-support traceability (21 CFR 821). Complaint handling and vigilance reporting (803) and corrections/removals (806) depend on DHR integrity.

3) Canonical Contents of a DHR / eDHR

DHR content varies by device class, process complexity, and risk, but a robust eDHR typically includes:

• Identification & context. Product code, lot/serial numbers, work order, revision level, and the BOM/routing version in effect (config traceability).
• Component acceptance status. Records of Component Release including supplier, incoming inspection results, certificates (where used), and lot status at issue.
• Process execution. Time-stamped completion of each MES step with parameters and Dual Verification/sign-offs for critical actions; alarms and overrides with reason codes.
• In-process & final inspection. Measured values, pass/fail against acceptance criteria, sampling plans (e.g., AQL), and SPC control-chart evidence where applicable.
• Labeling & UDI. Approved label artwork reference via Approval Workflow, label template/version used, Barcode Validation scans, serialisation/UDI data, and reconciliation counts.
• Nonconformances & dispositions. Linked NCRs, quarantine/segregation records, rework instructions, retest outcomes, and justifications—tied to CAPA where systemic.
• Environmental/process qualifications. Where relevant, references to equipment calibration and cleaning validation state, sterilization cycle records, or process validation lots.
• Quality release. QA authorization with Part 11 e-signature; release criteria met; holds/waivers documented under Change Control where applicable.

“If a data point affects release, it must be attributable, contemporaneous, and recoverable. Anything less is an opinion, not a record.”

4) Governance: Data Integrity & Record Lifecycle

A credible eDHR program implements ALCOA+ and audit trail principles: entries are attributable to unique users or instruments; legible and contemporaneous; original with protected raw data; accurate, complete, consistent, enduring, and available. Part 11/Annex 11 controls enforce identity and e-signatures; access controls protect role separation; configuration baselines ensure the DHR references the exact DMR/BOM/revision used. Records must be retained and renderable for the predicate retention period and presented in human-readable form on demand. Finally, procedural controls matter as much as technical: training, periodic eDHR review, and CSV evidence for the systems that generate and store records.

5) Interfaces: DHF, DMR, UDI & Postmarket

The DHR sits at the end of the design→manufacturing chain. The DHF justifies the design; the DMR defines “how to build and inspect”; the DHR proves execution. UDI/traceability identifiers from Part 830 are applied and captured in the DHR to support distribution controls and, where applicable, implant tracking. Postmarket processes (complaints, vigilance/803; corrections/806) rely on DHR retrieval to identify affected lots/units and to determine whether a field action is necessary. Robust Data Retention & Archival ensures DHRs remain intact over time and technology changes.

6) Common Failure Modes & How to Avoid Them

• Paper–electronic mismatch. Building on paper and transcribing to systems invites transcription errors and late entries. Fix: execute natively in eDHR; where paper is necessary, apply audit-trail scans and metadata-rich capture.
• Version drift. DHR shows steps executed to an obsolete DMR revision. Fix: MES enforces effective-date control and locks work orders to specific configuration baselines.
• Label governance gaps. Labels printed from outdated artwork or wrong language. Fix: bind printing to approved masters via Approval Workflow; interlock printing with barcode checks and second-person verification.
• Uncontrolled rework. Rework instructions not controlled; retest not linked. Fix: NCR→QMS linkage with controlled rework plans and full re-inspection captured in the DHR.
• Audit trail disabled or unreadable. System cannot show who changed a value and why. Fix: Part 11/Annex 11 compliant audit trails with human-readable reports and review-by-exception.
• Fragmented genealogy. Component lots not captured at point of use. Fix: enforce scan-to-use and Directed Picking from controlled WMS bins.

7) Metrics That Matter

• Right-first-time eDHR completion. % records with zero data defects at QA review; trend by line and product.
• DHR retrieval time. Minutes to render a complete, human-readable DHR for any lot/unit—target single-digit minutes.
• Genealogy completeness. % of components with captured lot/serial at point of use; % of scans validated by Barcode Validation.
• Label reconciliation accuracy. Difference between labels issued/used/voided; near-miss interlock “blocks” as a leading indicator.
• Postmarket linkage speed. Time from complaint signal to affected lot identification via DHR.

8) How It Relates to V5

V5 by SG Systems Global provides an integrated MES + WMS + QMS architecture to execute and store eDHRs with Part 11 and audit-trail controls. In V5 MES, work instructions are step-gated: users scan components from allowed WMS bins (Bin / Location Management); Dual Verification and tolerance interlocks prevent mis-assembly; equipment status and cleaning validation states are enforced before processing. In V5 WMS, Directed Picking and Dynamic Lot Allocation ensure only released and compatible lots are available. In V5 QMS, nonconformances, CAPA, and Change Control link directly to the affected DHR records. Label printing is tied to approved masters through Approval Workflow with Barcode Validation at application; UDI data feed is captured automatically. For audits, V5 renders inspection-ready DHR packets and lineage graphs within minutes—reducing retrieval time and risk.

9) FAQ

Q1. DHR vs DMR vs DHF—what’s the difference?
The DHF documents design control (why the device is suitable). The DMR is the master recipe—how to build and inspect. The DHR shows that a specific lot/unit was built and inspected per the DMR.

Q2. Do all steps need e-signatures?
Not necessarily, but critical steps affecting identity, strength, safety, or labeling should require authenticated users and often a second-person verification. All entries must be attributable and audit-trailed.

Q3. How long must DHRs be retained?
Retention is defined by predicate rules and risk; many device records must be retained for the expected life of the device but not less than two years from release. Ensure archival preserves readability and metadata.

Q4. Can we export DHRs to PDF and discard raw data?
PDFs help readability, but inspectors may request the system of record data, metadata, and audit trails. Keep raw sources accessible and linked.

Q5. How do we handle rework in the DHR?
Through controlled NCRs with approved rework instructions, re-verification/re-validation as required, and clear segregation status—every action captured in the eDHR before release.