Measurement & Operations

Which Time and Record Count After an Offline eCOA Gap

How clinical trial teams handle offline eCOA entries: resolving wrong device clocks, duplicate records from replacement devices, and preserving audit trails under FDA, EMA, and ICH rules.

· · 24 min read

Editorial still life with two unbranded study tablets, a disconnected coiled cable, a brass analog clock, and a closed oxblood binder on warm paper

Score the diary window from the clock the protocol named, and keep both device records when a replacement tablet syncs the same day. The later server receipt is transfer metadata, not a new observation time. A stamp left on the time zone the participant left is not, by itself, proof that the entry fell inside the participant's current local window. 21 CFR 11.10(e) forbids a sync rule that obscures the earlier record. The analysis plan may name which record is scored; it does not get to delete the other. The server file is a certified copy only after a validated transfer carries the original acquisition time and the changes. No regulator sets a maximum number of offline hours. Part 11 is the binding U.S. requirement not to obscure prior information. FDA's October 2024 questions and answers, EMA's 2023 computerised-systems guideline, and ICH E6(R3) are current expectations, and adoption of the ICH text is not the same as legal effect in every region.

The offline decision that starts after a trustworthy stamp

Treat the offline data-collection window as an independent record-integrity problem rather than an ordinary network delay. In clinical trial operations, the standard single-device scenario is already methodologically settled: when a participant enters an electronic clinical outcome assessment (eCOA) on a single validated device, the device completion timestamp anchors the clinical observation, the subsequent server sync timestamp serves as transport metadata, and no retrospective editing or transcription into electronic data capture (EDC) is permitted. That fundamental baseline is established in our companion analysis on reconciling eCOA and EDC timestamp conflicts. However, that baseline assumes the clock that stamped the entry was trustworthy and that transmission produces exactly one persistent electronic record.

The decisions addressed here begin precisely where that clean assumption fails. Specifically, trial teams face two high-impact operational hazards during disconnected data collection: first, what happens when the device clock itself was set to the wrong time zone or drifted before recording an offline assessment; and second, what happens when a prolonged offline gap prompts site personnel to issue a replacement device, resulting in two conflicting original records for the identical diary day once connectivity returns. Neither situation can be solved by simple database overwrites, informal data queries, or post-hoc rater coaching.

The applicable sentences come from different instruments. Under the U.S. Food and Drug Administration's October 2024 guidance, Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers, Questions 20 through 23 address digital health technologies. An electronic patient-reported outcome mobile application is the example in Question 20; the guidance has no section titled offline eCOA. Question 23 says the agency does not intend to inspect individual digital health technologies for source-data verification. For inspection purposes, electronic source data are considered to be located in the durable electronic data repository into which the data and metadata are transmitted via a direct, uninterruptable, and secure connection according to the sponsor's pre-specified plan. An offline buffer is outside that sentence. A mobile application or provisioned tablet holding the assessment in local memory is not a direct, uninterruptable connection.

In parallel, EMA's 2023 Guideline on computerised systems and electronic data in clinical trials (EMA/INS/GCP/112288/2023), Annex A5.1.1.2, says data saved on the device are the original record created by the trial participant and are source data. They should be transferred early to a durable server by a validated procedure at pre-defined times. After that transfer, the data on the server are considered certified copies and the original data can be removed from the device. ICH E6(R3) Annex 1, adopted on 16 June 2026, expects validated or otherwise appropriate transfer, exchange, and migration processes, with reconciliation as appropriate, so electronic data and relevant metadata retain their integrity (section 4.2.5). Section 3.16.1(i) says the sponsor should not change data entered by the investigator or trial participants unless the change is justified, agreed upon in advance by the investigator, and documented. It does not bar the investigator from requesting a correction.

When a replacement device collects the same diary day before the original device synchronizes, 21 CFR 11.10(e) requires that record changes not obscure previously recorded information. A last-upload-wins rule that deletes or hides the earlier entry fails that requirement. Both records stay visible. No regulator sets a universal number of offline hours. The protocol and data management plan should name the clock the window uses and the gap the study will accept. The statistical analysis plan should name which duplicate is scored. Those are study choices. They are not a numeric ceiling taken from the EMA guideline.

Which clock is allowed to stamp the entry

Whether an offline diary counts inside its window depends on which clock stamped it. If the diary is due between 18:00 and 23:59, the software should test that window against the clock the protocol named. A handset or tablet clock the participant can change is not that standard unless the protocol says so.

EMA section 5.5 says accurate and unambiguous date and time, given in Coordinated Universal Time or as time plus a time zone set by an external standard, should be captured automatically. Users should not be able to modify the date, time, and time zone on the data-entry device when that information is used as a timestamp. Section 4.5 says the time point of the observation and the time point of storage should be kept as metadata, including the audit trail, and that accurate date and time should be linked and set by an external standard.

For bring-your-own-device collection, the handset clock is not the time source. EMA Annex A5.1.3.1 says the application should use an external source for date and time and should not rely on information from the user's device. Deployment choices for a personal handset versus a provisioned tablet are compared in evaluating BYOD versus provisioned eCOA device architectures. That guide compares device models. It does not decide which clock stamps an offline entry.

FDA Question 14 says controls should keep the electronic system's date and time correct, and people with system-administrator roles should be notified if a discrepancy is detected. The ability to change the date or time should be limited to authorized administrators, and any such change should be documented. The question does not require an automated alert or a separate justification field beyond that documentation. EMA Annex A3.3 treats changing system settings, including system time, as a privileged-administrator capability. Those users should be sufficiently independent of trial conduct and of generating, modifying, or reviewing the data.

When a trial spans time zones, FDA Question 14 says the sponsor should indicate the time zone that corresponds to the date and time stamp, or indicate that times are recorded as Greenwich Mean Time. ICH E6(R3) Annex 1 section 4.2.2(d) expects automatic capture of the date and time of entries or transfers to be unambiguous, for example Coordinated Universal Time. EMA Annex A5.1.1.1 says the timestamp should record the time of data entry and not only the time of submission or transmission. Logical checks should prevent unreasonable changes such as time travel, for example moving months or years backward or forward. Those checks do not make a departed-zone stamp equal to the participant's current local time.

Regulatory instrumentClock controlWhat the stamp meansWhere the original sits during an offline gapWhat sync is not allowed to do
21 CFR 11.10(e), a binding closed-system controlDoes not set a device-clock rule and does not set a maximum number of offline hours.Use a secure, computer-generated, time-stamped audit trail of operator entries and actions that create, modify, or delete electronic records.Does not move source data into a server merely because a file arrived.Record changes shall not obscure previously recorded information. Keep the audit trail at least as long as the records and available for FDA review and copying.
FDA electronic-systems questions and answers, October 2024Question 14: keep the system date and time correct, notify administrators of a discrepancy, limit changes to authorized administrators, and document them. In a multi-zone trial, name the stamp's time zone or record Greenwich Mean Time.Question 12: the audit trail must include the date and time, the person making the change, and the old and new values, and should include the reason when applicable. Question 13: record deliberate actions such as save or submit, not every keystroke.Question 23: for inspection, digital-health-technology source data are in the durable repository only when transfer uses a direct, uninterruptable, and secure connection. An offline buffer is outside that sentence.Question 22: use a validated transfer contemporaneously or as soon as possible, and put the transfer date and time in the audit trail. Question 3: a certified copy includes the copy's creation time plus the original acquisition time and the changes.
EMA/INS/GCP/112288/2023, an inspectorate guidelineSection 5.5: capture UTC, or time plus a zone set by an external standard, automatically. Users should not be able to change the date, time, or zone used as a timestamp. Annex A5.1.3.1: a bring-your-own-device app uses an external time source, not the user's device. Annex A3.3: changing system time should sit with administrators independent of trial conduct and data review.Annex A5.1.1.1: record data-entry time, not only submission or transmission. Logical checks should prevent time travel. Section 6.2.1: keep entry time and save time as separate metadata. Transaction time should be short and traceable. The guideline sets no number of hours.Annex A5.1.1.2: data saved on the device are the original record and the source data until a validated transfer at pre-defined times. After that transfer, the server data are certified copies and the device original may be removed.Annex A5.1.1.6: have a procedure to replace a lost or malfunctioning device and to merge several devices' data for one participant without losing traceability. Time-stamp entries, transfer times, and volume in bytes. The text does not use source system or justified latency threshold.
ICH E6(R3) Annex 1, adopted 16 June 2026Section 4.2.2(d): automatic date and time of entries or transfers should be unambiguous, for example Coordinated Universal Time.Section 4.2.2: document initial entries and later changes, including the reason where appropriate, and do not disable audit trails.The glossary includes participant-entered electronic patient-reported outcome data in source records. Section 3.16.1(i): the sponsor should not change investigator- or participant-entered data unless the change is justified, agreed with the investigator, and documented.Section 4.2.5: use validated or otherwise appropriate transfer so data and relevant metadata retain integrity. Section 2.12.2: changes stay traceable and do not obscure the original entry. Section 4.3.6: have contingency procedures against loss of essential data.

Worked example: a diary stamped in the departed zone

To understand how clock discrepancies distort endpoint evaluation, consider a labeled hypothetical scenario from a multinational oncology trial evaluating daily neuropathic pain via an electronic diary. In this hypothetical protocol, Participant P-108 is provisioned with a dedicated study tablet configured to collect a Numerical Rating Scale (NRS) pain score once daily between 18:00 and 23:59 local time. The statistical analysis plan defines a diary day as valid only if completed within this prespecified six-hour evening window.

Participant P-108, in this labeled hypothetical, departs London (UTC+0) on Day 14 and travels to New York. The example uses eastern standard time (UTC-5), not daylight time, so the offset stays explicit. The provisioned tablet is in airplane mode and stays disconnected. The scenario assumes the tablet is locked so the participant cannot change its clock, which is the control EMA section 5.5 expects, and that nobody updates the zone when the participant travels. The clock therefore remains on London time (UTC+0). On the evening of Day 14, at 21:30 eastern standard time, the participant completes the daily pain assessment. Section 5.5 does not say that a locked departed zone is the participant's current local window.

Because the tablet clock was not updated, the software records the entry timestamp as 02:30 on Day 15 (UTC+0). The participant remains offline through Day 16. On the afternoon of Day 17, at 14:15 eastern standard time (19:15 UTC), the tablet connects to hotel Wi-Fi and transmits the buffered Day 14 record to the central server.

If the clinical data management team has not prespecified the handling of offline travel stamps, the data ingestion pipeline faces two severe analytical failures:

  • Analytical Failure Mode A (Scoring from Server Receipt): If the central database treats the upload timestamp (Day 17 at 19:15 UTC) as the observation time, it marks the record as a late Day 17 entry and marks Day 14 missing. The upload time is not the time the participant completed the diary.

  • Analytical Failure Mode B (Uncritical Acceptance of the Departed-Zone Stamp): If the database blindly evaluates the recorded 02:30 Day 15 (UTC+0) timestamp against the study's 18:00–23:59 evening window rule, the entry is flagged as an out-of-window assessment completed in the middle of the night on Day 15. In reality, the participant completed the diary at 21:30 local time on Day 14—precisely inside the protocol-mandated evening window.

Three limits follow from the sources, and they are not the same rule. First, the 2025 Journal of the Society for Clinical Data Management chapter says participants should be instructed not to change device locations, such as time zones, because that can affect programmed notifications and alerts. That sentence is about alerts. It is not the rule that classifies the clinical window. Second, the protocol has to name the clock before the first offline entry: the site's baseline zone, Coordinated Universal Time, or another named zone. A stamp left on the departed zone does not prove the diary was inside the participant's current local window, and the server receipt time does not repair it. Third, the sponsor should not change the recorded stamp unless the change is justified, agreed upon in advance by the investigator, and documented (ICH E6(R3) Annex 1 section 3.16.1(i)). A correction requested by the investigator or the participant should be justified and supported by source records from around the original entry (sections 3.16.1(j) and 4.2.4). The 2023 data-change recommendations keep that change under site control and preserve the original value in the audit trail. They do not authorize the sponsor to rewrite the stamp from a later itinerary.

When a replacement device creates a second original

A sharper complication is an offline gap that the site reads as a lost device. Continuing the same hypothetical, the tablet stays disconnected after the participant leaves London. By the evening of Day 15 the compliance view shows no new transmission since before travel, and the coordinator treats that silence as a broken or lost tablet.

Assuming Tablet A is broken or lost, the site invokes its emergency provisioning procedure and couriers a secondary replacement tablet (Tablet B) to the participant's New York hotel. Upon receiving Tablet B on the evening of Day 15, the participant completes the Day 15 diary assessment. However, out of concern that earlier data were lost, or prompted by an overzealous site notification, the participant also accesses an open retrospective diary form on Tablet B and re-enters the pain scores for Day 14.

On Day 17, Tablet A finally connects to the hotel network and uploads its buffered local records—including the original Day 14 entry recorded offline at 21:30 local time. Simultaneously, Tablet B syncs its records. The central repository now receives two competing records for the exact same participant, visit day, and endpoint parameter.

How should this dual-record conflict be handled under the electronic-record rule and the current expectations?

  • Prohibition Against Automated Overwriting: Under 21 CFR 11.10(e), electronic systems cannot obscure previously recorded information. An eCOA ingestion pipeline must never be programmed with a 'last upload wins' or 'timestamp precedence overwrite' rule that silently deletes or supersedes the earlier record. Both the Tablet A and Tablet B entries must persist in the central database.

  • Traceable Multi-Device Merging: EMA Annex A5.1.1.6 says that if a device malfunctions or is lost, there should be a procedure to replace it and to merge data from several devices for one participant without losing traceability. Annex A5.1.1.5 says the accountability log of devices handed out should include the device identification number so it can be reconciled to the participant. Traceability means both records remain attributable to a device. It does not mean the later sync overwrites the earlier one.

  • Sponsor Modification Restrictions: Under ICH E6(R3) Annex 1 section 3.16.1(i), the sponsor should not change data entered by the investigator or trial participants unless the change is justified, agreed upon in advance by the investigator, and documented. Section 3.16.1(j) says corrections requested by investigators or participants should be justified and supported by source records around the time of the original entry. Choosing one pain score and deleting the other obscures the first record. 21 CFR 11.10(e) does not allow that.

  • Site Control and Sensitivity Analysis: The 2023 consensus recommendations describe a workflow in which the site keeps control of source data and the service provider makes an approved change on the site's behalf. The audit trail preserves the original and corrected values. The abstract says discordant data should be reviewed and reconciled, including by sensitivity analysis, and not by arbitrarily overruling the investigator. The analysis plan may pre-specify that one record is scored and the other is retained for that analysis. Neither the paper nor the regulations name Tablet A, or any other record, as the required winner.

flowchart TD
  subgraph Offline_Capture["Offline capture in the hypothetical"]
    T1["Tablet A, still on the departed zone<br/>Day 14 completed at 21:30 eastern standard time<br/>Stamp reads 02:30 on Day 15, UTC+0<br/>Held in local memory"]
    T2["Tablet B, the replacement<br/>Day 15 diary completed<br/>Day 14 entered again on Tablet B<br/>Held in local memory"]
  end
  subgraph Transmission_Gap["Reconnect on Day 17"]
    Sync1["Tablet A transmits the buffered Day 14 entry<br/>Upload at 19:15 UTC"]
    Sync2["Tablet B transmits its Day 14 and Day 15 entries"]
  end
  subgraph Central_Repository["Durable repository"]
    Conflict["Two originals for participant P-108, diary day 14"]
    PersistA["Record A retained<br/>Device stamp and upload time both kept"]
    PersistB["Record B retained<br/>Not dropped because it arrived later"]
    AuditLog["Audit trail<br/>21 CFR 11.10(e) does not obscure the earlier record<br/>EMA Annex A5.1.1.6 merges without losing traceability"]
    SAP["The analysis plan names which record is scored<br/>The other record stays available<br/>No regulator names the winner"]
  end
  T1 --> Sync1
  T2 --> Sync2
  Sync1 --> Conflict
  Sync2 --> Conflict
  Conflict --> PersistA
  Conflict --> PersistB
  PersistA --> AuditLog
  PersistB --> AuditLog
  AuditLog --> SAP
Hypothetical sync of two device originals for one diary day. Both records stay visible. The analysis plan names which one is scored.

What the audit trail still has to show after sync

The audit trail is what lets a reviewer tell a certified copy from a new observation dated on arrival. FDA Question 3 says that if a copy is kept in place of an original, it should include the date and time the copy was created and the metadata of the original, including the acquisition time stamp and the changes made to the data. The receipt time does not replace the acquisition time.

No single sentence lists one mandatory offline package. The fields below are the ones these sources actually name. 21 CFR 11.10(e) is a requirement for covered electronic records. The FDA questions and answers and EMA section 6.2 are expectations, and they do not use identical wording.

  1. Initial Observation Acquisition Timestamp: The time of data entry on the device, not only the later submission or transmission time (EMA Annex A5.1.1.1). The stamp should be unambiguous: Coordinated Universal Time, or local time plus a zone set by an external standard (EMA section 5.5). A multi-zone trial should name that zone or record Greenwich Mean Time (FDA Question 14). ICH E6(R3) section 4.2.2(d) gives Coordinated Universal Time as the example.

  2. Local Storage Timestamp: The timestamp of saving to storage, kept separate from the entry timestamp. EMA section 6.2.1 says both should be metadata and gives saving to a hard drive as the example. For electronic patient-reported outcomes, data may sit temporarily in local memory and should not be edited before saving without the originator's knowledge.

  3. Data Originator Identity: Who entered the data. FDA Question 20 says that when a participant manually enters an electronic patient-reported outcome app, the participant is the data originator, and the recorded date and time are metadata. If someone else enters on the participant's behalf, that person is the originator and the reason should be documented. ICH E6(R3) section 2.12.10(d) is a different duty: when the investigator provides the device, traceability should be maintained and the participant should be trained.

  4. In-App Edit-Check and Prompt History: FDA Question 13 says an audit trail need not record every keystroke. It should record deliberate actions that create, modify, or delete records, such as save or submit. If an edit check prompts a correction, the audit trail should include the original response, the fact that the edit check prompted a correction, and any change made in response.

  5. Central Transmission Timestamp: The date and time of transfer from the device to the durable repository, included in the audit trail (FDA Question 22). Transmission should use a validated process, contemporaneously or as soon as possible after the data are recorded, according to the sponsor's pre-specified plan. Question 22 is in the digital-health-technology section. Question 20's participant-entered outcome app is the bridge to this use, not a section titled offline eCOA.

  6. Transaction Duration and Payload Integrity: The duration from local capture to central upload, which EMA section 6.2.1 calls transaction time and says should be short and traceable. The guideline sets no number of hours. Annex A5.1.1.2 says important actions should be time-stamped unambiguously, including data entries, transfer times, and volume in bytes. That sentence does not require a cryptographic checksum.

  7. Post-Transmission Modification History: If a later change is made, FDA Question 12 says the audit trail must include the date and time, the individual making the change, and the old and new values, and should include the reason when applicable. EMA section 6.2.1 says the audit trail should show the initial entry and the changes, including the previous and current value, what changed, who changed it, when, and where applicable why. 21 CFR 11.10(e) still forbids obscuring the earlier information. ICH E6(R3) section 2.12.2 says changes to source records should be traceable, should not obscure the original entry, and should be explained if necessary.

Lifecycle stageWhere the record sitsFields the sources nameCitationWhat that field does not prove
Entry on the deviceLocal capture, with or without a networkData-entry time, not only later submission. An unambiguous stamp: Coordinated Universal Time, or local time plus a zone from an external standard. On a personal device, time comes from an external source rather than the handset.EMA section 5.5, Annex A5.1.1.1, and Annex A5.1.3.1; FDA Question 14; ICH E6(R3) section 4.2.2(d)A departed-zone stamp is not proof the diary was inside the participant's current local window. The server receipt is not this field.
Save before uploadTemporary local memoryEntry time and save-to-storage time as separate metadata. An edit before saving should be acknowledged by the originator and recorded in the audit trail.EMA section 4.5 and section 6.2.1A local save does not make the server file the original. The guideline's storage example is a hard drive, not a named flash-memory control.
Validated transferDurable repository after a pre-defined transferTransfer date and time, volume in bytes, and a transaction time that is short and traceable. If the server copy replaces the device original, include the copy's creation time plus the original acquisition time and the changes.FDA Questions 22 and 3; EMA Annex A5.1.1.2 and section 6.2.1Arrival time does not replace acquisition time. Question 23's inspection location applies only to a direct, uninterruptable, and secure connection.
Later change or second deviceBoth device records retained, plus any site-controlled changePrevious and current value, who, when, and why where applicable. A device identification number so the merge stays traceable. The sponsor does not pick a winner by editing participant-entered data unless the change is justified, agreed with the investigator, and documented.21 CFR 11.10(e); FDA Question 12; EMA section 6.2.1 and Annex A5.1.1.5 and A5.1.1.6; ICH E6(R3) sections 3.16.1(i), 3.16.1(j), and 2.12.2A pre-specified rule may score one record and keep the other. It may not obscure the first. No source names which record must win.

What the protocol has to name before the first offline entry

The protocol, the eCOA specification, and the data management plan should name these rules before the first participant is randomized. Deciding the clock, the acceptable gap, or the duplicate after entries already exist leaves the team without a pre-specified rule for the stamp and the second original.

Before the first participant is randomized, the protocol, the eCOA specification, and the data management plan should settle these boundaries. Leaving them until after offline entries exist is how a wrong stamp and a second original become unresolvable.

  • Reference Clock and Travel Protocols: The protocol should say which clock the diary window uses: Coordinated Universal Time, the site's baseline zone, or another named zone. For participants who travel, that sentence has to exist before the first offline entry. A lock that stops the participant from editing the device clock, which EMA section 5.5 expects, will also leave a departed zone in place unless the specification says how the named zone is updated.

  • Empirical Latency Expectations vs Vendor Claims: Commercial briefs sometimes say EMA 2023 makes an offline device a source system that needs a justified latency threshold before recruitment, and they attach vendor-synthesized compliance figures to that claim. Those figures are not reused here. The phrases source system and justified latency threshold do not appear in EMA/INS/GCP/112288/2023. Section 6.2.1 says the interval from local capture to central upload should be short and traceable. Annex A5.1.1.2 says transfer should follow a pre-defined procedure at pre-defined times. The guideline sets no number of hours. The protocol and data management plan name the gap this study will accept.

  • Duplicate Record Hierarchy in the SAP: The statistical analysis plan should say, before the first offline entry, which duplicate is scored and that the other record is retained. Scoring the first contemporaneous entry and keeping the replacement entry for a sensitivity analysis is one permissible pre-specified rule. Scoring the replacement entry and retaining the first is another. Neither choice is the regulatory winner. The 2023 recommendations point to sensitivity analysis so discordant data are not resolved by overruling the investigator.

  • Risk-Based Audit-Trail Review Cadence: EMA section 6.2.2 says procedures for risk-based, trial-specific audit-trail review should be in place, and that review can identify data entered at unexpected or inconsistent hours and dates and can detect device malfunction. FDA Question 12 says periodic review of the audit trail may be helpful, and that the decision to review should be based on a risk assessment. Upload-pattern review, including a long gap that surfaces only on the visit day, belongs in turning protocol endpoint risks into monitoring signals. That guide owns the review design. The offline signals to send it are unexpected hours, a long gap before upload, and two device identifiers for one diary day.

  • Close-Out Procedures for Returned Devices: The 2025 chapter's close-out checklist includes confirming that collected eCOA data have synced and been uploaded before database lock, and that provisioned devices are returned. The same chapter asks the vendor what happens when data cannot be sent, including whether they stay on the device until transmission. The return step should look for that unsent entry. Vendor confirmation belongs in the checklist only where the data management plan requires it. The chapter is good-practice guidance, not a regulation.

  • Contingency and Alternate Data-Entry Pathways: FDA Question 5 says that when records exist only in electronic form, sufficient backup and recovery procedures should be in place, and backup and recovery logs should be maintained so the scope of any data loss can be assessed. Question 8 says the sponsor should document the electronic systems used, including electronic clinical outcome assessment, with a diagram of data flow from creation to final storage, and should consider backup, recovery, contingency plans, and alternative data-entry methods when the system is unavailable. Question 9 includes, among investigator inspection topics, documentation that any backup, recovery, or contingency plan for source records has been used. ICH E6(R3) section 4.3.6 says contingency procedures should be in place to prevent loss of, or loss of access to, data essential to participant safety, trial decisions, or trial outcomes.

Name the clock, the gap the study will accept, and the duplicate-scoring rule before the first offline entry. Keep both records visible, and let the audit trail show the entry time, the save time, the transfer time, and any later change. That is what makes a late server file a copy of the original rather than a new observation dated on arrival.