What Is CDISC? A Complete Guide to Clinical Data Standards

Introduction

Pharmaceutical companies were once free to submit clinical trial data to the FDA in whatever internal format they preferred. Each sponsor built its own dataset structures, named its own variables, and organized its outputs according to its own conventions. A regulatory reviewer moving from one sponsor's submission to the next had to learn a new schema each time before scientific review could begin. Cross-study comparisons were close to impossible.

CDISC was built to solve that. The Clinical Data Interchange Standards Consortium is a global nonprofit organization founded in 1997 by Rebecca Kush, PhD, to develop platform-independent standards for clinical research data ^[1],[24]. Its standards define how data should be collected, structured, labeled, and submitted, from the first electronic case report form (eCRF) field at an investigative site through to the final analysis dataset in a regulatory submission package. For sponsors submitting to the U.S. FDA, Japan's PMDA, Denmark's DKMA, and other regulators that mandate standardized study data, CDISC standards determine whether a submission can be efficiently processed and reviewed once it arrives at the agency.

Why CDISC Matters in Clinical Trials

The practical case for CDISC rests on both efficiency and regulatory compliance. On the efficiency side, a 2006 Business Case project conducted by CDISC and Gartner, with support from PhRMA, found that implementing CDISC standards can reduce resource requirements by up to 60% overall for a single clinical research study, with start-up savings reaching up to 80% when standards are adopted at the beginning of a trial ^[2]. The findings came from interviews with 35 individuals across 22 companies in the U.S. and Europe. The savings reflect the compounding cost of not having to rebuild, re-label, and re-map data as a study moves from collection toward submission. Specific results will vary by study size, complexity, and baseline practices, and the research itself dates from the mid-2000s; teams in heavily automated environments today may see different ratios.

The regulatory case is more direct. FDA has built internal reviewer tools designed to work with CDISC-formatted datasets, allowing reviewers to run standard analyses without custom programming and generate data visualizations that support identification of safety signals and missing data patterns ^[3]. Standardized data makes the agency's review more efficient, which is part of why the agency moved to require it.

The CDISC Standards Family

CDISC does not publish a single standard. It maintains a suite of interlocking frameworks, each addressing a different stage of the data lifecycle. Four foundational standards drive most of the work in a regulated clinical trial: CDASH, SDTM, SEND, and ADaM. These operate alongside controlled terminology, therapeutic area extensions, and data exchange formats.

At a Glance: Required vs. Useful Upstream

CDASH: Data Collection

The Clinical Data Acquisition Standards Harmonization standard (CDASH) defines how data should be collected on case report forms. It specifies variable names, field labels, and collection formats so that what a coordinator enters at a clinical site maps directly to the downstream submission format ^[4]. Without CDASH, a participant's weight might appear as "WT" at one site and "body_weight_kg" at another. CDASH removes that inconsistency before it can propagate into downstream datasets.

CDASH is not itself mandated by FDA for submission, but its adoption at the eCRF design stage substantially reduces the mapping effort required to produce compliant Study Data Tabulation Model datasets later ^[4]. Teams that designed non-CDASH forms and applied SDTM conversion retroactively after database lock found the process significantly harder: more complex mapping decisions, traceability gaps requiring programming workarounds, and documentation challenges for issues that could not be fully resolved ^[5].

SDTM: Organizing Clinical Data for Submission

The Study Data Tabulation Model defines a universal structure for clinical trial tabulation datasets, organizing data into domain-specific tables. Domains cover Demographics (DM), Adverse Events (AE), Laboratory Results (LB), Vital Signs (VS), and a range of additional standard categories defined in the SDTMIG; the full set of domains varies across SDTMIG versions ^[6]. Each row represents a single observation; columns represent defined variables with specified names, data types, and permissible values. Dataset metadata is submitted separately using the Define-XML exchange standard.

SDTM is one of the required standards sponsors must use, as specified in the FDA's Data Standards Catalog, for NDA, ANDA, and certain BLA submissions, effective December 2016 ^[6]. It is also required by Japan's PMDA. The SDTM Implementation Guide (SDTMIG) provides the practical specifications teams use to build compliant datasets.

SEND: The Nonclinical Standard

The Standard for Exchange of Nonclinical Data applies SDTM's organizing framework to preclinical animal toxicology and safety pharmacology studies. Its implementation guide (SENDIG) defines the domains and variables appropriate for nonclinical work ^[7]. SEND is required by FDA for nonclinical studies supporting NDAs, certain ANDAs, and BLAs, meaning sponsors with applicable nonclinical studies need SDTM-compliant clinical data and SEND-compliant nonclinical data in the same submission package.

ADaM: From Tabulation to Analysis

The Analysis Data Model occupies the space between SDTM and the statistical outputs in a clinical study report. Per CDISC's specification, ADaM defines dataset and metadata standards that support the efficient generation, replication, and review of clinical trial statistical analyses, and traceability between analysis results, analysis data, and data represented in SDTM ^[8]. ADaM datasets are derived from SDTM, organized to support the statistical analyses described in the protocol and statistical analysis plan, and they drive the production of tables, listings, and figures (TLFs).

The traceability requirement in ADaM is not a formality. When a reviewer wants to understand how a specific efficacy endpoint was calculated, ADaM provides the documented path from the reported result back to the observed data. Without it, the submission's analytic chain is opaque and cannot be independently replicated.

Controlled Terminology

CDISC Controlled Terminology (CT) is the vocabulary standard governing the acceptable values used within CDISC datasets. It is developed jointly with the National Cancer Institute's Enterprise Vocabulary Services (NCI-EVS) and published quarterly ^[9]. The collaboration ensures consistency with the broader NCI Thesaurus and supports semantic interoperability across systems ^[10].

The practical implication is that every codelist field has an approved set of submission values, and anything outside that set fails conformance validation. For the SEX variable in the Demographics domain, for example, the accepted submission values are M (Male), F (Female), U (Unknown), and UN (Undifferentiated) ^[9],[23]. Other spellings, abbreviations, or numeric codes are non-compliant. Because controlled terminology is updated quarterly, teams must verify that their implementation aligns with the specific catalog version accepted by the relevant agency for their submission; the currently accepted CT package is listed in the FDA Data Standards Catalog ^[22].

Therapeutic Area User Guides

For disease-specific data elements beyond the foundational standards, CDISC publishes Therapeutic Area User Guides (TAUGs) covering Alzheimer's disease, cardiovascular disease, diabetes, oncology, virology, and other areas ^[11]. Each TAUG extends the foundational standards with disease-specific metadata, variable definitions, and worked examples. FDA periodically updates which TA standards it supports, reflected in the FDA Data Standards Catalog and the Study Data Standards Resources page; sponsors working in specific disease areas should verify the current catalog before finalizing their data management specifications.

Operational Impact for Sponsors, CROs, and Sites

The most consequential CDISC-related decision a sponsor makes is when to adopt the standards. CDASH delivers the greatest value before the first eCRF is designed. An academic research organization that initially applied SDTM conversion only after database lock found that subsequent studies, which used CDASH-compliant forms from the start, required substantially less mapping effort and produced more tractable SDTM datasets throughout the study lifecycle ^[5]. Retroactive conversion is not just a data management challenge; it is a documentation and audit trail challenge, and unresolvable issues require programmatic workarounds and written justification ^[5],[12].

That early-adoption advantage scales directly to multi-site studies. Data from 30 sites using CDASH-aligned forms is structurally consistent from the day of entry; data from 30 different internal formats requires normalization before any cross-site analysis can begin. For integrated safety and efficacy summaries, which pool data from multiple completed studies, the difference between consistent SDTM domains and inconsistent legacy formats can represent months of reconstruction work.

A Practical Pre-Study Checklist

For sponsors starting a new study, the following reduces CDISC-related friction downstream:

Regulatory and Documentation Considerations

FDA's binding guidance on standardized study data, published in December 2014, established a compliance schedule tied to study start dates, not submission dates. Studies submitted in NDAs, ANDAs, and certain BLAs must comply with FDA-supported CDISC standards if the study started after December 17, 2016. The requirements vary by submission type and data category; the full applicability matrix is detailed in FDA TCG Table 6 ^[13],[14].

Teams should consult the current FDA Data Standards Catalog ^[22] and the most recent TCG for the accepted standard versions and any updated applicability provisions before study initiation. Not all data types and application sections are covered uniformly. Standard versions accepted by FDA are updated periodically, and submitting a version no longer listed in the catalog can itself generate conformance issues; verification against the current catalog at the time of study design and again before submission is advisable.

The FDA Data Standards Catalog specifies SDTM, SEND, ADaM, Define-XML, and CDISC Controlled Terminology as the required standards for applicable submissions ^[22]. The Study Data Technical Conformance Guide (TCG), most recently updated in March 2026, is a technical specifications document that supplements the binding electronic study data guidance; it is not itself a binding guidance document but provides the specifications and recommendations that sponsors should follow to prepare a reviewable submission package ^[14]. The TCG's Technical Rejection Criteria (TRC) describe the conditions under which FDA may issue a refuse-to-file (RTF) or refuse-to-receive (RTR) action when submitted data fails to meet standard requirements ^[14]; see also ^[13] for a practical overview of TRC scenarios.

Japan's PMDA, a Platinum Member of CDISC, has required CDISC standards for new drug applications submitted since October 1, 2016 ^[15]. Denmark's DKMA requires CDISC format for marketing authorization applications and certain variations ^[16]. China's NMPA has formally recommended CDISC standards, specifically SDTM and ADaM, for clinical data submissions ^[16]. The European Medicines Agency (EMA) has been conducting structured pilot programs evaluating CDISC-formatted data in regulatory review: a clinical study data proof-of-concept pilot accepting SDTM and ADaM submissions has been running since September 2022 ^[17], and a separate SEND proof-of-concept study was launched in January 2024 to evaluate nonclinical data review ^[18]. EMA has not issued a binding mandate equivalent to FDA or PMDA requirements; teams planning EU submissions should verify current EMA guidance directly.

AI and Automation Perspective

Producing a CDISC-compliant submission package manually is resource-intensive. Mapping raw site data to SDTM domains, generating Define-XML metadata, running conformance checks, deriving ADaM datasets from SDTM, and documenting the full audit trail across all of it has historically consumed substantial statistical programming effort on every trial.

Validation tools have begun to reduce that workload in targeted ways. Engines like Pinnacle 21 check datasets against CDISC conformance rules and produce structured reports of violations, allowing teams to identify and address issues earlier rather than discovering them at submission review. EDC systems with built-in CDASH templates generate collection forms already aligned with SDTM requirements, narrowing the mapping gap at source. These tools do not eliminate the judgment calls involved in SDTM domain assignment, non-standard variable documentation, or handling unexpected data values; they surface the conformance errors that follow from those decisions.

CDISC's own 360i initiative, officially launched in March 2025, is the organization's most ambitious automation project ^[19]. The vision is end-to-end standards connectivity: a machine-readable protocol specification feeding into CDASH data collection design, which feeds into SDTM mapping, which feeds into ADaM derivations and analysis outputs, with full traceability maintained throughout the chain. At the 2025 U.S. Interchange in October, CDISC presented a clickable prototype developed with PwC to demonstrate this workflow against a breast cancer oncology use case. A global AI Innovation Challenge launched in June 2025 drew teams applying AI and machine learning to CDISC-related tasks ^[19].

CDISC has also been working with the Vulcan HL7 FHIR Accelerator on a joint project to develop an exchange standard for ICH M11 and to bridge CDISC standards with FHIR-formatted real-world healthcare data ^[20]. Patient data from EHRs increasingly arrives in FHIR format; mapping that to SDTM currently requires specialized manual effort. Standardized FHIR-to-SDTM mapping specifications would substantially reduce that burden if they mature into accepted practice.

The 2023 release of CDISC Dataset-JSON introduced a JSON-based alternative to the legacy SAS Transport (XPT) format for dataset submission. FDA published its Dataset-JSON Pilot Report in July 2024, confirming technical feasibility while noting that some FDA analytical tools still require updates to process the new format fully ^[21]. The shift reflects where statistical programming is heading as R and Python gain adoption in clinical data science alongside SAS.

Two constraints remain constant through all of these changes. First, automated validation tools identify conformance violations; they do not resolve the clinical and methodological judgment calls that produced them. Second, CDISC-compliant submission packages still require qualified human review. The tools change what that review time is spent on, not whether it is required.

How Kitsa Fits Into This Problem

Regulatory document generation sits directly downstream of CDISC-structured data. A protocol's treatment arms, planned assessments, and primary endpoints are represented across multiple interdependent artifacts: SDTM Trial Design datasets capture the study's structure; ADaM derivation specifications encode the analytic logic for each endpoint; and the clinical study report narrative, statistical analysis plan, Study Data Reviewer's Guide (SDRG, which documents clinical SDTM datasets), and Analysis Data Reviewer's Guide (ADRG, which documents ADaM analysis decisions) must all reflect that structure consistently. When the data are well-organized from the start, these documents fit together without gaps. Kitsa's KScribe platform generates regulatory documents that align with the CDISC-structured data sponsors produce, reducing the manual reconciliation between statistical outputs and the narrative content that regulators review alongside them.

Key Takeaways

• •CDISC is a global nonprofit that maintains data standards for clinical research, covering the full data lifecycle: eCRF design (CDASH), tabulation submission (SDTM, SEND), statistical analysis (ADaM), data exchange (Define-XML, Dataset-JSON), and vocabulary (Controlled Terminology).
• •FDA requires CDISC-formatted submissions for NDAs, ANDAs, and certain BLAs where the clinical study started after December 17, 2016. Requirements vary by data type and submission category; the full applicability matrix is in FDA TCG Table 6.
• •A 2006 Gartner/CDISC/PhRMA Business Case study found that CDISC implementation can reduce resource requirements by up to 60% overall and up to 80% at study start-up. These figures reflect the mid-2000s baseline and vary substantially by study type and context.
• •Submissions that fail FDA's Technical Rejection Criteria for data standards may receive a refuse-to-file or refuse-to-receive action. Less severe conformance issues generate data validation notes requiring correction before review proceeds.
• •CDASH adoption before eCRF build reduces SDTM mapping effort downstream. Teams that converted non-standard data to SDTM retroactively after database lock report substantially more difficult and time-intensive processes.
• •CDISC's 360i initiative (launched March 2025) aims to connect standards end-to-end from protocol design through submission via automation. It is a multi-year effort; current automation covers validation tooling and prototyping, not full workflow replacement.
• •FHIR integration, Dataset-JSON, and the ICH M11 digital protocol standard are near-term evolutions in how CDISC standards interact with broader health data formats.

FAQ

References

You Might Also Like