How to Prepare SDTM Domains for Regulatory Submission: A Hands-On Clinical SAS Tutorial

Preparing SDTM domains for regulatory submission is one of the most important skills for a Clinical SAS Programmer. Pharmaceutical companies and CROs need programmers who can transform raw clinical trial data into standardized datasets that can be reviewed consistently by regulatory authorities.

This process involves much more than renaming variables. A professional SDTM programmer must understand clinical trial data, CDISC standards, SDTM domains, controlled terminology, ISO 8601 dates, data mapping, SAS programming, validation, metadata, ADaM and ultimately how standardized data supports Tables, Listings and Figures (TLF).

This tutorial explains the complete workflow using a fictional clinical trial and practical SAS examples.

What Is SDTM?

SDTM, or Study Data Tabulation Model, is a CDISC standard for organizing and formatting clinical study data.

The Clinical Data Interchange Standards Consortium (CDISC) develops standards that help clinical research organizations represent, exchange and analyze clinical data consistently.

CDISC states that SDTM supports data organization for clinical research and helps improve regulatory review and approval processes. SDTM is also a required standard for certain FDA submissions. (CDISC)

A typical clinical data flow looks like this:

Clinical Trial Data
       ↓
Raw Data
       ↓
SDTM
       ↓
ADaM
       ↓
TLF
       ↓
Clinical Study Report
       ↓
Regulatory Submission

Understanding this complete flow is essential for anyone pursuing a career in Clinical SAS programming.

---

Why Is SDTM Important for Regulatory Submission?

Clinical trials generate large amounts of data from:

• Electronic Data Capture (EDC)

• Laboratory systems

• Randomization systems

• Safety databases

• ECG systems

• Imaging systems

• External vendors

• Patient questionnaires

• Other clinical data sources

Without standardization, two studies could represent the same clinical information in completely different ways.

SDTM provides a common framework for representing this information.

For example, one database might call an adverse-event variable:

EVENT_NAME

while another might use:

AE_TERM

SDTM provides standardized structures such as:

AETERM
AEDECOD
AESEV
AESTDTC
AEENDTC

This makes the data easier for programmers, statisticians and regulatory reviewers to understand.

Current CDISC and Regulatory Standards

A Clinical SAS programmer should never assume that an old project specification is automatically suitable for a new study.

CDISC currently publishes SDTM v2.1. (CDISC)

The published SDTMIG v3.4 provides implementation guidance for human clinical-trial tabulation datasets and is intended to be used with SDTM v2.0. It includes domain-specific assumptions, business rules and examples. (CDISC)

CDISC also notes that SDTM v3.0 and SDTMIG v4.0 are in development, so standards continue to evolve. (CDISC)

For FDA submissions, the applicable version should be determined from the FDA Data Standards Catalog and current technical requirements. FDA's current Study Data Technical Conformance Guide was issued in June 2026. (U.S. Food and Drug Administration)

Therefore, the first rule of regulatory SDTM programming is:

Always confirm the applicable CDISC and regulatory standards before programming.

SDTM Regulatory Submission Workflow

A practical SDTM workflow can be represented as:

Raw Clinical Data
        ↓
Data Review
        ↓
Study Data Standards Plan
        ↓
Mapping Specification
        ↓
SDTM Programming
        ↓
SDTM Domains
        ↓
QC & Validation
        ↓
Define-XML / Metadata
        ↓
ADaM
        ↓
TLF
        ↓
Regulatory Submission

Let's walk through this process using a fictional study.

Step 1: Understand the Clinical Trial

Consider a fictional Phase III study.

Study ID: ABC001

Treatment: Drug A vs Placebo

Population: Adult patients

The study collects:

• Demographics

• Treatment exposure

• Adverse events

• Laboratory tests

• Vital signs

• Medical history

• Concomitant medications

• Disposition

• Subject visits

For our tutorial, we will create:

DM
EX
AE
LB
VS
MH
CM
DS
SV

These are some of the most commonly encountered SDTM domains in clinical SAS programming.

Step 2: Review the Raw Clinical Data

Suppose the raw demographic dataset contains:

SUBJECT	SITE	TREATMENT	SEX	AGE
001	101	Drug A	F	45
002	101	Placebo	M	52
003	102	Drug A	F	38
004	102	Placebo	M	61

Raw adverse-event data:

SUBJECT	EVENT	START_DATE	END_DATE	SEVERITY
001	Headache	15-Jan-2026	17-Jan-2026	Mild
002	Nausea	20-Jan-2026	21-Jan-2026	Moderate
003	Headache	18-Jan-2026	20-Jan-2026	Mild

Raw laboratory data:

SUBJECT	TEST	RESULT	UNIT
001	Hemoglobin	13.5	g/dL
002	Hemoglobin	14.1	g/dL
003	Hemoglobin	12.8	g/dL

Before writing SAS code, the programmer needs to understand what each variable represents.

Step 3: Create an SDTM Mapping Specification

The mapping specification is the blueprint for SDTM programming.

Example:

Raw Variable	SDTM Domain	SDTM Variable	Transformation
SUBJECT	DM	SUBJID	Direct
SITE	DM	SITEID	Direct
SEX	DM	SEX	Standardize
AGE	DM	AGE	Direct
TREATMENT	EX	EXTRT	Standardize
DOSE	EX	EXDOSE	Direct
UNIT	EX	EXDOSU	Standardize
START_DATE	EX	EXSTDTC	ISO 8601
END_DATE	EX	EXENDTC	ISO 8601
EVENT	AE	AETERM	Direct
EVENT	AE	AEDECOD	Medical coding
SEVERITY	AE	AESEV	Controlled terminology
START_DATE	AE	AESTDTC	ISO 8601
END_DATE	AE	AEENDTC	ISO 8601

A production mapping specification should additionally document derivations, origins, controlled terminology, algorithms, comments and traceability.

Step 4: Create the DM Domain

The DM (Demographics) domain contains subject-level information.

Typical variables include:

STUDYID
DOMAIN
USUBJID
SUBJID
SITEID
SEX
AGE
AGEU
ARM
ARMCD

The most important identifier is often USUBJID, the Unique Subject Identifier.

Suppose the study specification defines:

USUBJID = STUDYID-SITEID-SUBJID

Then:

ABC001-101-001
ABC001-101-002
ABC001-102-003

can be generated.

SAS Example

data sdtm.dm;
    set raw.dm;

    length studyid $20
           domain  $2
           usubjid $40;

    studyid = "ABC001";
    domain  = "DM";

    subjid = subject;
    siteid = site;

    usubjid = catx("-", studyid, siteid, subjid);

    ageu = "YEARS";

    keep studyid domain usubjid subjid siteid
         sex age ageu;
run;

This is a simplified educational example. Production programming must follow the approved study specifications.

Step 5: Prepare the EX Domain

The EX (Exposure) domain represents exposure to study treatment.

Suppose the raw data contains:

SUBJECT	TREATMENT	DOSE	UNIT	START_DATE	END_DATE
001	Drug A	100	mg	10-Jan-2026	09-Feb-2026
002	Placebo	0	mg	10-Jan-2026	09-Feb-2026
003	Drug A	100	mg	12-Jan-2026	11-Feb-2026

The mapping might be:

TREATMENT  → EXTRT
DOSE       → EXDOSE
UNIT       → EXDOSU
START_DATE → EXSTDTC
END_DATE   → EXENDTC

SAS Example

data sdtm.ex;
    set raw.exposure;

    studyid = "ABC001";
    domain  = "EX";

    usubjid = catx("-", studyid, siteid, subject);

    extrt  = treatment;
    exdose = dose;
    exdosu = unit;

    exstdtc = put(start_date, yymmdd10.);
    exendtc = put(end_date, yymmdd10.);

    keep studyid domain usubjid
         extrt exdose exdosu
         exstdtc exendtc;
run;

Step 6: Prepare the AE Domain

The AE (Adverse Events) domain is one of the most important SDTM domains for clinical trial safety data.

Typical variables include:

STUDYID
DOMAIN
USUBJID
AESEQ
AETERM
AEDECOD
AESTDTC
AEENDTC
AESEV
AEOUT

Consider:

Subject: 001
Event: Headache
Severity: Mild

The collected event can be represented as:

AETERM = Headache

The coded medical dictionary term could be:

AEDECOD = HEADACHE

AETERM and AEDECOD should not automatically be treated as identical.

Step 7: Generate AESEQ

If a subject experiences multiple adverse events, sequence numbers can distinguish individual records.

Example:

USUBJID	AESEQ	AETERM
ABC001-101-001	1	Headache
ABC001-101-001	2	Nausea
ABC001-101-001	3	Dizziness

A simplified SAS approach is:

proc sort data=raw.ae out=ae_sorted;
    by subject start_date;
run;

data sdtm.ae;
    set ae_sorted;

    by subject;

    if first.subject then aeseq = 0;
    aeseq + 1;

    studyid = "ABC001";
    domain = "AE";

    usubjid = catx("-", studyid, siteid, subject);

    aeterm = event;

    aestdtc = put(start_date, yymmdd10.);
    aeendtc = put(end_date, yymmdd10.);

    aesev = upcase(severity);

    keep studyid domain usubjid aeseq
         aeterm aestdtc aeendtc aesev;
run;

In a production environment, medical coding and controlled terminology should come from the approved study processes.

Step 8: Understand Findings Domains

Findings domains are particularly important in clinical SAS programming.

Examples include:

• LB — Laboratory Tests

• VS — Vital Signs

• EG — ECG

• QS — Questionnaires

• PE — Physical Examination

For example, laboratory data might be represented using:

LBTESTCD
LBTEST
LBORRES
LBORRESU
LBSTRESC
LBSTRESN
LBSTRESU

---

Step 9: Understand ORRES and STRES

Suppose the raw hemoglobin result is:

13.5 g/dL

The original result can be represented using:

LBORRES  = 13.5
LBORRESU = g/dL

A standardized numerical result can be represented using:

LBSTRESN = 13.5
LBSTRESU = g/dL

If unit conversion is necessary, the standardized result may differ from the original result.

The programmer must document the conversion algorithm and ensure that it is clinically appropriate.

Step 10: Apply Controlled Terminology

Controlled terminology is an essential component of CDISC SDTM implementation.

For example, values such as:

Male
MALE
M
Man

should not simply be mixed together.

The applicable CDISC terminology and study standards should determine the appropriate representation.

Controlled terminology can apply to:

• Sex

• Race

• Ethnicity

• Severity

• Outcome

• Relationship

• Units

• Findings tests

• Other standardized variables

Always confirm the terminology release applicable to the study.

Step 11: Handle ISO 8601 Dates

SDTM commonly uses ISO 8601 representations for dates and times.

For example:

15-Jan-2026

becomes:

2026-01-15

In SAS:

aestdtc = put(start_date, yymmdd10.);

For datetime:

datetimec = put(datetime, e8601dt.);

Never invent missing clinical information simply to create a complete date.

For example:

2026-01

should not automatically become:

2026-01-15

unless an approved study-specific rule supports the derivation.

---

Step 12: Prepare the LB Domain

Suppose the raw laboratory dataset contains:

Subject	Test	Result	Unit
001	Hemoglobin	13.5	g/dL
002	Hemoglobin	14.1	g/dL
003	Hemoglobin	12.8	g/dL
001	ALT	25	U/L
002	ALT	31	U/L

The SDTM mapping could include:

TEST        → LBTEST
TEST CODE   → LBTESTCD
RESULT      → LBORRES
UNIT        → LBORRESU
RESULT      → LBSTRESN

A simplified SAS program:

data sdtm.lb;
    set raw.lab;

    studyid = "ABC001";
    domain = "LB";

    usubjid = catx("-", studyid, siteid, subject);

    lbtest = test;
    lborres = strip(result);
    lborresu = unit;

    lbstresc = strip(result);
    lbstresn = input(result, best32.);
    lbstresu = unit;

    keep studyid domain usubjid
         lbtest lborres lborresu
         lbstresc lbstresn lbstresu;
run;

The real implementation should account for data types, units, reference ranges, qualifiers and study-specific requirements.

Step 13: Select the Correct SDTM Domain

Domain selection is one of the most important skills for an SDTM programmer.

The programmer should first determine the appropriate SDTM observation class and then the appropriate domain.

The major classes include:

Interventions
Events
Findings
Findings About

CDISC emphasizes determining the SDTM class before selecting the specific domain. (CDISC)

This becomes particularly important with specialized clinical data.

For example, SDTMIG v3.4 includes domains and structures covering areas such as genomics, cell phenotype and biospecimen data. (CDISC)

Therefore, an experienced SDTM programmer should not simply rely on memorized lists of domains.

Step 14: Perform SDTM Validation

Creating the dataset is only part of the job.

The SDTM programmer must perform quality control and conformance checks.

Important checks include:

Dataset Checks

• Correct dataset name

• Correct domain

• Correct variables

• Correct labels

• Correct types

• Correct lengths

• Correct structure

Data Checks

• Missing USUBJID

• Duplicate records

• Invalid dates

• Invalid terminology

• Unexpected values

• Incorrect sequence numbers

• Incorrect units

Cross-Domain Checks

For example:

DM
 ↓
AE
 ↓
EX
 ↓
LB
 ↓
VS
 ↓
CM

Subject identifiers and other relationships should be reviewed for consistency.

CDISC publishes SDTM and SDTMIG conformance rules, while FDA maintains its own regulatory technical requirements and validation resources. (CDISC)

Step 15: Perform SAS Quality Control

A simple duplicate check:

proc sort data=sdtm.ae
          out=ae_check
          nodupkey
          dupout=ae_duplicates;
    by studyid usubjid aeseq;
run;

Check missing identifiers:

proc sql;
    select *
    from sdtm.ae
    where missing(studyid)
       or missing(usubjid)
       or missing(domain);
quit;

Check adverse-event severity:

proc freq data=sdtm.ae;
    tables aesev / missing;
run;

These checks are useful for development, but they do not represent a complete regulatory validation program.

---

Step 16: Understand Define-XML

A regulatory submission is not simply a collection of datasets.

Metadata is also important.

Define-XML provides metadata describing datasets, variables, controlled terminology and other submission information.

FDA identifies Define-XML as the metadata standard accompanying SDTM and ADaM datasets for applicable submissions. (U.S. Food and Drug Administration)

A simplified relationship is:

SDTM Dataset
      +
Variable Metadata
      +
Dataset Metadata
      +
Controlled Terminology
      ↓
Define-XML

The metadata should accurately describe the datasets that are actually being submitted.

Step 17: Understand ADaM

After SDTM, clinical trial data may be transformed into ADaM (Analysis Data Model) datasets for statistical analysis.

A simplified flow is:

RAW DATA
   ↓
SDTM
   ↓
ADaM
   ↓
TLF

Examples of analysis datasets include:

ADSL
ADAE
ADLB
ADVS

For example:

SDTM.AE
    ↓
ADAE
    ↓
Adverse Event Tables

SDTM primarily standardizes the representation of clinical trial observations, while ADaM supports analysis-ready datasets and traceability for statistical analysis.

---

Step 18: Where Does TLF Fit?

TLF stands for:

Tables, Listings and Figures

TLF programming is an important part of clinical SAS programming because the final statistical outputs used in clinical study reporting are generated from analysis datasets.

A typical workflow is:

Raw Data
   ↓
SDTM
   ↓
ADaM
   ↓
SAS TLF Programs
   ↓
Tables
Listings
Figures
   ↓
Clinical Study Report

Tables

Tables summarize important clinical results.

Examples include:

• Demographic summary

• Treatment exposure

• Adverse events

• Serious adverse events

• Laboratory summaries

• Vital-sign summaries

• Efficacy endpoints

Example:

Treatment	N	Mean Age	SD
Drug A	50	54.2	8.1
Placebo	50	53.7	7.9

Step 19: TLF Listings

Listings generally provide detailed subject-level information.

For example, an adverse-event listing might contain:

Subject	Treatment	AE Term	Severity	Start Date
001	Drug A	Headache	Mild	15-Jan-2026
002	Placebo	Nausea	Moderate	20-Jan-2026

Listings are useful for reviewing individual patient data.

Step 20: TLF Figures

Figures visually communicate clinical trial results.

Common examples include:

• Kaplan-Meier curves

• Forest plots

• Mean change over time

• Laboratory trends

• Treatment response

• Patient disposition diagrams

SAS procedures such as PROC SGPLOT, PROC LIFETEST and other statistical procedures can be used depending on the analysis requirement.

Step 21: Simple TLF SAS Example

Suppose we have an ADaM dataset called ADSL.

A demographic summary could begin with:

proc means data=adam.adsl n mean std min max;
    class trt01a;
    var age;
run;

For a categorical summary:

proc freq data=adam.adsl;
    tables trt01a*sex / norow nocol nopercent;
run;

A figure could be created using:

proc sgplot data=adam.adlb;
    series x=visitnum y=aval / group=trt01a;
    xaxis label="Visit";
    yaxis label="Mean Laboratory Value";
run;

These are simplified educational examples. Production TLF programming requires approved statistical analysis specifications, shells, programming specifications, formatting standards and QC.

Step 22: Why SDTM and TLF Skills Should Be Learned Together

A Clinical SAS professional who understands only SDTM may be limited to the data-standardization side of the clinical programming workflow.

A programmer who understands:

SAS
+
SDTM
+
ADaM
+
TLF

has a much broader understanding of the clinical data lifecycle.

For example:

Raw AE
 ↓
SDTM AE
 ↓
ADAE
 ↓
AE Table
 ↓
Clinical Study Report

Understanding this complete chain helps the programmer understand why data needs to be structured correctly at every stage.

---

Step 23: Build a Hands-On Clinical SAS Project

To practice SDTM programming and TLF programming, create a fictional Phase III clinical trial with 100 subjects.

Create these raw datasets:

RAW_DM
RAW_EX
RAW_AE
RAW_LB
RAW_VS
RAW_CM
RAW_MH
RAW_DS

Transform them into:

SDTM_DM
SDTM_EX
SDTM_AE
SDTM_LB
SDTM_VS
SDTM_CM
SDTM_MH
SDTM_DS

Then create analysis datasets:

ADSL
ADAE
ADLB
ADVS

Finally, generate:

Demographic Tables
Adverse Event Tables
Laboratory Tables
Vital Sign Tables
Subject Listings
Laboratory Figures
Efficacy Figures

This creates a complete raw data → SDTM → ADaM → TLF training project.

Step 24: Create a Regulatory Submission Checklist

Before submission, review:

CDISC Standards

• Applicable SDTM version confirmed

• Applicable SDTMIG confirmed

• Controlled Terminology release confirmed

• Therapeutic Area guidance reviewed where applicable

SDTM Programming

• Domains correctly selected

• Mapping specifications completed

• Derivations documented

• ISO 8601 dates checked

• Controlled terminology checked

• USUBJID consistency checked

• Sequence variables checked

Validation

• SAS QC completed

• Duplicate checks completed

• Cross-domain checks completed

• CDISC conformance checks completed

• Regulatory validation findings reviewed

Metadata

• Dataset metadata reviewed

• Variable metadata reviewed

• Define-XML prepared

• Traceability reviewed

TLF

• ADaM datasets validated

• TLF shells approved

• Tables programmed

• Listings programmed

• Figures programmed

• Independent QC completed

• Output reviewed against specifications

For FDA submissions, always verify the current technical requirements rather than relying on an old checklist. FDA's current Study Data Technical Conformance Guide was issued in June 2026, and FDA directs sponsors to its Data Standards Catalog for applicable supported standards and deadlines. (U.S. Food and Drug Administration)

Common Mistakes in SDTM Programming

Mistake 1: Treating SDTM as Variable Renaming

SDTM involves:

Mapping
+
Derivation
+
Standardization
+
Controlled Terminology
+
Validation

It is not simply a rename exercise.

Mistake 2: Ignoring the Clinical Meaning

A programmer must understand what the collected data represents before mapping it.

Mistake 3: Using Outdated Standards

CDISC and regulatory requirements evolve. Always verify the applicable version.

Mistake 4: Creating Incorrect Dates

Do not invent missing clinical information.

Mistake 5: Ignoring TLF Requirements

The structure of SDTM and ADaM ultimately supports downstream clinical analysis and reporting.

Mistake 6: Focusing Only on SAS Syntax

A strong Clinical SAS Programmer needs both programming and clinical data-standard knowledge.

Skills Needed for a Clinical SAS Programmer

A job-ready Clinical SAS professional should ideally develop skills in:

SAS Programming

• Base SAS

• Advanced SAS

• PROC SQL

• SAS Macro

• Data manipulation

• Statistical procedures

• Reporting procedures

Clinical Data Standards

• CDISC

• SDTM

• SDTMIG

• Controlled Terminology

• ADaM

• Define-XML

Clinical Programming

• Raw-to-SDTM mapping

• SDTM domain programming

• ADaM programming

• TLF programming

• QC and validation

• Regulatory submission concepts

Clinical Research

• Clinical trial phases

• Randomization

• Treatment arms

• Adverse events

• Laboratory data

• Vital signs

• Efficacy endpoints

• Safety analysis

Career Opportunities in Clinical SAS

These skills can support career paths such as:

• Clinical SAS Programmer

• SDTM Programmer

• ADaM Programmer

• Statistical Programmer

• Clinical Data Programmer

• CDISC Programmer

• Clinical Reporting Programmer

• TLF Programmer

• Senior Statistical Programmer

• Clinical Programming Lead

For candidates entering the pharmaceutical, biotechnology and CRO industries, a combination of SAS + SDTM + ADaM + TLF provides a much stronger practical foundation than learning SAS syntax alone.

---

A Complete Clinical SAS Learning Roadmap

A practical learning sequence is:

Base SAS
   ↓
Advanced SAS
   ↓
Clinical Trial Concepts
   ↓
CDISC Fundamentals
   ↓
SDTM
   ↓
SDTM Programming
   ↓
Validation
   ↓
ADaM
   ↓
TLF Programming
   ↓
Regulatory Submission Concepts

The most effective learning method is to work with realistic clinical trial datasets rather than only memorizing SDTM variables.

 

Preparing SDTM domains for regulatory submission requires a combination of clinical knowledge, CDISC standards, SAS programming, data mapping, controlled terminology, validation and regulatory awareness.

The complete clinical programming lifecycle can be understood as:

RAW DATA
   ↓
SDTM
   ↓
ADaM
   ↓
TLF
   ↓
Clinical Study Report
   ↓
Regulatory Submission

SDTM provides the standardized foundation for clinical trial data, ADaM prepares data for statistical analysis, and TLF programming transforms analysis results into tables, listings and figures used for clinical reporting.

For anyone planning a career as a Clinical SAS Programmer, learning SDTM, ADaM and TLF programming together provides a practical understanding of how clinical trial data moves from raw collection through standardized datasets to final statistical reporting.

The key principle is:

Understand the clinical data → map it correctly → program SDTM → validate it → build ADaM → generate TLF → document and trace everything.

That is the foundation of professional Clinical SAS programming for clinical trials and regulatory submissions.