ADSL: The Subject-Level Analysis Dataset

Introduction

The ADSL, or Subject-Level Analysis Dataset, is one of the most important datasets in an ADaM-based clinical trial submission.

If a clinical trial contains thousands or millions of observations across laboratory tests, adverse events, vital signs, ECGs, questionnaires, tumor assessments, concomitant medications, and exposure records, ADSL provides the subject-level framework that connects those observations to the analysis populations, treatment assignments, dates, and other subject characteristics needed for statistical reporting.

The central structural rule is simple:

That rule makes ADSL fundamentally different from many other analysis datasets.

For example, an adverse-event analysis dataset can contain many records per subject because a subject may experience multiple adverse events. A laboratory analysis dataset can contain many records per subject because a subject can have many laboratory tests at many visits. ADSL, in contrast, is subject-level.

What Does ADSL Stand For?

ADSL stands for:

The name reflects both its content and its structure.

It is an ADaM dataset designed around the subject as the primary unit of analysis.

Where ADSL Fits in the CDISC Data Flow

A simplified clinical-trial data flow is:

The relationship is not necessarily a single linear transformation.

A typical analysis environment may contain several source datasets and derivations, with ADSL serving as a common subject-level source for many downstream analyses.

Why Is ADSL So Important?

Consider a safety table showing treatment-emergent adverse events.

The event dataset tells us what happened to subjects.

But the analysis also needs to know:

• Which treatment each subject received
• Which subjects belong to the Safety Population
• Which treatment period applies
• When treatment started
• When treatment ended
• Relevant demographic characteristics

Those subject-level variables are often supplied by ADSL.

The same principle applies to efficacy.

An efficacy dataset may contain repeated tumor measurements, questionnaire scores, or laboratory-derived endpoints. The analysis still needs a consistent subject-level definition of treatment, population, and relevant dates.

The One-Record-Per-Subject Rule

The defining structural characteristic of ADSL is:

For example, suppose a study contains 500 randomized subjects. If all 500 subjects are represented in the ADSL analysis environment, ADSL would generally contain 500 subject-level records.

There should not be multiple ADSL records simply because a subject has multiple visits or multiple adverse events.

ADSL Is Not a Visit-Level Dataset

This distinction is fundamental.

Suppose Subject 001 has five visits. A visit-level dataset might contain:

ADSL would not contain five records for this subject.

Instead, ADSL contains subject-level information such as:

The repeated measurements belong in an appropriate longitudinal analysis dataset.

Typical ADSL Variables

ADSL commonly contains several categories of variables.

The exact variables included in a study-specific ADSL depend on the protocol, Statistical Analysis Plan, analysis specifications, and regulatory submission requirements.

ADSL Variable Classes

A useful way to understand ADSL is to divide variables into several broad classes.

Identifiers: STUDYID, USUBJID, and SUBJID

Identifiers are among the most important variables in ADSL because they allow records to be linked across datasets.

For example:

STUDYID    USUBJID        SUBJID
ABC123     ABC123-001-01  01
ABC123     ABC123-001-02  02
ABC123     ABC123-001-03  03

The USUBJID is particularly important because analysis datasets commonly use it as the subject-level key.

Planned Treatment vs. Actual Treatment

Treatment variables require careful attention because the treatment a subject was planned to receive is not necessarily identical to the treatment the subject actually received.

For example:

Subject 002 was planned for Drug A but actually received placebo.

Whether a particular analysis uses planned or actual treatment is determined by the analysis specification.

Character and Numeric Treatment Variables

ADaM datasets commonly contain both character and numeric representations of categorical variables.

For treatment, an example is:

The numeric treatment code can be useful for statistical procedures, while the character variable provides the display value.

Treatment Sequence and Period Variables

More complicated studies may contain multiple treatment periods.

Examples include:

• Crossover studies
• Extension periods
• Rescue treatment
• Open-label extensions
• Multiple treatment phases

A study may therefore require additional treatment variables such as:

TRT01P
TRT01A
TRT02P
TRT02A
TRT01PN
TRT01AN
TRT02PN
TRT02AN

The exact treatment structure must follow the study-specific analysis requirements.

Analysis Population Flags

Population flags are among the most useful variables in ADSL.

A flag typically contains:

and often:

For example:

Why Population Flags Matter

Different analyses may use different populations.

The precise definitions must come from the protocol, SAP, and analysis specifications.

Example: Safety Population Flag

Suppose the study defines the Safety Population as all subjects who received at least one dose of study treatment.

Conceptually:

A programmer might derive this from treatment exposure information rather than simply copying a randomization flag.

Important Population-Flag Pitfall

A common mistake is to assume that all analysis populations are nested.

For example, a subject may satisfy one population definition but not another.

The following assumption is unsafe:

unless the study's population definitions actually establish that relationship.

Always derive each flag from its documented definition.

Dates in ADSL

Dates are central to clinical-trial analysis.

ADSL may contain dates associated with:

• Reference start
• Reference end
• Randomization
• First treatment
• Last treatment
• Study completion
• Early termination
• Death
• Other important study milestones

The exact set depends on the study.

Character Dates vs. Analysis Dates

SDTM commonly contains ISO 8601 character date/time variables such as RFSTDTC.

Analysis datasets may derive numeric SAS dates or equivalent date representations for analysis.

For example:

RFSTDTC = "2026-01-15"

TRTSDT = 2026-01-15

The character date preserves the source representation, while the analysis date supports calculations.

Calculating Study Day

If an analysis date is measured relative to treatment start, a common calculation is conceptually:

For example, if treatment begins on January 15 and an assessment occurs on January 22:

The exact study-day convention must follow the analysis specification.

Treatment Start and End Dates

Treatment dates are frequently used by downstream analysis datasets.

For example:

Treatment dates are particularly important for defining treatment-emergent events and time-relative analyses.

Treatment Duration

If treatment begins on date \(D_s\) and ends on date \(D_e\), a simple inclusive duration calculation is:

For example:

The exact derivation may differ when exposure is interrupted, treatment is recorded at the dose level, or the analysis uses exposure records rather than only treatment dates.

Demographic Variables

ADSL often contains demographic characteristics needed for baseline tables and subgroup analyses.

Examples include:

The definition of each variable should be consistent with the source data and analysis specifications.

Baseline Variables in ADSL

ADSL may also contain subject-level baseline measurements.

Examples include:

• Baseline weight
• Baseline height
• Baseline body mass index
• Baseline disease characteristics
• Baseline laboratory characteristics
• Baseline disease stage

For example:

If weight is 80 kg and height is 1.75 m:

Whether a derived baseline value belongs in ADSL or another analysis dataset depends on how it is used.

Baseline Is an Analysis Concept

One of the most important lessons for new ADaM programmers is that baseline is not always simply the first record in the dataset.

A study may define baseline as:

• The last non-missing assessment before first dose
• The last assessment before randomization
• The last assessment before treatment
• A protocol-specific reference measurement

The appropriate definition must be implemented exactly as specified.

Disposition Variables

ADSL often contains subject-level disposition information.

Examples include:

These variables allow disposition tables and listings to be constructed from a consistent subject-level framework.

ADSL and Exposure

Exposure information is another important component of the subject-level analysis environment.

Depending on the study, ADSL may contain variables representing:

• First treatment date
• Last treatment date
• Treatment duration
• Total dose
• Average daily dose
• Exposure categories
• Treatment-emergent analysis windows

Detailed dose-level records may instead reside in an exposure analysis dataset.

ADSL and Adverse Events

An adverse-event analysis dataset such as ADAE may contain multiple records per subject.

For example:

ADSL remains:

The ADAE record can therefore be associated with subject-level treatment and population information through USUBJID.

ADSL and Laboratory Data

A laboratory analysis dataset may contain many records for a single subject.

For example:

USUBJID   PARAM     AVISIT       AVAL
001       ALT       Baseline     22
001       ALT       Week 4       27
001       ALT       Week 8       31
001       AST       Baseline     19
001       AST       Week 4       24
001       AST       Week 8       26

ADSL supplies the subject-level context.

A downstream analysis might combine ADLB with ADSL using:

proc sort data=adsl;
  by usubjid;
run;

proc sort data=adlb;
  by usubjid;
run;

data adlb2;
  merge adsl(in=a)
        adlb(in=b);
  by usubjid;

  if b;
run;

The if b; statement keeps the laboratory observations while bringing in subject-level ADSL variables.

Why ADSL Should Usually Be Created Early

ADSL is often developed early in the ADaM programming process because many downstream datasets depend on it.

ADSL and the Subject-Level Structure of ADaM

ADaM emphasizes analysis-ready data and traceability.

ADSL provides a natural location for variables that describe the subject as a whole rather than an individual measurement or event.

ADSL vs. BDS

A common conceptual distinction is between ADSL and the Basic Data Structure (BDS).

ADSL is subject-level.

A BDS dataset generally represents analysis observations, often with one or more records per subject and parameter.

ADSL vs. OCCDS

ADSL is also different from occurrence data structures such as those used for adverse events or concomitant medications.

An occurrence dataset can have multiple records for each subject.

ADSL should not duplicate those occurrences.

Instead:

ADSL Source Data

ADSL is frequently derived from multiple SDTM domains and other appropriate sources.

Examples include:

The source is not always a single SDTM domain.

A major part of ADaM programming is combining source information into a coherent analysis-ready subject-level record.

Example: Building ADSL From DM and EX

Suppose DM contains:

USUBJID       RFSTDTC
ABC-001-01    2026-01-15
ABC-001-02    2026-01-17

and EX contains treatment exposure:

USUBJID       EXTRT     EXSTDTC      EXENDTC
ABC-001-01    Drug A    2026-01-15   2026-04-20
ABC-001-02    Placebo   2026-01-17   2026-03-15

The ADSL derivation might produce:

Why You Should Not Simply Merge Every SDTM Domain Into ADSL

A common beginner mistake is to think:

That is not how ADSL should be conceptualized.

Many SDTM domains have multiple records per subject.

A naive merge can therefore multiply records.

For example, if Subject 001 has:

• 5 adverse events
• 20 laboratory records
• 10 vital-sign records
• 4 concomitant medications

a careless merge can create a Cartesian-like multiplication of observations.

The One-to-One vs. One-to-Many Problem

Suppose ADSL contains one record:

USUBJID    TRT01A
001        Drug A

and ADAE contains three records:

USUBJID    AESEQ
001        1
001        2
001        3

A one-to-many relationship is expected.

After joining ADSL to ADAE, the subject-level variables are repeated across the three ADAE records.

That is appropriate for a downstream event dataset. It is not appropriate to create three ADSL records.

ADSL Derivation Workflow

Establishing the ADSL Subject Population

Before deriving variables, the programmer must determine which subjects should appear in ADSL.

A common source is DM because it provides the subject-level study population.

However, the exact population represented in ADSL should follow the study's ADaM specification.

The important point is that the programmer should explicitly define the subject-level master dataset rather than allowing the population to emerge accidentally from a series of merges.

SAS: Starting ADSL From DM

proc sort data=sdm.dm
          out=dm;
  by usubjid;
run;

data adsl;
  set dm;

  keep
    studyid
    usubjid
    subjid
    age
    sex
    race
    rfstdtc
    rfendtc
  ;
run;

This creates a starting subject-level dataset.

Additional variables can then be derived from appropriate sources.

SAS: Adding Treatment Information

Suppose treatment information has already been summarized to one record per subject.

proc sort data=ex_summary;
  by usubjid;
run;

data adsl;
  merge adsl(in=a)
        ex_summary;
  by usubjid;

  if a;
run;

The critical requirement is that ex_summary is also one record per subject.

Checking the ADSL Key

One of the most important quality-control checks is verifying that USUBJID is unique.

proc sort data=adsl
          out=adsl_check
          nodupkey
          dupout=adsl_duplicates;
  by usubjid;
run;

If adsl_duplicates is not empty, the ADSL structure requires investigation.

Record-Count Validation

Suppose the study has 642 subjects represented in the intended ADSL population. The programmer should be able to reconcile:

to the expected subject population.

proc sql;
  select count(*) as n_records,
         count(distinct usubjid) as n_subjects
  from adsl;
quit;

For a valid one-record-per-subject dataset:

Deriving Treatment Flags

A common pattern is to derive a treatment flag based on whether the subject received treatment.

data adsl;
  set adsl;

  if not missing(trtsdt) then
    saffl = "Y";
  else
    saffl = "N";
run;

This is only an illustrative programming pattern.

The actual Safety Population definition must follow the study-specific analysis specification.

Deriving Treatment Duration in SAS

data adsl;
  set adsl;

  if nmiss(trtsdt,trtedt)=0 then
    trtdurd = trtedt - trtsdt + 1;
run;

The +1 reflects an inclusive duration convention.

Whether this exact convention is appropriate must be confirmed against the analysis specification.

Deriving Analysis Flags From Subject-Level Criteria

Suppose the analysis specification defines an analysis population based on randomization and availability of relevant analysis data.

The programmer might implement the logic in stages.

data adsl;
  set adsl;

  if randfl = "Y" then
    ittfl = "Y";
  else
    ittfl = "N";
run;

The code is simple. The difficult part is ensuring that the definition represented by the code is exactly the one required by the study.

Do Not Hide Complex Derivations in One Line

A population flag can appear trivial but have complicated underlying logic.

For example, a Per-Protocol flag may depend on:

• Major protocol deviations
• Treatment compliance
• Eligibility
• Minimum follow-up
• Availability of required endpoint data

Such derivations should be documented clearly rather than compressed into opaque programming.

R Implementation

ADSL can also be created in R using packages such as dplyr.

library(dplyr)

adsl <- dm %>%
  select(
    STUDYID,
    USUBJID,
    SUBJID,
    AGE,
    SEX,
    RACE,
    RFSTDTC,
    RFENDTC
  )

Additional subject-level sources can then be summarized before joining.

Summarizing Exposure Before Joining to ADSL

ex_summary <- ex %>%
  group_by(USUBJID) %>%
  summarise(
    TRTSDT = min(EXSTDTC, na.rm = TRUE),
    TRTEDT = max(EXENDTC, na.rm = TRUE),
    .groups = "drop"
  )

The important feature is that the resulting dataset has one row per USUBJID.

Joining Subject-Level Sources in R

adsl <- adsl %>%
  left_join(
    ex_summary,
    by = "USUBJID"
  )

The same structural principle applies in R as in SAS:

Do not join a many-record-per-subject source directly into ADSL unless the relationship and resulting structure are explicitly controlled.

Checking Uniqueness in R

adsl %>%
  count(USUBJID) %>%
  filter(n > 1)

The expected result should contain no subjects with more than one ADSL record.

Checking Missing Treatment Assignments

adsl %>%
  summarise(
    n_subjects = n(),
    n_missing_trt = sum(is.na(TRT01P))
  )

Unexpected missing treatment assignments should be investigated rather than silently replaced.

ADSL and Treatment-Emergent Concepts

ADSL often supplies the treatment dates needed by downstream datasets.

For an adverse event occurring on date \(D_{AE}\), treatment start date \(D_{TRT}\), and treatment end date \(D_{END}\), a simplified treatment relationship might be:

Additional treatment-emergent definitions may involve pre-treatment periods, washout windows, partial dates, and other study-specific rules.

ADSL and Baseline Flags in Other Datasets

ADSL can provide dates and subject-level context used to derive baseline flags in BDS datasets.

For example, an ADLB record may need to determine whether a laboratory assessment occurred before treatment.

The analysis dataset can use ADSL's treatment date to support the derivation.

data adlb;
  merge adlb(in=a)
        adsl(keep=usubjid trtsdt);
  by usubjid;

  if a;

  if adt < trtsdt then
    ablfl = "Y";
run;

Again, the actual baseline definition may be more sophisticated.

ADSL and Analysis Windows

ADSL dates can also support analysis-window calculations.

For example, if an analysis is defined relative to first dose:

A downstream dataset can then derive visit windows based on ADY.

This demonstrates why ADSL dates are not merely descriptive variables. They can become fundamental inputs to downstream derivations.

ADSL and Traceability

A key ADaM principle is that derived analysis values should be traceable.

For ADSL, traceability means being able to explain where an important variable came from and how it was derived.

ADSL and the Analysis Data Model

ADSL is part of the broader ADaM framework.

Other analysis datasets may include:

• ADAE — adverse events
• ADLB — laboratory data
• ADVS — vital signs
• ADCM — concomitant medications
• ADMH — medical history
• ADTTE — time-to-event analysis
• ADQS — questionnaire data
• ADTR — tumor response or tumor-related analysis data

Not every study uses every dataset, and naming conventions can vary according to the study's analysis model.

ADSL as the Parent Dataset

It is useful to visualize the relationship conceptually:

The relationship is best understood as a subject-level context layer rather than as a requirement that every downstream dataset literally merge every ADSL variable.

Controlled Terminology and ADSL

Categorical variables in ADSL should be consistent with the study's controlled terminology and analysis specifications.

Examples include:

• Sex categories
• Race categories
• Ethnicity categories
• Treatment labels
• Analysis population flags
• Disposition categories

Character labels and numeric codes should remain consistent wherever the same analysis concept is used.

Why Numeric Treatment Codes Matter

Suppose the treatment groups are:

The numeric variable can be useful for ordering and analysis, while the character variable provides the readable label.

Analysis Population Denominators

ADSL population flags are often directly related to denominators used in tables.

Suppose:

• 100 subjects are randomized
• 98 subjects receive at least one dose
• 95 subjects meet the primary efficacy population definition
• 90 subjects meet the per-protocol criteria

Then ADSL may contain:

Those counts should reconcile to the corresponding analysis flags.

Population-Reconciliation Programming

proc freq data=adsl;
  tables
    randfl
    saffl
    ittfl
    ppfl
    / missing;
run;

This is one of the simplest but most valuable ADSL validation steps.

Treatment-by-Population Checks

Population flags should also be reviewed by treatment.

proc freq data=adsl;
  tables trt01p*saffl
         trt01p*ittfl
         trt01p*ppfl
         / missing norow nocol nopercent;
run;

This can reveal unexpected treatment imbalances caused by derivation errors.

ADSL Data Quality Checks

A strong ADSL validation process should include structural, derivational, and clinical checks.

Independent Programming Validation

ADSL is an excellent candidate for independent QC because many downstream datasets depend on it.

A QC programmer can independently reproduce:

• Subject counts
• Treatment assignments
• Treatment dates
• Population flags
• Disposition categories
• Key baseline characteristics

The production and QC programs should not simply duplicate the same programming logic without independent review.

Common ADSL Programming Errors

1. Creating more than one record per subject. This is usually caused by merging a subject-level dataset with a many-record-per-subject source without first summarizing it.
2. Using the wrong treatment variable. Planned and actual treatment are not interchangeable.
3. Deriving population flags from convenience variables. Population membership should follow the documented analysis definition.
4. Using the wrong treatment start date. First exposure, randomization date, first dose date, and study reference date are not necessarily the same.
5. Ignoring partial dates. Character ISO dates may not always contain complete dates.
6. Overwriting source information unnecessarily. Source-derived variables should remain traceable.
7. Hard-coding treatment labels. Treatment values should be controlled and specification-driven.
8. Creating variables that belong in downstream datasets. ADSL should remain subject-level rather than becoming a repository for every analysis calculation.
9. Failing to document derivations. A derived population flag should have a clear rationale.
10. Failing to reconcile denominators. ADSL population counts should agree with study-level expectations.

The Difference Between Source Data and Analysis Data

ADSL is not simply a copy of SDTM DM.

DM may provide much of the subject-level foundation, but ADSL can add derived variables required for analysis.

For example:

This distinction is central to understanding ADaM.

Example: From DM to ADSL

ADSL and the Define-XML Metadata Layer

For a regulatory submission, dataset metadata should explain the variables, their labels, origins, derivations, and other relevant metadata.

A well-constructed ADSL therefore requires more than a technically correct SAS dataset.

The metadata and derivation documentation should communicate:

• What each variable means
• Where it came from
• How it was derived
• What controlled terminology applies
• What role it plays in analysis

ADSL and Reviewer Traceability

A reviewer should be able to move conceptually from:

The exact implementation depends on the study and submission package, but the goal is transparent analysis traceability.

A Practical ADSL Specification

A study-specific ADSL specification might look like this:

ADSL Derivation Documentation

A good derivation specification should explain not only what is being derived, but why.

For example, instead of:

SAFFL = "Y" if TRTSDT is nonmissing

the specification should state the study-defined rule, source data, relevant exceptions, and treatment-emergent logic.

The programming code then implements that documented rule.

ADSL and Partial Dates

Clinical-trial dates are not always complete.

An SDTM date might contain:

2026-01
2026
2026-01-15

These values have different levels of precision.

A programmer should not silently convert an incomplete date into a precise date without following the specified imputation rule.

ADSL and Study Completion

Subject-level study completion can depend on several sources.

For example:

• Scheduled completion
• Early withdrawal
• Lost to follow-up
• Death
• Protocol-defined discontinuation

A disposition derivation should reconcile the relevant disposition records rather than simply selecting the first or last record without considering the study rules.

ADSL and Death Information

When relevant to the study, subject-level death information can support time-to-event analyses and disposition.

A death date may originate from a death/disposition source and may be subject to reconciliation across multiple sources.

The analysis dataset should use the prespecified source hierarchy and reconciliation rules.

ADSL and Treatment Compliance

Some studies require subject-level treatment compliance variables.

For example:

Whether this belongs in ADSL depends on whether the resulting value is a subject-level analysis variable needed across analyses.

Detailed dose records should generally remain in the appropriate exposure analysis structure.

ADSL and Subgroup Variables

ADSL is also a natural location for subject-level subgroup variables used across multiple analyses.

Examples might include:

• Age group
• Geographic region
• Disease stage
• Baseline disease severity
• Biomarker category
• Prior treatment category

For example, age may be categorized as:

The exact cut points must be prespecified.

Why Derived Subgroups Need Careful Documentation

A derived subgroup can materially affect statistical conclusions.

For example, changing the definition from:

to:

changes the population assigned to each subgroup.

Therefore, seemingly small ADSL derivation changes can affect multiple tables and figures.

ADSL as a Source for Demographic Tables

A standard demographics table can often be generated directly from ADSL.

For example:

proc means data=adsl n mean std median min max;
  where saffl = "Y";
  class trt01p;
  var age;
run;

Categorical variables can similarly be summarized using frequency procedures.

proc freq data=adsl;
  where saffl = "Y";
  tables trt01p*sex;
run;

The exact population should follow the table specification.

ADSL and Denominator Control

A particularly important role of ADSL is helping define denominators.

For a binary endpoint, the denominator may be:

For safety:

This makes population flags critical to the reproducibility of statistical tables.

ADSL and Downstream Dataset Merging

A common downstream pattern is:

where one ADSL record can correspond to many ADLB records.

This relationship should be understood before programming any merge.

A Safe SAS Merge Pattern

proc sort data=adsl;
  by usubjid;
run;

proc sort data=adlb;
  by usubjid;
run;

data adlb_analysis;
  merge adlb(in=a)
        adsl(in=b);
  by usubjid;

  if a;
run;

This retains the observations from ADLB while attaching subject-level ADSL variables.

Why Merge Order Matters

The merge:

merge adsl adlb;

does not automatically make the resulting dataset conceptually "ADSL."

The resulting structure is determined by the incoming observations and merge logic.

The programmer must always verify:

• Which dataset defines the output population
• Which dataset contributes repeated records
• Whether the BY variables are unique
• Whether observations are being unintentionally dropped
• Whether observations are being unintentionally duplicated

ADSL Validation With Subject-Level Counts

A useful validation table is:

Subject-Level Reconciliation

One of the strongest ADSL QC approaches is to select individual subjects and trace their variables back to source data.

For example:

ADSL QC: Boundary Subjects

Boundary subjects are especially useful for validation.

Examples include:

• Subject randomized but never treated
• Subject treated only once
• Subject with treatment interruption
• Subject with an incomplete treatment date
• Subject who withdrew early
• Subject with a major protocol deviation
• Subject near a subgroup boundary

These subjects are often more informative for QC than randomly selected "ordinary" subjects.

ADSL and Protocol Deviations

Protocol deviations may affect population flags, particularly per-protocol or other analysis populations.

The programmer should not independently decide which deviations exclude a subject.

Instead, the analysis population should follow the prespecified protocol deviation categorization and SAP rules.

ADSL and Blinding

In blinded studies, ADSL programming may need to distinguish variables that can be generated while blinded from variables requiring unblinded treatment information.

For example, certain subject identifiers and demographic variables can often be prepared without revealing treatment assignment, whereas final actual treatment derivations may require access to treatment information.

The programming workflow should follow the study's blinding and data-review plan.

ADSL in Interim Analyses

ADSL can also be produced for interim analyses.

However, the subject population, treatment information, data cut, and analysis rules must correspond to the interim analysis specification.

An interim ADSL and final ADSL may therefore differ because the underlying data cut and analysis population can differ.

Data Cutoff Dates

A clinical study may have a data cutoff date:

Variables representing events or assessments after the cutoff should not silently enter a frozen analysis.

The handling of cutoff dates should be explicit in the analysis programming specifications.

ADSL and Reproducibility

A high-quality ADSL should be reproducible.

If the source data and approved derivation specifications are unchanged, a fresh execution of the program should reproduce the same subject-level dataset.

This requires:

• Controlled source versions
• Stable derivation logic
• Documented population rules
• Documented treatment rules
• Documented date handling
• Validated programming

ADSL Programming Checklist

Common ADSL Questions

Should ADSL contain one record for every randomized subject?

Not automatically.

The exact subject population represented in ADSL is study-specific and should follow the ADaM specification.

Can ADSL contain subjects who were not randomized?

Potentially, yes, depending on the study and the intended subject-level analysis population.

The answer should come from the analysis specification rather than from an assumption that ADSL must equal the randomized population.

Can ADSL contain multiple treatment periods?

Yes.

Complex studies may require multiple treatment variables or period-specific subject-level variables.

Should every variable from DM be copied into ADSL?

Not necessarily.

ADSL should contain variables needed for the analysis environment and defined by the study's specifications.

Should every ADaM dataset contain all ADSL variables?

No.

Downstream datasets should contain the variables needed for their analysis structure. ADSL provides subject-level information that can be brought into those datasets as appropriate.

ADSL vs. SDTM DM

The Most Important Difference

The fundamental conceptual difference is:

ADSL sits firmly in the second category.

ADSL and Analysis-Ready Thinking

An analysis-ready dataset should reduce the amount of interpretation required by the statistician or reporting programmer.

For example, rather than requiring every downstream programmer to repeatedly determine which subjects received treatment, ADSL can provide a consistent subject-level treatment variable.

Rather than independently recreating population membership for every table, ADSL can provide the approved analysis flags.

This reduces duplication and promotes consistency.

ADSL as a Single Source of Subject-Level Truth

A useful practical concept is:

If treatment assignment is derived independently in ten downstream programs, there are ten opportunities for inconsistency.

If the approved subject-level treatment variable is derived in ADSL and reused, the analysis environment becomes easier to control.

But ADSL Should Not Become a "Junk Drawer"

There is an equally important opposite principle.

ADSL should not become a dataset containing every variable that anyone might possibly need.

Variables should have a clear subject-level analytical purpose.

For example, a highly visit-specific laboratory transformation generally belongs in the appropriate laboratory analysis dataset rather than in ADSL.

A Good ADSL Is Small but Powerful

The goal is not to maximize the number of variables.

The goal is to provide the right subject-level analysis information.

A well-designed ADSL might contain several hundred variables in a complex study, while a simpler study might require considerably fewer.

The appropriate size is driven by analytical requirements, not by a fixed number of columns.

Final ADSL Validation

Before an ADSL dataset is released for downstream programming, verify:

• Exactly one record exists per subject.
• The subject population is correct.
• USUBJID values are unique.
• Treatment assignments are correct.
• Planned and actual treatment are not confused.
• Treatment dates are correct.
• Population flags reconcile to expected counts.
• Demographics reconcile to source data.
• Disposition information is correct.
• Exposure derivations are correct.
• Missing values have been reviewed.
• Partial dates have been handled according to specification.
• Subgroup derivations are correct.
• Variable labels and formats are correct.
• Traceability is documented.
• Independent QC has been completed.

ADSL in a Complete Analysis Workflow

The overall workflow can be summarized as:

The Three Rules to Remember

If you are new to ADaM programming, remember these three rules.

Summary

ADSL is the foundational subject-level dataset within many ADaM analysis environments.

Its defining structural characteristic is:

ADSL commonly provides:

• Subject identifiers
• Demographic characteristics
• Planned treatment
• Actual treatment
• Important study and treatment dates
• Analysis population flags
• Subject-level baseline characteristics
• Disposition information
• Exposure-related variables
• Subject-level subgroup variables

The most important programming challenge is not writing the SAS or R code. It is correctly translating the protocol, SAP, ADaM specifications, source data, and analysis conventions into a consistent subject-level dataset.

Once ADSL is correctly constructed and validated, it becomes a powerful foundation for downstream datasets such as ADAE, ADLB, ADVS, ADCM, ADTTE, and other study-specific analysis datasets.

References

Clinical Data Interchange Standards Consortium (CDISC). Analysis Data Model (ADaM) Implementation Guide.
Clinical Data Interchange Standards Consortium (CDISC). Analysis Data Model (ADaM) v2.1.
Clinical Data Interchange Standards Consortium (CDISC). Study Data Tabulation Model (SDTM) Implementation Guide.
Clinical Data Interchange Standards Consortium (CDISC). CDISC Foundational Standards.
U.S. Food and Drug Administration. Study Data Technical Conformance Guide.