eDHR Implementation: From Scope to Controlled Cutover

eDHR Implementation starts with a decision about evidence: what must remain understandable when someone asks how a particular device or batch was manufactured, assessed, and dispositioned? A successful rollout does more than replace paper fields. It establishes which records control each decision, who resolves discrepancies, and what evidence permits the next implementation stage.

Use the DHR definition for terminology and the existing eDHR reference for electronic evidence architecture. This guide concentrates on implementation: establishing a baseline, challenging it with one production packet, and deciding whether to proceed. DHR, DMR, and DHF are used here as familiar historical or operational vocabulary, not current named Part 820 sections.

The US scope is finished devices intended for human use and the operations actually performed. Section 820.1 covers design, manufacture, packaging, labeling, storage, installation, and servicing; manufacturers performing only some covered operations comply with the requirements applicable to those operations. Under 820.10(a), the documented QMS must comply with applicable incorporated ISO 13485 requirements and other applicable Part 820 requirements. Section 820.7 identifies the incorporated ISO 13485:2016 edition.

The FDA QMSR overview identifies 2 February 2026 as the effective date. Former 820.184, viewed as of 1 February 2026, required DHRs for each batch, lot, or unit. That historical provision is not the current implementation specification.

Your first deliverable is a scope statement naming the device family, site, operations, electronic records, external evidence, and excluded functions. Distinguish the device's intended use from the software's intended use. The example covers assembly, mechanical acceptance testing, packaging, labeling, and production-record review—not device design validation or every activity within the manufacturer's QMS.

For this exercise, Maya Chen owns production evidence and implementation execution. Luis Ortega owns quality decisions and performs the subsequent review. These are two accountable owners, not a universal staffing model or a requirement for two signatures. Maya prepares each evidence package; Luis reviews it after preparation. Neither an upload nor a populated status field substitutes for that review.

Before configuring a workflow, build a decision map. Each row should answer who produces the evidence, which record is authoritative, what discrepancy would stop progression, and who decides the next action. Avoid assigning a department without an accountable person.

Make the handoff specific. Maya does not send Luis a message saying the batch is complete; she submits a packet with its revision, quantity reconciliation, unresolved items, and requested decision. Luis records whether he accepts the evidence, returns it for correction, or maintains a hold. An unresolved item retains an owner and a next action even when no completion date can responsibly be promised.

Reader task: select one existing production record and identify a decision that currently depends on an email, an individual's memory, or a changing spreadsheet. Add its authoritative evidence and decision owner to your map. If two sources disagree, document the discrepancy-resolution route before attempting migration.

The fictional device is RT-6, a nonsterile reusable manual tissue retractor. Its stipulated intended use is holding tissue aside during surgery. That description supplies context for the exercise; it is not a clinical instruction or a claim that the illustrative manufacturing controls establish device safety.

The software's proposed intended use is narrower: present the authorized production baseline, associate material and test evidence with the correct batch and position, calculate reconciliation summaries, and present unresolved evidence for an authorized disposition decision. It does not determine the device's clinical suitability.

For this exercise, instruction revisions become effective through a documented transition decision. Do not define current as whichever file was uploaded most recently. Specify how new work starts, how work in progress is assessed, and how an authorized change affects an already-open packet. A new revision does not silently rewrite the historical baseline.

Define authority at field level. The test-source record controls the observed force, units, method revision, and tested identity. The production packet controls its association with the assembly position. The material transaction record controls consumption; a reservation only expresses planned allocation. Luis's disposition record controls release status. A summary calculates from these sources rather than replacing them.

Your migration task is to retrieve the actual revision associated with one old execution. Then introduce a newer revision in an evaluation environment and repeat retrieval. Preserve the old document, its historical association, and any correction history. A link that now opens only the latest instruction fails this practical historical-reconstruction test.

Packet PKT-RT-612 covers order JOB-RT-612 and batch RT-261012. It opens on 12 October 2026. The planned and started quantity is 240 assemblies. Positions P001–P240 identify assemblies within this exercise's trays; they are local tracking keys, not a claim that every device requires individual serialization.

The stipulated mechanical acceptance rule is at least 40 N under TP-RT-08 revision 03. This threshold and the extent of testing are invented for the exercise, not recommended device specifications or default test coverage. One useful history is P232: original result T-RT612-232-A is 33 N; after authorized rework, separate result T-RT612-232-B is 45 N.

At 16:00, Maya submits the packet for discrepancy review, not release. It includes source results, rework execution, scrap disposition SD-081, material transactions, labeling records, and two pending acceptance items. Luis can review portions already complete without declaring the entire batch acceptable.

Before reading the reconciliation below, answer three questions: How many distinct assemblies exist in the accounting? How many have complete mechanical acceptance evidence? How many have been released? Different answers are expected because physical identity, technical evidence, and authorized disposition describe different things.

Start with mutually exclusive current states. The nine reworked assemblies were already included in the 240 started; they are not nine additional devices. Seven subsequently acquired passing acceptance evidence, while two remain unresolved. The 228 first-pass passes plus seven accepted reworks produce 235 mechanically accepted assemblies.

Pin lot PIN-RT-612 initially had 260 pins reserved for the order. Only 255 were issued; the remaining five were never issued. Do not turn the reservation into consumption. Of the issued pins, six were returned unused. Nine replacement pins were fitted during rework, while the nine removed pins were separately scrapped. Counting replacement pins as new finished assemblies would corrupt both output and genealogy.

Reader finding: 249 consumed pins is compatible with 240 started assemblies because replacement work consumed material without creating new units. Conversely, 244 finished devices—235 accepted plus nine reworked—would double-count seven accepted reworks and misrepresent the two pending ones.

Have Maya compare these equations with physical tray locations and transaction identifiers, not just a dashboard total. Luis should ask whether the categories overlap and whether every transition has supporting evidence. A balanced equation can still hide an incorrect status, so reconciliation is necessary for this exercise but not sufficient for release.

Two different problems challenge the packet. At 07:05, before assembly starts, Maya finds WI-RT-17 revision 03 on a local workstation. At 15:10, a transferred result appears to show a passing 46 N for P236, but its source header names batch RT-261009 and TP-RT-08 revision 02. Neither problem should be repaired by silently changing a displayed revision.

The obsolete instruction finding is resolved only because the stipulated exposure check establishes that no assembly work occurred under revision 03. If work had occurred, simply switching the screen would not answer which devices were affected. The next task would be an impact assessment and authorized disposition of that work.

For P236, matching the position and seeing a passing number does not establish identity. Compare batch, position, test execution, method revision, units, and source status. Keep the rejected association and document its correction separately. A replacement transfer is not permission to overwrite the received evidence or fabricate a new test execution.

Reader finding: P236 has an unresolved evidence-association problem; P237 has an unexecuted acceptance activity. Both are pending now, but their next actions differ. Their earlier failures remain historical facts. Luis maintains the batch hold under the exercise's procedure, and Maya owns both follow-ups. Neither item becomes passed merely because its rework task is complete.

Section 820.45 requires documented labeling and packaging procedures addressing integrity, inspection, storage, and operations. It requires examination for accuracy before release or storage where applicable, including the specified identification and instruction information. Labeling release for use must be documented, and mixup-prevention controls include inspection before use and documented inspection results.

Translate those requirements into the operations actually performed. Do not substitute a universal demand for every label specimen, a vision system, or a particular barcode grade. Select and justify the evidence and inspection method appropriate to the applicable process.

In the example, LREL-612 records examination and release for use of LBL-RT-06 revision 02 at 07:35. The examination compares applicable identification, storage, handling, and processing information with the approved baseline. The exercise stipulates no expiration-date field; that is not a conclusion for another device.

Label reconciliation is 250 issued = 235 applied + 2 damaged and destroyed + 13 unused and secured. Two of the 13 unused labels are reserved for P236 and P237; they have not been consumed. PACK-RT-612 records pre-use checks and inspection of the 235 labeled assemblies, while batch closeout remains pending. Release of labeling for use is not release of the devices for distribution.

Section 820.35(c) requires UDI recording for each medical device or batch of medical devices. In an actual implementation, retain the assigned UDI and its association with the relevant device or batch. This training packet uses EVID-UDI-612 with the explicitly nonissuable surrogate TRAINING-RT6-261012; it is not a valid UDI.

Your task is to distinguish three records: approved artwork, labeling examination/release evidence, and what was actually applied. Ask Luis to reconstruct that chain without treating a print-job total as proof of correct application.

Part 11 applicability follows required records and their electronic use, not the application name. Section 11.1(b) covers records in electronic form created, modified, maintained, archived, retrieved, or transmitted under FDA records requirements, and electronic submissions under the specified statutes. It excludes paper records merely transmitted electronically. Make the predicate-record assessment before assigning controls.

Identify the system boundary too. Section 11.3 defines a closed system by access controlled by persons responsible for record content; an open system lacks that condition. Applicable closed-system controls in 11.10 include authorized access, authority checks, accurate and complete copies, retrieval protection, and time-stamped audit trails whose changes do not obscure earlier information. Section 11.30 addresses open systems and additional measures as necessary for authenticity, integrity, and confidentiality.

For applicable signed electronic records, 11.50 requires signer name, signing date/time, and signature meaning, including in human-readable forms. Section 11.70 requires signatures to remain linked to their records against ordinary transfer or copying that would falsify a record. Section 11.100 addresses unique signatures, identity verification, and certification to FDA of their intended legal equivalence.

Under 11.200, nonbiometric electronic signatures employ at least two distinct identification components, with specified signing-session controls. Two components do not mean two people or two approval signatures. Determine review responsibilities from applicable requirements and the controlled process, not that phrase.

For this rollout, Maya prepares an applicability register identifying each required electronic evidence category, its authoritative location, access roles, correction mechanism, export contents, and retention-policy reference. Luis reviews that register before relying on electronic disposition signatures. Challenge whether Maya can enter production observations without also acquiring Luis's disposition authority.

FDA's CSA guidance distinguishes necessary validation evidence maintained electronically from routine logs unnecessary to support a validated state. It also explains that its referenced Part 11 validation enforcement discretion does not extend to production/QMS software validation obligations. Do not interpret enforcement discretion as repeal of validation or permission to discard required evidence.

FDA's final Computer Software Assurance guidance, issued 3 February 2026, supersedes the 24 September 2025 version. Its recommendations are nonbinding. It addresses production and QMS software, not design-and-development verification or validation of device software functions.

The guidance recommends evaluating intended functions and reasonably foreseeable failures. High process risk means a failure may cause a quality problem that foreseeably compromises safety. For high process risk, assurance is commensurate with medical-device risk; for not-high process risk, it is commensurate with process risk. A human control matters only to the extent it can detect or prevent the relevant consequence.

Do not classify the whole application as low risk because a reviewer exists. If Luis sees only the same incorrectly associated result as everyone else, his review does not independently detect the error. Removing his source comparison later changes the control assumptions and requires reassessment.

FDA permits risk-based selection among scripted, unscripted, and combined approaches; the examples are not exclusive mandates for either risk category. Here, repeatable scripted challenges suit exact identity and quantity rules, while exploratory work can examine confusing status displays and navigation. Choose coverage and repetition from the risks and observed evidence, not a fixed number of batches or cycles.

Supplier assessments and relevant supplier evidence can contribute to assurance. Map their scope to your configuration and intended use, then identify remaining work. A vendor document title or certification alone does not demonstrate that this packet's association rule behaves correctly.

The following is a fictional execution record, not actual product qualification. On 13 October 2026, Maya evaluates candidate C0.8 with CFG-RT-04 under AP-RT-09 revision 02, using an isolated copy of PKT-RT-612. The copy preserves the 16:00 production state. Testing cannot alter the authoritative production packet or turn its pending items into released devices.

DEF-27 retains the input, expected rejection, actual association, configuration, performer, date, and affected intended function. A proposed C0.9 correction remains proposed. Maya must demonstrate rejection of wrong identities and acceptance of correctly matched evidence, then assess dependent summaries and disposition behavior. Retain the failed execution alongside later results; do not replace it with a clean rerun.

On 14 October, Luis records the fictional review conclusion: not acceptable for the proposed intended use; no operational pilot or cutover authorization. AT-03 failed and AT-05 remains unexecuted. Passing quantity calculations do not offset a safety-relevant association failure, and pending recovery work cannot be accepted by assumption.

FDA recommends assurance records covering intended use, risk analysis, conducted activities, issues, an acceptability conclusion, performer/date, and established review/approval when appropriate. Table 1 illustrates differing record detail; it is not a universal demand for identical scripts or independent review of every activity. Digital logs and retained results can provide evidence without duplicating everything into screenshots.

Keep evaluation, operational pilot, and cutover distinct. Evaluation challenges candidate behavior without relying on it for production decisions. An operational pilot uses an approved scope and controls. Cutover changes the authoritative operating arrangement. In this case, the failed association test stops progression before the operational pilot.

Define pilot exit by demonstrated coverage: relevant operating roles can perform their tasks; normal and exception paths preserve identity and revisions; reconciliations agree with physical work; evidence can be retrieved; and unresolved items have acceptable dispositions. Select pilot exposure from the intended uses and risks. Do not substitute a customary week count or a default number of successful batches.

If paper and electronic records coexist during the pilot, name the authoritative source for each evidence category in advance. Parallel capture without authority rules creates two competing histories. Maya records differences and their origins; Luis determines whether they affect product disposition, assurance conclusions, or both.

The cutover request should identify the approved configuration, effective boundary, work in progress, open exceptions, trained roles, and recovery arrangement. Stop if instruction revisions cannot be established, associations remain ambiguous, quantities do not reconcile, required evidence is unavailable, or the planned authority controls are unproven. These are proposed project stop rules, not universal regulatory wording.

For recovery, preserve the last trusted packet state and identify work performed afterward. Maya reconciles physical positions, material movements, observations, and decisions against the recovered record. Luis authorizes resumption only after assessing the differences. Restoring software does not undo physical manufacturing, remove a hold, or authorize retrospective approval. Continue only those activities the controlled contingency procedure actually permits.

Before retirement of an old record arrangement, ask Maya to retrieve PKT-RT-612 using only the proposed retained package and authorized access. Luis should reconstruct its 240-unit partition, original instruction baseline, P232 failure/rework/retest history, P236 mismatch, P237 pending activity, and zero-release decision. A polished summary without its supporting evidence does not satisfy this exercise.

Set retention through an applicability assessment and controlled policy, not a universal eDHR duration or an assumption of lifetime retention. For applicable closed-system records, 11.10(c) requires protection enabling accurate and ready retrieval throughout the retention period. Its audit-trail provision requires retention at least as long as the subject records. Include linked evidence, historical revisions, corrections, and decision context in retrieval planning.

A later change may alter the risk assumptions even without changing the device: removing manual source comparison, changing an identifier mapping, revising permissions, replacing archive tools, or modifying status calculations. Maya identifies affected intended behaviors and historical records; Luis reviews the proposed assurance and transition evidence before approving use.

Eight Selected Owner Questions

• Scope—Can Luis identify the approved operations and exclusions in SCP-RT-01, rather than infer them from a software module name?
• Authority—Can Maya identify which source controls each contested value and show the documented resolution of disagreement?
• Revision—Can Maya retrieve WI-RT-17 revision 04 after a newer instruction becomes effective without rewriting this packet?
• Quantity—Can Maya explain 240 assemblies and 249 consumed pins, with rework and reservations handled correctly?
• Exception—Can Luis distinguish P232's resolved acceptance history from P236's pending evidence and P237's unexecuted retest?
• Assurance—Can Luis connect each proposed intended behavior to executed evidence, including DEF-27 and the pending recovery test?
• Cutover—Can Luis identify the decision that permits progression, the stop conditions, and the authority arrangement during a pilot?
• Retrieval—Can Maya retrieve the linked history and corrections after a configuration or archive change, and can Luis interpret its disposition?

These questions cover selected rollout evidence only; they are not an overall medical-device readiness assessment. For buyer evaluation, request demonstrations and retained outputs against these questions, recording what remains unshown. Keep definition work in the DHR reference, architecture questions in the eDHR reference, and this implementation decision tied to the actual evidence.