BDS vs. ADaM Dataset Structures

Introduction

One of the most important concepts in ADaM programming is understanding the structure or grain of an analysis dataset. A dataset can contain correct variables and still be unsuitable for an analysis if the records are at the wrong level.

This is where the distinction between ADSL, BDS, and other ADaM structures becomes especially important.

A common misconception is that BDS and ADaM are competing dataset standards. They are not. ADaM is the overall analysis data model, while BDS is one of the standard ADaM structures used to organize analysis observations.

What Is ADaM?

The Analysis Data Model (ADaM) is a CDISC standard for organizing analysis-ready clinical-trial data. Its purpose is not merely to store variables. ADaM is intended to make the relationship between source data, analysis derivations, and statistical results understandable and traceable.

An analysis dataset should therefore allow a reviewer to understand:

• who the subject is;
• what treatment or analysis group applies;
• what was measured or derived;
• when the measurement occurred;
• which baseline was used;
• how change was calculated;
• which records are included in a particular analysis; and
• where important analysis values originated.

ADaM includes standard structures such as ADSL and BDS, as well as structures and approaches for other types of analysis data.

What Is BDS?

BDS stands for Basic Data Structure. It is a general-purpose ADaM structure designed for analysis observations organized around subjects, parameters, and, where applicable, analysis time points.

A useful conceptual representation is:

The exact key depends on the dataset. A BDS dataset may have additional dimensions, and not every BDS dataset uses the same combination of timing variables. The important principle is that the observation grain must be explicitly defined.

The First Question: What Does One Record Represent?

Before programming an ADaM dataset, write a sentence that defines its grain. For example:

This sentence is more useful than simply saying "this is a BDS dataset." It tells the programmer what a unique observation should mean.

ADSL: The Subject-Level Dataset

ADSL is generally the dataset that describes the subject as a whole. It commonly contains one record per subject.

Typical ADSL variables include:

A simplified ADSL might look like this:

USUBJID   TRT01P        AGE   SEX   SAFFL
001       Drug A          58     F       Y
002       Drug A          64     M       Y
003       Placebo         51     F       Y
004       Placebo         69     M       N

There is no Week 4 row for subject 001 in this example because ADSL is not trying to represent the subject's repeated laboratory or efficacy observations.

BDS: Repeated Analysis Observations

Now consider a laboratory parameter such as ALT. A subject can have a baseline value, a Week 2 value, a Week 4 value, and a Week 8 value.

A BDS representation might look like:

Here, one subject has four records for the same parameter. That is exactly the kind of repeated observation pattern for which BDS is particularly useful.

The Relationship Between ADSL and BDS

The relationship is important because many BDS analyses require subject-level information from ADSL. For example, treatment assignment, age, sex, region, or analysis-population flags may be needed when creating a BDS analysis dataset or producing a statistical table or figure.

BDS Is Not "The ADaM Dataset"

Another common misconception is to call BDS the ADaM dataset. There is no single universal "ADaM dataset."

A clinical trial can contain multiple ADaM datasets, each serving a different analysis purpose.

BDS vs. ADSL at a Glance

BDS vs. OCCDS

OCCDS is useful for occurrence-based analyses, where the central analytical object is an event or occurrence rather than a repeatedly measured parameter. Adverse-event analysis is the classic example.

A Simple Mental Model

The BDS Observation Grain

The most important programming decision in a BDS dataset is its observation grain.

Suppose a study analyzes systolic blood pressure. The dataset might have:

as the practical uniqueness concept. For example:

001 + SYSBP + 0
001 + SYSBP + 2
001 + SYSBP + 4
001 + SYSBP + 8

But if the dataset contains multiple records at the same nominal visit because of multiple assessment dates, replicate measures, derived records, or different analysis concepts, additional variables may be needed to define uniqueness.

PARAM and PARAMCD

One of the defining ideas in BDS is that the dataset can contain multiple analysis parameters in a single long-format dataset.

For example:

This means that a single BDS dataset can represent several related analysis parameters.

A simplified structure could therefore be:

The parameter variable tells the analysis system what the numeric value represents.

AVAL: The Analysis Value

For a numeric BDS parameter, AVAL is commonly used for the analysis value.

For example, if the analysis parameter is systolic blood pressure:

means 120 mmHg when the corresponding parameter definition specifies systolic blood pressure in mmHg.

The same BDS dataset could have another parameter where:

represents diastolic blood pressure. The meaning comes from the combination of the parameter definition and value, not from the number alone.

AVALC for Character Analysis Values

Not every analysis parameter is numeric. Categorical or character results can use AVALC.

For example:

Whether a particular analysis should be represented with AVAL, AVALC, or another variable depends on the parameter and the analysis specification.

Baseline, Change, and Percent Change

BDS is particularly useful when the analysis requires derivations from a baseline value.

For a numeric endpoint:

and:

Suppose:

Then:

and:

Baseline Is a Derivation, Not Just a Column

One of the most important BDS programming tasks is defining which observation becomes baseline.

A common convention is the last non-missing, protocol-allowed assessment before the first dose, but the actual study definition may be different.

The baseline rule should be documented in the analysis specification or SAP and implemented consistently.

A Concrete Baseline Example

Suppose subject 001 has three measurements before treatment:

If the study defines baseline as the last eligible non-missing value before first dose, then:

If the Week 4 value is 108:

and:

Analysis Timing Variables

BDS datasets frequently contain both calendar dates and analysis timing variables. Common examples include:

The precise variables used depend on the analysis and dataset specification.

ADT and ADY

Suppose first dose occurred on 01-Jan and the assessment occurred on 29-Jan. If the analysis convention defines treatment day 1 as the day of first dose, then a common relative-day calculation is:

For 29-Jan versus 01-Jan:

The exact day-number convention should always follow the study's analysis specification.

Nominal Visit vs. Actual Timing

Consider a Week 4 assessment collected on Day 30 rather than exactly Day 29. The record might contain:

This preserves both the nominal analysis visit and the actual analysis date. They answer different questions.

Analysis Flags

Analysis datasets often contain flags that identify observations included in a specific analysis.

A common example is ANL01FL. The exact meaning should be defined by the dataset specification.

For example:

if AVISIT = "Week 4" then ANL01FL = "Y";

But that code is only illustrative. In a real study, the analysis flag may depend on baseline availability, visit windows, treatment exposure, duplicate-selection rules, or other prespecified conditions.

What Makes BDS "Analysis Ready"?

A BDS dataset is useful because it brings together the information needed to perform the analysis without repeatedly reconstructing the analysis dataset from raw or SDTM data.

For a typical repeated numeric endpoint, the analysis record may contain:

One BDS Dataset Can Contain Multiple Parameters

Suppose a laboratory BDS contains ALT, AST, bilirubin, and creatinine. The dataset can remain in a long structure:

This is fundamentally different from a wide dataset in which each laboratory test would occupy its own column.

Long vs. Wide Data

For example, a long structure might be:

USUBJID  PARAMCD  AVISIT  AVAL
001       ALT       Week 4    41
001       AST       Week 4    36
001       BILI      Week 4     0.8
001       CREAT     Week 4     1.0

Whereas a wide representation could be:

USUBJID  ALT  AST  BILI  CREAT
001         41     36      0.8     1.0

BDS generally favors the parameterized analysis-observation approach because it supports consistent analysis variables across multiple parameters.

Why BDS Is Useful for Statistical Programming

Suppose the same analysis logic needs to be applied to 20 laboratory parameters. A parameterized BDS structure lets the programmer use common logic for:

• baseline selection;
• change derivation;
• visit selection;
• analysis flags;
• summary statistics; and
• treatment-group reporting.

The parameter definition changes, but the overall analytical pattern remains consistent.

BDS for Vital Signs

A vital-sign BDS might contain:

Each subject can have multiple records for each parameter.

BDS for Laboratory Data

Laboratory analyses are another natural use case. A BDS can support analyses of:

• continuous laboratory values;
• change from baseline;
• shift from baseline;
• categorical toxicity grades;
• normal-range status; and
• other derived laboratory endpoints.

The exact BDS design depends on the analysis requirements. A single study may use multiple analysis parameters and multiple derived variables within the same laboratory analysis dataset.

BDS for Efficacy Endpoints

BDS is also commonly used for repeated efficacy measurements. For example, an oncology analysis may contain:

Depending on the implementation, derived efficacy parameters may be represented as separate parameter records or as derived analysis variables associated with the underlying parameter.

Baseline and Post-Baseline Records

A BDS dataset may contain a baseline record and multiple post-baseline records. For example:

This makes it possible to analyze either the observed value or the derived change, depending on the statistical method.

Why BASE Must Be Consistent

If two post-baseline records for the same parameter use different baseline values without an explicit reason, the resulting CHG and PCHG values can be wrong.

For example, if:

then:

If a programming error instead uses 115 as baseline:

The analysis result changes materially.

Parameter-Level Baseline Selection

Baseline selection can be parameter-specific. For example, the baseline ALT value should generally come from the ALT parameter's eligible observations, not from the patient's baseline AST.

Conceptually:

This is one reason PARAMCD is so important in BDS derivation logic.

Multiple Parameters and Different Units

A BDS dataset can contain parameters with different units, but the analysis specification must make their interpretation unambiguous.

For example:

The values 120 and 72 cannot be interpreted independently of the parameter definition.

Derived Parameters vs. Derived Variables

This distinction can cause confusion.

Suppose a study has an observed hemoglobin parameter and wants to calculate change from baseline. One implementation may retain:

PARAMCD = "HGB"
AVAL    = observed hemoglobin
BASE    = selected baseline hemoglobin
CHG     = AVAL - BASE

Here, CHG is a derived variable associated with the parameter. The exact representation of derived analysis concepts should follow the applicable ADaM implementation and study specification.

DTYPE and Derived Records

Some BDS datasets contain records that are not direct observations but are derived for a specific analytical purpose. The DTYPE variable can be used where appropriate to identify the type of derived record.

The exact values and use of DTYPE should be defined by the applicable ADaM specification and dataset metadata.

Traceability

A major ADaM principle is traceability. An analysis value should be explainable by following the derivation back toward its source.

For example:

Traceability does not mean every analysis variable must be a direct copy of an SDTM variable. It means the derivation should be understandable and documented.

SRCSEQ and Source Traceability Variables

Study implementations may use source variables such as domain, variable, and sequence information to improve traceability. Examples can include:

The exact implementation should follow the study's ADaM metadata and traceability conventions.

BDS Is Not a Copy of SDTM

Another common mistake is to take an SDTM domain and simply rename columns until the result looks like BDS.

SDTM and ADaM serve different purposes.

From SDTM to BDS

A typical conceptual workflow might be:

Example: Building a Laboratory BDS

Suppose the source laboratory data contain:

A BDS representation could be:

Example: Adding Percent Change

For Week 4:

For Week 8:

The BDS therefore allows a statistical programmer to analyze either the observed hemoglobin values or the derived changes, depending on the prespecified analysis.

BDS and Statistical Models

Repeated-measures BDS data are particularly useful for statistical procedures that require observations at multiple analysis times.

For example, a mixed model may analyze:

The exact model depends on the endpoint and SAP. The important point is that the BDS dataset can provide repeated subject-level observations in a structure that maps naturally to the model.

Analysis Visit Selection

A study may have several records near the same nominal visit. For example:

A dataset specification may require selection of one record for a particular analysis. That selection is not inherent in the word BDS. It is an analysis rule.

ANL01FL and Analysis-Specific Selection

Suppose the study selects one Week 4 observation according to a prespecified rule. The selected record might be flagged:

USUBJID  AVISIT  AVAL  ANL01FL
001       Week 4    110     
001       Week 4    108     Y
001       Week 4    109     

Again, the selection rule must be documented. The flag should identify records for the intended analysis, not simply records that happen to look plausible.

BDS and Visit Windows

Clinical trials often define analysis windows around nominal visits. For example, Week 4 might have a permitted window around the target day.

A conceptual rule might classify an assessment based on:

where the lower and upper windows are specified by the analysis plan.

The exact windows should never be invented by the programmer merely because they make the dataset convenient.

BDS Does Not Determine the SAP

This is an important conceptual boundary.

The SAP defines the statistical analysis. The ADaM dataset implements the analysis data needed to perform it.

For example, a BDS dataset does not decide:

• which visit is the primary endpoint;
• which baseline definition applies;
• which population is primary;
• which imputation method is required; or
• which statistical model should be used.

Those decisions come from the protocol, SAP, shells, specifications, and applicable analysis conventions.

Common BDS Variables

Not every BDS dataset contains every variable. The dataset should contain the variables needed for the specific analysis and should conform to the applicable ADaM standard and study metadata.

When Should You Use ADSL Instead of BDS?

Use ADSL when the primary analytical unit is the subject.

Examples include:

• baseline demographic summaries;
• treatment exposure summaries;
• disposition;
• subject-level population counts;
• subject-level treatment assignment; and
• subject-level covariates.

If the analysis asks for one value per subject, ADSL may be the appropriate starting point, although another analysis dataset may still be created for derived endpoints.

When Should You Use BDS?

BDS is generally a strong fit when the analysis is based on repeated or parameterized observations.

Examples include:

• laboratory values over time;
• vital signs over time;
• ECG measurements;
• repeated efficacy measurements;
• change from baseline;
• percent change from baseline;
• repeated categorical assessments; and
• other parameter-oriented analysis observations.

When BDS Is Not the Best Mental Model

If the analysis is fundamentally about individual occurrences or events, another structure may be more appropriate.

For example, an adverse-event analysis is naturally occurrence-oriented:

The central object is the event, not a numeric measurement of a parameter at a repeated analysis visit.

BDS vs. One-Record-Per-Subject Data

A Common Programming Error: Flattening BDS

A programmer may be tempted to create columns such as:

BASE  WEEK4  WEEK8  WEEK12

This can make a dataset look convenient for one specific table, but it loses the natural repeated-observation structure.

A parameterized BDS representation is more naturally:

USUBJID  PARAMCD  AVISIT  AVAL
001       HGB       Week 4     12.4
001       HGB       Week 8     12.1
001       HGB       Week 12    12.0

The latter can be summarized, modeled, plotted, and subset by visit using consistent analysis variables.

Another Common Error: Treating PARAMCD as the Entire Key

PARAMCD identifies the parameter, not the complete observation.

Subject 001 can have:

USUBJID  PARAMCD  AVISIT
001       HGB       Baseline
001       HGB       Week 4
001       HGB       Week 8

All three records have the same PARAMCD. The visit and subject distinguish the observations.

Another Common Error: Ignoring Treatment Structure

Treatment variables often originate in ADSL and are used throughout analysis datasets. A BDS record should be associated with the correct treatment definition for the analysis.

For example, planned and actual treatment can differ.

Which treatment variable is used in a particular analysis should be determined by the SAP and analysis specification.

Programming BDS in SAS

A simplified SAS pattern might begin by sorting the source observations:

proc sort data=source;
  by USUBJID PARAMCD ADT;
run;

Baseline selection might then be implemented using a study-specific rule. For example, a simplified illustration could be:

data bds;
  set source;

  by USUBJID PARAMCD;

  /* Derive analysis value */
  AVAL = VALUE;

  /* Study-specific timing derivation */
  ADY = ADT - TRTSDT + 1;

  /* Additional baseline/change logic would follow */
run;

Calculating CHG in SAS

if n(AVAL BASE) = 2 then
  CHG = AVAL - BASE;

For percent change, the denominator should be checked before division:

if n(AVAL BASE) = 2
   and BASE ne 0
then
  PCHG = (AVAL - BASE) / BASE * 100;

Programming BDS in R

The same concepts can be implemented in R. For example:

bds <- source |>
  dplyr::mutate(
    AVAL = VALUE,
    ADY = as.numeric(ADT - TRTSDT) + 1,
    CHG = AVAL - BASE,
    PCHG = 100 * (AVAL - BASE) / BASE
  )

In production code, baseline derivation and zero-baseline handling should be implemented explicitly rather than assumed.

Grouping and Parameter-Level Derivations in R

bds <- source |>
  dplyr::group_by(USUBJID, PARAMCD) |>
  dplyr::arrange(ADT, .by_group = TRUE) |>
  dplyr::mutate(
    BASE = dplyr::first(AVAL)
  ) |>
  dplyr::ungroup()

The line selecting the first value is only a teaching example. A real study should select baseline according to the prespecified eligibility and timing rules, not simply take the first record.

Creating a BDS Summary

Once BDS is correctly structured, many summaries become straightforward. For example, mean change by treatment and visit can be derived from the analysis records selected for the relevant analysis.

proc means data=bds n mean std;
  where PARAMCD="HGB"
    and ANL01FL="Y";
  class TRT01P AVISIT;
  var CHG;
run;

The statistical method, population, visit selection, and treatment variable must still match the SAP.

BDS and Analysis Tables

A common clinical-trial table may display:

• N;
• number of subjects;
• mean;
• standard deviation;
• median;
• minimum;
• maximum;
• least-squares means;
• standard errors; and
• confidence intervals.

BDS supplies the analysis observations. The table-generation program applies the statistical and reporting rules to those observations.

BDS and Analysis Figures

BDS can also serve as the source for figures such as:

• mean change-from-baseline plots;
• box plots;
• spaghetti or spider plots;
• shift plots;
• laboratory trend plots; and
• other longitudinal displays.

For a longitudinal figure, variables such as USUBJID, ADY, AVAL, PCHG, AVISIT, and treatment assignment may be sufficient depending on the display.

BDS and the Analysis Population

A BDS dataset may contain observations from subjects who are not eligible for every analysis. For example, a subject may be in the safety population but not have a valid post-baseline measurement for a particular efficacy endpoint.

Therefore, the programmer must distinguish:

Missing Data in BDS

Missing data should generally remain missing rather than being silently converted to zero.

For example, if a Week 8 measurement is missing:

A missing measurement does not mean the patient had no change.

Duplicate Records

Duplicate observations are especially important in BDS because repeated records are expected, but unintended duplicate records are not.

For example, two Week 4 records may be legitimate if the analysis specification allows multiple observations. Alternatively, one may need to be selected for the primary analysis.

The programmer should therefore ask:

1. Are both records clinically valid?
2. Are they distinct source observations?
3. Do they represent different analysis concepts?
4. Does the SAP specify a selection rule?
5. Should one record receive an analysis flag?

Unit Conversion

BDS derivations may require unit standardization. Suppose a laboratory value is reported in a source unit that differs from the analysis unit.

If the conversion is:

then the conversion factor C must be documented and validated.

The analysis dataset should make the final analytical unit unambiguous.

Why Units Matter for CHG and PCHG

A unit conversion should generally be resolved before calculating derived quantities that depend on the measurement scale.

For example, if baseline and post-baseline values are represented in different units, calculating:

would be meaningless.

BDS and Derived Categories

Continuous values can sometimes be transformed into categorical analysis variables. For example, change from baseline could be classified as:

The thresholds above are purely illustrative. Actual categorization must come from the protocol, SAP, or analysis specification.

BDS and Shift Analysis

A common laboratory analysis compares baseline categories with post-baseline categories. For example:

The BDS may contain the underlying categorical analysis values needed to create the shift table, although the exact implementation depends on the study's analysis design.

BDS and Time-to-Event Data

Not every endpoint belongs naturally in BDS. A pure time-to-event analysis often requires event indicators and analysis times at the subject level or in another specialized analysis structure.

For example:

The appropriate ADaM structure depends on how the endpoint is defined and what analysis data are needed.

Custom ADaM Structures

Sometimes a standard ADaM structure does not adequately represent an analysis. A study may therefore use a custom analysis dataset.

A custom structure should not be used simply because the programmer prefers a different layout. There should be a clear analytical reason and appropriate documentation.

The Difference Between Structure and Content

This distinction is fundamental.

Structure answers:

• What does a record represent?
• What variables define the observation?
• How are repeated observations organized?

Content answers:

• What clinical endpoint is being analyzed?
• What value is being measured?
• What derivations are required?
• What analysis population is being used?

BDS provides a standard structural pattern, but the study determines the content and derivation logic.

A Useful BDS Design Exercise

Before writing code, complete the following sentence:

For example:

Then identify the variables needed to make that statement true.

BDS Design Checklist

Quality Control: Validate the Grain First

The first QC question should not be "does the dataset have the right number of rows?" It should be:

For a BDS dataset, inspect combinations such as:

USUBJID + PARAMCD + AVISITN

and determine whether duplicates are expected or unexpected. If multiple records are allowed, identify the additional variables that distinguish them.

QC Example: Duplicate Detection in SAS

proc sort data=bds out=bds_check nodupkey;
  by USUBJID PARAMCD AVISITN;
run;

This is a useful diagnostic, but it should not automatically delete records. If duplicates are legitimate, the correct response is to understand the additional grain rather than suppress the observations.

QC Example: Duplicate Detection in R

bds |>
  dplyr::count(USUBJID, PARAMCD, AVISITN) |>
  dplyr::filter(n > 1)

The output identifies combinations requiring review.

QC: Validate Baseline

Select several subjects manually and trace:

1. all eligible pre-treatment observations;
2. the observation selected as baseline;
3. the BASE value on post-baseline records;
4. the CHG calculation; and
5. the PCHG calculation, if applicable.

For example:

If the dataset produces different values, investigate the derivation before using the data for reporting.

QC: Validate Parameter Consistency

For each PARAMCD, confirm that:

• PARAM is consistent;
• units are appropriate;
• AVAL has the expected scale;
• baseline comes from the same parameter;
• CHG uses the same parameter baseline; and
• analysis flags apply according to the parameter-specific rules.

QC: Validate Treatment

Compare treatment variables between ADSL and BDS for sampled subjects. For example:

Any mismatch should be investigated rather than silently corrected in the reporting program.

QC: Validate Analysis Flags

If a table uses:

where ANL01FL="Y";

then QC should establish why each flagged record was selected. The flag should be reproducible from the documented rule.

Common Mistakes

1. Calling BDS and ADaM the same thing. ADaM is the analysis data model; BDS is one standard structure within ADaM.
2. Defining BDS as simply "one row per subject per visit." BDS is parameter-oriented and its exact grain must be defined for the dataset.
3. Using ADSL for repeated measurements. ADSL is generally one record per subject and is not the natural repeated-measure structure.
4. Ignoring PARAMCD. Parameter identity is central to many BDS datasets.
5. Using different baselines for the same parameter without a defined reason. This can invalidate CHG and PCHG.
6. Replacing missing values with zero. Missing is not zero.
7. Assuming AVISIT is the same as actual time. Nominal visit classification and actual analysis timing are different concepts.
8. Deleting duplicates automatically. First determine whether multiple records are legitimate.
9. Copying SDTM into ADaM without analysis derivations. ADaM must support the analysis.
10. Forcing every analysis into BDS. ADSL, OCCDS, and custom structures exist for different analytical needs.
11. Creating flags without documenting their purpose. Every analysis-selection flag should have a defined meaning.
12. Calculating percent change when BASE is zero without a rule. The denominator and handling of zero baseline require explicit specification.

ADSL + BDS + OCCDS: How They Work Together

Together, these structures can support a large portion of a clinical-trial analysis environment. They are complementary rather than mutually exclusive.

Example Clinical-Trial Architecture

The actual dataset names and structures depend on the study and implementation, but the architecture illustrates how different analysis datasets can coexist.

BDS and Metadata

A high-quality BDS implementation should be supported by metadata that explain:

• dataset purpose;
• record structure;
• variable labels and types;
• controlled terminology where applicable;
• derivation algorithms;
• origin;
• source datasets;
• analysis flags;
• parameter definitions; and
• traceability.

The dataset should be understandable to someone who did not write the original program.

Define the Dataset Before Writing the Program

A strong workflow is to create the specification first.

How to Choose Between ADSL and BDS

A Worked Example: One Subject Across Three Layers

Consider subject 001 receiving Drug A. ADSL might contain:

The laboratory BDS might contain:

The adverse-event analysis dataset might contain:

Each dataset answers a different analytical question.

Why This Matters for TFL Programming

A statistical programmer may receive a shell for a table showing mean change from baseline by treatment and visit. The shell alone does not determine the dataset structure. The programmer must understand the analysis data needed to produce it.

A likely workflow is:

The Most Important Distinction

The single most important conceptual distinction is:

Final Comparison

Practical Checklist for BDS Programming

Bottom Line

For a clinical programmer, the most reliable approach is to stop thinking of BDS as simply a list of standard variables and instead think in terms of record grain, parameter identity, analysis timing, derivation logic, and traceability.

Once those concepts are clear, variables such as PARAMCD, AVAL, BASE, CHG, PCHG, ADT, ADY, AVISIT, AVISITN, and ANL01FL become components of a coherent analysis structure rather than isolated CDISC terminology.

References

CDISC. Analysis Data Model (ADaM) Implementation Guide. Current applicable version and controlled terminology should be used for production submissions and study-specific implementations.

CDISC. Analysis Data Model (ADaM). CDISC standards documentation and implementation guidance.

CDISC. Study Data Tabulation Model (SDTM) Implementation Guide. Current applicable version should be used for the study's SDTM implementation.

FDA. Study Data Technical Conformance Guide. Current applicable version should be consulted for regulatory submission expectations.

FDA. Data Standards Catalog. Use the current applicable standards and controlled terminology for production submissions.