An electronic device history record should prove that the physical device was built, inspected, labeled, and released against the approved definition in effect for that unit or lot. It is not a scanned traveler and it is not a folder assembled after production.
Seal turns the approved device master data into guided execution. Components, equipment, operators, process values, inspections, labels, software, sterilization evidence, exceptions, and release decisions accumulate around the actual serial or lot identity while work occurs.
The eDHR is the as-built product record
The approved definition describes what may be built. The eDHR records what was built. That distinction must survive revisions, substitutions, rework, split lots, outsourced operations, and serial-level variation.
For each released population, Seal preserves the effective product and process version, work order, dates, quantities, operators, equipment, component lots or serials, inspections, labels, acceptance evidence, and accountable release. Unit-level products can carry their own genealogy; true batch products can share evidence without copying it into thousands of records.
FDA's Quality Management System Regulation became effective on February 2, 2026 and incorporates ISO 13485:2016 by reference. The regulatory framework changed, but the operational need did not: the manufacturer must retain controlled evidence that production and acceptance followed the applicable specification and quality system.
A complete eDHR answers unit-level questions without reconstruction
For any serial or controlled lot, an authorized reviewer should be able to answer:
- which product, revision, market, and approved route governed the build;
- which component lots and serials were installed, removed, returned, or scrapped;
- which people, equipment, fixtures, programs, and software executed each operation;
- which measured values and source files supported in-process and final acceptance;
- which labels and UDI identities were printed, applied, rejected, or replaced;
- which nonconformances, concessions, rework steps, and re-inspections affected the unit;
- which sterilization or outsourced-process population contained it; and
- who released it, under which evidence state, and where it later shipped.
Those answers must come from connected source records, not a narrative assembled for an inspection. Seal stores shared order-level evidence once and unit-specific evidence at the unit, preserving both performance and exact traceability.
Device master data becomes executable behavior
Drawings and procedures remain controlled source documents, but production needs structured rules. A device configuration resolves the current bill of materials, routing, work instructions, tools, fixtures, equipment classes, software or firmware, inspection plans, sampling, labels, and signatures.
Effectivity can depend on date, site, line, market, model, revision, or serial range. Seal freezes the applicable configuration when execution begins. An engineering change identifies open orders, inventory, training, inspection programs, labels, validation evidence, service stock, and released populations before the new state becomes effective.
Work orders create the physical population
ERP can remain authoritative for demand and the work-order reference. Seal creates or receives the GMP execution identity and the planned product, revision, quantity, site, and due state.
Serialization may occur at order creation, at a controlled production step, or when the physical identifier is applied. The system distinguishes reserved, commissioned, built, accepted, rejected, scrapped, released, and shipped states. Split and merge events preserve which evidence applies to which physical units.
The eDHR therefore answers both directions: given a device, show every input and decision; given a component or process concern, show every affected device.
Components are verified at point of use
Each issue or scan checks part number, approved revision, supplier and internal lot, serial where applicable, status, expiry, quantity, and eligibility for the active device configuration. Alternate parts require an effective approved rule, not a free-text explanation.
Actual consumption remains distinct from planned consumption. Scrap, return, substitution, and partial use reconcile against the work order. A supplier nonconformance can trace forward through subassemblies and finished serials without relying on an exported ERP report.
Assembly records preserve sequence and workmanship
Guided steps expose only the effective instruction and required evidence. Barcode scans, torque values, cure conditions, setup confirmations, photographs, machine results, and witness signatures enter at the operation where they matter.
Dependencies control sequence while approved branches handle legitimate variation. A skipped operation, late entry, failed prerequisite, or out-of-range value remains an exception. The record retains the original value, correction, reason, user, timestamp, and downstream assessment rather than overwriting the build history.
Equipment, tools, and people gate execution
The selected asset must be qualified for the operation and current for calibration, maintenance, setup, and software state. The selected operator must hold the effective training and practical qualification for the task.
Tooling and fixtures can carry their own serial identity, calibration range, usage count, location, and product-contact history. A later calibration failure can identify every unit processed since the last acceptable condition and place that population into assessment.
Inspection belongs to the operation and device
Incoming, in-process, and final inspection records retain characteristic, method, instrument, sample or unit, specification, measured value, result, inspector, and review state. Machine vision or tester output can remain authoritative in its source while Seal receives the contextual result and evidence reference.
Sampling plans resolve from the effective configuration and risk. Failed inspection identifies the exact unit or bounded lot population and triggers the approved nonconformance path. Retest and resample remain separate, justified events.
Labels and UDI are generated from approved state
Label content should come from controlled product, market, manufacturing, expiry, and UDI data. Seal renders the approved template, verifies printer and stock, records the output identity, and confirms application to the correct physical device or packaging level.
Reprints retain reason and relationship to prior output. Commission, aggregation, decommission, scrap, and packaging events reconcile serial identities. A label change identifies affected configurations, inventory, open orders, markets, and validation before release.
Rework creates a controlled branch, not a rewritten history
Nonconformance starts with the affected device, operation, characteristic, component, equipment, and evidence attached. Containment identifies the physical population. Review determines correction, rework, use-as-is where permitted, return, or scrap.
An approved rework instruction creates additional execution while preserving the original failed state. Re-inspection demonstrates the disposition outcome. The completed eDHR shows both the intended route and every authorized departure.
Software and firmware are manufactured configuration
For connected or software-containing devices, the installed software, firmware, configuration, cryptographic identity, installation tool, and verification result belong in the as-built record. A generic note that software was loaded is not sufficient genealogy.
Seal can verify the approved version and capture the device-reported identity. A patch or configuration change can trace from design approval through production effectivity and into the installed base requiring assessment or field action.
Sterilization and outsourced steps keep the device boundary
Sterilization loads, external processing, special processes, and contract operations may occur outside the assembly line. Their evidence must still resolve to the exact device population.
Shipment to the provider, custody, load composition, cycle or process identity, certificates, deviations, receipt, and acceptance attach to the eDHR. Pending external evidence remains pending; a document upload alone does not silently release units.
Release is review of an already complete record
Review by exception highlights missing steps, corrections, overrides, failed checks, open nonconformances, unreconciled materials or labels, overdue equipment, and pending external evidence. Reviewers can inspect the full underlying record.
The disposition records product and revision, device population, evidence state, open conditions, decision, accountable role, and signature meaning. Release changes the controlled state of the physical units; it does not merely complete a PDF.
Complaints and field actions close the genealogy loop
The released serial or lot connects complaints, service, returns, adverse events, corrections, removals, and recalls to the original build evidence. A reported failure can expose configuration, components, suppliers, equipment, inspection history, and similar units.
Conversely, a component, process, or software finding can trace forward to the installed population. Post-market evidence can initiate CAPA or change without modifying the historical eDHR.
System boundaries preserve the authoritative source
PLM may own design structures, drawings, and engineering changes. ERP may own demand and financial inventory. Seal can own the effective manufacturing configuration, controlled execution, actual genealogy, inspections, exceptions, and disposition. Testers and machines can own acquisition; labeling and serialization platforms can own specialist identities and events; service systems can own field work.
Each interface needs more than a field map. It defines object identity, authoritative state, expected chronology, acknowledgement, correction, duplicate handling, outage behavior, reconciliation, and record retention. A firmware value reported by a tester must resolve to the same device and approved software definition used by the route. A component issue in ERP must not release a unit whose Seal genealogy remains incomplete.
This boundary design is part of validation because it determines which system a reviewer trusts when values disagree or messages arrive late.
Prove one serial from component receipt to release
The first implementation should execute one representative device through component receipt, serial assignment, assembly, automated and manual inspection, a failed check, approved rework, UDI labeling, external processing, review, and release.
Then perform a backward trace from the released serial and a forward trace from a component lot. Rehearse an equipment calibration failure, incorrect firmware, label reprint, missing supplier evidence, and field complaint. The system is ready when each scenario identifies the exact population and reconstructs the decision without manual compilation.
