Author: Bhanoji Duppada
Edition: First Edition, 2026
Website: learnhub101.com
This work was created with AI assistance under the direction and editorial supervision of Bhanoji Duppada. All technical content has been reviewed, verified, and edited by the author. The author retains full copyright and creative responsibility.
Copyright © 2026 Bhanoji Duppada. All rights reserved.
No part of this publication may be reproduced or transmitted without prior written permission of the author.
By Bhanoji Duppada
Understanding Clinical Data Standards from First Principles
CDISC standards can feel overwhelming. Between SDTM, ADaM, controlled terminology, Define.xml, and dozens of implementation guides, new programmers often struggle to see the big picture.
This book decodes CDISC by explaining the why behind every standard, not just the what. You'll understand why SDTM stores dates as characters, why ADaM needs both PARAM and PARAMCD, and why Define.xml matters for FDA review. With that understanding, the implementation details become intuitive rather than arbitrary.
Published: 2026 | Pages: 200+
© 2026 Bhanoji Duppada. All rights reserved.
CDISC (Clinical Data Interchange Standards Consortium) is the organization that defines how clinical trial data should be structured when submitted to regulatory agencies like the FDA, EMA, and PMDA.
In simpler terms: CDISC creates the rules for organizing your clinical data so that a reviewer at the FDA can open your datasets and immediately understand what they're looking at --- without needing to read 500 pages of documentation.
Before CDISC, every pharmaceutical company structured their clinical trial data differently. Company A called it "DEMOG" with a variable "BIRTHDAY." Company B called it "DM" with "DOB." Company C had five separate files for demographic information.
The FDA was drowning. Reviewers had to learn a new data structure for every submission. A single reviewer might handle 10 submissions per year, each with completely different variable names, dataset structures, and coding conventions.
In 2004, the FDA issued guidance recommending CDISC standards for electronic submissions. By 2016, CDISC SDTM and ADaM became mandatory for most NDA/BLA submissions to the FDA. The PMDA (Japan) followed. The EMA (Europe) is moving in the same direction.
Today, if you want to submit a drug for approval in the United States, your data must be in CDISC format. Period.
CDISC isn't one standard --- it's a family of related standards that cover the entire clinical data lifecycle:
What it covers: How data is collected on Case Report Forms (CRFs). Who uses it: Data managers, EDC designers. Your involvement: Low. You receive data that was collected per CDASH guidelines.
What it covers: How collected data is organized for submission. Who uses it: You. This is your primary job. The concept: Raw data from the EDC system is "mapped" (transformed) into standardized SDTM domains. Every clinical trial has the same domain names (DM, AE, CM, VS, LB, EX, DS) with the same variable names and structures.
What it covers: How SDTM data is restructured for statistical analysis. Who uses it: You. This is your second primary job. The concept: SDTM data is good for storage and review but not always ideal for analysis. ADaM restructures it with analysis-specific variables --- baseline flags, change from baseline, treatment-emergent flags, population flags.
What it covers: The allowed values for coded variables. Example: The variable AESEV (AE severity) can only contain: "MILD", "MODERATE", "SEVERE". Not "mild", not "GRADE 1", not "1". Exactly those three values.
What it covers: The metadata document that describes every dataset, variable, and codelist in your submission. Who uses it: The FDA reviewer opens this first. It's their roadmap to your data.
Job security: Every clinical programming job requires CDISC knowledge. It's not a nice-to-have --- it's table stakes.
Efficiency: Once you understand the CDISC model, you can switch between studies and even between companies with minimal ramp-up. The DM domain is the same everywhere.
Quality: CDISC gives you a checklist. If your DM domain has all required variables with correct types and controlled terminology values, it's probably correct. Standards reduce bugs.
Career growth: Programmers who deeply understand CDISC (not just follow templates) become leads and architects. The difference between a junior and senior programmer is often the depth of their CDISC understanding.
Think of CDISC like postal addresses. Before standardization, people wrote addresses any way they wanted: "John Smith, the red house by the river, Springfield." That worked for local mail carriers who knew the area, but not for national delivery.
CDISC is the equivalent of: Street Address, City, State, ZIP Code. Everyone knows where each piece goes. Any mail carrier in any city can deliver it. Any FDA reviewer can read your data.
By the end of this book, you'll understand: - Every major SDTM domain --- what each variable means and why it exists - The ADaM model --- ADSL, BDS, OCCDS structures and when to use each - Controlled terminology --- how to apply it correctly - Define.xml --- how to read it, generate it, and troubleshoot it - Pinnacle 21 validation --- interpreting and fixing common errors - The philosophy behind the standards --- so you can handle edge cases
Let's start with the big picture in Chapter 2: how CDASH, SDTM, ADaM, and Define.xml connect together.
Imagine you're an FDA reviewer in 2003. You've received three drug applications this month. Company A stores adverse events in a dataset called ADVERSE_EVENTS with a variable called AE_VERBATIM_TERM. Company B uses SAFETY_AE with ADVERSE_EVENT_TEXT. Company C uses AE with AETERM.
Same data. Three completely different structures. Before you can even evaluate the drug's safety, you spend weeks figuring out each company's custom data model. Multiply this across 100+ submissions per year, and you understand why the FDA was desperate for standardization.
CDISC (Clinical Data Interchange Standards Consortium) was founded in 1997 to solve this problem. Its mission: create universal data standards so that every company structures clinical trial data the same way.
CDISC isn't one standard --- it's a family of interconnected standards:
CDASH → What data to COLLECT on the CRF
(Case Report Form design standard)
↓
SDTM → How to ORGANIZE collected data for submission
(Study Data Tabulation Model)
↓
ADaM → How to ANALYZE data for statistical tables
(Analysis Data Model)
↓
Define-XML → How to DOCUMENT your datasets (metadata)
↓
Controlled → What VALUES are allowed in coded fields
Terminology (CDISC CT --- published quarterly)
As a clinical programmer, you work primarily with SDTM, ADaM, Define-XML, and Controlled Terminology. CDASH is the data management team's responsibility (they design the CRFs). But understanding CDASH helps you know why certain variables exist in the raw data.
The FDA didn't just suggest CDISC --- they mandated it:
2004: FDA issues guidance encouraging CDISC standards 2014: FDA publishes final guidance requiring standardized study data 2016: Electronic submissions MUST use CDISC SDTM and ADaM formats 2017: Refuse to File (RTF) letters issued for non-compliant submissions
If your submission doesn't use CDISC, the FDA can reject it before scientific review even begins. Your drug could cure cancer, but if the data isn't in SDTM/ADaM format with Define.xml, the FDA sends it back.
Other regulatory agencies followed: - EMA (Europe): Strongly recommends CDISC, moving toward mandate - PMDA (Japan): Requires CDISC for all new submissions since 2020 - Health Canada: Strongly recommends, accepts CDISC - TGA (Australia): Accepts CDISC format
Here's what a clinical programmer's workflow looks like with CDISC:
RAW DATA (from EDC system like Rave or InForm)
│
├── CDASH-designed CRFs → raw datasets have predictable structure
│
▼
SDTM MAPPING (your first programming task)
│
├── Map raw variables to CDISC standard names
│ raw.ae_verbatim → sdtm.ae.AETERM
│ raw.severity_code → sdtm.ae.AESEV (using CT: MILD/MODERATE/SEVERE)
│
├── Apply Controlled Terminology
│ "1" → "MILD", "2" → "MODERATE", "3" → "SEVERE"
│
├── Create Define.xml to document everything
│
├── Validate with Pinnacle 21
│
▼
ADaM CREATION (your second programming task)
│
├── ADSL from DM + EX + DS
├── ADAE from AE + ADSL (add TRTEMFL, AOCCFL)
├── ADVS from VS + ADSL (add BASE, CHG, ABLFL)
│
├── Create Define.xml (ADaM)
├── Write ADRG (reviewer's guide)
│
▼
TLF GENERATION (your third programming task)
│
├── Tables from ADaM datasets
├── Listings from ADaM datasets
├── Figures from ADaM datasets
│
▼
eCTD SUBMISSION PACKAGE
│
├── /m5/datasets/sdtm/ (XPT files + define.xml)
├── /m5/datasets/adam/ (XPT files + define.xml)
└── /m5/datasets/misc/ (ADRG, SDRG, aCRF)
CDISC.org: The standards body. Publishes SDTM IG, ADaM IG, CT packages, Define-XML spec.
Pinnacle 21 (Formedix): Validation tool. Checks your datasets against CDISC rules. The FDA runs the same checks, so you must pass before submitting.
PhUSE (Pharmaceutical Users Software Exchange): Community of clinical programmers sharing best practices, code examples, and white papers.
R Submissions Working Group: Cross-industry group that published pilot R-based submissions to demonstrate FDA acceptance.
Chapter 2 breaks down SDTM's fundamental structure --- domains, observation classes, and the variable naming conventions that make every clinical dataset navigable.
SDTM organizes all clinical trial data into domains. Each domain is a single dataset that contains one type of information:
DM = Demographics (one row per subject)
AE = Adverse Events (one row per event)
CM = Concomitant Medications (one row per medication)
VS = Vital Signs (one row per test per timepoint)
LB = Laboratory Results (one row per test per timepoint)
EX = Exposure (one row per dosing record)
DS = Disposition (one row per disposition event)
MH = Medical History (one row per condition)
The naming convention is sacred: Domain names are always 2 characters. Variable names within a domain start with the domain prefix: AETERM (AE domain), VSTESTCD (VS domain), CMTRT (CM domain). This prefix system means that when you see LBSTRESN, you instantly know it's from the LB (laboratory) domain and contains a standardized result in numeric format.
Every domain belongs to one of four observation classes. The class determines the variable pattern:
Domains: DM, SV, SE Pattern: Study-level information, not per-observation data Key domain: DM has exactly ONE row per subject --- it's the anchor for the entire submission
Domains: AE, DS, MH, CE, DV
Variable pattern: --TERM (what happened) + --STDTC/--ENDTC (when)
AE: AETERM = "HEADACHE", AESTDTC = "2025-03-15", AEENDTC = "2025-03-18"
DS: DSTERM = "COMPLETED", DSSTDTC = "2025-06-30"
MH: MHTERM = "TYPE 2 DIABETES", MHSTDTC = "2018"
Domains: VS, LB, EG, PE, QS, FT, IE
Variable pattern: --TESTCD/--TEST (what) + --ORRES/--STRESN (result)
VS: VSTESTCD = "SYSBP", VSTEST = "Systolic Blood Pressure",
VSORRES = "142", VSSTRESN = 142, VSSTRESU = "mmHg"
LB: LBTESTCD = "HGB", LBTEST = "Hemoglobin",
LBORRES = "13.2", LBSTRESN = 13.2, LBSTRESU = "g/dL"
Domains: EX, CM, PR, SU, EC
Variable pattern: --TRT (what given) + --DOSE/--DOSU (how much)
EX: EXTRT = "DRUG XYZ 200MG", EXDOSE = 200, EXDOSU = "mg"
CM: CMTRT = "METFORMIN", CMDOSE = 500, CMDOSU = "mg"
Every SDTM variable falls into one of five identifier types:
Identifier Variables --- WHO is this about?
STUDYID = Study identifier (same for all records)
DOMAIN = Domain abbreviation ("AE", "VS", "LB")
USUBJID = Unique subject identifier (the universal key)
--SEQ = Sequence number (unique within USUBJID + DOMAIN)
Topic Variables --- WHAT was observed?
Events: --TERM (verbatim) + --DECOD (coded)
Findings: --TESTCD (short code) + --TEST (full name)
Interventions: --TRT (treatment name)
Qualifier Variables --- Additional DETAILS
--SCAT = Subcategory
--BODSYS = Body system (MedDRA SOC for AE)
--ORRES = Original result (character)
--STRESN = Standardized result (numeric)
--STRESU = Standardized units
Timing Variables --- WHEN did it happen?
--STDTC = Start date/time (ISO 8601 character)
--ENDTC = End date/time (ISO 8601 character)
--DY = Study day (numeric, relative to reference date)
VISIT = Visit name
VISITNUM = Visit number
Rule Variables --- HOW should this be classified?
--SEV = Severity (MILD/MODERATE/SEVERE)
--SER = Serious (Y/N)
--REL = Relationship to treatment
--OUT = Outcome
USUBJID (Unique Subject Identifier) is the single most important variable in CDISC. It uniquely identifies every subject across all domains, all studies, and all submissions. The FDA uses USUBJID to link records across datasets.
Format: Typically STUDYID-SITEID-SUBJID (e.g., "XYZ-001-101-0001")
Rules: 1. Must be unique across ALL studies in a submission (including ISS/ISE pooling) 2. Must be consistent across all domains (same subject = same USUBJID everywhere) 3. Must be character type (not numeric --- preserves leading zeros) 4. Should be human-readable (helps FDA reviewers navigate data)
Chapter 3 dives into DM --- the anchor domain that every submission starts with. Getting DM right means everything downstream flows correctly.
This is a free sample of the first 3 chapters. The complete guide continues with dozens more chapters of production-ready code, CDISC standards, and FDA submission practices.