This is a ready-to-use validation test script for an ePRO/eCOA system where the participant creates the record, frequently unobserved, on a device. Because there is no site staff watching the entry, attribution, contemporaneity, and prevention of back-dating are the central integrity questions, and the test cases below concentrate there. Replace every <<FILL: ...>> placeholder and scale to your risk assessment. A filled specimen follows. This content is general educational reference, not legal or regulatory advice.
1. Approval and identity
| Field | Entry |
|---|---|
| Protocol number | <<FILL: VAL-ePRO-###>> |
| System / version | <<FILL>> |
| Instrument(s) validated | <<FILL: e.g. daily pain diary, weekly symptom eCOA>> |
| Device model | Provisioned / BYOD (matrix in section 5) |
| Author / QA approver | <<FILL>> |
2. Objective
Provide documented evidence that the ePRO/eCOA system presents the validated instrument faithfully, enforces entry windows and controlled timestamps, attributes each entry to the correct participant and device, maintains a complete audit trail, and transmits data to the trial database completely and reconcilably.
3. Prerequisites
- Approved URS and risk assessment; instrument licensed and its electronic implementation authorized by the instrument owner where required.
- Evidence of measurement equivalence for any paper-to-electronic migration (methodological, not just software).
- Test environment with the study instrument(s) configured; controlled server clock available.
- Defined device matrix (section 5) for BYOD.
4. Core test cases
Record for each: actual result, pass/fail, tester, date, evidence.
| ID | Requirement | Test step | Expected result |
|---|---|---|---|
| TC-01 | Instrument fidelity | Compare the electronic instrument to the validated source (wording, options, recall period, skip logic, scoring) | Exact match; scoring computes correctly |
| TC-02 | In-window entry | Make an entry inside the defined window | Accepted, timestamped, in-window flag true |
| TC-03 | Out-of-window entry | Make an entry outside the window | Accepted but flagged out-of-window, or blocked per design; not back-dated to a prior period |
| TC-04 | Duplicate entry | Attempt a second entry the same period | Blocked or flagged as duplicate per design rule |
| TC-05 | Server-authoritative time | Change the device clock forward, then enter | Server timestamp is authoritative; device-server delta logged |
| TC-06 | Future-dating prevention | Attempt to set a future date | Prevented |
| TC-07 | Offline capture and sync | Enter offline; restore connectivity | Original entry time preserved; sync time recorded separately; no data loss |
| TC-08 | Attribution | Inspect an entry’s binding | Bound to the correct participant and device, including on BYOD |
| TC-09 | Audit trail | Make and correct an entry; export the trail | Change captured with who/what/when/why; independently reviewable |
| TC-10 | Transmission reconciliation | Transmit a known count of entries to the database | Counts in equal counts out; gaps flagged, none silent |
5. Device matrix (BYOD)
Execute the fidelity and rendering checks (TC-01, and item truncation/scaling) on each supported configuration. An untested configuration is not supported.
| Config | OS | OS version | Screen size | Fidelity pass? |
|---|---|---|---|---|
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | |
<<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
Policy for unsupported devices: <<FILL: provision a device>>.
6. Acceptance criteria
- The electronic instrument matches the validated source exactly and scores correctly.
- Entry windows are enforced or flagged; duplicates and future-dating are handled per design.
- The record’s authoritative time comes from a controlled server clock, with any device delta detectable and logged.
- Offline entries preserve original entry time and reconcile on sync with no silent loss.
- Every entry is attributed to the correct participant and device across the supported matrix.
- Transmission to the database reconciles, counts in equal counts out, with gaps flagged.
7. Deviation handling and conclusion
Log deviations with impact and resolution; resolve high-risk failures (timestamp control, attribution, transmission completeness) and re-test before the conclusion. Conclude with a documented release statement signed by Validation and QA.
8. Attachments
- Traceability matrix (URS to test case).
- Executed evidence (screen captures, record and audit-trail exports, reconciliation reports).
- Measurement-equivalence evidence for any migrated instrument.
Filled specimen: TC-05 (server-authoritative time)
The following shows one executed high-risk test case. Details are illustrative.
Instrument: daily pain diary, window 18:00 to 23:59 local, once per day.
| Field | Entry |
|---|---|
| Test case | TC-05, device-clock manipulation |
| Step 1 | Set device clock forward by 3 hours |
| Step 2 | Complete a diary entry at real local time 19:30 |
| Expected | Record time comes from the server (19:30), not the manipulated device; a device-server delta of +3h is logged and detectable |
| Actual | Record stamped 19:30 UTC-derived server time; delta +03:00 logged in the audit trail; entry retained in-window |
| Result | Pass |
| Evidence | Audit-trail export AT-05; record field export |
| Tester / QA | K. Adeyemi / M. Osei, 15 July 2026 |
The two rows inspectors probe hardest are this one and offline sync: does the participant’s device clock determine the record’s time, or does a controlled server clock, and is any drift detectable. Designing for server-authoritative time before first patient avoids a painful retrofit after data is collected.
Common inspection findings this protocol prevents
- Diary timestamps driven by an uncontrolled participant device clock, with no detection of drift or back-dating.
- A validated instrument that renders inconsistently across devices, threatening measurement equivalence.
- Entries with no reliable attribution to participant and device on BYOD.
- Data transmitted between device, platform, and database that was never reconciled, so records drop or duplicate.
- A paper instrument moved to electronic with no measurement-equivalence evidence.
How to adapt this protocol
- Set the entry-window and duplicate rules to your instrument’s design.
- Expand the device matrix to every configuration you intend to support; drop any you will not test.
- Point the transmission test at your real database and reconciliation reports.
- Attach the measurement-equivalence evidence for any migrated instrument; it is a methodological requirement, not just a software one.