SDTM vs ADaM: When to Use Each and How They Connect in a Submission

Knowing SDTM vs ADaM helps teams tell mapping errors from wrong baseline choices and derivation errors before a submission. CDISC standards govern how datasets are built; the study’s requirements govern derivations and analyses.

What is SDTM? The Study Data Tabulation Model is a CDISC standard for organising clinical study data into defined tabulation domains: DM for demographics, LB for laboratory tests and AE for adverse events, for example [1, 4]. What is ADaM in clinical trials? The Analysis Data Model standardises analysis datasets and supports traceability between results and their source data; ADSL (subject level) and ADLB (laboratory analysis) are common examples [2]. SDTM standardises tabulation data; ADaM supports the planned statistical analyses.

Table 1 compares SDTM and ADaM datasets. SDTM is not simply a copy of raw data: mapping involves standardisation, coding and controlled terminology. ADaM uses predecessor data and documented analysis specifications to build datasets for the intended analyses. The two models are complementary, not interchangeable [2, 3].

ADSL vs DM shows the difference at subject level. DM holds standardised demographic and other subject-level tabulation data; ADSL holds the subject-level analysis variables and population flags the analyses need. ADSL may draw on DM and other domains, but it is not a renamed DM [2].

Data move through four stages, from collected data to reported results (Figure 1). Source data are mapped into SDTM domains. SDTM to ADaM mapping then applies the statistical analysis plan and analysis specifications to select records and derive variables. ADaM datasets finally feed the tables, listings and figures. Document how source records relate to analysis variables so that, when a discrepancy appears, the team can find where it started and what it affects downstream.

Use SDTM to represent study data in standard tabulation structures; use ADaM to prepare data for a defined analysis. Laboratory results and adverse events belong in SDTM domains. Analysis populations, baseline and change from baseline (BASE and CHG), treatment comparisons and analysis traceability belong in ADaM. The choice depends on the task, not on which model looks more sophisticated.

Traceability lets a reviewer see where an analysis value came from, which records contributed and which rules were applied. Source identifiers help, but complete traceability also needs metadata and documented relationships [2, 3]. Suppose the SAP defines baseline as the last eligible, non-missing ALT value before treatment, and change from baseline as the post-baseline value minus baseline. The values below are illustrative.

LBSEQ 12 is the baseline record and LBSEQ 18 the post-baseline record. The ADLB dataset could hold:

For the post-baseline record, CHG = AVAL − BASE = 105 − 125 = −20. AVAL comes from LBSEQ 18 while BASE comes from LBSEQ 12, which is why an analysis value and its baseline can trace to different source records. Variables such as SRCDOM, SRCVAR and SRCSEQ can identify source records; the baseline link may need additional documentation.

Apply baseline flags correctly. ADaM ABLFL marks the record chosen as analysis baseline under the SAP definition; it should not be copied automatically from an SDTM flag. In SDTMIG v3.3, --BLFL is a sponsor-defined baseline flag, and --LOBXFL, introduced in that version, marks the last non-missing observation before exposure [4]. Neither is automatically the SAP-defined baseline.

Catch derivation defects with independent QC. If a submitted ADLB record shows AVAL = 105, BASE = 125 and CHG = −15, the documented rule gives −20, so the value is wrong. Check the programming logic, baseline selection and source relationship, fix the error and rerun the affected checks and outputs. Independent QC should test the documented rule, not repeat the production program’s logic.

Define-XML describes submitted dataset structures, variables, controlled terminology and other metadata [5]. It helps reviewers understand the datasets but does not replace the derivation specifications needed to explain complex calculations. Submission documentation should align dataset structures, metadata, derivation rules and traceability information.

Reliable SDTM ADaM programming checks both structure and analysis logic:

1. Structural conformance: datasets, variables, data types and conformance rules.
2. Derivation QC: baseline definitions, flags, derivations, analysis periods and included records.
3. Traceability and metadata: predecessor relationships, derivation documentation and Define-XML.
4. Statistical review: populations, endpoints, comparisons and adherence to the SAP.
5. Output reconciliation: analysis datasets agree with tables, listings and figures.

Test hard baseline cases: several pre-treatment values, missing values, unscheduled visits and unclear treatment dates. Structural validation alone cannot show that every required record is present or that the analysis is appropriate.

For FDA submission requirements, establish which standards and versions apply. FDA’s study data resources and Data Standards Catalog list supported standards and requirement dates; applicability depends on the review centre, study start date and submission type [6]. Before finalising specifications, confirm the reviewing centre and submission type, the catalog entries that apply to the study start date, the SDTM, ADaM and implementation-guide versions, and the current Study Data Technical Conformance Guide [7]. Keep a standards log of the versions chosen and why. FDA guidance describes the agency’s current thinking; it is not legally binding unless a statute or regulation is cited.

SDTM standardises clinical study data; ADaM structures it for analysis and traceability. Submissions hold up when derivations are documented, metadata are complete and QC tests the rules independently.