Common CDISC Submission Pitfalls

Introduction

A CDISC regulatory submission is much more than a collection of correctly formatted SAS transport files.

A submission must communicate clinical data in a way that is standardized, internally consistent, traceable, technically valid, and understandable to a regulatory reviewer.

This distinction explains why some submission problems are difficult to detect. A dataset may pass many automated validation checks and still contain problems that make the submission difficult to review.

For example:

• An ADaM variable may be correctly derived but poorly documented.
• A controlled-term value may be technically plausible but inconsistent with the selected terminology release.
• An SDTM domain may contain the correct observations but use an inappropriate modeling approach.
• A Define-XML file may describe most variables but fail to adequately explain important derived variables.
• A validation warning may be legitimately explainable, but the explanation may never have been documented.
• A submission may contain internally inconsistent standards versions across datasets and metadata.

What Makes a CDISC Submission Difficult?

A typical regulatory data package contains multiple interconnected layers.

A problem introduced in one layer can propagate into several others.

For example, an incorrectly defined baseline can affect:

• SDTM-derived variables
• ADaM baseline flags
• change-from-baseline calculations
• analysis populations
• efficacy tables
• figures
• Define-XML derivations
• traceability

This is why submission QC must be performed as an integrated process rather than as independent checks of individual files.

Pitfall #1: Starting With the Dataset Instead of the Regulatory Requirements

Pitfall #2: Mixing Standards Versions

Standard                    Version / Release
------------------------------------------------
SDTM                        [approved version]
SDTMIG                      [approved version]
ADaM                        [approved version]
ADaMIG                      [approved version]
Define-XML                  [approved version]
CDISC Controlled Terminology [approved release]
MedDRA                      [approved version]
WHODrug                     [approved version]
LOINC                       [approved version, if applicable]
TAUG                        [applicable version]

Pitfall #3: Treating Controlled Terminology as an Optional Cleanup Step

Controlled terminology is not simply a cosmetic standardization exercise.

It provides the standardized values used in CDISC datasets and is an important part of submission consistency.

A common mistake is to wait until the end of programming to reconcile terminology.

That approach creates unnecessary downstream work because terminology affects SDTM values, Define-XML metadata, validation, reviewer interpretation, and sometimes derivations.

Do Not Confuse Collection Terminology With Submission Terminology

A value collected operationally does not necessarily have to be represented identically in the submission dataset.

The key question is:

The mapping should be documented and reproducible.

Pitfall #4: Incorrect Domain Modeling

Pitfall #5: Treating SDTM as a Direct Copy of the EDC

SDTM is not an electronic case report form dump.

Source data may contain:

• Operational field names
• Local abbreviations
• Free-text values
• Repeated forms
• Administrative variables
• System-generated identifiers
• Vendor-specific representations

The submission dataset instead needs a standardized representation that follows the applicable CDISC model and implementation guidance.

A useful conceptual distinction is:

The transformation logic should be documented and reproducible.

Pitfall #6: Losing the Relationship Between SDTM and ADaM

Source
  |
  +---- SDTM
  |
  +---- separate analysis database
              |
              +---- ADaM

Source / Collected Data
          |
          v
        SDTM
          |
          v
        ADaM
          |
          v
      TLF Outputs

Pitfall #7: Incomplete ADaM Traceability

Traceability is often discussed as if it means merely knowing the source dataset.

In practice, strong traceability means being able to answer questions such as:

• Where did this analysis parameter originate?
• Which SDTM observations contributed?
• How was baseline determined?
• How was the change from baseline derived?
• How was the analysis flag assigned?
• How was the treatment-emergent flag derived?
• How was the censoring date determined?
• Which records contributed to the analysis population?

For a derived variable:

Each transition should be explainable.

Example: Change From Baseline

Suppose an ADaM dataset contains:

BASE = 100
AVAL = 72
CHG  = -28
PCHG = -28%

The programmer should be able to demonstrate:

But a reviewer may also need to know how BASE was selected. That is where metadata and derivation documentation become critical.

Pitfall #8: Poor Baseline Definitions

Baseline is one of the most consequential derivations in clinical-trial analysis.

It can affect:

• Change from baseline
• Percent change
• Shift tables
• Responder analyses
• Time-to-event endpoints
• Laboratory summaries
• Vital-sign analyses
• ECG analyses
• Tumor-response analyses

A vague derivation such as:

BASE = pre-treatment value

may be inadequate.

A robust specification should identify:

• The population
• The analysis parameter
• The allowable timing window
• The relationship to first dose
• How multiple candidate observations are handled
• What happens when no qualifying value exists
• How unscheduled assessments are treated

Pitfall #9: Incomplete Define-XML

Define-XML is one of the most important pieces of submission metadata because it tells the reviewer what the submitted datasets contain.

A common mistake is to treat Define-XML as an automated export that only needs to be generated after the datasets are finished.

The result may contain:

• Missing derivation descriptions
• Incomplete origins
• Incorrect controlled terminology references
• Missing value-level metadata
• Incomplete Where Clause definitions
• Incorrect dataset labels
• Incorrect variable lengths or types
• Metadata that no longer matches the final datasets

What Define-XML Should Communicate

At minimum, submission metadata should allow the reviewer to understand:

Pitfall #10: Define-XML Does Not Match the Final Dataset

This is one of the most preventable submission errors.

Consider a final ADaM dataset containing:

PARAMCD
PARAM
AVAL
BASE
CHG
PCHG
ANL01FL
ANL02FL

If the Define-XML was generated before the final dataset was modified, it may still describe an earlier structure.

That creates a metadata/data mismatch.

The final QC cycle should therefore compare:

Pitfall #11: Treating Validation as a Pass/Fail Exercise

Automated validation is essential, but a submission should not be reduced to:

That implication is false.

Validation tools identify potential conformance issues. Some findings require correction; others may be explainable based on the study design, data, or applicable standards.

The correct process is:

Pitfall #12: Ignoring Warnings Because They Are Not Errors

A warning is not automatically irrelevant.

For example, a warning may identify:

• A missing expected variable
• An unusual value
• An unexpected relationship
• A terminology inconsistency
• A potential metadata problem
• A questionable record structure

Some warnings are legitimate.

The problem occurs when teams simply label all warnings as:

"Known issue"

without documenting the actual reason.

Pitfall #13: Validation Against a Nonfinal Dataset

A common workflow problem is validating one version of the datasets and then making additional changes afterward.

For example:

Dataset v1
   |
Validation
   |
Errors fixed
   |
Dataset v2
   |
Metadata updated
   |
Dataset v3
   |
Submission

If v3 is submitted without a final validation cycle, the team cannot assume that the previous validation results still apply.

The desired process is:

Final data freeze
      |
      v
Final dataset generation
      |
      v
Final Define-XML generation
      |
      v
Final validation
      |
      v
Resolve findings
      |
      v
Rebuild affected components
      |
      v
Final validation
      |
      v
Submission package freeze

Pitfall #14: Incorrect Variable Attributes

Dataset content is not the only thing that matters.

Variable metadata such as:

• Name
• Label
• Type
• Length
• Format
• Order
• Controlled terminology

A particularly common issue occurs when a variable is technically populated correctly but its metadata no longer matches the final dataset.

For example, if a variable's length was changed during programming but the metadata was not regenerated, the physical dataset and Define-XML can diverge.

Pitfall #15: Truncating Character Variables

Character-variable length problems can be especially dangerous because truncation may not always be visually obvious.

Consider:

Original:
"Subject withdrew consent because of relocation"

Incorrectly truncated:
"Subject withdrew consent because of relo"

Even if the dataset remains technically readable, information has been lost.

This can occur through:

• Incorrect SAS lengths
• Improper SQL casts
• Data-step attribute inheritance
• Concatenation into undersized variables
• Transport-file generation issues

A robust submission QC process should explicitly inspect character lengths and unexpected truncation.

Pitfall #16: Duplicate Records That Look Legitimate

Duplicates are not always identical rows.

Two observations can have different timestamps, sequence numbers, or values and still violate the intended key structure of a domain.

For every dataset, define the expected uniqueness structure.

The exact uniqueness structure must follow the applicable standard and study implementation.

Pitfall #17: Incorrect Subject-Level Population Flags

ADaM population flags are frequently used throughout tables and analyses.

Examples include:

SAFFL
ITTFL
FASFL
EFFFL
PPROTFL
ANL01FL
ANL02FL

A small error in one subject-level flag can propagate across many outputs.

For example:

If the flag is wrong for even a small number of subjects, the denominator, event counts, descriptive statistics, and inferential analyses may all change.

Pitfall #18: Treatment Assignment Inconsistencies

Treatment variables are another common source of submission problems.

Potential inconsistencies include:

• Planned treatment differs between datasets.
• Actual treatment is derived differently in different programs.
• Treatment labels differ between datasets.
• Numeric treatment codes do not align with labels.
• Analysis treatment differs from the treatment used in the TLF.

The treatment hierarchy should be explicitly documented.

Subject
   |
   +-- Planned treatment
   |
   +-- Actual treatment
   |
   +-- Analysis treatment
   |
   +-- Treatment sequence / period
   |
   +-- Treatment-emergent logic

Pitfall #19: Incorrect Date and Datetime Handling

Dates are deceptively simple.

Potential problems include:

• Incorrect ISO 8601 representation
• Incorrect partial dates
• Improper imputation
• Confusion between date and datetime
• Incorrect study day
• Time-zone transformations
• Incorrect treatment-relative day

For example:

The exact study-day derivation should follow the applicable SDTM convention and study specification.

Pitfall #20: Overimputing Dates

A common programming shortcut is to convert every incomplete date into a complete date.

For example:

2026-04
→
2026-04-15

This may introduce information that was never collected.

If date imputation is required for analysis, it should occur in the appropriate analysis layer and be governed by the prespecified methodology.

The standardized tabulation representation should not silently transform unknown information into known information.

Pitfall #21: Incorrect Handling of Missing Data

Missingness is part of the clinical data structure.

A submission can be damaged when programmers attempt to "complete" datasets without understanding why observations are missing.

Examples include:

• Replacing missing results with zero
• Carrying values forward without justification
• Creating artificial assessments
• Deleting missing records that are clinically meaningful
• Confusing not done with not applicable
• Confusing unknown with not collected

These concepts are not interchangeable.

The exact representation depends on the applicable domain and terminology.

Pitfall #22: Deriving Values in SDTM That Belong in ADaM

Another common mistake is putting analysis-oriented derivations into SDTM simply because they are useful for analysis.

SDTM should represent standardized clinical tabulation data. ADaM is designed to support analysis.

The distinction can be summarized as:

This does not mean that every derived variable belongs in ADaM or that SDTM contains no derived values.

Rather, the derivation should be evaluated based on the purpose and meaning of the variable within the applicable standard.

Pitfall #23: Creating "Analysis Variables" Without Metadata

Adding a variable such as:

RESPFL = "Y"

does not make the variable useful unless the submission explains:

• What "response" means
• Which criteria were applied
• Which observations were used
• What population was considered
• How missing data were handled
• What time period was used

The variable name is not the derivation.

The derivation is the combination of:

Pitfall #24: Incorrect Value-Level Metadata

Value-level metadata becomes important when the meaning or metadata of a variable depends on the value of another variable.

For example, a BDS parameter variable may identify multiple parameters:

PARAMCD    PARAM
------------------------------------------------
SYSBP      Systolic Blood Pressure
DIABP      Diastolic Blood Pressure
PULSE      Pulse Rate

The meaning and possibly controlled terminology associated with analysis variables can differ by parameter.

A Define-XML implementation that only describes the generic variable may not provide sufficient detail for the reviewer.

Pitfall #25: Weak Computational Methods

A computational method such as:

Derived from source data.

does not provide meaningful traceability.

A stronger description explains the algorithm.

For example:

Baseline is defined as the last non-missing valid assessment
prior to first dose. If multiple assessments occur on the same
date, the assessment with the latest collection time is selected.
Change from baseline is calculated as AVAL minus BASE.

The exact wording should match the actual study derivation.

Pitfall #26: Broken Traceability Between TLFs and ADaM

A regulatory reviewer may need to move backward from a result to the subjects and observations that produced it.

Consider a table reporting:

Treatment A
N = 125
Mean Change = -18.4
SD = 24.7

A robust analysis environment should make it possible to determine:

1. Which subjects contributed?
2. Which analysis flag selected them?
3. Which parameter was used?
4. Which time point was analyzed?
5. Which baseline values were used?
6. Which observations were excluded?
7. How were missing values handled?

This is the practical meaning of analysis traceability.

Pitfall #27: Assuming the TLF and ADaM Automatically Agree

It is possible for an ADaM dataset to be internally correct while the TLF program applies different selection logic.

For example:

ADaM:
ANL01FL = "Y"

TLF program:
PARAMCD = "SYSBP"
and
AVISIT = "Week 12"
and
not missing AVAL

If the TLF program silently adds or removes conditions that are not reflected in the intended analysis definition, the result may not correspond to the specified analysis.

A strong TLF architecture makes the analysis population and parameter selection explicit.

Pitfall #28: Not Preserving the Study's Analysis Intent

CDISC compliance does not automatically guarantee statistical correctness.

A perfectly structured ADaM dataset can still implement the wrong analysis.

For example, an endpoint may require:

• A specific analysis window
• A specific baseline rule
• A specific censoring rule
• A specific handling of intercurrent events
• A specific population definition

If the programming follows the dataset structure but ignores the statistical analysis specification, the resulting dataset can be technically elegant and scientifically wrong.

Pitfall #29: Ignoring Therapeutic-Area Guidance

Foundational SDTM knowledge is not always enough.

Therapeutic-area implementation guides can contain important domain-specific modeling expectations.

Examples include:

• Oncology
• Cardiovascular disease
• Diabetes
• COVID-19
• Multiple sclerosis
• Parkinson's disease
• Respiratory disease

A common mistake is to implement only the foundational model and ignore therapeutic-area conventions.

The correct workflow is:

Pitfall #30: Forgetting External Dictionaries

Clinical submissions frequently depend on external dictionaries and coding systems.

Examples include:

• MedDRA
• WHODrug
• LOINC
• SNOMED CT
• UCUM

The submission should clearly identify the applicable versions where required.

Using one dictionary version to code data and another version in the metadata can create inconsistencies.

Pitfall #31: Incorrect Unit Handling

Units can create subtle but serious problems.

For example:

Collection:
mg/dL

Analysis:
mmol/L

SDTM:
mg/dL

Define-XML:
mmol/L

The physical values, standardized units, and metadata must be coherent.

Unit standardization should consider:

• Collected unit
• Standardized unit
• Conversion factor
• Precision
• Rounding
• Reference ranges
• Controlled terminology

Pitfall #32: Incorrect Numeric Precision

A conversion can be mathematically correct but still produce an inappropriate representation if precision is not controlled.

For example:

If the analysis specification requires a particular number of decimal places, the conversion and rounding rules should be explicit.

Do not allow different programs to independently decide how many decimal places to retain.

Pitfall #33: Incorrect SUPPQUAL Relationships

Supplemental qualifier structures can become problematic when teams use them as a generic storage location for information that should have been represented elsewhere.

Before placing a variable into supplemental qualifiers, determine whether:

• The variable already exists in the parent domain.
• A standard variable should be used.
• The information belongs in another domain.
• The information genuinely represents a supplemental qualifier.

The relationship between the supplemental record and parent record must also be maintained correctly.

Pitfall #34: Incorrect RELREC Relationships

Relationships between records are particularly important when one observation depends on or relates to another observation.

Incorrect relationships can cause the reviewer to misinterpret the clinical meaning of the records.

Examples include:

• Linking the wrong parent record
• Incorrect identifiers
• Missing relationship records
• Relationships that cannot be reconstructed

Relationship structures should be independently reviewed rather than assuming that identifiers are correct because the individual domains passed validation.

Pitfall #35: Poor Dataset Labels

A dataset name such as:

adlb.xpt

tells the reviewer very little.

The metadata should provide a meaningful description of what the dataset contains.

Compare:

Bad:
"Analysis dataset"

Better:
"Laboratory Analysis Dataset"

The dataset label should communicate the dataset's purpose and content clearly.

Pitfall #36: Missing or Ambiguous Comments

A comment is valuable when it resolves a question that the standard structure cannot answer by itself.

Useful comments can explain:

• Study-specific implementation decisions
• Known deviations
• Nonstandard data sources
• Complex derivations
• Unusual missingness
• Known validation findings

Comments should not simply restate the variable label.

Pitfall #37: Submission Reviewers Have to Reverse Engineer the Study

A technically compliant submission can still be frustrating to review if the reviewer has to reconstruct the study's data architecture.

The reviewer should be able to understand:

Pitfall #38: Treating Define-XML as a Programming Deliverable

Define-XML is sometimes left entirely to the final stage of the project.

This creates a serious problem because metadata decisions often expose underlying data-design problems.

For example, when trying to document a variable, the team may discover that:

• The origin is unclear.
• The derivation was never formally specified.
• The source dataset is ambiguous.
• The controlled terminology is uncertain.
• The value-level metadata was never defined.

These are not merely metadata problems. They are signs that the underlying analysis specification or dataset design may need improvement.

Pitfall #39: Generating Define-XML Automatically Without Reviewing It

Automation is valuable.

Blind automation is dangerous.

An automated generator can accurately reproduce incorrect metadata.

For example:

Dataset
   |
   +-- Variable exists
   |
   +-- Generator documents variable
   |
   +-- But derivation is wrong
   |
   +-- Define-XML is technically populated
   |
   +-- Reviewer receives incorrect explanation

The Define-XML should therefore receive substantive review, not just schema validation.

Pitfall #40: Failing to Check Define-XML Against the Standards

Define-XML conformance includes more than well-formed XML.

The document should be checked against:

• The selected Define-XML version
• The applicable Define-XML schema
• Define-XML conformance rules
• Controlled terminology expectations
• The actual datasets
• The study's implementation conventions

A document can be valid XML and still be poor submission metadata.

Pitfall #41: Using Outdated Controlled Terminology in Metadata

Controlled terminology releases are updated over time.

A submission should identify and consistently apply the terminology version appropriate to the study and submission.

This becomes particularly important when terminology changes between development milestones.

Pitfall #42: Ignoring the Difference Between CDISC and FDA Requirements

CDISC develops standards. FDA determines which study-data standards and versions it supports for regulatory submissions.

These concepts are closely related but not identical.

A common misconception is:

That is not a safe assumption.

Submission planning must consider the applicable FDA Data Standards Catalog, technical conformance guidance, submission timing, and study-specific circumstances.

Pitfall #43: Forgetting That Submission Timing Matters

The relevant standards landscape changes over time.

A project that began several years ago may be governed by different supported versions than a newly initiated study.

Therefore, the submission team should maintain a historical record of:

• Study start date
• Applicable FDA standards support
• Standards versions selected
• Controlled terminology release
• Implementation-guide versions
• Submission-specific regulatory decisions

This prevents a late-stage debate over why a particular standards version was selected.

Pitfall #44: Not Rechecking Requirements Before Submission

The opposite mistake is assuming that the standards selected at study startup are automatically sufficient for the final submission.

A submission-readiness review should confirm the current regulatory requirements applicable to the actual submission.

This is especially important when:

• The study has been running for several years.
• Standards have been updated.
• The submission type has changed.
• The sponsor is submitting to multiple regions.
• The study contains new data types.

Pitfall #45: Incorrect XPT / Transport-File Assumptions

The physical submission format imposes constraints that should be considered throughout the programming lifecycle.

Do not wait until the final packaging step to discover:

• Invalid variable names
• Unexpected variable lengths
• Unsupported characters
• Encoding issues
• Dataset naming problems
• File corruption
• Incorrect labels

The exact technical requirements depend on the applicable FDA submission specifications and supported format.

Pitfall #46: Filename and Dataset Naming Problems

A surprisingly common failure is inconsistent naming.

For example:

adsl.xpt
ADSL.xpt
adsl_final.xpt
adsl_submission.xpt

The final submission package should follow the approved naming conventions consistently.

Dataset naming should also align with:

• Define-XML
• Reviewer documentation
• Submission package structure
• Internal dataset inventory

Pitfall #47: Missing Datasets That Were Expected

A technically valid submission can still be incomplete if a required dataset or supporting metadata component is missing.

Create a submission inventory.

Pitfall #48: Not Reconciling Dataset Inventories

Maintain at least three inventories:

1. Programmer-generated dataset inventory
2. Define-XML dataset inventory
3. Final submission-package inventory

These should reconcile exactly where applicable.

Any difference should be investigated rather than assumed to be harmless.

Pitfall #49: Failing to Reconcile SDTM and ADaM Subject Counts

Subject counts provide a simple but powerful sanity check.

For example:

Differences may be completely legitimate. The problem is unexplained differences.

Pitfall #50: Ignoring Cross-Dataset Reconciliation

Important identifiers and attributes should be reconciled across datasets.

Examples include:

• USUBJID
• STUDYID
• SITEID
• ARM
• ACTARM
• Treatment codes
• Dates
• Analysis populations

A simple reconciliation can reveal problems that domain-specific validation cannot detect.

Cross-Dataset QC Example

DM
 |
 +-- USUBJID
 |
 +---- ADSL
 |       |
 |       +-- Treatment
 |       +-- Population Flags
 |
 +---- ADAE
 |       |
 |       +-- Treatment
 |       +-- TRTEMFL
 |
 +---- ADLB
 |       |
 |       +-- Treatment
 |       +-- ANL01FL
 |
 +---- ADTTE
         |
         +-- Treatment
         +-- Censoring

The question is not simply whether each dataset is valid independently.

The question is whether the same patient is represented consistently across the submission.

Pitfall #51: Inconsistent Study Identifiers

Identifiers should be standardized and reconciled across all submitted components.

Common problems include:

• Case differences
• Trailing spaces
• Unexpected prefixes
• Different study identifiers across datasets
• Incorrect sponsor-specific identifiers

These errors can prevent otherwise correct datasets from being linked properly.

Pitfall #52: Ignoring Character Case and Whitespace

A value that looks identical to a human may not be identical to a computer.

"SUBJ001"
"SUBJ001 "
"subj001"

Depending on the variable and standard, these may have different implications.

Submission QC should identify:

• Leading spaces
• Trailing spaces
• Unexpected capitalization
• Non-printing characters
• Unexpected Unicode characters

Pitfall #53: Incorrect Handling of Non-ASCII Characters

Modern clinical data can contain characters that were not common in older submission workflows.

Potential problems include:

• Names containing diacritics
• Special symbols
• Non-Latin characters
• Smart quotes
• Unexpected encoding

Submission pipelines should be tested using representative production data, not only synthetic ASCII-only examples.

Pitfall #54: Not Testing the Actual Final Package

Testing individual datasets is not equivalent to testing the final submission.

A final-package test should validate the actual files that will be delivered.

Development files
      |
      v
Production datasets
      |
      v
Define-XML
      |
      v
Package assembly
      |
      v
FINAL PACKAGE
      |
      v
Validation
      |
      v
Independent review

This catches problems introduced during copying, renaming, packaging, or metadata replacement.

Pitfall #55: Changing Data After Final Validation

This is one of the most dangerous process failures.

Suppose final validation occurs on:

ADSL_2026_09_01.xpt

and the team subsequently modifies:

ADSL_2026_09_02.xpt

The previous validation result no longer establishes the conformance of the new file.

Any substantive post-validation change should trigger impact assessment and, when appropriate, revalidation.

Pitfall #56: Treating "No Findings" as the End of QC

Automated validation answers only some questions.

It may not detect:

• A scientifically incorrect derivation
• An incorrect analysis population
• A wrong baseline rule
• A misleading label
• A missing clinical concept
• A wrong treatment assignment
• An incomplete explanation
• A mismatch between the SAP and programming

Therefore:

is a stronger model of submission readiness.

Pitfall #57: No Independent Review of Derived Variables

Independent review is particularly important for high-impact derivations.

Examples include:

• Analysis populations
• Baseline
• Change from baseline
• Response categories
• Time-to-event variables
• Censoring
• Treatment-emergent flags
• Exposure durations
• Protocol deviation flags

A second programmer or independent validation program should reproduce the important logic wherever appropriate.

Pitfall #58: Using Only Program Comparison as QC

Program-to-program comparison is useful but not sufficient.

Two programmers can independently implement the same incorrect specification.

Therefore, independent validation should combine:

• Program comparison
• Source-data review
• Specification review
• Statistical review
• Clinical review where applicable
• Aggregate reconciliation

Pitfall #59: Poor Documentation of Known Issues

Known issues should be documented while the reasoning is still fresh.

A useful issue record contains:

Avoid vague explanations such as:

"Known issue. No impact."

Instead explain:

"The finding is generated because [specific condition].
The condition is expected because [study-specific reason].
The affected records represent [clinical meaning].
No correction is made because [technical/scientific rationale]."

Pitfall #60: Treating Reviewer Documentation as an Afterthought

Reviewer documentation should not be written only after all programming is complete.

The document should capture decisions made throughout development.

Useful topics include:

• Standards versions
• Study-specific implementation decisions
• Known validation findings
• Important data peculiarities
• Derivation conventions
• Special population definitions
• Data limitations
• Important differences from standard expectations

The Submission Pitfall Matrix

Building a Submission-Readiness Framework

A robust submission process can be organized into seven layers.

Submission Readiness Checklist

A Practical Final QC Architecture

A mature submission process should use multiple independent QC layers.

Automated Reconciliation Examples

Many submission checks can be automated.

Dataset Inventory Reconciliation

Expected datasets
        |
        v
Generated datasets
        |
        v
Define-XML datasets
        |
        v
Submission package

Check:
Expected = Generated = Metadata = Package

Variable Reconciliation

For each dataset:

Dataset variables
        |
        +---- Define-XML variables
        |
        +---- Expected standard variables
        |
        +---- Controlled terminology
        |
        +---- Length/type attributes

Subject Reconciliation

DM subjects
   |
   +---- ADSL subjects
   |
   +---- Safety subjects
   |
   +---- Efficacy subjects
   |
   +---- TTE subjects

Investigate every unexpected difference.

Example SAS QC Pattern

A simple subject-count reconciliation can be implemented with SAS.

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

proc sql;
  select count(distinct usubjid) as n_subjects
  from adae;
quit;

The counts should not necessarily be identical. The purpose is to identify differences that require explanation.

Example R QC Pattern

library(dplyr)

adsl %>%
  summarise(
    n_subjects = n_distinct(USUBJID)
  )

adae %>%
  summarise(
    n_subjects = n_distinct(USUBJID)
  )

Checking Duplicate Subject Records

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

For a subject-level dataset such as ADSL, any returned records should be investigated.

Checking for Unexpected Whitespace

adsl %>%
  filter(
    USUBJID != trimws(USUBJID)
  )

Checking for Missing Key Variables

adsl %>%
  summarise(
    missing_usubjid = sum(is.na(USUBJID)),
    missing_studyid = sum(is.na(STUDYID)),
    missing_trt = sum(is.na(TRT01P))
  )

These checks are simple, but they are valuable because they detect problems that may otherwise survive until late in the submission process.

Metadata-First Programming

One of the strongest improvements a statistical programming organization can make is to move metadata development earlier in the lifecycle.

Instead of:

Dataset
   ↓
TLF
   ↓
Define-XML at the end

consider:

Specification
   ↓
Metadata design
   ↓
Dataset design
   ↓
Programming
   ↓
Validation
   ↓
Final metadata reconciliation

This exposes ambiguity earlier.

Why Metadata-First Development Works

If a variable cannot be clearly described before programming begins, that may indicate that the variable itself is poorly specified.

For every important derived variable, ask:

Common Anti-Patterns

The 10 Highest-Risk Submission Pitfalls

If time is limited, prioritize these ten areas.

1. Wrong applicable standards version
2. Inconsistent controlled terminology
3. Incorrect SDTM modeling
4. Incorrect baseline or population derivations
5. Incomplete ADaM traceability
6. Incomplete or inaccurate Define-XML
7. Dataset/metadata mismatches
8. Unresolved or poorly explained validation findings
9. Cross-dataset inconsistencies
10. Changes after final validation without revalidation

Submission Readiness: A Five-Question Test

Before submission, ask five questions.

A Submission-Ready Data Flow

The following architecture illustrates the overall goal.

                    ┌──────────────────────┐
                    │  Source / Collected   │
                    │        Data           │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │        SDTM          │
                    │ Standardized Clinical│
                    │     Tabulation       │
                    └──────────┬───────────┘
                               │
                    ┌──────────┴───────────┐
                    │                      │
                    ▼                      ▼
          ┌──────────────────┐   ┌──────────────────┐
          │     Define-XML   │   │      ADaM        │
          │    SDTM Metadata │   │ Analysis Data    │
          └──────────────────┘   └────────┬─────────┘
                                          │
                                          ▼
                                ┌──────────────────┐
                                │      TLFs         │
                                │ Tables/Listings/ │
                                │     Figures      │
                                └──────────────────┘

       Cross-cutting controls:
       standards → terminology → validation → traceability → QC

The Submission Is a System, Not a Folder

One of the most useful ways to think about regulatory submissions is as a system of linked evidence.

The reviewer should be able to move from:

and also use metadata to understand every transition:

When these relationships are clear, the submission becomes much easier to review.

Final Submission QC Checklist

What Statistical Programmers Should Remember

For statistical programmers, the most important lesson is that CDISC submission programming is not primarily about knowing variable names.

The deeper skill is understanding how the components fit together.

A strong programmer should be able to move between:

• Clinical meaning
• CDISC modeling
• Statistical analysis
• Dataset derivation
• Metadata
• Validation
• Traceability
• Regulatory review

The best submission programs are therefore not merely programs that create datasets.

They are programs that create datasets whose meaning can be reconstructed, validated, and defended.

Summary

The most common CDISC submission pitfalls are rarely caused by a single incorrect variable.

They usually arise from disconnects between components:

• Standards and implementation
• SDTM and ADaM
• ADaM and TLFs
• Datasets and Define-XML
• Controlled terminology and actual values
• Derivations and their documentation
• Validation findings and their explanations
• Final datasets and the final submission package

The strongest way to prevent these problems is to treat the submission as one integrated system.

References

U.S. Food and Drug Administration. Study Data Technical Conformance Guide — Technical Specifications Document. June 2026.

U.S. Food and Drug Administration. Study Data for Submission to CDER and CBER. FDA Study Data Standards Resources.

U.S. Food and Drug Administration. Study Data Standards Resources. FDA.

Clinical Data Interchange Standards Consortium (CDISC). SDTM v2.1.

Clinical Data Interchange Standards Consortium (CDISC). ADaM v2.1 and ADaM foundational guidance.

Clinical Data Interchange Standards Consortium (CDISC). Define-XML v2.1 and current Define-XML v2.1 package updates.

Clinical Data Interchange Standards Consortium (CDISC). Conformance Rules for Define-XML v2.1.

Clinical Data Interchange Standards Consortium / NCI EVS. CDISC Controlled Terminology and terminology release documentation.

Clinical Data Interchange Standards Consortium (CDISC). Data Exchange standards and regulatory submission metadata guidance.