Creating ADAE: Adverse Event Analysis Datasets

Introduction

Adverse event analysis is one of the most important components of a clinical trial's safety evaluation.

Safety tables may answer questions such as:

• How many subjects experienced at least one adverse event?
• How many subjects experienced a serious adverse event?
• How many subjects experienced a Grade 3 or higher event?
• How many subjects discontinued treatment because of an adverse event?
• Which preferred terms occurred most frequently?
• Which events were considered related to study treatment?

The underlying source for many of these analyses is the SDTM Adverse Events domain, AE.

However, the SDTM AE dataset is designed primarily for standardized clinical data tabulation and submission.

It is not necessarily organized in the exact form required to produce every analysis table or listing.

That is where an adverse-event analysis dataset commonly referred to as ADAE becomes useful.

What Is ADAE?

ADAE is commonly used as the name for an adverse-event analysis dataset within an ADaM implementation.

It is important, however, to understand the terminology precisely.

ADAE is not simply a renamed copy of SDTM AE.

An ADAE dataset typically combines:

• Adverse-event information from SDTM AE
• Subject-level treatment information from ADSL
• Analysis dates and analysis days
• Treatment-period variables
• Treatment-emergent flags
• Analysis flags
• Occurrence or counting variables
• Other study-specific derivations needed for safety analysis

The precise variable set depends on the study's ADaM implementation, statistical analysis plan, and sponsor conventions.

Where ADAE Fits in the CDISC Data Flow

A typical clinical-trial data flow looks like this:

The important concept is that each layer has a different purpose.

ADAE Is Usually an Occurrence-Oriented Dataset

Adverse events are fundamentally different from many laboratory or vital-sign analyses.

A laboratory BDS dataset may contain one record for a subject at a particular parameter and visit.

An adverse-event dataset usually represents individual event occurrences.

For example, one subject might experience:

Each event remains identifiable as a separate occurrence.

One Record Does Not Necessarily Mean One Subject

A common beginner mistake is to think:

That is incorrect.

A subject can have zero, one, or many adverse-event records.

Therefore:

The subject-level information belongs in ADSL, while the event-level information belongs in ADAE.

ADSL and ADAE

ADSL and ADAE serve different purposes.

A single subject appears once in ADSL but may appear many times in ADAE.

The Basic ADAE Derivation Flow

Source Dataset: SDTM AE

The SDTM AE domain contains standardized information about adverse events.

Common AE variables include:

The exact SDTM variable set depends on the collected data and applicable SDTMIG version.

ADAE Does Not Replace SDTM AE

A common misconception is that ADAE should be used instead of SDTM AE.

That is not the intended relationship.

SDTM AE remains the standardized tabulation representation.

ADAE is the analysis representation.

ADSL Variables Commonly Needed by ADAE

The ADAE dataset often requires treatment information from ADSL.

Typical variables include:

The exact variable names depend on the study and ADaM implementation.

Why Treatment Information Matters

Consider two subjects.

The preferred term is the same, but the safety analysis must distinguish the treatment groups.

That treatment context generally comes from subject-level analysis data.

Joining ADSL to ADAE

The basic relationship is:

In practical programming terms, each AE record is associated with the matching subject-level record.

/* SAS-style example */

proc sort data=ae out=ae_s;
  by usubjid;
run;

proc sort data=adsl out=adsl_s;
  by usubjid;
run;

data adae;
  merge ae_s(in=inae)
        adsl_s(in=inadsl);
  by usubjid;

  if inae and inadsl;
run;

The merge should be carefully controlled so that one subject-level ADSL record does not accidentally multiply AE records.

ADAE Record Identification

A useful ADAE implementation normally preserves the original event identity.

For example:

Keeping the source sequence is extremely useful for traceability.

Analysis Dates

SDTM often stores date/time values as ISO 8601 character variables.

For example:

For many analyses, the adverse-event analysis date is a SAS date or equivalent numeric date representation.

A typical derivation might produce:

The exact treatment of partial dates must follow the SAP, ADaM specifications, and study-specific derivation rules.

Partial Dates

Adverse-event dates may sometimes be incomplete.

For example:

A programmer should never silently invent a date without an approved derivation rule.

If a partial date is imputed, the imputation methodology should be documented and traceable.

Analysis Start Day

Once an analysis start date has been derived, an analysis day can be calculated.

A common convention is:

when the adverse-event start date occurs on or after treatment start.

For example:

The first treatment day is therefore Day 1.

Why the +1 Matters

Suppose treatment begins on February 1 and an adverse event begins on February 1.

The calendar difference is zero days.

But under the Day 1 convention:

Therefore the event occurs on treatment Day 1.

Analysis End Date and End Day

If the adverse event has an end date, an analysis end date can similarly be derived.

For example:

An event occurring from Day 5 through Day 8 would therefore have:

Duration of an Adverse Event

If both start and end dates are available, an event duration can be calculated.

A common elapsed-duration calculation is:

For example, an event beginning March 10 and ending March 12 has:

The exact variable name and derivation should follow the study's analysis specification.

Treatment-Emergent Adverse Events

One of the most important ADAE derivations is the treatment-emergent adverse-event flag.

A treatment-emergent event is generally an event that begins after treatment starts, or an event that was present before treatment but worsens after treatment, according to the prespecified analysis definition.

The exact definition must come from the SAP and study programming specifications.

A Simple TEAE Example

The resulting treatment-emergent flag depends on the prespecified TEAE algorithm.

The Treatment-Emergent Window

Many trials define an analysis window that extends through a specified number of days after the last treatment.

Conceptually:

where \(W\) is a protocol- or SAP-defined post-treatment window.

For example, a study could define its primary treatment-emergent safety period as treatment start through 30 days after the last dose.

TEAE Derivation as a Logical Rule

A simplified example might look like:

The actual implementation can be considerably more complex.

Pre-Treatment Adverse Events

Consider an event that begins before treatment.

The first event may remain non-treatment-emergent.

The second may become treatment-emergent if the study's rules classify worsening of a pre-existing condition as treatment-emergent.

Severity Versus Seriousness

These concepts are frequently confused.

Severity describes the intensity of an adverse event.

Seriousness describes whether an adverse event meets regulatory criteria for a serious adverse event.

A severe event is not automatically a serious adverse event.

Conversely, a serious adverse event is not necessarily severe.

Severity Analysis

A typical severity classification might contain:

• Mild
• Moderate
• Severe

Depending on the study, severity may instead be represented using CTCAE grades or another grading system.

For example:

If CTCAE grades are collected, the analysis representation may retain the grade and may derive additional flags for Grade 3 or higher.

Serious Adverse Events

The SDTM AE domain may identify serious events using variables such as AESER and seriousness-category variables.

ADAE may retain these variables and derive analysis flags such as:

• Serious event flag
• Death flag
• Life-threatening event flag
• Hospitalization flag
• Disability flag
• Congenital anomaly flag
• Other medically important event flag

The exact variables depend on the study implementation.

Relationship to Study Treatment

Safety analyses frequently distinguish adverse events considered related to study treatment from those considered unrelated.

The source relationship variable might contain categories such as:

• Not Related
• Unlikely Related
• Possibly Related
• Probably Related
• Definitely Related

The exact controlled terminology depends on the study.

A sponsor may then define an analysis flag such as:

Why Relationship Rules Must Be Specified

Suppose the investigator uses:

• Possibly Related
• Probably Related
• Definitely Related

as "related."

Another study might use a different grouping.

Therefore, the programmer should never assume the relationship grouping without a documented rule.

Action Taken With Study Treatment

An adverse event may result in an action such as:

• Drug interrupted
• Drug withdrawn
• Dose reduced
• Dose increased
• No change
• Not applicable

These variables are often useful for safety listings and summaries.

Outcome

The event outcome describes what happened to the adverse event.

Examples include:

• Recovered/resolved
• Recovering/resolving
• Not recovered/not resolved
• Recovered/resolved with sequelae
• Fatal
• Unknown

The analysis dataset generally preserves the source information and may derive additional flags when needed for specific analyses.

Occurrence Flags

A particularly important ADAE concept is the use of occurrence flags.

Suppose a subject experiences three headaches:

The first record can be marked as the first occurrence of the preferred term for the subject.

This can help prevent one subject with multiple occurrences of the same AE from being counted multiple times in a subject-incidence table.

Why Occurrence Flags Matter

Suppose five subjects experience headache:

• Subject 001: one occurrence
• Subject 002: three occurrences
• Subject 003: one occurrence
• Subject 004: two occurrences
• Subject 005: one occurrence

There are:

event records.

But only:

subjects with headache.

Safety incidence tables typically count subjects rather than raw event records.

First Occurrence Flags

A common approach is to identify the first occurrence within a defined analysis category.

For example:

by usubjid aebodsys aedecod;

if first.aedecod then aoccfl = "Y";
else aoccfl = "N";

However, actual occurrence-flag logic should be aligned with the analysis category being counted.

Different Counting Levels

Safety outputs may count events at several levels.

A carefully constructed ADAE dataset can support all of these analyses.

Example ADAE Structure

A simplified ADAE dataset might look like this:

Typical ADAE Variable Categories

This table is illustrative rather than a universal ADAE standard.

ADAE and Treatment Variables

A safety analysis may need both planned and actual treatment.

For example:

Whether planned or actual treatment is used for a particular safety analysis depends on the SAP.

Multi-Period and Crossover Studies

ADAE becomes more complicated when subjects receive multiple treatment periods.

For example:

An adverse event beginning on March 5 may need to be associated with Drug B rather than simply with the subject's overall treatment assignment.

Therefore, ADAE programming in crossover or multi-period studies may require period-specific treatment derivations.

Treatment Period Variables

A study may derive variables such as:

• TRTP
• TRTA
• TRTPN
• TRTAN
• TRTxxP
• TRTxxA
• Period identifiers
• On-treatment indicators

The exact implementation depends heavily on the study design.

ADAE and Safety Population

The safety population is frequently identified in ADSL.

For example:

may indicate that the subject belongs to the safety population.

ADAE can carry this flag onto every event record for that subject.

A safety analysis can then use:

where saffl = "Y";

or an equivalent analysis restriction.

Why Population Flags Belong in ADAE

Suppose ADSL contains:

Subject 003 may still have AE records in SDTM AE.

Whether those events are included in a particular safety analysis can be controlled through the analysis-population flag.

Deriving ADAE in SAS

A basic SAS workflow can be organized into several stages.

Step 1: Read SDTM AE

data ae;
  set sdtm.ae;
run;

Step 2: Read ADSL

data adsl;
  set adam.adsl;
run;

Step 3: Merge Subject-Level Information

proc sort data=ae;
  by usubjid;
run;

proc sort data=adsl;
  by usubjid;
run;

data adae;
  merge ae(in=inae)
        adsl(in=inadsl);
  by usubjid;

  if inae and inadsl;
run;

Deriving Analysis Dates in SAS

A complete implementation should use a controlled approach to ISO date/time conversion.

For a complete ISO date:

astdt = input(substr(aestdtc,1,10), yymmdd10.);
format astdt date9.;

This simple example is appropriate only when the date is complete and the analysis specification permits this derivation.

Deriving Analysis Day in SAS

if not missing(astdt) and not missing(trtsdt) then do;

  if astdt >= trtsdt then
    astdy = astdt - trtsdt + 1;

  else
    astdy = astdt - trtsdt;

end;

The pre-treatment convention must match the study's analysis specification.

Deriving Treatment-Emergent Status

A simplified example might be:

if not missing(astdt)
   and not missing(trtsdt)
   and astdt >= trtsdt
then trtemfl = "Y";
else trtemfl = "N";

R Implementation With dplyr

The same general process can be implemented in R.

library(dplyr)

adae <- ae %>%
  left_join(
    adsl %>%
      select(
        USUBJID,
        TRT01P,
        TRT01A,
        TRTSDT,
        TRTEDT,
        SAFFL
      ),
    by = "USUBJID"
  )

The resulting dataset contains event-level information from AE and subject-level information from ADSL.

Deriving Analysis Dates in R

library(lubridate)

adae <- adae %>%
  mutate(
    ASTDT = ymd(substr(AESTDTC, 1, 10)),
    AENDT = ymd(substr(AEENDTC, 1, 10))
  )

Again, this example assumes complete date information and should not be used as a universal partial-date imputation algorithm.

Deriving Analysis Days in R

adae <- adae %>%
  mutate(
    ASTDY = case_when(
      ASTDT >= TRTSDT ~ as.integer(ASTDT - TRTSDT) + 1L,
      ASTDT < TRTSDT  ~ as.integer(ASTDT - TRTSDT),
      TRUE ~ NA_integer_
    )
  )

Deriving a Basic TEAE Flag in R

adae <- adae %>%
  mutate(
    TRTEMFL = case_when(
      !is.na(ASTDT) &
      !is.na(TRTSDT) &
      ASTDT >= TRTSDT ~ "Y",
      TRUE ~ "N"
    )
  )

The code demonstrates the programming pattern rather than establishing a universal treatment-emergent definition.

Sorting ADAE

A useful sort order preserves subject and event chronology.

adae <- adae %>%
  arrange(
    USUBJID,
    ASTDT,
    AESEQ
  )

Including AESEQ provides a deterministic ordering when multiple events have the same start date.

Occurrence Flags in R

A simplified first-occurrence flag for a preferred term might be:

adae <- adae %>%
  arrange(USUBJID, AEDECOD, ASTDT, AESEQ) %>%
  group_by(USUBJID, AEDECOD) %>%
  mutate(
    AOCCFL = if_else(row_number() == 1, "Y", "N")
  ) %>%
  ungroup()

Real studies may require more sophisticated occurrence definitions.

Why Occurrence Logic Is More Complicated Than It Looks

Suppose a subject has:

If the analysis concerns treatment-emergent headache, the first occurrence among all AE records may not be the correct record for the TEAE analysis.

Therefore, occurrence flags should be defined within the relevant analysis population and category.

Example: First TEAE by Preferred Term

Suppose:

For a TEAE incidence table, the relevant first occurrence is the first treatment-emergent headache, not necessarily the first headache ever reported.

Safety Tables and ADAE

ADAE is often the primary analytical source for safety outputs such as:

• Overall adverse-event incidence
• Adverse events by system organ class and preferred term
• Serious adverse events
• Grade 3 or higher adverse events
• Related adverse events
• Adverse events leading to treatment discontinuation
• Adverse events leading to dose interruption
• Adverse events leading to death
• Common adverse events

Example Safety Table Logic

Suppose the study contains 100 subjects in Drug A and 100 subjects in Drug B.

If 42 Drug A subjects experience nausea and 31 Drug B subjects experience nausea, the table might report:

The denominator generally comes from the appropriate analysis population, while the numerator comes from distinct subjects meeting the specified AE definition.

Counting Subjects Rather Than Records

Suppose Drug A has 60 nausea records but only 42 unique subjects.

The safety table should not normally report:

if the table is intended to represent subject incidence.

Instead:

would represent the percentage of subjects experiencing at least one qualifying nausea event.

Worst Severity

Safety summaries frequently need the maximum severity experienced by each subject for a given preferred term.

Suppose one subject has:

For a "worst severity" subject-level summary, the relevant category is:

This is one reason ADAE often needs to retain all event-level records while the output program performs subject-level summarization.

Worst Severity Derivation

If severity is ordinally coded:

then:

The numeric coding must be explicitly defined and should not be inferred from alphabetical ordering.

Seriousness and Severity Can Be Cross-Classified

Consider four events:

This illustrates why severity and seriousness should be analyzed separately.

Events Leading to Treatment Discontinuation

A common safety analysis asks:

The ADAE dataset may use action-taken information to identify qualifying events.

The exact derivation might identify events where the treatment was permanently withdrawn because of the adverse event.

The analysis flag could then be conceptually represented as:

Death Due to Adverse Event

Deaths require particularly careful analysis.

A study may need to distinguish:

• Subject death
• Adverse event with fatal outcome
• Death occurring during treatment
• Death occurring during follow-up
• Death attributed to a specific adverse event

The source data and analysis rules must determine how these concepts are connected.

ADAE Listings

ADAE also supports detailed safety listings.

A listing might contain:

ADAE and Data Traceability

One of the major benefits of a well-constructed ADAE dataset is traceability.

A reported adverse event should be traceable through:

This allows a programmer or reviewer to investigate an unexpected table value back to the underlying event.

Common ADAE Derivation Categories

ADAE and the Analysis Population

A useful conceptual model is:

The ADAE dataset contains event-level analysis information.

The output program determines how those records are summarized according to the table shell and SAP.

Example End-to-End Dataset

Consider the following simplified ADSL:

Suppose SDTM AE contains:

After adding treatment context and analysis derivations, ADAE might conceptually contain:

What Happened in the Derivation?

For Subject 001:

For the second event:

The events are therefore positioned on treatment Days 3 and 10.

Validation of the Example

The programmer should be able to trace:

• Subject 001 to the correct ADSL treatment
• AESEQ 1 to the correct SDTM AE record
• ASTDY 3 to the correct treatment-start date
• TRTEMFL Y to the applicable TEAE rule
• AESEV Mild to the source AE severity

If any of these relationships fail, the ADAE derivation requires investigation.

Common Mistake: Incorrect Subject Merge

Suppose ADSL accidentally contains two records for Subject 001.

A merge can potentially produce duplicated AE records.

For example:

A careless implementation can result in more than three ADAE records.

Common Mistake: Treating Every AE as a TEAE

An AE occurring before treatment should not automatically receive TRTEMFL="Y".

Consider:

This indicates that the event began before treatment.

Whether it becomes treatment-emergent because of worsening is a separate question.

Common Mistake: Ignoring the Treatment End Date

Suppose treatment ends on:

and an event begins on March 1.

It may still fall within a post-treatment safety window.

Therefore, TEAE programming may require both:

and:

rather than checking only whether the event occurred after treatment started.

Common Mistake: Confusing AEDECOD and AETERM

The reported term and coded preferred term serve different purposes.

Safety summaries commonly use the standardized preferred term.

Detailed listings may display both.

Common Mistake: Counting AE Records Instead of Subjects

This is one of the most consequential programming errors.

If one subject has five headache records, that subject should generally contribute one subject to a "subjects with headache" incidence analysis.

The analysis dataset must therefore support subject-level counting.

Common Mistake: Using Alphabetical Severity Ordering

Suppose severity values are:

• Mild
• Moderate
• Severe

A programmer should not use alphabetical sorting to determine the worst event.

The analysis should use an explicitly defined severity order.

Common Mistake: Losing Original AESEQ

Removing the original sequence identifier makes traceability more difficult.

A strong ADAE dataset should preserve enough source identifiers to allow a reviewer to move from analysis data back to SDTM AE.

Common Mistake: Deriving Dates Without Documenting Imputation

Suppose:

A programmer should not silently convert this to February 1 simply because the software requires a complete date.

Any imputation must follow the predefined methodology.

ADAE Programming Specification

Before programming begins, create a derivation specification.

Derivation Specification vs. Programming Code

The specification should describe the business or clinical rule.

The program should implement that rule.

For example:

The SAS or R program then implements that rule.

ADAE QC Strategy

Quality control should occur at several levels.

Structural Validation

First confirm that the dataset has the expected structure.

Questions include:

• Is USUBJID present?
• Is AESEQ retained?
• Are dates stored in the expected format?
• Are character and numeric variables correctly typed?
• Are required labels present?
• Are treatment variables correctly formatted?
• Are analysis flags populated according to their specifications?

Record-Count Validation

A fundamental check is:

The counts do not necessarily have to be identical if the analysis dataset intentionally excludes records or applies a defined analysis population.

However, any difference should be explainable.

Duplicate Detection

A useful QC check is to identify unexpected duplicate combinations.

proc sort data=adae;
  by usubjid aeseq;
run;

data dupes;
  set adae;
  by usubjid aeseq;

  if first.aeseq and last.aeseq then delete;
run;

The precise uniqueness key depends on the dataset design.

Date Validation

For each event, check that:

when both dates are available and the event is not subject to a special exception.

Also check:

• Events with start dates before treatment
• Events beginning on first dose
• Events after last dose
• Events outside the defined safety window
• Partial dates
• Impossible date relationships

TEAE Flag Validation

Create a targeted QC sample containing:

• Clearly pre-treatment events
• Events on treatment Day 1
• Clearly post-treatment events
• Events after treatment end
• Events inside the post-treatment window
• Pre-treatment events that worsen
• Events with partial dates

Each should be reviewed against the written TEAE rule.

Extreme and Boundary Cases

Boundary cases are particularly valuable for validation.

Missing End Dates

An ongoing adverse event may have no end date.

For example:

The programmer should not create an artificial end date merely to complete a duration calculation.

Ongoing Adverse Events

A useful ADAE implementation can identify events that remain ongoing at a specified analysis cutoff.

For example:

may indicate that the event had not resolved at the time of data collection, depending on the source data and outcome variables.

Post-Treatment Adverse Events

A post-treatment event does not automatically mean that it should be excluded.

Safety reporting may include:

• On-treatment events
• Events during a predefined follow-up window
• Serious adverse events during a longer follow-up period
• Events occurring after treatment but considered related to treatment

The relevant population must therefore be defined before programming.

ADAE in Blinded Studies

During blinded data review, treatment assignments may be masked.

The dataset structure should nevertheless support the eventual analysis.

Depending on the study, programmers may work with blinded treatment codes until the appropriate unblinding point.

ADAE in Double-Dummy or Complex Designs

Complex trials may involve:

• Multiple investigational products
• Placebo components
• Double-dummy administration
• Rescue medication
• Background therapy
• Cross-over treatment
• Open-label extensions

The ADAE treatment derivation must match the study's treatment architecture.

ADAE and Concomitant Medications

An adverse event may lead to concomitant-medication use.

For example:

These datasets remain distinct.

ADAE should not absorb CM data merely because the two domains are clinically related.

ADAE and Exposure

Exposure information may also be relevant to safety analyses.

For example, an event may occur after a subject has received a certain amount of treatment.

However, exposure calculations generally belong in an exposure analysis dataset or other appropriate ADaM structure.

ADAE may be linked to exposure-derived variables when required by the analysis plan.

ADAE and Laboratory Abnormalities

Adverse events and laboratory abnormalities should also be distinguished.

For example:

• A laboratory result may become abnormal.
• The investigator may subsequently report an adverse event.

These are not automatically the same record.

The laboratory analysis belongs to an appropriate laboratory analysis dataset, while the reported AE belongs in ADAE.

ADAE and Medical Coding

AE analysis often relies heavily on standardized medical coding.

Important concepts include:

• Reported term
• Preferred term
• System organ class
• Dictionary version
• Dictionary coding date

The exact terminology depends on the coding dictionary and study standards.

Dictionary Version Matters

If an adverse event is coded using a particular dictionary version, the analysis dataset should preserve the relevant coding information required for traceability.

This is especially important when:

• Dictionary versions change during the study
• Terms are recoded
• Output is regenerated
• Historical data are mapped to newer terminology

ADAE and MedDRA Hierarchy

Safety summaries often use multiple levels of the medical terminology hierarchy.

For example:

ADAE therefore needs to retain the coded terminology needed by the intended outputs.

Example: Building a TEAE Table

Suppose ADAE contains:

For nausea, there are three event records but only two subjects.

Therefore, an incidence table should count Subjects 001 and 002 once each.

Programming the Subject Count in R

nausea_subjects <- adae %>%
  filter(
    SAFFL == "Y",
    TRTEMFL == "Y",
    AEDECOD == "Nausea"
  ) %>%
  distinct(USUBJID) %>%
  summarise(
    N = n()
  )

Programming the Subject Count in SAS

proc sql;

  select
    count(distinct usubjid) as n_subjects

  from adae

  where
    saffl = "Y"
    and trtemfl = "Y"
    and aedecod = "Nausea";

quit;

Common Safety Table Denominators

The denominator usually corresponds to the relevant treatment population.

For example:

If 42 of 100 safety subjects experience an AE:

The denominator should be determined from the table specification, not from the number of ADAE records.

ADAE and Analysis Visit

Unlike laboratory or efficacy BDS datasets, adverse events are not naturally visit-based.

An event can begin on any day.

Therefore, ADAE commonly emphasizes:

• Start date
• End date
• Analysis day
• Treatment period
• Event occurrence

rather than forcing every event into a nominal visit structure.

Time-to-Onset Analysis

ADAE can support analyses of time to first adverse event.

For a qualifying event:

This can then be summarized across subjects.

Duration of Adverse Events

If start and end dates are available:

The resulting variable can support descriptive summaries of event duration.

For example:

First Dose vs. Randomization

An important distinction in safety analyses is whether timing is referenced to:

• Randomization
• First dose
• First exposure
• Start of treatment period

These dates may not always be identical.

Baseline Adverse Events

A subject may have an AE before the first dose.

For example:

These events should remain distinguishable in ADAE even if they are not included in the primary TEAE table.

Baseline and Worsening

A pre-treatment event can complicate safety analysis if its severity changes.

For example:

The study may define the worsening event as treatment-emergent.

This requires an explicit derivation rule.

Ongoing Events at Treatment End

Consider:

The event is ongoing at treatment end.

Depending on the safety analysis definition, it may continue into a post-treatment follow-up period.

ADAE and Data Cutoff

Clinical-trial analyses are performed at a data cutoff.

The ADAE dataset therefore reflects the information available at that cutoff.

This matters because:

• An event may still be ongoing.
• An end date may not yet be available.
• A coding update may occur after an earlier cutoff.
• A serious-event classification may change during follow-up.

ADAE and Database Lock

At database lock, the analysis dataset should represent the locked clinical data according to the applicable analysis specifications.

The programmer should not manually "fix" clinical values in ADAE simply because they appear unexpected.

Unexpected source values should be investigated through the appropriate clinical-data-management and programming processes.

ADAE Quality-Control Checklist

Independent QC Programming

A strong QC process should not simply duplicate the production program line for line.

If both programs contain the same logic error, identical results do not prove correctness.

Useful independent checks include:

• SQL-based record counts
• Independent R calculations
• Subject-level frequency checks
• Manual review of boundary cases
• Comparison against source listings
• Independent derivation of selected flags

Example Independent TEAE Check in R

teae_check <- adae %>%
  mutate(
    expected_teae = case_when(
      !is.na(ASTDT) &
      !is.na(TRTSDT) &
      ASTDT >= TRTSDT ~ "Y",
      TRUE ~ "N"
    )
  ) %>%
  filter(
    TRTEMFL != expected_teae
  ) %>%
  select(
    USUBJID,
    AESEQ,
    AEDECOD,
    ASTDT,
    TRTSDT,
    TRTEMFL,
    expected_teae
  )

For a simplified study, an empty result may be expected.

For a production study, however, the expected rule may be more sophisticated than this example.

Traceability Example

Suppose a safety table reports:

A reviewer should be able to determine:

1. Which 42 subjects were counted
2. Which ADAE records qualified
3. Which TEAE rule was applied
4. Which preferred term was used
5. Which treatment assignment was used
6. Which population denominator was used

This is the practical meaning of analysis-data traceability.

ADAE and Table Shells

Before finalizing ADAE, review the planned safety tables.

Ask:

• Does the table require TEAEs?
• Does it require serious AEs?
• Does it require related AEs?
• Does it require worst severity?
• Does it require treatment discontinuations?
• Does it require death-related events?
• Does it require subject incidence rather than event counts?

These questions determine which ADAE variables and flags are needed.

ADAE and SAP Alignment

The SAP is particularly important because it defines the statistical meaning of the safety summaries.

For example, the SAP may specify:

• Safety population
• TEAE period
• Definition of related AE
• Severity summary
• Handling of multiple occurrences
• Handling of missing severity
• Handling of partial dates
• Treatment assignment convention

The ADAE derivation should implement those decisions.

ADAE and Define-XML

The final ADaM dataset should be documented in the study metadata.

This includes information about:

• Variable labels
• Variable origins
• Computational methods
• Controlled terminology
• Value-level metadata where applicable
• Derivation descriptions

A reviewer should be able to understand how important analysis variables were created.

Variable Origin

For example:

What Makes a Good ADAE Dataset?

A high-quality ADAE dataset should be:

• Traceable: each analysis record can be traced to source data.
• Reproducible: derivations can be regenerated from documented rules.
• Analysis-ready: planned safety outputs can be generated without repeated manual manipulation.
• Consistent: treatment, population, and event definitions are applied uniformly.
• Reviewable: programmers and statisticians can understand the derivations.
• Validated: important values and flags have independent QC.

ADAE vs. SDTM AE

ADAE vs. ADSL

ADAE Is Not Just a Copy of AE Plus ADSL

Although much of ADAE can be traced directly to AE or ADSL, the purpose of ADAE is analysis readiness.

That may require:

• Date conversion
• Day calculations
• Treatment-period derivations
• TEAE classification
• Relatedness grouping
• Occurrence flags
• Analysis population flags
• Study-specific safety indicators

These derivations transform standardized source information into analysis-ready information.

Worked Example: Complete ADAE Derivation

Consider Subject 101.

The analysis start date is:

The analysis end date is:

The analysis start day is:

The analysis end day is:

The event duration is:

Because the event begins after treatment starts, it would satisfy the simple post-treatment onset criterion:

subject to the actual study-specific TEAE definition.

Worked Example: Pre-Treatment Event

Now consider Subject 102.

The event starts before treatment:

Therefore, it is not treatment-emergent under a simple onset-based rule.

However, if the same event worsens after treatment, the final classification may depend on the study's worsening rule.

Worked Example: Post-Treatment Event

Suppose:

The event occurs after treatment end.

Whether it is included in the primary TEAE analysis depends on the defined post-treatment safety window.

If the window ends March 31, it would not qualify.

If the window extends 30 days beyond treatment end, it may qualify.

The Importance of the Analysis Window

The same clinical event can therefore produce different results under different safety definitions.

This is why the analysis window must be explicitly defined.

ADAE and Multiple Treatments

For studies with multiple treatment periods, a subject may have:

The programmer may need to determine which treatment period was active when the event began.

This may require comparing:

• Event start date
• Period start date
• Period end date
• Actual exposure

The implementation should be based on the study design rather than a generic one-period assumption.

ADAE and Rescue Medication

Rescue medication can complicate the interpretation of adverse events.

For example, a subject may experience nausea, receive rescue medication, and then report a subsequent event.

ADAE records the AE.

Concomitant-medication analysis records the rescue medication.

The relationship between the two may be investigated but should not be collapsed into one dataset.

ADAE and Treatment-Emergent Abnormalities

An abnormal laboratory result and an AE are separate concepts.

For example:

A clinical event may correspond to a laboratory abnormality, but the two records should remain traceable to their respective sources.

Output Validation From ADAE

One of the strongest QC techniques is to reproduce selected safety summaries directly from ADAE.

For example:

This calculation should agree with the corresponding production table.

Subject-Level Incidence Algorithm

A general conceptual algorithm is:

Why ADAE Is Central to Safety Programming

ADAE is the bridge between individual clinical adverse-event observations and the aggregate safety conclusions presented in a clinical study report.

It connects:

A well-designed ADAE dataset therefore reduces the amount of ad hoc logic needed in downstream tables and listings.

Practical ADAE Development Workflow

Final ADAE Checklist

Common ADAE Mistakes

1. Simply copying SDTM AE into ADAE. ADAE generally requires analysis context and derivations.
2. Joining ADSL without checking uniqueness. A duplicated ADSL subject can duplicate every AE record.
3. Calling every post-dose AE a TEAE. The actual TEAE definition may include additional rules.
4. Ignoring pre-treatment events. Some may become treatment-emergent because of worsening.
5. Hard-coding a post-treatment window. The window must come from the study-specific analysis definition.
6. Confusing severity and seriousness. They represent different clinical concepts.
7. Counting event records instead of subjects. Safety incidence generally requires distinct-subject counting.
8. Deriving worst severity using alphabetical sorting. Severity requires an explicit ordinal definition.
9. Discarding AESEQ. This weakens source traceability.
10. Inventing complete dates from partial dates. Date imputation must follow the approved rule.
11. Ignoring treatment periods. Complex designs may require period-specific treatment assignment.
12. Failing to reconcile ADAE to safety outputs. A technically valid dataset can still implement an incorrect analysis rule.

The Most Important Concept

The most important idea when creating ADAE is that the dataset is not merely a storage location for adverse events.

It is an analysis layer.

The source AE record tells you what was reported.

ADAE adds the analytical context needed to answer questions such as:

• Was the event treatment-emergent?
• Which treatment should be used in the analysis?
• When did the event occur relative to treatment?
• Was it serious?
• What was its severity?
• Was it considered related?
• Did it lead to treatment interruption or discontinuation?
• Should this occurrence count toward subject incidence?

Those questions are what transform the source event data into an analysis-ready safety dataset.

References

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

CDISC. Study Data Tabulation Model (SDTM) and SDTM Implementation Guide. Clinical Data Interchange Standards Consortium.

CDISC. ADaM Occurrence Data Structure (OCCDS). Clinical Data Interchange Standards Consortium.

U.S. Food and Drug Administration. Study Data Technical Conformance Guide. FDA Center for Drug Evaluation and Research.

U.S. Food and Drug Administration. Providing Regulatory Submissions in Electronic Format — Standardized Study Data. FDA.