Electronic Device History Record (eDHR) – Digital Proof of Device Manufacture & Traceability

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

Updated November 2025 • 21 CFR 820/QMSR, EU MDR, ISO 13485, UDI, MES, QMS, Data Integrity

An Electronic Device History Record (eDHR) is the digital implementation of the Device History Record required for medical devices and diagnostics. It documents how each device, lot or batch was actually built, tested, labelled and released against the approved design and manufacturing instructions. Where a traditional Device History Record (DHR) is a stack of paper travellers, test sheets and signatures, an eDHR is a structured, Part 11‑aligned collection of electronic records tied to MES, QMS, labelling, UDI and supply‑chain systems. It is the system‑of‑record that lets a manufacturer prove, without rummaging in archives, that a specific device was built as claimed.

“If it isn’t in the DHR, it didn’t happen. If the DHR is not trustworthy, regulators and customers will assume the control never existed.”

1) Where eDHR Sits in the Device Documentation Stack

Device manufacturers live with a trio of core records: the Design History File (DHF), which documents how the device was designed; the Device Master Record (DMR), the controlled set of specifications and instructions describing how to make it; and the DHR, which shows how each unit, lot or batch was actually made and tested. Under 21 CFR 820 (and its successor, the Quality Management System Regulation, QMSR), manufacturers must maintain DHRs that demonstrate conformity to the DMR and quality system procedures. ISO 13485 and EU MDR 2017/745 echo this by requiring production and traceability records as part of the technical documentation.

eDHR sits in that same position; it does not create new obligations so much as provide a modern way to meet them. Instead of treating DHR as a static file compiled at the end of the order, eDHR treats “device history” as a living, digital object constructed from execution data, quality events and identifiers in real time and stored under the same QMS that governs design and risk.

2) From Paper DHRs to Digital Device History

Traditional DHRs were physical: job travellers with tick‑boxes, hand‑written inspection results, printouts from test rigs, and labels stapled to forms. In small‑volume, single‑site operations that approach was tolerable, even if reviews were slow and error‑prone. As manufacturers added sites, outsourced to CMOs, and adopted UDI and global distribution, paper became a bottleneck and a risk. Scanning those packs into a document management system (DMS) improved access but did not change the underlying reality: inspectors still had to read through images page by page, and most of the data was effectively locked away from analysis.

An eDHR rethinks this model. Execution systems and connected equipment capture data as work happens, not at the end of the shift. Checklists become structured forms; torque or leak‑test results stream in from test stands; component and label scans link directly to specific work orders and units. Instead of manually assembling a DHR as a one‑off act, the system is assembling eDHR content continuously. That is what makes instant retrieval and automated release rules realistic, rather than wishful thinking pinned on scanned PDFs and spreadsheets.

3) DMR, DHR, eDHR & eMMR – How the Records Relate

In device, the DMR plays the same role that a master manufacturing record does in pharmaceuticals. It contains approved drawings, BOMs, assembly and test procedures, labelling and packaging specifications, and any special process instructions. In a digital stack, these elements live in PLM, DMS or directly in MES as controlled objects. The DHR (or eDHR) then captures execution against that master: which version of the DMR applied, which components and lots were actually used, which tests were performed and what their outcomes were, who did what, and when.

Many mixed‑portfolio sites also use Master Manufacturing Records (MMR) and eMMR for drug or biologic products. Conceptually, the DMR/eDHR pair and MMR/eBMR pair are parallel: a controlled “how to make it” master and an executed “how we made this instance” record. Architectures that treat all of these simply as specialised views over a common execution data model have an easier time validating and scaling than those that bolt separate point solutions together for device, drug and combination products.

4) What an eDHR Actually Contains

Regulations describe the DHR content at a high level: the dates of manufacture, quantity manufactured, quantity released, acceptance records, primary labelling and unique identification, among other elements. An eDHR translates this into concrete, structured fields that can be searched, filtered and reported. At minimum, it records the product identifier and revision, the work order or job, the lots and serial numbers, the UDI device identifier and production identifiers, and the equipment and lines used. It also records execution data: which steps were done, by which operators, using which calibrated tools and test rigs; what each test result was; whether any limits were approached or exceeded; and whether any rework was performed.

Labelling and packaging details form another critical section. eDHR should show which label version and artwork were applied, how barcodes and 2D symbols were encoded, and whether label verification or vision inspection checks passed. Finally, the record must show the quality decision: the identity of the reviewer, the status (accept/reject), and any justifications or concessions. In an eDHR context, all of these are discrete data points with time stamps, user IDs and audit trails—not just text in a scanned batch pack.

5) eDHR vs eBMR in Mixed Device–Drug Operations

In facilities that manufacture both devices and medicinal products, or combination products such as drug‑device kits, it is common to see both electronic batch records (eBMR) and eDHR. eBMRs are inherently batch‑centric: they focus on raw materials, process parameters and in‑process results for a defined quantity of product. eDHR, by contrast, is inherently unit‑centric: it focuses on assemblies, serialisation, configuration and the unit’s final state as shipped. From a regulator’s perspective, both views matter in combination products: the eBMR for the drug component must show GMP compliance under 21 CFR 210/211, while the eDHR must demonstrate device control and traceability under 820/QMSR and MDR.

Rather than implementing completely separate systems, many organisations choose a single MES platform capable of generating both eBMR and eDHR outputs from the same execution data, with different templates and reports tuned to each regulatory audience. That approach simplifies CSV, because there is one validated core instead of parallel stacks of partially overlapping logic. It also makes future changes—such as adding serialization at unit or case level—easier to apply consistently across everything you make.

6) Data Integrity, Part 11 & Annex 11 Expectations

Once you move DHRs into electronic form, they fall squarely under data‑integrity and electronic records expectations. Regulators expect that eDHR data are attributable, legible, contemporaneous, original and accurate (ALCOA+), and that the systems involved enforce access control, audit trails and electronic signatures where appropriate. In the U.S., 21 CFR Part 11 governs electronic records and signatures used to meet predicate rule requirements, including those in Part 820/QMSR and Part 803/806/821 for post‑market activities. In Europe and other markets, Annex 11 and data‑integrity guidance play a similar role.

Practically, this means eDHR platforms must provide role‑based access control (User Access Management), system‑generated audit trails that cannot be disabled, time‑synchronised clocks, and secure retention and archival aligned with the product’s life and regulatory timelines (Record Retention & Archival). They must also be validated under a risk‑based VMP, with documented requirements, design, testing and change‑control records. “We export data to Excel to check it” is not considered a robust approach if that spreadsheet drives release decisions or investigation outcomes.

7) Integration with MES, QMS, Labelling & Traceability

A credible eDHR is never just one application; it is the sum of how the site’s execution, quality and information systems work together. MES or other execution systems orchestrate routes, work instructions and step‑level data capture. The QMS manages deviations, nonconformances, CAPAs and complaints that must be visible from the DHR. Labelling systems control artwork, claims and languages under labelling control, generate UDI symbols under 21 CFR 830, and provide verification results.

Traceability layers such as end‑to‑end lot genealogy and Global Batch Traceability then tie components, intermediates and finished devices to orders, pallets and customers. The eDHR is effectively a “view” across all of this: the place where, for a given device or lot, a reviewer can see which instructions applied, which components and tools were used, which issues were raised, what labels were applied and to whom the devices were shipped—without logging into five different systems and manually reconciling IDs.

8) Shop‑Floor Execution, Work Instructions & Training Control

From an inspector’s point of view, an impressive eDHR user interface means nothing if the underlying execution was uncontrolled. That is why eDHR and shop‑floor discipline are so tightly linked. Work instructions need to be current, approved and specific to the product, revision and configuration being built; eDHR‑aware MES systems pull those instructions from a controlled source and present them at the point of use. Operators must be trained and qualified to perform the steps they are assigned; that is typically managed through a training matrix and enforced at login so that untrained personnel cannot record critical steps.

Critical checks—such as torque settings, leak tests, firmware loads and visual inspections—are enforced through hard‑gated workflows, often using poka‑yoke concepts and electronic pass/fail controls. Line clearance and setup checks are captured as structured entries, not signatures on a photocopied form. The result is that the eDHR is not simply a record of “what people remembered to write down”; it is the by‑product of an automated workflow that makes it difficult to proceed without doing the right things in the right order with the right tools.

9) Nonconformances, Rework, CAPA & Complaint Linkage

Device regulators look for evidence that issues are captured transparently, investigated appropriately and used to improve the system. eDHR is where they expect to see that feedback loop anchored. When a test fails or an assembly step is not completed as specified, the event should generate a structured nonconformance report (NCR) or NCMR, tied to the specific units or lots involved. If rework is allowed, the approved rework route must be executed under control, with repeat tests or inspections, and the eDHR must clearly show what was done and why (Rework).

Systemic or significant issues should escalate into CAPA, and those CAPAs may in turn drive changes to DMR, inspection plans, supplier controls or training. Complaint investigations—especially those that might lead to MDR reports, EU field safety notices or recalls—need direct access to device‑level histories, not just aggregated statistics. When eDHR and QMS are properly connected, investigators can move from a complaint record to the full history for that device and to other devices with similar patterns in a few clicks, instead of running an ad‑hoc paper chase under time pressure.

10) UDI, Serialization & Downstream Traceability

Modern device regulation leans heavily on unique identification. The U.S. UDI rule in 21 CFR 830, similar schemes under EU MDR and initiatives such as AusUDID (Australia UDI) all expect devices to be uniquely identifiable and for that identity to link back to manufacturing and distribution history. An eDHR implementation that does not make UDI central is therefore missing the point. For each UDI or serial number, it should be possible to recover the entire manufacturing story: which component lots were used, what tests were performed and passed, which labels and IFUs were applied, and which customer or patient ultimately received the device (Traceability).

On the logistics side, SSCC, case and pallet serialisation and shipping documents link eDHRs to distribution legs, returns and repairs (Returns & RMA). When potential problems are discovered, recall‑readiness hinges on the ability to go from a defect pattern or supplier issue to a precise list of affected devices and customers rapidly (Recall Readiness). eDHR is the technical tool that makes that possible without paralysing the business or over‑recalling out of caution.

11) Global Regulatory Context for eDHR‑Style Records

Outside the U.S., the exact term “DHR” may not appear, but the requirement is still there in substance. EU MDR and IVDR require manufacturers to maintain technical documentation that covers production, post‑production and traceability in detail. ISO 13485 clause 7.5 demands records of production, installation and servicing activities. Regulators such as the TGA expect similar documentation. The U.S. QMSR’s alignment with ISO 13485 is explicitly intended to harmonise these expectations.

For global manufacturers, maintaining one way of working for the FDA and another for Europe or Australia is untenable. Instead, most standardise on a single eDHR concept that meets the strictest of these expectations and can be presented in different regulatory wrappers as needed. In other words, “DHR” becomes the internal name for a record that is capable of supporting all major regulators, whether they use that specific term or not. The internal standard is often written into the company’s global QMS so that site‑level procedures cannot quietly drift back to paper workarounds.

12) KPIs & Business Impact of eDHR

Although eDHR is typically justified as a compliance project, the reasons it stays funded are usually operational. One set of metrics concerns release and documentation quality: how long it takes from completion of manufacturing to QA disposition; how frequently records are returned for correction; and how often incomplete or illegible entries show up. Another set concerns responsiveness: how quickly the organisation can retrieve the history of a specific device for a complaint, auditor or notified body; and how quickly it can scope a potential field action.

On the financial side, eDHR can reduce the manual labour of compiling, checking and archiving paper packs; improve on‑time‑in‑full (OTIF) performance by shortening release bottlenecks; and lower the Cost of Poor Quality (COPQ) by making systemic issues visible earlier. Over time, data mined from eDHRs can inform design improvements, supplier changes and maintenance strategies, turning what began as a regulatory artifact into a genuine source of competitive advantage and risk reduction.

13) Implementation Steps in Regulated Environments

Implementing eDHR in a running operation is not a simple software install; it is a staged transformation of processes, systems and behaviours. A typical path starts with a mapping exercise: for one or two representative product families, document exactly what is in the current DHR, where each piece of information lives (paper, spreadsheets, test systems, ERP, MES), and which regulatory clauses it supports. From there, define a harmonised eDHR data model that captures those requirements explicitly, avoiding both gaps and unnecessary duplication. That model then informs MES configuration, integrations to QMS, labelling and PLM, and any electronic forms needed for residual manual data capture.

Under CSV/CSA and the site’s VMP, the eDHR solution is validated, with particular attention to workflows that affect release and traceability. Pilots or parallel runs—where both paper and eDHR are maintained for a period—allow QA and inspectors to build confidence that the digital record is at least as reliable as the old one. Only then is paper formally retired under change control, training rolled out more broadly, and the pattern extended to additional products, lines and sites. Organisations that skip the mapping and piloting steps often discover too late that their eDHR is missing key content or is not trusted by QA, resulting in shadow paper processes and duplicated effort.

14) How eDHR Fits in SG Systems–Style Architectures

In a V5‑style execution architecture, eDHR is not a bolt‑on module; it is the natural output of digital manufacturing. The same platform that manages recipes, routings, work instructions and tolerances on the shop floor also captures operator actions, test results, label verifications and quality events as structured data. Integration with QMS modules ensures that NCRs, CAPAs, change controls and complaints are visible from the device history record. Traceability capabilities such as Global Batch Traceability and end‑to‑end genealogy link devices to component lots, pallets, shipments and returns.

For mixed plants, the same infrastructure can surface both eBMR and eDHR views: the pharma inspector sees a batch‑oriented record tuned to 21 CFR 211 and annexes; the device inspector sees a device‑oriented history tuned to 820/QMSR and MDR; both draw from the same validated source. That convergence is what makes eDHR sustainable: instead of being a bespoke project for each product line, it becomes an inherent property of how the plant runs and how SG‑style platforms capture and protect manufacturing data.

15) FAQ

Q1. Is an electronic DHR (eDHR) explicitly required by regulators?
No. Regulations require a DHR, but generally allow records to be paper or electronic as long as they are complete, legible, retrievable and controlled. In practice, the complexity of UDI, global supply chains and multi‑site operations makes purely paper DHRs difficult to manage and defend. Many regulators now expect scalable, reliable systems, which strongly nudges manufacturers toward eDHR even if it is not named explicitly.

Q2. Does scanning paper DHRs into a DMS count as eDHR?
Scanning into a controlled DMS can improve accessibility and retention, but it does not provide most of the benefits associated with eDHR: real‑time data capture, structured search, instant genealogy and strong integration with MES, QMS and labelling. It is closer to “electronic archiving of paper DHRs” than to a true eDHR, and regulators will still judge your control based on how data are generated and used, not just where the PDFs live.

Q3. How is eDHR different from eBMR in a combination‑product plant?
eBMR focuses on batch‑level manufacturing history for medicinal components, while eDHR focuses on device‑level history, serialisation and configuration. Combination products typically require both perspectives. A common approach is to use one MES core with templates that generate an eBMR for the drug part and an eDHR for the device part, linked via shared identifiers so that the total product history can be reconstructed without maintaining completely separate stacks of systems.

Q4. Who should own eDHR within the organisation?
Ownership is shared. Quality Assurance (QA) typically owns the DHR/eDHR process and acceptance criteria; Manufacturing owns execution and data capture; IT/OT owns the underlying platforms and integrations; and Regulatory Affairs ensures alignment with submissions and global expectations. Clear RACI definitions in SOPs are essential so that validation, change control, template design and access to eDHR data are not left in a grey zone between departments.

Q5. What is a pragmatic first step toward eDHR?
A pragmatic starting point is to choose a single, representative product family and map its current DHR content and data flows in painful detail. Then, design a minimal eDHR template and configure existing MES, QMS and labelling systems to populate it, filling gaps with well‑designed electronic forms where necessary. Run that line in parallel with the old paper process under a defined pilot, validate the digital record under CSV/CSA principles, and only then expand to other products and retire paper via controlled change. Trying to “big‑bang” eDHR across all products and sites without that focused learning step is usually what leads to expensive rework and disappointing adoption.

Related Reading
• Core Device Records: Device History Record (DHR) | Design History File (DHF) | MMR | eBMR
• Regulations & Standards: 21 CFR 820 / QMSR | ISO 13485 | EU MDR | 21 CFR 11
• Systems & Data Integrity: MES | QMS | DMS | Data Integrity | Audit Trail
• Traceability & Field Actions: UDI | Lot Genealogy | Recall Readiness | Deviation / NCR | CAPA