The eDHR self-builds as the device is built — not reconstructed at release.
V5 Ultimate is the medical-device eDHR platform that owns the floor. DMR-locked routings. Torque tools and vision systems pushing readings directly. UDI at the workstation. Per-serial Device History Record locked the moment final inspection signs. 21 CFR 820, ISO 13485 and IEC 62304 evidence generated continuously — so your next 510(k), MDR Tech File, or surveillance audit reads the same record the line wrote.
You're shopping for eDHR software because your DHR is rebuilt by QA after the device is gone.
DHR review per unit takes 30–90 minutes — and the backlog grows every shift
Last FDA inspection cited 820.184 — gaps between travelers, label scans and operator logs
UDI submissions to GUDID are a manual quarterly project nobody owns
Calibration lapses get caught at audit, not at the moment the tool was used
Design controls live in one system, manufacturing in another — the RTM is a spreadsheet
Complaint → MIR → CAPA touches four tools and three people before evidence is attached
An eDHR an FDA investigator can read end-to-end without an Excel reconciliation.
Per-serial eDHR that self-builds live
Not assembled after the fact. Every operator action — torque, signature, scan, deviation — writes the DHR for that serial number as the build happens. The record locks the moment final inspection signs.
DMR-locked production routings
Routings reference the locked Device Master Record revision. Operators only see the current effective rev. A document control change cannot bypass the build; the build cannot bypass the DMR.
UDI at the workstation
DI + PI assembled at the point of build, printed to the label printer, verified by camera, and pushed to GUDID / EUDAMED on a schedule — not at month-end reconciliation.
Tool-aware step gating
Calibrated torque drivers, micrometers, leak testers and vision systems push readings directly. Out-of-calibration tool? The station is locked. Operator without the current training rev? The step won't open.
DHF + RTM + risk file, linked
Design inputs/outputs traceability matrix is the same spine that links to your IEC 62304 software requirements and ISO 14971 risk file — so every test on the floor traces back to the URS it satisfies.
Complaint → MIR → CAPA on the same record
A field complaint resolves to the serial, the serial resolves to the eDHR, the eDHR resolves to the supplier lots and the operator. MIR drafts itself; CAPA opens with the evidence already attached.
The wins come from structure, not from killing the clipboard.
- DHR review collapses from days to minutes — the record is correct at sign-off, not after rework
- 510(k) / MDR Tech File evidence is generated continuously, not assembled in a 6-week sprint
- UDI submissions to GUDID and EUDAMED stop being a manual quarterly project
- ISO 13485 + 21 CFR 820 surveillance audits read the same record the floor wrote
- Validation under GAMP 5 Second Edition with CSA-aligned evidence delivered at go-live
Designed against the device-investigator's checklist.
21 CFR 820 (QSR)
820.30 design controls, 820.40 document control, 820.70 production & process, 820.90 nonconforming product, 820.100 CAPA, 820.184 DHR — enforced in step gating, not parked in a binder.
ISO 13485:2016 + ISO 14971
Structural QMS backbone; risk file linked unit-by-unit to the design inputs the build verified. The same RTM proves your URS is tested and your risks are controlled.
EU MDR 2017/745 + IEC 62304
Tech File evidence pack assembled continuously. Software-of-unknown-provenance and SaMD trace into the same RTM. UDI-DI / UDI-PI ready for EUDAMED.
See how V5 stacks up against the device-eQMS incumbents.
Medical-device eDHR software, answered.
What is medical-device eDHR software?
Electronic Device History Record (eDHR) software replaces the paper DHR required under 21 CFR 820.184 with an electronic record that captures every step of building a serialised device — operator e-signature, torque value, label print, in-process inspection, deviation — as it happens. The released DHR is generated automatically with a full audit trail bound to the unit's serial number.
How is this different from an eQMS like Greenlight Guru?
An eQMS owns design controls, CAPA, complaint and audit. It assumes the device is built somewhere else. V5 is the build environment — the routing, the operator kiosk, the torque tool integration, the UDI label print. The eDHR self-builds as the operator works, instead of being assembled from inputs after the fact. V5 also covers the eQMS surface, so most buyers consolidate.
Does V5 cover 21 CFR 820, ISO 13485 and IEC 62304?
Yes — all three are first-class. 21 CFR 820 controls (820.30 design, 820.40 docs, 820.70 production, 820.184 DHR, 820.90 nonconforming, 820.100 CAPA) are enforced in the workflow, not parked in a binder. ISO 13485:2016 is the structural backbone. IEC 62304 software-of-unknown-provenance + software-as-medical-device requirements link to the design-control RTM.
Does V5 generate UDI and submit to GUDID / EUDAMED?
Yes. V5 assembles UDI Device Identifier (DI) + Production Identifier (PI) at the workstation, prints the GS1 / HIBCC label, verifies it by camera, and produces the GUDID / EUDAMED submission file on the schedule you configure. No spreadsheet handoff.
Can V5 run on-premises for implantables or defence-linked devices?
Yes. V5 Ultimate On-Premises is containerised, air-gap capable, with customer-owned keys and customer-owned data. Standard offering for implantable, combination-product and defence-linked manufacturers who cannot send records off-site.
How long does implementation take?
Most device manufacturers run their first signed eDHR within 30–45 days of kickoff. Full multi-line rollout typically 8–16 weeks depending on integrations (ERP, LIMS, calibration system) and product mix.
See V5 build a real eDHR for a real serial number.
Free trial. No "talk to sales" gate. First signed eDHR in 30–45 days.