Creating ADTTE: Time-to-Event Analysis Datasets

Introduction

Many important clinical-trial endpoints are not simply measurements collected at a fixed visit. Instead, the endpoint depends on when an event occurs or how long a patient remains event-free.

Examples include:

• Overall survival
• Progression-free survival
• Time to progression
• Duration of response
• Time to treatment failure
• Time to discontinuation
• Time to first subsequent therapy
• Time to deterioration

These endpoints require more than a simple analysis value.

For each patient, the analysis must establish a starting point, identify whether the event occurred, determine the relevant event or censoring date, and calculate the elapsed time.

The resulting analysis structure is commonly represented using an ADTTE dataset.

What Is ADTTE?

ADTTE stands for an ADaM Time-to-Event analysis dataset.

Unlike a typical BDS dataset in which each record might represent a laboratory measurement or efficacy assessment, an ADTTE record generally represents a patient's result for a particular time-to-event parameter.

For example, a patient might have:

The exact variables and parameter definitions depend on the study, but the fundamental structure is similar.

The Fundamental ADTTE Concept

A time-to-event observation can be thought of as:

The elapsed time between these two points becomes the primary analysis value.

The exact day-count convention must be defined by the study's analysis specification.

For many analyses, if the start date is Day 1, the calculation is:

If the start date is represented as Study Day 0, a different convention may be appropriate.

Why Time-to-Event Analysis Is Different

Suppose two patients enter a study on the same date.

Patient A dies after 300 days. Patient B is still alive after 600 days when the study data cutoff is reached.

Their records are fundamentally different:

Patient B has not experienced an observed death at 600 days.

The 600-day observation therefore does not mean:

Instead, it means:

That distinction is one of the most important concepts in time-to-event programming.

Event Versus Censoring

ADTTE commonly distinguishes an observed event from a censored observation through a variable such as CNSR.

A common convention is:

The Basic ADTTE Variables

A typical ADTTE dataset may contain variables from several conceptual groups.

Additional variables may be required to support traceability, stratification, subgroup analysis, treatment periods, censoring categories, or endpoint-specific analysis.

ADTTE Is Usually a Parameterized Dataset

One of the defining features of ADTTE is the use of PARAM and PARAMCD.

Instead of creating a completely separate dataset for overall survival, progression-free survival, duration of response and other endpoints, multiple time-to-event parameters can often be represented in a common structure.

For example:

The exact codes should be defined consistently within the study and should follow the study's ADaM implementation conventions.

One Patient Can Have Multiple ADTTE Records

Suppose patient 001 contributes three time-to-event endpoints.

This does not represent three repeated measurements of the same endpoint.

It represents three different time-to-event parameters.

The Start Date Is Endpoint-Specific

The start date is one of the most important ADTTE derivations.

Different endpoints can have different time origins.

These are examples rather than universal definitions.

The protocol, statistical analysis plan and endpoint-specific analysis specification determine the actual time origin.

Why the Start Date Matters So Much

Consider a patient who is randomized on January 1 and receives first dose on January 8.

Suppose the patient dies on July 1.

If overall survival begins at randomization, the time is measured from January 1.

If an endpoint instead begins at first dose, the time is measured from January 8.

The resulting AVAL values are therefore different.

This is why the start-date derivation should be documented explicitly rather than buried inside programming code.

Visualizing the ADTTE Timeline

The following interactive illustration shows how a single patient's time-to-event record can be constructed.

Overall Survival

Overall survival is one of the clearest examples of a time-to-event endpoint.

A simplified definition might be:

Suppose:

The patient experienced the event.

If the day-count convention is inclusive:

For this example:

The exact numerical result should always be checked against the study's defined date convention.

Overall Survival With Censoring

Now suppose another patient is alive at the database cutoff.

The patient contributes follow-up information but no observed death.

The resulting ADTTE record allows the survival procedure to treat the patient as being event-free through the censoring time.

Progression-Free Survival

Progression-free survival is more complicated because the event can often be triggered by more than one type of occurrence.

A simplified PFS event may be:

• Objective disease progression
• Death from any cause

The precise definition, assessment source, handling of new anticancer therapy, missing assessments and censoring conventions must be specified in the protocol and SAP.

For a patient who progresses before death:

The event date is the qualifying progression date.

If the patient dies before documented progression, the event date may instead be the date of death, depending on the endpoint definition.

PFS Requires Event Prioritization

Consider a patient who has both:

• Progressive disease on Day 180
• Death on Day 240

For a conventional PFS endpoint in which the first qualifying event defines the endpoint:

not Day 240.

The death occurred later, after the patient had already experienced the PFS event.

Illustrative PFS Timeline

Duration of Response

Duration of response presents a different derivation problem.

The patient must first have a qualifying response.

The duration is then measured from the prespecified response start date to the date of progression or death, depending on the endpoint definition.

The start date is therefore not necessarily randomization or first treatment.

This distinction is critical.

Time to Response

Time to response is conceptually different from duration of response.

Time to response measures:

Duration of response measures:

These endpoints therefore use different start dates and different event definitions.

The Core ADTTE Variables

USUBJID

USUBJID identifies the subject.

ADTTE should generally be traceable back to the subject-level analysis dataset and ultimately to the clinical data.

PARAMCD

PARAMCD identifies the time-to-event parameter.

Examples include:

PARAMCD    PARAM
-------    ---------------------------
OS         Overall Survival
PFS        Progression-Free Survival
DOR        Duration of Response
TTR        Time to Response

PARAM

PARAM provides the human-readable description.

It should be consistent with the analysis specification and parameter controlled terminology used by the study.

STARTDT

STARTDT represents the date from which elapsed time is measured.

This is often the most important derivation variable in ADTTE.

ADT

ADT represents the analysis endpoint date.

Depending on CNSR, this may be:

• An observed event date
• A censoring date

AVAL

AVAL represents the analysis time.

For a days-based endpoint, this is usually a numeric number of days.

CNSR

CNSR identifies whether the record represents an event or a censored observation.

A common convention is:

EVNTDESC

EVNTDESC can provide additional explanation of what happened.

Examples include:

The precise categories should be study-defined.

Event Date Versus Censoring Date

The same ADT variable can represent either an event date or a censoring date.

That is why CNSR is essential.

Building ADTTE From Source Data

ADTTE rarely comes from a single source domain.

Depending on the endpoint, the programmer may need information from:

• ADSL
• ADRS
• SDTM DS
• SDTM RS
• SDTM AE
• SDTM MH
• Survival follow-up data
• Vital status data
• Exposure data
• Other study-specific sources

The exact source structure depends on the study.

Typical ADTTE Derivation Flow

Candidate Dates and the Event Hierarchy

Time-to-event programming frequently requires the programmer to collect multiple candidate dates before deciding which date becomes ADT.

For example, a PFS endpoint could potentially involve:

The endpoint specification determines which candidate wins.

For a conventional time-to-first-event endpoint:

if a qualifying event exists before the applicable censoring condition.

Event Hierarchy Is Not the Same as Date Sorting

Simply sorting all dates and selecting the earliest date can be wrong.

Suppose the dataset contains:

• A routine clinic visit on Day 30
• A progression event on Day 180
• A death on Day 240

The earliest date is Day 30, but it is not an endpoint event.

The programmer must first classify candidate records according to whether they satisfy the endpoint definition.

Example: PFS Derivation

Suppose a patient has:

The PFS event is progression on Day 196.

Therefore:

and:

The later death does not change the PFS event date.

Example: Censored PFS

Now suppose another patient has:

If no progression or death occurs and the SAP specifies censoring at the last adequate tumor assessment, then:

and:

The patient contributes 224 days of event-free follow-up under that censoring rule.

Censoring Is Not "Missing"

A censored observation is not equivalent to missing data.

This distinction is fundamental.

A censored patient contributes information to the survival analysis.

Kaplan-Meier Analysis and ADTTE

ADTTE is designed to provide the data needed by time-to-event statistical procedures such as the Kaplan-Meier estimator.

The analysis essentially uses:

• Time: AVAL
• Event indicator: derived from CNSR
• Treatment group: typically from ADSL or carried into ADTTE
• Parameter: PARAMCD

Under the common CNSR convention:

so that:

and:

Interactive Kaplan-Meier Illustration

ADTTE Does Not Contain a Kaplan-Meier Curve

An important conceptual distinction is that ADTTE contains the patient-level input to the survival analysis.

The Kaplan-Meier estimator is calculated later.

where \(\widehat{S}(t)\) is the estimated survival function.

The Survival Function

The Kaplan-Meier estimator estimates the probability of remaining event-free through time \(t\).

Conceptually:

where:

• \(t_i\) = an event time
• \(d_i\) = number of events at that time
• \(n_i\) = number at risk immediately before the event time

ADTTE supplies the patient-level event and censoring information required to construct this analysis.

Why Censoring Must Be Correct

Suppose 100 patients are followed.

If the programmer accidentally classifies 20 censored patients as events, the estimated survival curve can change dramatically.

Likewise, if genuine events are incorrectly censored, the survival estimate can be artificially inflated.

ADTTE and ADSL

ADTTE generally depends heavily on ADSL.

ADSL commonly provides:

• USUBJID
• Treatment assignment
• Randomization information
• First treatment date
• Analysis population flags
• Stratification variables
• Other subject-level covariates

ADTTE then adds endpoint-specific information.

ADTTE and ADRS

For oncology trials, ADTTE and ADRS often work closely together.

ADRS may contain response assessments such as:

• Complete response
• Partial response
• Stable disease
• Progressive disease
• Not evaluable

ADTTE may use those assessments to derive:

• Time to response
• Duration of response
• Progression-free survival

Time to Event Versus Event Date

These are related but different variables.

The date is useful for traceability and derivation.

The elapsed time is what the survival procedure generally analyzes.

Why Keep Both Dates?

A programmer could theoretically store only the resulting AVAL.

But retaining STARTDT and ADT provides valuable traceability.

For example:

allows a reviewer to reconstruct the time calculation.

This is especially useful during:

• Programming QC
• Clinical review
• Data review
• Regulatory submission review
• Issue investigation

Analysis Day Versus Calendar Difference

One of the most common ADTTE programming errors involves misunderstanding the difference between calendar-date subtraction and the study's analysis-day convention.

Suppose:

and:

Simple date subtraction gives:

But an inclusive Day 1 convention could produce:

Therefore, the programmer must know whether the endpoint uses:

• Elapsed calendar days
• Inclusive study days
• Analysis day relative to treatment
• Another protocol-defined convention

Handling Partial Dates

Time-to-event endpoints can encounter partial dates.

For example, a source record might contain:

01JAN2025
15FEB2025
2025-03
2025-04-XX

Whether a partial date can be used depends on the endpoint and the rules specified in the SAP or data derivation specifications.

A programmer should not automatically impute a missing day.

Data Cutoff Dates

Time-to-event analyses frequently use a data cutoff date.

For overall survival, for example, patients without an observed death may be censored based on the last known survival information available by the cutoff.

The cutoff therefore influences which observations are available for deriving the endpoint.

The Difference Between Cutoff and Last Contact

These dates should not automatically be treated as identical.

Which date is used for censoring depends on the endpoint-specific rules.

Censoring Rules Must Be Endpoint-Specific

There is no single universal censoring rule for all ADTTE parameters.

For example, OS may use survival follow-up information, while PFS may depend on tumor-assessment history and progression rules.

DOR may have yet another censoring strategy.

These examples illustrate why copying censoring code from one endpoint to another can be dangerous.

Post-Progression Assessments

Post-progression information can create complex derivation scenarios.

For some endpoints, measurements after progression are no longer relevant to the primary endpoint event.

For others, post-event data may still be retained for descriptive or supporting analyses.

The programmer should therefore distinguish:

• Data used to determine the endpoint
• Data retained for traceability
• Data used in supplementary analyses

Event Description Variables

A useful ADTTE implementation often records why the endpoint ended.

For example:

This information can be extremely helpful when reviewing the endpoint population.

Why EVNTDESC Matters

Suppose two treatment groups have the same number of PFS events.

The event-description distribution may nevertheless be different.

The underlying patient experience may therefore differ even when the overall event count is similar.

Multiple Time-to-Event Parameters

A study can contain many ADTTE parameters.

For example:

PARAMCD    PARAM
-------    ---------------------------------
OS         Overall Survival
PFS        Progression-Free Survival
TTR        Time to First Response
DOR        Duration of Response
TTD        Time to Treatment Discontinuation
TTNT       Time to Next Treatment

The final dataset may therefore contain multiple records per patient.

Parameter-Level Record Counts

A basic QC check is to examine the number of records by parameter.

proc freq data=adtte;
  tables paramcd / missing;
run;

Unexpected counts can reveal:

• Missing parameters
• Duplicate records
• Patients incorrectly included
• Patients incorrectly excluded
• Unexpected parameter generation

Expected Cardinality

If the study has 500 patients in the relevant analysis population and every patient should contribute exactly one OS record, the expected number of OS records is:

If only responders contribute DOR, and 120 patients qualify as responders, then:

These simple expectations are powerful QC checks.

ADTTE Record Structure

A conceptual ADTTE record might look like this:

Deriving AVAL Manually

Suppose:

and:

The calendar difference is:

Under an inclusive convention:

This is the type of simple arithmetic that should always be independently checked during QC.

Negative AVAL Values

A correctly constructed time-to-event record generally should not have a negative analysis time.

If:

then:

This is usually a strong signal that something is wrong.

Potential causes include:

• Incorrect start date
• Incorrect event date
• Date parsing error
• Time-zone/date conversion issue
• Incorrect endpoint population
• Incorrect event hierarchy

Zero-Day Events

An event occurring on the same calendar date as the start date can legitimately produce a very small analysis time, depending on the convention.

For example:

could produce:

under an inclusive convention.

Whether same-day events are possible and how they are represented should be specified and validated.

Missing Start Dates

If STARTDT cannot be established, AVAL generally cannot be derived reliably.

For example:

STARTDT = .
ADT     = 15JUL2025
AVAL    = .
CNSR    = 0

This should trigger investigation.

The correct action depends on the endpoint and prespecified data handling.

Patients With No Event and No Follow-Up

A patient who has no event and no adequate follow-up cannot automatically be treated as simply censored at an arbitrary date.

The programmer must establish whether there is sufficient information to define the censoring date.

Analysis Population Flags

ADTTE may contain one or more analysis flags.

For example:

ANL01FL = "Y"

could identify the records included in a particular primary analysis.

The precise flag structure should be defined by the study.

Analysis flags can be useful when:

• Multiple versions of an endpoint are present
• Sensitivity analyses are required
• Different analysis populations exist
• Alternative censoring rules are evaluated

Primary and Sensitivity Analyses

Time-to-event endpoints often have sensitivity analyses that modify censoring or event handling.

For example, one analysis may treat a particular intercurrent event as censoring while another may treat it as an event.

These should not be mixed into the primary endpoint record without clear identification.

The exact implementation should follow the analysis dataset specification.

Intercurrent Events

Time-to-event endpoints can be affected by events occurring after treatment initiation.

Examples include:

• New anticancer therapy
• Treatment discontinuation
• Protocol deviation
• Withdrawal of consent
• Loss to follow-up
• Death

How each event is handled depends on the endpoint strategy.

The analysis may use:

• Treatment policy
• Composite strategy
• Hypothetical strategy
• While-on-treatment strategy
• Principal-stratum strategy

The ADTTE derivation must reflect the prespecified estimand and endpoint definition.

ADTTE and the Estimand

The estimand provides the broader framework for defining the treatment effect of interest.

For time-to-event endpoints, this affects questions such as:

• What event counts?
• What happens after treatment discontinuation?
• What happens after new therapy?
• Which observations are censored?
• What population is analyzed?

ADTTE operationalizes the endpoint definition at the patient-record level.

SAS Implementation: Basic AVAL Derivation

A simplified SAS derivation might look like:

adtte = source;

if not missing(startdt) and not missing(adt) then
  aval = adt - startdt + 1;

format startdt adt yymmdd10.;

This is intentionally simple.

A production ADTTE program must implement the actual endpoint-specific rules.

SAS Implementation: Event and Censoring Logic

if not missing(eventdt) then do;

  adt      = eventdt;
  cnsr     = 0;
  evntdesc = eventdesc;

end;

else if not missing(censdt) then do;

  adt      = censdt;
  cnsr     = 1;
  evntdesc = censdesc;

end;

if not missing(startdt) and not missing(adt) then
  aval = adt - startdt + 1;

The key principle is that event and censoring logic should be derived from clearly defined candidate variables rather than from a single opaque statement.

SAS Implementation: Parameter Assignment

length paramcd $8 param $100;

paramcd = "OS";
param   = "Overall Survival";

For a parameterized dataset, the program may construct different records using different endpoint-specific derivation blocks.

SAS Implementation: PFS Example

if not missing(progdt) and
   not missing(deathdt) then do;

  if progdt <= deathdt then do;
    adt      = progdt;
    cnsr     = 0;
    evntdesc = "Progressive Disease";
  end;

  else do;
    adt      = deathdt;
    cnsr     = 0;
    evntdesc = "Death";
  end;

end;

else if not missing(progdt) then do;

  adt      = progdt;
  cnsr     = 0;
  evntdesc = "Progressive Disease";

end;

else if not missing(deathdt) then do;

  adt      = deathdt;
  cnsr     = 0;
  evntdesc = "Death";

end;

else if not missing(lastassessdt) then do;

  adt      = lastassessdt;
  cnsr     = 1;
  evntdesc = "No Progression at Last Assessment";

end;

This illustrates the programming structure, not a universal PFS algorithm.

R Implementation

The same principles can be implemented in R.

library(dplyr)

adtte <- source_data %>%
  mutate(
    PARAMCD = "OS",
    PARAM   = "Overall Survival",
    ADT     = if_else(
      !is.na(DEATHDT),
      DEATHDT,
      CUTOFFDT
    ),
    CNSR    = if_else(
      !is.na(DEATHDT),
      0,
      1
    ),
    EVNTDESC = if_else(
      !is.na(DEATHDT),
      "Death",
      "Alive at Cutoff"
    ),
    AVAL = as.numeric(ADT - STARTDT) + 1
  )

Again, the censoring and event rules must be replaced with the actual study-specific definitions.

Creating Multiple Parameters in R

A parameterized ADTTE dataset can be constructed by generating endpoint records and combining them.

os <- derive_os(data)

pfs <- derive_pfs(data)

dor <- derive_dor(data)

adtte <- bind_rows(
  os,
  pfs,
  dor
) %>%
  arrange(
    USUBJID,
    PARAMCD
  )

This structure can make the derivation logic easier to maintain and test.

R Survival Analysis

Once ADTTE is constructed, a Kaplan-Meier analysis can be performed using packages such as survival.

library(survival)

pfs_data <- adtte %>%
  filter(PARAMCD == "PFS")

fit <- survfit(
  Surv(
    AVAL,
    CNSR == 0
  ) ~ TRT01P,
  data = pfs_data
)

summary(fit)

Here:

identifies the observed event under the common ADTTE convention.

SAS PROC LIFETEST Example

proc lifetest data=adtte
              plots=survival;

  where paramcd = "PFS";

  time aval * cnsr(1);

  strata trt01p;

run;

The notation:

time aval * cnsr(1);

means that CNSR=1 is treated as the censoring value, so CNSR=0 represents the event.

Median Survival

If the estimated survival curve crosses 0.50, a median time-to-event can be estimated.

Conceptually:

The corresponding \(t\) is the estimated median.

ADTTE itself does not contain the median.

The median is a summary statistic calculated from the time-to-event analysis.

Why ADTTE Should Remain at Patient Level

ADTTE is not a summary dataset.

It should retain patient-level information so that downstream procedures can calculate:

• Kaplan-Meier curves
• Median survival
• Quartiles
• Landmark estimates
• Event counts
• Censoring counts
• Hazard ratios
• Subgroup analyses

If patient-level information were collapsed too early, much of this analysis would become impossible.

ADTTE and Hazard Ratios

A Cox proportional hazards model can use the same underlying time-to-event information.

Conceptually:

where \(h(t|X)\) is the hazard at time \(t\) given covariates \(X\).

The treatment coefficient can be transformed into a hazard ratio:

ADTTE therefore serves as a key analysis input for both nonparametric and model-based time-to-event analyses.

Stratified Time-to-Event Analysis

Some studies stratify survival analyses by baseline factors.

Examples include:

• Disease stage
• Geographic region
• Prior therapy
• Biomarker status

The relevant stratification variables must be available in the analysis dataset or traceable to ADSL.

Subgroup Analysis

ADTTE can also support subgroup analyses.

For example:

The same patient-level ADTTE records can often support all these analyses.

ADTTE and Data Traceability

A strong ADTTE dataset should allow the programmer or reviewer to understand:

Traceability becomes especially important when the endpoint is based on multiple source domains.

Event Selection Example

Consider the following candidate events:

For a time-to-first-event PFS definition, the progression date wins.

What If Progression and Death Occur on the Same Date?

A study may encounter the situation in which progression and death share the same date.

The programmer must follow the endpoint's event-priority convention.

For example, the event description could potentially distinguish:

• Progressive Disease
• Death
• Progressive Disease and Death on Same Date

The exact convention should be specified rather than invented during programming.

Duplicated Source Records

Duplicate clinical records can create duplicate event candidates.

For example:

This does not necessarily mean that the patient experienced two progression events.

The source-data structure and derivation rules must determine whether the records represent duplicates, multiple assessments, or genuinely distinct events.

One Record Per Patient Per Parameter

For many ADTTE primary endpoints, the expected structure is:

If the dataset contains multiple records for the same patient and PARAMCD, investigate whether they represent:

• Legitimate alternative analyses
• Multiple records incorrectly retained
• Sensitivity parameters
• Programming duplication

Duplicate QC

proc sort data=adtte
          out=adtte_dups
          nodupkey
          dupout=dup_records;

  by usubjid paramcd;

run;

If the intended key is more complex, include the appropriate variables.

Checking CNSR

proc freq data=adtte;

  tables paramcd * cnsr / missing;

run;

Unexpected CNSR distributions should be investigated.

For example, if nearly every patient has CNSR=0, the event derivation may have been overly permissive.

Checking AVAL

proc means data=adtte
           n nmiss min p25 median p75 max;

  class paramcd;

  var aval;

run;

This helps identify:

• Missing analysis times
• Negative values
• Extremely large values
• Unexpected parameter distributions

Checking Dates

data qc_dates;

  set adtte;

  if not missing(startdt)
     and not missing(adt)
     and adt < startdt;

run;

Any records returned by this check should be reviewed.

Independent AVAL Recalculation

One of the strongest QC techniques is to independently recalculate AVAL.

data qc_aval;

  set adtte;

  if not missing(startdt)
     and not missing(adt) then
    aval_qc = adt - startdt + 1;

  if aval ne aval_qc then
    mismatch = 1;

run;

The exact formula should match the study's specified convention.

Event-Date QC

For every observed event, verify that ADT corresponds to an actual qualifying event source.

Event/Censoring Cross-Check

A useful conceptual check is:

and:

Violations of these relationships are important QC findings.

Parameter-Specific QC

Each endpoint should have its own validation checks.

Duration of Response: Eligibility First

A patient without a qualifying response generally cannot contribute a standard DOR record.

Therefore, DOR derivation often begins with:

Only if the answer is yes does the program proceed to:

DOR Example

Suppose:

If the endpoint uses Day 84 as the response start date:

This illustrates why DOR cannot simply be calculated from first treatment to progression.

Time to Response Example

Using the same patient:

The same patient therefore has:

Competing Events

Some time-to-event endpoints can involve competing events.

For example, when studying a specific cause of death, death from another cause may prevent the event of interest from occurring.

The appropriate analysis may then require competing-risk methodology rather than a simple Kaplan-Meier analysis treating all other outcomes as ordinary censoring.

Time to First Subsequent Therapy

Another possible endpoint is time to first subsequent anticancer therapy.

The endpoint might be defined as:

The event date is therefore derived from subsequent-therapy data rather than from tumor assessments.

This illustrates the flexibility of ADTTE.

Time to Treatment Discontinuation

A treatment-discontinuation endpoint might use:

• Treatment start as the time origin
• Permanent treatment discontinuation as the event
• Alternative censoring rules for patients still receiving treatment

The exact definition must distinguish between temporary interruptions and permanent discontinuation where relevant.

ADTTE for Safety Time-to-Event Analyses

ADTTE is not limited to efficacy.

Time-to-event concepts can also be used for safety analyses, such as:

• Time to first treatment-emergent adverse event
• Time to first serious adverse event
• Time to dose modification
• Time to treatment discontinuation due to an adverse event

The event definitions and risk periods must be explicitly specified.

Risk Periods

Some endpoints begin only after a patient enters a particular state.

For example, DOR begins after response.

A time-to-first-adverse-event analysis may begin at first treatment.

The risk period therefore matters.

An event outside the relevant risk period should not be incorrectly attributed to the endpoint.

ADTTE and Treatment Emergence

For safety time-to-event analyses, the programmer may need to determine whether an adverse event meets the treatment-emergent definition.

That requires rules involving:

• Event start date
• First treatment date
• Pre-existing conditions
• Severity changes
• Study-specific treatment-emergent criteria

The event definition should come from the safety analysis specification.

Handling Unscheduled Assessments

Unscheduled assessments can affect time-to-event endpoints.

For example, an unscheduled scan may identify progression before the next planned visit.

Whether that assessment is used depends on the prespecified analysis rules.

Assessment Date Versus Visit Date

For time-to-event derivations, the actual assessment date may be more important than the nominal visit label.

For example:

If progression is documented at Day 91, the endpoint date may be Day 91 even though the planned Week 16 assessment occurs later.

Data Cutoff and Late Data

Clinical databases may contain information entered after the nominal cutoff, depending on database and analysis processes.

The analysis specification should define how late-arriving information is handled.

The programmer should never silently modify the cutoff rules based on whatever data happen to be present in the programming environment.

ADTTE and Submission Readiness

For regulatory submissions, reviewers may need to understand how the time-to-event endpoints were derived.

This makes the following particularly important:

• Clear parameter definitions
• Traceable dates
• Transparent event indicators
• Consistent censoring logic
• Subject-level reproducibility
• Controlled derivation rules

Common ADTTE Programming Mistakes

1. Reversing CNSR. Treating 1 as event and 0 as censoring when the study uses the opposite convention.
2. Using the wrong start date. For example, using treatment start for DOR when the endpoint begins at response.
3. Using death instead of the earlier progression event for PFS.
4. Choosing the earliest calendar date without determining whether it is a qualifying endpoint event.
5. Ignoring the data cutoff. This can cause follow-up beyond the analysis boundary to enter the endpoint.
6. Manufacturing censoring dates. A patient should not be censored at a date unsupported by the endpoint rules.
7. Calculating AVAL with an undocumented +1 adjustment.
8. Including nonresponders in DOR.
9. Failing to distinguish event date from censoring date.
10. Creating duplicate patient/parameter records.
11. Using post-event information incorrectly.
12. Failing to validate event descriptions.
13. Hard-coding a censoring rule from another study.
14. Ignoring competing events when the estimand requires special handling.
15. Assuming every time-to-event endpoint uses the same derivation.

ADaM BDS Versus ADTTE

ADTTE is related conceptually to BDS but has important time-to-event-specific features.

ADTTE Versus a Simple Event Dataset

A simple event dataset might answer:

ADTTE answers a richer question:

That makes ADTTE much more useful for survival analysis.

A Complete Illustrative ADTTE

This small table illustrates the basic parameterized nature of ADTTE.

Reading the Example

Patient 001 has two records.

For OS, the patient experienced death.

For PFS, progression occurred earlier and therefore defines the PFS event.

Patient 002 remains alive and has no documented progression through the specified censoring point.

Patient 003 contributes an observed OS event.

A Useful Mental Model

For every ADTTE record, ask five questions:

If those five questions can be answered clearly, the ADTTE record is usually much easier to understand and validate.

Building ADTTE From the SAP

Before writing code, extract the endpoint definition from the statistical analysis plan.

For each endpoint, document:

ADTTE Specification Example

A programmer might create an internal specification such as:

Parameter:
  PFS

Start:
  Randomization date

Event:
  First documented progression or death

Event date:
  Earliest qualifying event

Censor:
  No progression and no death

Censor date:
  Last adequate disease assessment,
  according to SAP rules

CNSR:
  0 = event
  1 = censored

AVAL:
  Analysis time in days

Time convention:
  As defined in the SAP

This specification becomes the bridge between the clinical definition and the programming implementation.

Endpoint Derivation Matrix

This matrix is often one of the most useful documents a programmer can create before beginning the ADTTE program.

Programming Strategy: Separate Derivation From Assembly

A maintainable program often separates:

1. Source-data preparation
2. Event derivation
3. Censoring derivation
4. Time calculation
5. Parameter assignment
6. Dataset assembly
7. QC

This is generally easier to review than putting every endpoint into a single large block of nested conditional statements.

Example Modular SAS Structure

/*-----------------------------------------
  1. Prepare subject-level information
-----------------------------------------*/

data adsl_base;
  set adsl;

  keep usubjid
       trt01p
       randdt
       trtsdt
       saffl;
run;


/*-----------------------------------------
  2. Derive OS
-----------------------------------------*/

data os;
  set adsl_base;

  length paramcd $8
         param $100
         evntdesc $100;

  paramcd = "OS";
  param   = "Overall Survival";

  /* Endpoint-specific event/censoring logic */

run;


/*-----------------------------------------
  3. Derive PFS
-----------------------------------------*/

data pfs;
  set adsl_base;

  length paramcd $8
         param $100
         evntdesc $100;

  paramcd = "PFS";
  param   = "Progression-Free Survival";

  /* Endpoint-specific event/censoring logic */

run;


/*-----------------------------------------
  4. Assemble ADTTE
-----------------------------------------*/

data adtte;
  set os pfs;

  if not missing(startdt)
     and not missing(adt) then
    aval = adt - startdt + 1;

run;

Why Modular Programming Helps

Modular derivation makes it easier to answer questions such as:

• How was OS derived?
• How was PFS derived?
• Which source generated the progression date?
• Why was this patient censored?
• Why is DOR restricted to responders?

It also makes endpoint-specific QC easier.

Validation Against Known Patients

A strong ADTTE validation process should include hand-reviewed patients.

For example, deliberately select patients representing:

• Observed death
• Death without prior progression
• Progression followed by death
• No progression through cutoff
• Early treatment discontinuation
• Responder with durable response
• Responder with progression
• Patient with missing assessments
• Patient with unscheduled assessment
• Patient with unusual date relationships

Example Patient-Level Validation

Population-Level Validation

After reviewing individual patients, examine aggregate results.

Useful summaries include:

• Number of patients
• Number of events
• Number censored
• Event percentage
• Minimum time
• Median time
• Maximum follow-up
• Event-description distribution

Event Count Reconciliation

For each parameter:

provided every patient has exactly one record and the population is defined accordingly.

If the numbers do not reconcile, investigate the cause.

Example Reconciliation Table

For OS:

For PFS:

For DOR, only responders contribute:

Checking for Impossible Event Descriptions

A simple consistency check can identify logically impossible combinations.

The exact valid combinations depend on the endpoint.

Common Date QC

Check that:

• STARTDT is not after ADT.
• ADT does not exceed the applicable cutoff when prohibited by the analysis.
• Event dates correspond to source events.
• Censoring dates correspond to valid follow-up.
• DOR start dates correspond to qualifying responses.
• PFS event dates correspond to qualifying progression or death.

ADTTE and Reproducibility

A high-quality ADTTE dataset should be reproducible.

If the same source data and specification are processed again, the resulting ADTTE records should be consistent.

This requires:

• Version-controlled programs
• Stable specifications
• Documented derivations
• Controlled source data
• Independent QC
• Clear assumptions

ADTTE Documentation

Useful documentation includes:

• Dataset metadata
• Variable metadata
• Parameter definitions
• Endpoint derivation specifications
• Censoring rules
• Event hierarchies
• Source-data mappings
• Programming assumptions
• QC results

What Makes ADTTE Different From "Just a Survival Dataset"?

The important distinction is that ADTTE is an analysis dataset designed to represent the endpoint definition in a standardized, traceable form.

It connects:

The quality of the final survival analysis depends on the quality of every link in this chain.

The Three Most Important ADTTE Variables

If you are learning ADTTE for the first time, focus initially on:

Then add:

• STARTDT
• ADT
• EVNTDESC
• Treatment variables
• Population flags

The Four Dates You Should Always Understand

For many ADTTE derivations, it is useful to think explicitly about:

Why the Event Hierarchy Should Be Written Down

A verbal instruction such as "use progression or death" is often insufficient for programming.

A better specification explicitly states:

• Which events qualify
• Which source establishes each event
• How competing candidate events are prioritized
• What happens when dates are equal
• What happens when dates are missing
• What happens after treatment discontinuation
• What happens after subsequent therapy
• What happens at the data cutoff

The more complicated the endpoint, the more important this becomes.

ADTTE Quality-Control Checklist

Practical ADTTE Programming Checklist

What ADTTE Should Make Easy

A well-constructed ADTTE dataset should make it straightforward to answer:

• How many patients experienced the event?
• How many were censored?
• When did events occur?
• Why were patients censored?
• What was the median time-to-event?
• What was the survival probability at a specified landmark?
• How do treatment groups compare?
• How do subgroups compare?
• Can the analysis be independently reproduced?

ADTTE and Kaplan-Meier: The Complete Chain

The relationship can be summarized as:

The Most Important ADTTE Concept

The most important concept is that an ADTTE record represents a time-to-event observation, not simply an event.

A complete record answers:

From these elements, the analysis time is derived.

The statistical procedure then uses AVAL together with the event/censoring indicator.

Final Example

Suppose a patient is randomized on January 1, receives treatment on January 8, experiences progression on July 15 and dies on September 1.

For an endpoint whose start is randomization and whose event is the first of progression or death:

The first qualifying event is:

Therefore:

and, using the illustrative inclusive day-count convention:

The later September death does not replace the July progression for that time-to-first-event endpoint.

For OS, however, the same patient would have a different ADTTE record:

Thus, the same patient can legitimately have different time-to-event values for different parameters.

Bottom Line

References

CDISC. Analysis Data Model (ADaM) Implementation Guide. Clinical Data Interchange Standards Consortium.

CDISC. Analysis Data Model (ADaM). Clinical Data Interchange Standards Consortium.

ICH. E9: Statistical Principles for Clinical Trials. International Council for Harmonisation.

ICH. E9(R1): Addendum on Estimands and Sensitivity Analysis in Clinical Trials. International Council for Harmonisation.

Collett, D. Modelling Survival Data in Medical Research. Chapman & Hall/CRC.

Klein, J.P. and Moeschberger, M.L. Survival Analysis: Techniques for Censored and Truncated Data. Springer.