eDHRElectronic Device History Record

An electronic Device History Record (eDHR) is the per-unit evidence file that proves a specific finished medical device — one serial number, one UDI — was manufactured in accordance with its approved Device Master Record (DMR). The DHR concept is defined in 21 CFR 820.184; ISO 13485:2016 §7.5.1 calls the same artefact a 'record of medical device realization'; the EU Medical Device Regulation 2017/745 (Annex IX) requires equivalent traceability for every device placed on the EU market. 'eDHR' is simply the DHR captured electronically rather than on paper, with the additional controls 21 CFR Part 11 demands of electronic records.

The DHR is unit-level, not batch-level. A pharmaceutical Batch Record covers one lot. A medical-device DHR covers one device — even if that device is part of a build of one thousand identical units, each one carries its own DHR with its own serial, its own inspection results, its own labelling pull, and its own release signature. This is the single biggest structural difference between regulated discrete manufacturing and regulated process manufacturing, and it is why a process-MES bolted onto a device factory almost always fails 820.184.

The clause is short — three paragraphs and seven enumerated items — but every word counts. Paragraph (a) requires that each manufacturer maintain DHRs. Paragraph (b) requires that the DHR for each batch, lot or unit demonstrate the device is manufactured in accordance with the DMR and the requirements of Part 820. Paragraph (c) lists the seven things a DHR must include. Memorise the list — it is the spine of every FDA QSIT inspection of a device manufacturer.

1. Dates of manufacture — the actual start and finish, not the planned dates.
2. Quantity manufactured — total devices built, plus any scrapped or quarantined.
3. Quantity released for distribution — what shipped versus what stayed.
4. Acceptance records demonstrating the device is manufactured in accordance with the DMR — every in-process and final inspection signed by the inspector.
5. Primary identification label and labeling used for each production unit — the exact label content, the print job, and the operator who verified it.
6. Any unique device identifier (UDI) or universal product code (UPC), and any other device identification used.
7. Any device identification(s) and control number(s) used.

The wording matters. 'Demonstrating the device is manufactured in accordance with the DMR' means the DHR is not a free-form diary — it is a structured proof against the controlled spec. If the DMR says torque on Step 4 must be 1.2–1.6 N·m, the DHR must contain the actual torque value and the inspector signature accepting it. A DHR that just says 'Step 4 complete — initialled JS' is not Part 820 compliant, because it does not demonstrate accordance, it merely asserts it.

Newcomers to medical-device manufacturing routinely conflate the three records 21 CFR Part 820 requires. They are different artefacts answering different questions, and an inspector will test that you understand which is which.

The relationship is hierarchical. The DHF justifies the DMR — design inputs, verification protocols, design reviews, traceability matrices. The DMR controls every device of that family — the approved specs, drawings, work instructions, packaging spec, labelling spec, inspection procedures. The DHR is the per-unit evidence that one particular device honoured the DMR on its own day, on its own line, with its own operator and inspector.

An eDHR cannot exist without a controlled eDMR. The exact revision of every spec the operator followed must be the revision the DMR was at on the day the device was built. If the work instruction was at Rev C when the device was made and the eDHR points to Rev D (because the link is live, not snapshotted), the eDHR is misleading. This is why a Part-11-defensible eDHR system snapshots the active DMR onto the device record at the moment the work order is released, just as a Part-11-defensible eBMR snapshots the active MMR.

21 CFR 820 is technology-agnostic. A paper DHR is fully compliant if it satisfies 820.184. Many device companies still run paper traveller sheets, especially in low-volume implantable production. The reason eDHRs are now the dominant model is not regulatory mandate; it is the cost and risk profile of paper.

Where paper DHRs fail

• Transcription errors — operators read an instrument display and write a number, often wrong. Every retyping is a defect opportunity.
• Late entries — paper allows back-filling at end-of-shift, which violates the 'contemporaneous' principle of ALCOA+ and is one of the most common 483 observations.
• Lost evidence — a single missing inspection sheet can hold an entire device in quarantine for weeks while QA reconstructs the trail.
• Retrieval time — 820.180 requires records to be 'readily available' for inspection. A paper DHR pulled from off-site archive is not readily available.
• Illegibility — handwriting that nobody can read is a fundamental ALCOA failure ('Legible').

Where eDHRs win

• Direct instrument capture — torque drivers, calipers, cameras, leak testers feed their reading straight into the record. No transcription.
• Forced contemporaneity — operators cannot back-fill; the system timestamps every action at the moment it happens.
• Hard-gated workflow — operators cannot proceed past an unsigned step, cannot ship a unit with an open nonconformity, cannot release without QA review.
• Instant retrieval — pull any device's complete history by serial number in seconds, in the inspector's seat, on demand.
• Built-in trend analysis — pattern across thousands of DHRs becomes a CAPA signal rather than a forensic exercise.

An eDHR is a compound document. A well-structured one is organised so an inspector can navigate it the way they think about a device — top to bottom, identity → build → inspection → release. The following structure satisfies 820.184(c) and aligns with the way FDA QSIT inspectors actually open the file.

1. Device identity block

Serial number, UDI-DI (Device Identifier) and UDI-PI (Production Identifier) per 21 CFR 830, model number, family, configuration code, the DMR revision the device was built against, the work order it belongs to, the build date range.

2. Material genealogy

Every component consumed, with lot/serial number, the supplier, the receipt date, the CoC/CoA on file, and the bin or kit it was issued from. A single click should let an inspector pivot from any component lot to the list of every other device built from it — recall mathematics depends on this.

3. Process route

Ordered list of routing operations, each one showing: operator, start and finish timestamps, the work centre and equipment serial, the calibration status of that equipment on that day, parameters measured (torque, weld energy, dwell time), parameters acceptance criteria, the in-process inspection signature, and any deviation or rework loop with its linked NCR.

4. Labelling and UDI evidence

Every label printed for the device — type (primary, secondary, sterile pouch), the print job ID, the GS1-128 or Data Matrix payload printed, the operator who verified it, and (best practice) a photograph or scanner-confirmed read of the printed label. 820.184(c)(5) and (6) demand this.

5. Final inspection and acceptance

The final QA inspection record with its sampling plan, the results of every measurement, the cosmetic acceptance, packaging integrity, sterile-barrier integrity (where applicable) and the QA inspector e-signature releasing the device for distribution.

6. Release and shipping

Whether the unit was released for distribution, quarantined, scrapped, or moved to MRB. If released, the shipment, the customer, the date. If quarantined or scrapped, the NCR and disposition signature.

7. Signatures and audit trail

Every e-signature on the device — name, date and time, meaning of signature (per 21 CFR 11.50), and the hash of the record bytes at sign time so the signature cannot be detached. A computer-generated audit trail (per 21 CFR 11.10(e)) showing every create / update on the record.

The Unique Device Identification rule (21 CFR Part 830) requires a UDI on every device label and package. Inside the eDHR, the UDI is the canonical identifier that ties the unit to its labelling. The eDHR must record both halves of the UDI separately: the UDI-DI (Device Identifier — the device-model-level code, often a GS1 GTIN) and the UDI-PI (Production Identifier — the per-unit production data, typically a serial number, lot, expiry, manufacture date, or any combination required by the GMDN risk class).

A defensible eDHR captures three things about UDI: (1) the encoded payload that was actually printed (the AI string, not just the human-readable text), (2) the print job and printer used, and (3) a verification scan or visual operator-confirmation that the printed code is readable. The verification step exists because GS1-128 and Data Matrix barcodes can print but not scan — the human-readable text looks fine, but the underlying encoding is malformed, and the device fails downstream barcode reads in the distribution chain.

EU MDR Article 27 imposes equivalent requirements, with the additional obligation to upload the UDI-DI to EUDAMED. A well-designed eDHR makes the EUDAMED submission an automated downstream consequence of the device release event, not a parallel manual process.

The cleanest device manufacturers all face the same eDHR question: what happens when a unit fails an inspection? The 820.90 nonconformity clause is unambiguous — nonconforming product must be identified, documented, evaluated, segregated, and disposed by signed authority. The eDHR must show the entire round-trip: the failure, the NCR, the disposition (use as is / rework / scrap / return to supplier), the rework instructions (which must themselves be controlled documents), the re-inspection, and the release signature.

The temptation in a paper world is to write 'reworked, OK' and move on. In an eDHR, the system has to gate this. A failed inspection step cannot be re-opened; instead it must trigger a controlled rework loop that creates a new step, links it to the failure, references the rework instruction, captures the re-inspection, and closes the linked NCR. The original failure stays in the record forever — that is the audit-trail rule and the data-integrity rule both at once.

The eDHR application itself is GAMP 5 'Category 4' configured product or 'Category 5' bespoke software depending on how much it has been customised. Either way, the validation evidence pack the regulated organisation must produce includes the same artefacts.

1. User Requirements Specification (URS) — what the organisation requires the eDHR to do, traced to predicate-rule clauses.
2. Functional Specification (FS) and Design Specification (DS) from the supplier, or written in-house for bespoke software.
3. Risk assessment — which functions are critical to product quality, patient safety, or data integrity. eDHR signature capture and audit trail are always 'high'.
4. IQ (Installation Qualification) — the system is installed in the right environment, against the right infrastructure baseline.
5. OQ (Operational Qualification) — every Part-11 control (signature, audit trail, access, sequencing) works against scripted test cases.
6. PQ (Performance Qualification) — the system performs in real production conditions across representative device families.
7. Traceability matrix — every URS line traces to an FS line, a test case, and a passed test result.
8. Periodic review — typically annual, demonstrating the validated state still holds.

Inspectors do not always read the validation pack. They do always read the pack's table of contents, ask for one randomly named test case, and watch the auditee retrieve it. A pack you cannot retrieve is a pack you do not have.

1. Live links to DMR documents. The eDHR cites the DMR revision by reference, not by snapshot, so by the time an inspector opens the record the work instruction has moved to a new revision and the inspector cannot tell what the operator actually saw.
2. Audit trail off or filtered. The system has an audit-trail capability but it is off by default for performance reasons. The first 483 of any audit.
3. Shared logins. Operators use a station login, not their own. Every signature is 'STATION-03'. There is no attribution; 820.70(i) and Part 11.10(d) are both broken.
4. PDF disagrees with database. The eDHR PDF was generated once at release, then someone reopened the record and changed something downstream. The database says X, the PDF says Y. Falsification claim follows.
5. Rework without NCR. As above — a failed step is silently edited.
6. Equipment calibration not bound to step. The eDHR shows the torque value but not which torque driver or its cal-due date. If the driver was out of calibration on that day, every device made with it is suspect, and the eDHR cannot prove they were not.
7. Labelling print job not linked. The label printed is recorded; the printer ID, the print spool ID, and the operator who verified the label are not. 820.184(c)(5) explicitly asks for this.
8. No periodic audit-trail review. The trail captures everything but nobody ever looks at it. EU Annex 11 clause 9 requires regular review and most QMSR-aligned inspectors now also expect it.

Under EU MDR a manufacturer's responsibilities do not end at device release. The post-market surveillance plan (Article 84), the Periodic Safety Update Report (Article 86) and vigilance reporting (Articles 87–92) all depend on being able to slice the device population by characteristic: which serial numbers were built on which line, which lot of which component went into which device, which UDI-PI configuration shipped into which market. The eDHR is the primary source of all of this data.

Designing the eDHR with post-market data flow in mind — structured fields rather than free text, codified components rather than narrative descriptions, controlled vocabularies for failure modes — turns the post-market surveillance system from a forensic exercise into a query. The same logic applies to FDA Medical Device Reporting (MDR — confusingly, the same acronym as Device Master Record) under 21 CFR 803.

V5 Ultimate's discrete-mode workspaces ship with eDHR wired in from day one. When a medical-device tenant is created, the platform automatically configures Part 11 controls, unit-level routings, UDI capture, inspection forms, NCR/CAPA wiring, and the eDHR rendering pipeline. There is no 'turn on eDHR' switch; the workspace is eDHR-shaped from the start.

• On work-order release, V5 snapshots the active DMR onto the work order. The snapshot is immutable; revisions to the DMR after release do not affect the record.
• Each device serial is a first-class row. Routings, inspections, label prints, signatures all bind to that serial, not to the batch.
• Instruments (torque drivers, calipers, leak testers, weld controllers) feed values directly into the inspection step. Operators cannot type the value.
• Equipment calibration state is checked at the moment of use. An out-of-cal instrument cannot post a measurement.
• Operator login is per-person, with re-authentication for every Part 11 signature.
• NCRs are forced — a failed inspection cannot be quietly edited; the system creates an NCR, links it, and routes disposition.
• The eDHR PDF is rendered from the immutable history at the moment of distribution release, with the @react-pdf/renderer pipeline that ships every regulated report.