Endpoint‑First CRF Design & Schedule of Assessments

Why this matters

Case Report Forms (CRFs) are not just screens to “collect everything.” They are instruments to answer the endpoint questions your protocol asks. When CRFs are designed from endpoints backward:

• Sites know exactly what to capture and when.
• Expected data can be monitored, and missingness becomes visible.
• Statistical analysis is reproducible, because variables and timing align with the endpoint definitions.

Designing from endpoints first prevents two common failures: collecting extra data you never analyze, and discovering too late that you are missing the fields or timing needed to support the primary analysis.

Core concepts & definitions

• Endpoint‑first design Start with the protocol’s primary and secondary endpoints. For each endpoint, list the minimal variables, timing, and measurement conditions required for analysis and adjudication. Only then design CRFs.

• Expectedness A study‑specific set of rules that say which forms and fields should be present for each participant at each visit (or time point). A form is “missing expected” only once it is due (its window has closed), and conditional forms (for example, a pregnancy test) are expected only where they apply. Expectedness powers dashboards that show missing expected data. This is data expectedness, not the safety term (whether an adverse reaction is already listed in the reference safety information).

• Visit window The allowed time range around a target visit date (for example, “Week 4 ± 3 days”). Target dates are counted from a fixed anchor (usually randomization or first dose, Day 1), not from the previous actual visit, so one late visit does not shift the rest. Windows tell you when a measurement is on time for a visit and how to map unscheduled data. Out‑of‑window data are kept and flagged, never discarded; the statistical analysis plan (SAP) decides whether they are analyzed.

• Conditions of measurement Standardization rules for operator/device‑dependent data (for example, posture, rest period, cuff size and device model for blood pressure). Conditions make results comparable across sites.

• Adjudication flag / outcome Indicators and fields that show an event was sent for central review by an independent committee, blinded to treatment, and the committee’s decision, used for endpoint confirmation.

Design process, step‑by‑step

1. Extract endpoints from the protocol For each endpoint, copy the definition verbatim and note: population, components, start/stop rules, analysis method (time‑to‑event, change from baseline, proportion), and required adjudication.

2. Back‑map endpoints to data For each endpoint, list the minimal variables you must capture: dates/times, components, severity/grade, censoring or last‑contact date (if needed), any adjudication fields, and the dated events that change how the endpoint is read (for example, stopping study treatment or starting rescue medication). Avoid “nice to have” fields unless they support analysis or quality.

3. Translate the Schedule of Assessments (SoA; also called the Schedule of Activities or Schedule of Events) into expectedness Convert the SoA into an expectedness matrix: per visit/time point → required forms/fields → visit windows → allowability of repeats/unscheduled captures. This drives “missing expected” alerts.

4. Specify measurement conditions Write clear, testable rules for operator/device‑dependent data (for example, blood pressure posture, rest time, repeats, device model and calibration date). Put the rules in the CRF labels and in the CRF Completion Guidelines (CCGs).

5. Draft the CRFs Group fields by endpoint. Use simple, unambiguous labels, controlled codelists (standard CDISC CDASH fields and terminology where they exist), and built‑in hints. Include adjudication flags where relevant.

6. Pre‑build edit checks

   • Real‑time checks: local requiredness, allowable ranges, and conditional requiredness (for example, “If Event = Stroke, then Stroke Type is required”).
   • Batch checks: cross‑visit logic, timing windows, first‑event listings for time‑to‑event, baseline versus follow‑up comparisons.

7. Operationalize and maintain Publish CCGs with examples, train sites, and wire the expectedness matrix to your dashboards. On amendments, update the CRF, CCG, edit checks, and expectedness in lockstep, under change control and re‑tested before release.

What good looks like

• Endpoint‑specific CRF sections Each endpoint has its own concise module. Example: “Major Adverse Cardiovascular Event (MACE)” with component selection, event date/time, hospitalization, source document type, and adjudication fields.

• Visible expectedness A live expectedness matrix that powers study dashboards: “Week 12 Labs: expected, missing,” “Blood pressure (BP) at Week 12: collected outside window,” etc.

• Standardized measurement panels For operator/device‑dependent data (blood pressure, spirometry, electrocardiogram (ECG) intervals), the panel collects the conditions and the measurements together and explains the capture recipe in‑line.

• Mapping rules are explicit You can point to a one‑page rule for how unscheduled or out‑of‑window data map to visits (“map to the visit whose window contains the date; otherwise keep it as unscheduled and flag it; the SAP decides its use”).

Worked examples

The examples below are self‑contained illustrations. A real study takes its fields, windows and rules from its own protocol and SAP.

A. Time‑to‑first MACE in a cardiovascular trial

Endpoint definition (simplified): Time from randomization to first confirmed MACE, where MACE is any of: cardiovascular death, myocardial infarction (MI), or stroke.

CRF modules you need

1. Potential Endpoint Event Module (site)

   • Event occurred? Yes/No
   • Event type (component): Cardiovascular death / MI / Stroke / Other (specify)
   • Date and time of onset
   • Date and time of outcome (if resolved or death)
   • Hospitalization? Yes/No; admission and discharge dates
   • Source document type: Discharge summary / Imaging report / Death certificate / Other
   • Sent for adjudication? Yes/No; Adjudication ID (if Yes)

2. Adjudication Outcome Module (central: entered by the committee or loaded from its system, never by the site or data management)

   • Adjudication decision: Confirmed MACE / Not MACE
   • Final component: Cardiovascular (CV) death / MI / Stroke
   • Adjudication decision date
   • Notes (if discordant)

3. Follow‑up Status Module

   • Last known alive or last contact date
   • Vital status at last contact: Alive / Dead (non‑CV / CV)

Expectedness and windows

• Trigger: Any time (unscheduled allowed) from randomization to end of follow‑up.
• Window mapping: If an event occurs, the site records it immediately and, because each MACE component also meets serious adverse event criteria, reports it directly to pharmacovigilance (a protocol may exempt pre‑specified endpoints from immediate reporting; they are still documented and reconciled with pharmacovigilance); mapping to visits is not required for the endpoint, but last‑contact dates should be captured at each scheduled visit.

Edit checks to add

• If Event occurred = Yes, then Event type, onset date and Source document type are required.
• If Adjudication decision = Confirmed MACE, then Final component is required; every decision needs a decision date.
• First event logic (batch listing): identify the earliest Confirmed MACE per participant by event onset date, not decision date; statistics derives the analysis value per the SAP.

Why these fields?

• Time‑to‑event analysis needs a start date (randomization) and an end date (first confirmed event or censoring).
• Censoring requires last known alive/contact date.
• Component and adjudication fields ensure the event meets the endpoint definition, not just a local label.

B. Blood pressure (BP) as an efficacy measure

Goal: Compare change from baseline in sitting systolic and diastolic BP at Week 12.

Capture recipe (conditions of measurement)

• Posture: Seated with back supported; feet flat on the floor.
• Rest: Rest quietly for at least five minutes before first reading.
• Arm and cuff: Same arm each visit; record arm and cuff size.
• Device: Automated, validated device, ideally the same sponsor‑supplied model at every site; record model, serial number, and last calibration date.
• Repeats: Take two readings at least one minute apart; if systolic or diastolic differs by more than 5 mmHg, take a third.
• Result used for analysis: The average of the last two readings, systolic and diastolic separately (the system computes this). Example: 142/88 and 150/90 differ by 8 systolic, so a third is taken, 146/86; the result is 148/88.

CRF panel

• Posture (Seated/Standing/Supine)
• Rest time before reading (minutes)
• Arm used (Left/Right) and Cuff size
• Device model, Serial number, Last calibration date
• Reading 1: Systolic, Diastolic, Time
• Reading 2: Systolic, Diastolic, Time
• Reading 3 (if needed): Systolic, Diastolic, Time
• Calculated result stored: Systolic average, Diastolic average (system‑derived; not editable)

Expectedness and windows

• Baseline BP: expected at Screening and at Day 1 before the first dose; baseline is the last valid reading before the first dose (the protocol/SAP defines it).
• Week 12 BP: expected within the Week 12 visit window (for example, ± 3 days: if the protocol targets Week 12 at Day 85, counting randomization as Day 1, that is Days 82 to 88). If captured outside the window, the site still enters it as it happened; a programmed rule flags it out of window (usually a protocol deviation), and the SAP decides whether it counts for the Week 12 endpoint.

Edit checks

• If Posture ≠ Seated then a Reason is required.
• If Calibration date is older than the study‑allowed interval, raise a query.
• If Readings 1 and 2 differ by more than 5 mmHg (systolic or diastolic) and no third reading entered, raise a soft query (a warning that does not block saving).

C. Screening performance at sites

Purpose: Monitor variability and support corrective actions.

Counts per site and month (taken from participant‑level screening records, not retyped)

• Month and year
• Number screened
• Number enrolled (randomized or assigned)
• Top three screen‑failure reasons (coded list)
• Notes / local actions taken

Analysis

• Conversion rate = enrolled divided by screened for the same period (leave out anyone still in screening), tracked by site and month. Example: 12 enrolled of 30 screened is 40%; the screen‑failure rate is 60%.
• Trend conversion and top failure reasons across sites to guide targeted training or inclusion/exclusion clarifications.

Pitfalls & misconceptions

• Thinking the SoA is enough The Schedule of Assessments says when something is planned, not exactly which variables and conditions make the data usable for the endpoint. Use the endpoint section of the protocol as the source of truth.

• Omitting measurement conditions Without posture, rest time, device model, and calibration, BP data from different sites will not be comparable.

• Unclear rules for windows and mapping If you do not define how to handle out‑of‑window or unscheduled data, analysis teams will improvise later—and disagree.

• Adjudication fields added too late If adjudication IDs and decisions are not in the CRF from the start, you will be forced to reconcile offline trackers at database lock.

• Deferring CCG updates after amendments A protocol change without synchronized CRF and CCG updates breaks expectedness and confuses sites.

Practice in the wild (checklist)

• For each endpoint, list the minimal variables and the conditions of measurement.
• Build an expectedness matrix from the SoA with visit windows and rules for repeats/unscheduleds.
• Add adjudication flags and outcomes where events require central confirmation.
• Implement real‑time checks for requiredness and simple ranges; implement batch checks for windows and cross‑visit logic.
• Put the capture recipe (for example, BP) directly on the CRF and in the CCG.
• Wire the expectedness matrix to dashboards that show missing expected and out‑of‑window items.

Tiny example: Expectedness matrix (excerpt)

Visit	Window	Forms expected	Notes
Screening	Day −14 to Day −1	Eligibility, Medical History, BP Panel	Baseline = last valid BP before first dose
Day 1	Anchor (no window; no Day 0)	Randomization, BP Panel (pre‑dose), Concomitant Meds	Randomization date starts the time‑to‑event clock
Week 12	Day 85 ± 3 d (Days 82–88)	BP Panel, Labs, AE Review, Follow‑up Status	BP flagged if outside window; SAP decides use

Key points to remember

• Design from endpoints → data → CRFs. For each endpoint, capture only the minimal variables needed for analysis: dates/times, components, severity/grade (if relevant), adjudication fields, and—when applicable—last known alive/contact for censoring in time‑to‑event analyses.
• Translate the Schedule of Assessments into expectedness. Build a visit‑level expectedness matrix with visit windows, allowed repeats, and rules for unscheduled data. Make the mapping rules explicit (e.g., if out of window, keep and flag the data; the SAP states whether and how it is used).
• Make expectedness visible. Power dashboards with “missing expected” and out‑of‑window signals so gaps are actionable during conduct, not after.
• Standardize operator/device‑dependent measures. Specify and capture conditions of measurement (e.g., posture, rest time, arm/cuff, device model/serial, last calibration, repeat logic) and define how the analysis value is derived (e.g., average of the last two readings). Put the capture recipe on the CRF and in the CCGs.
• Structure CRFs by endpoint. Use concise modules with unambiguous labels and controlled codelists. Include adjudication flags/IDs/outcomes where needed to avoid offline reconciliation.
• Pre‑build edit checks. Use real‑time checks for requiredness and simple ranges; use batch checks for cross‑visit logic, visit‑window compliance, baseline vs follow‑up comparisons, and first‑event listings for time‑to‑event endpoints.
• Support time‑to‑event analysis. Ensure capture of the first confirmed event and maintain last‑contact at each visit for censoring; align fields with the endpoint’s start/stop rules.
• Monitor screening performance operationally. Track screened vs enrolled to trend conversion (or screen‑failure) rates by site and month, and review top failure reasons to target training or criteria clarifications.
• Maintain design integrity through change. On amendments, update CRFs, CCGs, edit checks, and expectedness in lockstep under change control and retrain sites so collection rules and analysis remain aligned.