Android Update, Offline Cache, and the Paper Backfill Request
A multicenter asthma trial uses an ePRO app for a daily morning symptom diary. The app caches entries offline and syncs when connectivity returns. A vendor update for Android 13 introduced a bug: on 12 participants' devices across three sites, the cache was cleared before sync, and four days of entries were lost. The sponsor asks sites to transcribe the participants' paper diaries into the EDC system to 'complete the dataset.' The protocol permits paper backup only when the electronic system is unavailable and requires that paper be used as source and entered with a documented reason. Some participants had taken photographs of their paper diary; others had no paper. The help desk has call logs but no entry content. The primary endpoint is change in symptom score at week 12. The data cutoff is in three weeks.
1. How should the team respond to the request to transcribe paper diaries into EDC?
Read the worked answer
The key distinction is contemporaneous source versus reconstruction. If a participant completed a paper diary at the time because the electronic system was unavailable, and the protocol permits paper backup, that paper can be the source. Transcribing it into EDC with a documented reason, the date, the person entering it, and a link to the paper source is acceptable data management, provided the audit trail preserves the original. But the team must not reconstruct entries from memory, help-desk call logs, or photographs taken later if the photographs are not the contemporaneous source. Photographs may be acceptable only if they clearly capture the original paper entry and the site verifies that the paper was completed at the time; even then, document the verification. Participants with no paper should remain missing. Do not enter values into the ePRO app retrospectively. The protocol's paper-backup condition should be applied consistently, and every transcription should be flagged as paper-sourced, not mixed silently with app data.
2. What root-cause and corrective actions should be required from the vendor and sponsor?
Read the worked answer
The immediate root cause is a regression in the offline cache during an operating-system update. The vendor should provide a written root-cause analysis covering what changed, why testing did not catch cache clearing before sync, which device models and OS versions are affected, and how the fix was validated. Corrective actions should include regression testing of offline-to-online sync, forced-sync and cache-persistence tests, staged rollout with a kill switch, version pinning, and a monitoring alert when a device has unsynced entries beyond a defined interval. The sponsor should assess whether other trials using the same app version are affected and whether any regulatory or IRB reporting is required. Sites need a clear workaround: paper backup only under the protocol condition, with participant instructions and a documented device-unavailability note. The CAPA should also address help-desk escalation, because call logs alone cannot reconstruct content. Finally, the vendor should confirm that the audit trail preserves entry creation and sync times after the fix.
3. What are the implications for the week-12 primary endpoint and the analysis plan?
Read the worked answer
Four lost days per affected participant are unlikely to be missing completely at random if the bug affected participants with poorer connectivity or older devices. The analysis team should quantify how many participants and days are affected, whether the missing days cluster around symptom exacerbations, and whether the paper-sourced values are comparable to app values. The primary analysis should follow the pre-specified handling of missing data; if that was complete-case, a sensitivity analysis using multiple imputation or pattern-mixture assumptions is needed. Paper-sourced entries should be identified with a source flag so the team can test whether including them changes the result. Do not impute the lost days as if they were observed, and do not let the backfill request turn into a fabricated complete dataset. The clinical study report should describe the incident, the affected period, the remediation, and the analysis impact.