- Published
- Updated
A restored interface does not demonstrate that every record created during an outage has arrived. The connection may look healthy while specific hours, questionnaires or participant records remain missing from the receiving system.
Preserve the meaning of data
Track connectivity and data completeness separately in the recovery plan. Establish an explainable relationship between failed requests, queued records, accepted records and processing exceptions. Define how records amended at the source during an outage are handled on replay. The recovery starting point should not depend solely on the last successful connection timestamp.
Worked example
For example, an ePRO interface fails overnight. Its dashboard turns green in the morning, but some completed questionnaires remain trapped in a queue. The team reconciles the source questionnaire list, delivery queue and EDC acceptance log using participant and questionnaire identifiers. Every unresolved difference receives an accountable owner and a documented next action.
Review checks
- Independently establish the source-record population affected by the outage.
- Confirm that replayed deliveries do not create duplicate observations.
- Keep failed recovery records visible in an exception list.
Acceptance and boundaries
Acceptance means every record within the affected population is accepted, excluded with a reason, or identified as an open issue. This example does not require one technical queue architecture for every interface. Select evidence proportionate to the study’s critical data. The study team should assess any impact on clinical timing separately; technical recovery cannot substitute for that judgement.
Frequently asked questions
- Why is a connectivity test insufficient?
- It shows current access, but not historical records that were lost, delayed or left pending.
- What if a missing record arrives later?
- Preserve its original collection time and explain how the delay affects the relevant data review.