From Protocol Endpoints to Data Requirements

Why this matters

Protocols describe what we want to learn; data managers must define which data make that analysis possible. If you don’t translate endpoints into specific fields and clear derivations:

• Teams over‑collect “just in case” data that never get analyzed.
• Critical items (like event time or units) get missed and can’t be fixed later.
• Derived results (time‑to‑event, change from baseline, responder flags) are inconsistent across teams because no algorithm is named or versioned.
• During lock or inspection, you can’t show how an analysis value came from source data.

This page shows a practical way to turn endpoint text into collections, derivations, and controls that anyone (sites, CRAs, statisticians) can follow.

Core concepts & definitions

Plain‑language glossary for newcomers:

• Endpoint — The outcome the study is trying to measure (e.g., “time to first event,” “change from baseline at Week 24”).

• Estimand — A precise statement of the treatment effect you will estimate, defined by five attributes:

  • Treatment condition (the treatment of interest and its comparator), Population (who), Variable (what), Intercurrent events (what to do if things like rescue meds or death occur), and Population‑level summary (how it’s summarized). Think of it as the rules of the question.

• Source element — A single value captured from the subject or a system (e.g., visit date, systolic blood pressure, death date).

• Analysis variable — The exact variable your statistician analyzes. It might be directly collected (e.g., “SBP at Week 12”) or derived (e.g., “days to first event”).

• Derived variable — A value computed from other fields using a named, versioned algorithm (with inputs, parameters, owner, and where it runs).

• Traceability — The ability to show, for any analysis value, the source records used and the exact algorithm version that produced it.

• CRF (Case Report Form) — Where sites enter study data in the EDC.

• SoA (Schedule of Assessments) — The calendar of visits/assessments. Helpful for when to collect, but not enough to define what to analyze.

• SAP (Statistical Analysis Plan) — The document that details how the endpoints will be analyzed, including derivation, censoring, and intercurrent‑event rules.

• IRT/IWRS (Interactive Response Technology / Interactive Web Response System) — The system that randomizes participants (and often manages drug supply); the source of the randomization date/time.

• Adjudication — Independent committee confirms whether an event meets protocol criteria.

• Censoring — Defining a “stop point” when no qualifying event is observed (e.g., end of follow‑up, withdrawal).

The process, step‑by‑step

Use these steps for each endpoint. Aim for a one‑page result per endpoint.

1. Extract the full endpoint text: Copy the actual endpoint/estimand from the protocol (not only the synopsis). Highlight:

   • Treatment condition, population, analysis variable, intercurrent events, population‑level summary measure/window.
   • Any special definitions (e.g., what counts as a “major event”).

2. List the minimal data needed: Write every source element required to compute or interpret the endpoint:

   • Events: what events qualify, how they are confirmed (e.g., adjudication).
   • Dates/times: randomization, visits, event start/stop, last known alive.
   • Qualifiers: units, method/device, “reason not done,” relationship to treatment.
   • Rules: censoring triggers, handling of rescues, protocol deviations.

3. Define the analysis variable(s): For each analysis variable, note:

   • Grain: per subject, per visit, per event?
   • Type: categorical/continuous/time‑to‑event/binary.
   • Units and scales: mmHg, kg, days, percentage, etc.
   • Derived or collected: if derived, reference the algorithm name + version.

4. Specify derivations (name + version + owner): For each derived variable, capture:

   • Algorithm name and version (e.g., TTE_v1.2 or ChangeFromBaseline_v2.0).
   • Inputs: exact fields, their units, and any conversions.
   • Parameters: visit windows, inclusion/exclusion rules, day‑1 logic.
   • Where it runs: a derived/calculated field in the EDC, an ETL job, or statistical programming.
   • Owner & change control: who approves and who updates when protocol changes.

5. Map to collection moments: For every required element, define:

   • Where collected: CRF page and field IDs; or integrated source (e.g., lab feed).
   • When collected: visit/time point, window, or event‑triggered rule.
   • Unscheduled logic: how sites enter event‑driven assessments.

6. Add quality hooks that protect the endpoint:

   • Ordering checks: ensure event happens after randomization.
   • Gatekeeping: derive time‑to‑event only once adjudication is complete; if a suspected event is not confirmed, the subject still needs a censoring derivation.
   • Completeness: if event is “Yes” but date/time or classification is missing, flag it as incomplete and raise a query.
   • Plausibility: date within visit window; units consistent; time zones handled.

7. Create the Endpoint Map (one‑pager): Lay out protocol text → data elements → CRF/source → derivation (versioned) → analysis variable → quality hooks → owner.

What good looks like

A practical Endpoint Map is short, specific, and versioned. Here’s a simple template you can emulate:

If a CRA, statistician, and data manager can each read it and answer what, where, when, how, and who, it’s “good.”

Worked examples

Self‑contained examples you can adapt.

Example A — Time to first MACE within 12 months (cardiovascular trial)

Plain‑English endpoint: For each participant, measure how long it takes from randomization until the first MACE (Major Adverse Cardiovascular Event, as defined in the protocol), observed within 12 months. If no qualifying event occurs, the participant is censored at last known follow‑up within the 12‑month period.

Analysis variable

• Name: Time‑to‑First‑MACE (days)
• Grain: One value per participant
• Type: Time‑to‑event (continuous, in days)
• Derived using: TTE_FirstEvent_MACE_v1.2 (owner: Biostats; runs in analysis pipeline)

Minimal required data (source elements)

• Randomization date and time (from IWRS/IRT).
• Each suspected cardiovascular event: event date/time, event type, and site narrative.
• Adjudication outcome for each suspected event (True/False and final event type).
• Death date/time and cause (if applicable).
• Last known alive date/time (from follow‑up).
• Study withdrawal/termination date (if applicable).
• End of follow‑up window for the 12‑month period.

Collection plan

• Randomization: captured automatically via IRT integration.
• Events: Unscheduled Event CRF opened when a qualifying event is suspected.
• Adjudication: centralized module; result flows back into EDC.
• Last known alive: required at each scheduled visit; also update at close‑out call.
• Withdrawal/termination: capture date/time and reason on Disposition CRF.

Derivation (described, not as a formula)

• Determine the start point as the randomization date/time.
• Identify the first adjudication‑confirmed MACE within 12 months.
• Compute the number of days from randomization to that first confirmed event, counting the randomization day as Day 1.
• If no confirmed event within 12 months, censor at the earliest of: last known alive date/time, withdrawal date/time, or end of follow‑up for 12 months.
• Store the result with the algorithm name and version in the derivation log.

Quality hooks

• Derive time‑to‑event only once adjudication is complete; a suspected event adjudicated False is not counted, and the censoring rule applies if no confirmed MACE remains.
• Ensure every event date/time is after randomization. The 12‑month window is a derivation rule, not an entry check: later events are valid data that are simply not counted.
• If event = “Yes” but event date/time or event type is missing, flag the CRF as incomplete and raise a query.
• Cross‑check death vs event ordering: if death occurs before any MACE, apply the protocol/SAP rule. A death that is part of the MACE definition (e.g., cardiovascular death) is the event; a non‑cardiovascular death is handled as a competing risk or a censoring event, as the SAP specifies.
• Time zone consistency check for all date/time fields.

Traceability

• Derivation log shows: subject ID, inputs used (with CRF IDs), adjudication record link, algorithm name/version, and timestamp of the run.
• Audit trail retained for IRT randomization timestamp and any updates.

Common edge cases and rules

• Two potential events same day: use the first adjudicated qualifying event timestamp.
• Death same day as MACE: follow the protocol/SAP hierarchy; count death as the event only if it is part of the MACE definition (e.g., cardiovascular death), handle non‑cardiovascular death as the SAP specifies (competing risk or censoring), and document the rule applied.
• Event outside window (e.g., 13 months): not counted; subject censored at the defined end of follow‑up.

Mini Endpoint Map (A)

Example B — Responder at Week 24 (virology study)

Plain‑English endpoint: Classify each participant as a Responder or Non‑Responder at Week 24 based on whether the lab value meets the protocol‑defined threshold at the Week‑24 window.

Analysis variable

• Name: Week‑24 Responder Flag (Yes/No)
• Grain: One value per participant
• Type: Binary (categorical)
• Derived using: ResponderFlag_Wk24_v1.0 (owner: Statistical Programming; runs in the analysis datasets, e.g., ADaM; CDM ensures the source lab data are complete and traceable)

Minimal required data

• Visit date/time for Week‑24 window (per SoA).
• Lab value(s) needed, with units and reference ranges.
• Threshold definition (from protocol).
• Allowed window around Week 24 (e.g., ±7 days).
• Handling rules if multiple eligible labs exist in the window (e.g., use the value closest to nominal day; tie‑breaker = earliest time).

Collection plan

• Labs captured via external feed; units standardized on load.
• Windowing applied in the derivation, using the scheduled visit plan.

Derivation (described)

• Identify all lab results within the Week‑24 window.
• Choose the “in‑window” result according to the selection rule.
• Compare that value to the threshold and set Yes if it meets the protocol‑defined response criterion (e.g., viral load below the protocol limit); otherwise No.
• If no valid lab in window, set to Missing per analysis plan (not imputed).

Quality hooks

• Unit normalization required before comparison.
• If multiple labs in window, log which was selected and why.
• If no lab in window but a visit occurred, trigger a data query.

Traceability

• Store the selected lab’s specimen ID, collection date/time, and the selection rule applied in the derivation log.

Example C — Change from baseline at Week 12 (metabolic study)

Plain‑English endpoint: For each participant, measure how much the Week‑12 value differs from baseline.

Analysis variable

• Name: Change‑from‑Baseline Week‑12
• Grain: One value per participant
• Type: Continuous
• Derived using: ChangeFromBaseline_v2.0 (owner: Biostats; runs in analysis)

Minimal required data

• Baseline definition (e.g., last non‑missing value on or before first dose).
• Week‑12 in‑window value, with unit and collection method.
• If multiple values exist at baseline or Week‑12, selection rule (e.g., closest to nominal day; if tie, earliest time).

Derivation (described)

• Select the baseline value following the baseline rule.
• Select the Week‑12 in‑window value following the selection rule.
• Compute the difference (Week‑12 minus Baseline) and store the result with algorithm version and inputs used.

Quality hooks

• Units must match; apply unit conversions on load.
• If baseline missing, flag for analysis handling per SAP (e.g., exclude from certain summaries).

Pitfalls & misconceptions

• Using the SoA as the analysis spec. The SoA tells you when to collect, not exactly what you need for analysis and derivations.
• Skipping algorithm documentation. Even “common” items (BMI, time‑to‑event, change from baseline) must reference a named, versioned algorithm.
• Forgetting times and time zones. Events without times (or inconsistent time zones) can change ordering logic.
• Ignoring intercurrent events. Rescue meds, treatment switch, or death need predefined handling consistent with the estimand.
• Collecting too much “just in case.” Increases burden and noise; define the minimal set needed to answer the endpoint.
• No adjudication gate. Deriving outcomes before independent confirmation risks rework and errors.
• Unclear window rules. Without clear visit windows and tie‑breakers, different programmers choose different records.
• No owner/change control. If nobody “owns” an algorithm, versions drift and results differ across programs.

Practice in the wild (checklist)

• Copy the exact endpoint/estimand text into your Endpoint Map.
• List every required source element (with CRF IDs or feed names).
• Define each analysis variable: grain, type, units, collected vs derived.
• For each derived value, record Algorithm Name + Version + Owner and where it runs.
• Specify windowing rules and tie‑breakers for multiple values.
• Record censoring and intercurrent event handling aligned with Biostats/SAP.
• Add at least one quality hook per critical element (gate, ordering, plausibility).
• Write the traceability plan (derivation log, lineage tables, audit links).
• Start a change log for the endpoint map (date, reason, approver).
• Review the map with Biostats, Safety/Clinical, and CRAs before go‑live.

Key points to remember

• Start from the endpoint/estimand, not the SoA. Write out all five estimand attributes (Treatment condition, Population, Variable, Intercurrent events, and Population‑level summary) so everyone is solving the same question.
• Define the analyzable variable(s) up front. State grain (per subject/visit/event), type (binary/continuous/TTE), units, and whether each is collected or derived.
• List the minimal source elements. Capture only what’s required (events, dates/times, qualifiers like units/method/device, adjudication flags) and where each will come from (CRF IDs or external feeds).
• Make windowing and selection rules explicit. Specify visit windows, tie‑breakers when multiple records exist, and clear baseline rules (e.g., last non‑missing pre‑dose).
• Specify censoring and intercurrent‑event handling. Align rules for censoring (e.g., last known alive, withdrawal, end of follow‑up) and for rescue meds, treatment switch, or death with the estimand/SAP.
• Version every derivation. Use named, versioned algorithms (with owner, parameters, inputs, and run location), even for “common” items like BMI, change from baseline, or time‑to‑event; manage changes under governance.
• Add protective quality hooks. Include adjudication gates, completeness checks, temporal ordering and plausibility checks, unit normalization, and time‑zone handling before any derivation runs.
• Map collection to moments and places. Specify when and where each element is captured (scheduled vs. event‑driven/unscheduled flows) and how integrated feeds are normalized on load.
• Maintain end‑to‑end traceability. For every analysis value, be able to show the selected source records, the rule that picked them, and the exact algorithm version used (derivation log + lineage/audit links).
• Actively find and close gaps early. In draft SoA/CRFs, look for missing times, units, windows, adjudication indicators, or ownership—then fix before go‑live.
• Keep a concise, version‑controlled Endpoint Map per endpoint. One page that ties protocol text → data elements → collection → derivations → quality hooks → analysis variable → owner, with a simple change log.
• Collect “just enough.” Avoid burden and noise by trimming anything not needed to compute or interpret the endpoint.