Electronic DHR (eDHR) Implementation: A 90-Day Playbook for Medical-Device Manufacturers

21 CFR 820.184 (and QMSR equivalent effective February 2026) requires the DHR to prove that each device or lot was manufactured in accordance with the DMR. In practice that means the dates of manufacture, the quantity manufactured, the quantity released for distribution, the acceptance records demonstrating the device meets DMR spec, the primary identification label and any labelling used, and any unique device identifier or control number. Two things trip up most first-time eDHR implementations. First, the acceptance records are captured but the DMR revision they were captured against is not, so a design change downstream leaves the DHR ambiguous. Second, the label evidence is a scan of what was printed rather than the structured DI + PI values, so lot recall queries have to be visual. A defensible eDHR captures the DMR revision on every step and stores the DI + PI values as structured fields on the record — the printed label is a rendering, not the source of truth.

The single most valuable design decision in an eDHR implementation is that the routing an operator executes references the released DMR revision by ID, not by lookup. If the routing pulls 'the current DMR', a design change in the middle of a shift silently changes the process on the next serial without a change-control record. If the routing pulls DMR-Rev-C specifically, the effect of a change is a controlled cutover: DMR-Rev-D is released, the routing revision is issued, training on Rev-D is re-signed by affected operators, and the next serial on that workstation starts on Rev-D — while any serial mid-flight completes on Rev-C. This one design decision is what separates an eDHR from a digitised traveller.

Every torque driver, vision camera, scale and dimensional gauge you connect to the eDHR is an in-scope Part 11 record source. That does not mean every tool needs a bespoke validation script — it means the integration pattern needs to be validated once and reused. Pick a small set of protocols (Open Protocol for torque, OPC-UA or MQTT for generic sensors, vendor-specific SDKs only when there is no alternative) and validate the integration layer once. From there, each new tool is a configuration exercise, not a validation exercise. The second essential pattern is calibration gating: the tool's calibration due date is a first-class field, and an expired tool cannot record a signed reading. That single control removes more Form 483 risk than any other integration decision.

UDI (21 CFR 830, EU MDR Article 27) requires each device to carry a Device Identifier and a Production Identifier — typically lot / batch, serial number, expiry date and manufacturing date. Two common implementations both fail: printing the UDI label at the end of the line (mis-labels happen and the audit trail is thin) and treating the printed label as the source of truth (the DHR captures a scan, not the structured values). The right pattern is DI + PI as structured fields on the eDHR at the moment the serial is committed, with the label printed at the workstation from those structured fields. GUDID (US) and EUDAMED (EU) submissions then read from the same structured source without a re-entry step.

Devices with embedded software or firmware need the software version installed on each serial captured in the DHR — this is where IEC 62304 SOUP register, anomalies and verification evidence intersect the eDHR. The pattern that works is: the software version is a structured field on the DHR at the step where firmware is flashed, the version references a released software item in the RTM, and the SOUP register is linked to that software item. A firmware change is then a design change (new software item revision, new RTM row, verification re-run) with an explicit DHR effect (next serial after cutover carries the new version). Half-measures — firmware version captured as a free-text field, SOUP register in a spreadsheet — are what turn a 510(k) letter into a deficiency letter.

Days 1 to 20: pick one line (usually the highest-pain line — that is where the ROI is), inventory current paper traveller steps, map to eDHR steps, freeze DMR revision A as the baseline. Days 21 to 45: install kiosks, integrate the calibrated tools on that line, configure the routing against DMR-Rev-A, run parallel paper + eDHR for the first 20 serials with QA sign-off on both. Days 46 to 60: cut over — paper is retired for that line, first 50 all-electronic serials complete, first Inspection Readiness pack generated for internal review. Days 61 to 75: fold in the first design change (DMR-Rev-B) as a real controlled cutover, verify training re-issue works end-to-end, verify a released DHR on Rev-A cannot be re-written. Days 76 to 90: dry-run an FDA-style inspection with internal QA playing investigator, fix any gap, publish the rollout template and start line #2. The single biggest anti-pattern is big-bang across every line at once — do not do it; the second-line rollout is 2 to 3× faster than the first because the pattern is proven.

Three questions come up in almost every 820.184 inspection. First: show me a DHR for serial X and prove it was built against a released DMR revision. Second: show me an operator who signed step Y and prove they were trained on the DMR revision in force at that time. Third: show me the audit trail for a value that was changed on this DHR and prove the change carried a reason. An eDHR that answers all three in under two minutes at the terminal has effectively closed the 820.184 exposure. An eDHR that requires a QA analyst to pull three reports and reconcile them is worse than paper, because it looks defensible and isn't.