Schedule of Assessments & Expectedness

Why this matters

“Expectedness” tells you what should be in the database by when for each participant. Without it:

• You can’t separate not expected (by design) from expected‑but‑missing.
• Currency and timeliness dashboards are guesswork.
• Sites don’t get clear coaching on what’s overdue or out of window.
• Statisticians later discover data are present but not analyzable due to window issues.

This page shows how to turn the Schedule of Assessments (SoA), also called the Schedule of Activities or Schedule of Events (SoE), into a machine‑checkable expectedness matrix that drives dashboards, edit checks, and predictable site guidance.

Core concepts & definitions

Plain‑language glossary for newcomers:

• Schedule of Assessments (SoA) — The study’s calendar of visits/time points and what is planned to be collected at each. Also called the Schedule of Activities or Schedule of Events (SoE).
• Expectedness — For a given participant, visit/time point, and form/measure: Is it due? (Yes/No), based on the SoA, visit windows, and the participant’s path (e.g., on treatment vs off treatment). A matrix rule can be conditional, but evaluated for one participant at one time point the answer is always Yes or No. Not the same as safety expectedness, which asks whether an adverse reaction is consistent with the reference safety information (e.g., the Investigator’s Brochure) and drives SUSAR (suspected unexpected serious adverse reaction) reporting; here, expected means due per the SoA.
• Nominal visit — The planned time point (e.g., Week 4). State the study‑day convention (e.g., Day 1 = randomization, no Day 0; whether Week 4 is Day 28 or Day 29 per protocol).
• Visit window — The allowed date range around the nominal visit (e.g., Week 4 ± 7 days).
• Operational due‑by — The last day you expect the form to be entered (often window end + a small data‑entry grace period).
• Data currency — How up to date the database is: the share of expected, past‑due forms that have been entered (and entered on time).
• Out‑of‑window — Data collected outside the allowed window: before the window start (early) or after the window end (late). The statistical analysis plan (SAP) defines whether it is still analyzable or only for information.
• Unscheduled visit — An event‑driven encounter (e.g., adverse event (AE), dose change) not on the SoA.
• Early Termination (ET) — The status/visit when a participant leaves the study before completion. Expected forms depend on the reason: withdrawal → ET visit forms (if the participant agrees) + disposition form; death → disposition form + death or serious adverse event (SAE) report; lost to follow‑up (LTFU) → disposition form once LTFU is declared after the protocol’s contact attempts.
• Conditional expectedness — Pages that are due only if conditions are true (e.g., “Female of childbearing potential → pregnancy test”).
• Rescreen / Re‑enroll — A new screening cycle (often with a new anchor date). Expectedness resets from the new anchor.

Four status axes to keep distinct

1. Expected? (Yes/No)
2. Present? (Yes/No)
3. Timely? Two separate checks: collected in window? (in window / early / late vs the visit window) and entered on time? (by the operational due‑by)
4. Analyzable? (Yes/No per SAP)

The process, step‑by‑step

Do this once per study, then keep it version‑controlled.

1. Define anchors and windows

   • Choose the timeline anchor(s): Screening date, Randomization date, First dose, and any cycle anchors.
   • For each nominal visit, set window start and window end (e.g., Week 4 ± 7 days).

2. List pages/measures per visit

   • For each CRF page/measure, capture: Form ID, title, who collects, and conditions (e.g., on treatment, sex, age group).

3. Write conditional logic (readable & checkable)

   • Use simple IF/THEN statements, not prose.
   • Example: IF on_treatment=Yes AND visit=Week4 THEN VitalSigns expected=Yes.

4. Record analyzability rules from the SAP

   • For each measure, capture the SAP analysis window for out‑of‑window data (it may differ from the protocol visit window; e.g., “analyzable up to ±14 days; else informational”). Biostatistics owns the rule; the data manager (DM) encodes it.

5. Define unscheduled and ET rules

   • Unscheduled substitution: When can an unscheduled measure stand in for a missed scheduled one? (e.g., “If no Week‑4 vitals, and an unscheduled vitals occur within Week‑4 window, use them.”)
   • ET forms expectedness: Triggered by withdrawal, death, or lost to follow‑up (once declared); list the ET forms expected for each reason and their due‑by rules.

6. Encode missingness

   • Distinguish Not expected (by design) from Expected‑pending (not yet due), Expected‑but‑missing (overdue), and Expected‑not done (explicit site indication, reason recorded).

7. Set operational due‑by and alerts

   • Define when each expected page becomes overdue (e.g., window end + 3 calendar days).
   • Define site alerts: expected‑but‑missing, out‑of‑window, and ET forms not started.

8. Publish the machine‑checkable expectedness matrix

   • Deliver as a table (CSV/JSON) consumed by electronic data capture (EDC) checks and dashboards.
   • Keep a change log (version, date, reason, approver).

What good looks like

A compact, unambiguous Expectedness Matrix (one row per page/visit):

If a clinical research associate (CRA), DM, and statistician can independently read a row and arrive at the same Expected/Overdue/Analyzable conclusion, your matrix is good.

Worked examples

Self‑contained scenarios you can adapt.

Example A — Fixed‑visit study with substitution rule

Study: Randomized trial with Baseline (Day 1), Week 4 (±7d), Week 12 (±14d), Month 12 (±30d). Measure: Vital Signs expected at all visits.

Rules

• Week‑4 Vital Signs are expected for participants on treatment.
• If no scheduled Week‑4 vitals exist, an unscheduled vitals record within 21–35 days substitutes.
• Analyzability: Out‑of‑window vitals up to ±14 days from nominal are analyzable; beyond that, informational only.
• Due‑by: Window end + 3 days.

Case A1 (in window, entered on time)

• Week‑4 visit on Day 30; vitals entered Day 31 → Expected=Yes, Present=Yes, In window, entered on time, Analyzable=Yes.

Case A2 (no scheduled, but unscheduled within window)

• No Week‑4 visit occurred; an unscheduled clinic check with vitals on Day 33.
• Substitution applies → counts as the Week‑4 vitals. Expected=Yes, Present via substitution, Analyzable=Yes.

Case A3 (late visit, late entry, not analyzable)

• Week‑4 visit on Day 50 (outside 21–35; also beyond ±14 from nominal 28), so any entry falls after the Day 38 due‑by.
• Expected=Yes, Present=Yes, Out‑of‑window (late visit), late entry, Analyzable=No. Track as Expected‑present, not analyzable.

Case A4 (early visit)

• Week‑4 visit on Day 18 (before the Day 21 window start; within ±14 from nominal 28); vitals entered Day 19.
• Expected=Yes, Present=Yes, Out‑of‑window (early visit), entered on time, Analyzable=Yes.

Example B — Treatment cycles (oncology)

Study: 28‑day cycles for 6 cycles; labs due Cycle Day 1 each cycle with window Day −2 to +3 relative to Day 1. Anchor: First dose = Cycle 1 Day 1.

Rules

• Labs expected on each Cycle Day 1 while on treatment.
• Conditional expectedness: If treatment held for toxicity, labs remain expected to assess recovery. While dosing is held, windows run from the planned Cycle Day 1; once dosing resumes, the cycle re‑anchors to the actual dose date. State which applies in the matrix.
• Analyzability: Labs beyond +3 days are informational only.
• Due‑by: +3 days from Day 1 (no extra grace).

Case B1 (dose held, labs still expected)

• Cycle 3 Day 1 (C3D1) planned for Day 57; dosing held for toxicity; recovery labs collected on Day 62 (planned C3D1 + 5).
• Expected=Yes, Present=Yes, Out‑of‑window=Yes (vs the planned C3D1 window), Analyzable=No (but still operationally required).

Case B2 (off treatment, still on study)

• Participant permanently stops study drug after Cycle 2; End‑of‑Treatment forms become expected within 7 days.
• Cycle 3+ Day‑1 labs become Not expected; protocol follow‑up visits (e.g., 30‑day safety, survival) stay Expected.

Case B3 (off study)

• Participant withdraws consent after Cycle 2; ET forms (the ET visit only if the participant agrees) become expected within 7 days.
• All later scheduled forms become Not expected.

Example C — Early Termination and SAE timeliness

Triggers

• Withdrawal, death, or lost to follow‑up (once declared) → ET forms expected for that reason.
• SAEs, plus any protocol‑specified adverse events of special interest (AESIs) or pregnancies, are event‑driven: reported within 24 hours of site awareness. Non‑serious AEs follow the study’s standard data‑entry timeline.

Case C1 (withdrawal)

• Participant withdraws on Day 120; ET forms due within 7 days. If absent on Day 128 → Expected‑but‑missing; escalate per the monitoring plan / data management plan.

Case C2 (SAE notification)

• The site becomes aware of an SAE on Monday 10:00; the initial SAE report is due by Tuesday 10:00.
• Report entered Wednesday 09:00 → Late entry (timeliness failure) even if within any visit window.

Pitfalls & misconceptions

• Windows treated as “nice to have.” If windows are optional, currency and analyzability become subjective.
• Merging expectedness with analyzability. Keep “Is it due?” separate from “Can we analyze it?”
• No substitution rules. Without clear unscheduled‑to‑scheduled mapping, teams double‑count or ignore usable data.
• Ignoring conditional pages. Pregnancy tests, device logs, concomitant meds sometimes depend on participant state—encode conditions explicitly.
• Using resolved‑query counts as a cleanliness proxy. Closed queries don’t show the study is current; track expected‑but‑missing, late‑entry and out‑of‑window forms alongside open‑query counts and ageing.
• Ambiguous due‑by logic. Define the grace period; otherwise “overdue” cannot be computed consistently.
• Forgetting rescreens. Expectedness resets from the current screening/randomization cycle.

Practice in the wild (checklist)

• Define anchors (randomization, first dose, cycles) and window start/end for each visit.
• Build a per‑form expectedness matrix with clear IF/THEN conditions.
• Specify unscheduled substitution rules per page (allowed? within what window?).
• Separate Expected? from Analyzable? and document out‑of‑window policy.
• Set due‑by rules and the grace period for data entry.
• Implement ops checks: expected‑but‑missing, out‑of‑window, late SAE reports, ET forms overdue.
• Version and publish the matrix; keep a change log and notify sites of updates.
• Align with Biostats on how substituted/out‑of‑window data are handled in the analysis.

Key points to remember

• Expectedness is binary—it answers “Is this page/measure due for this participant now?” based on the SoA anchors + visit windows + participant path (e.g., on/off treatment). A matrix rule can be conditional, but for one participant at one time point the answer is Yes or No. This is operational expectedness, not safety (SUSAR) expectedness.
• Keep four independent axes and never conflate them: Expected? / Present? / Timely? (collected in window, early or late; entered on time or late entry) / Analyzable? (per SAP).
• Express rules as simple, machine‑checkable IF/THEN conditions (not prose) and publish them in a version‑controlled Expectedness Matrix (one row per page/visit with window start/end, conditions, substitution, analyzability, and due‑by).
• Define an operational due‑by (e.g., window end + a study‑specific grace period) so systems can compute overdue consistently and drive currency dashboards.
• Use a consistent status vocabulary for review and dashboards: Not expected, Expected‑pending (not yet due), Expected‑present with its window and entry flags (e.g., Expected‑present‑timely, Expected‑present‑out‑of‑window (late visit)‑late entry), Expected‑but‑missing (overdue), and Expected‑not done (reason recorded).
• Pre‑specify unscheduled‑to‑scheduled substitution rules (allowed or not, and within which window) to avoid double counting and to credit usable data when a scheduled visit was missed.
• Separate expectedness from analyzability: define exactly when out‑of‑window data are analyzed (e.g., limited extension) vs informational only, and align with Biostats/SAP.
• Encode conditional expectedness explicitly (e.g., on‑treatment, sex/age‑based tests, device use). If treatment is held, state whether assessments remain expected (often yes for safety).
• Treat event‑driven pages distinctly: specify SAE reporting timeliness from site awareness (typically within 24 h, per protocol) independent of visit windows, and monitor late SAE reports separately; non‑serious AEs follow standard entry timelines.
• Define Early Termination (ET) triggers (withdrawal, death, lost to follow‑up once declared), the ET forms expected for each, and their due‑by; once ET is active, later scheduled forms typically become Not expected. Stopping treatment is not leaving the study: follow‑up forms usually stay expected.
• For rescreen/re‑enroll, reset anchors and recompute expectedness from the current cycle to avoid false “missing” flags from prior attempts.
• Judge operational health by expected‑but‑missing, out‑of‑window and late‑entry forms, SAE timeliness, and overdue ET forms—not by counts of resolved queries; open‑query ageing still matters, and open queries must reach zero before lock.
• Version and communicate: maintain a clear change log for the matrix and notify sites; ensure shared understanding across DM, CRAs, and Biostats.