CDASH

Introduction

CDASH: The Clinical Data Acquisition Standards Harmonization Implementation Guide (CDASHIG) establishes a standard way to collect data consistently across studies and sponsors so that data collection formats and structures provide clear traceability of submission data into the SDTM, delivering more transparency to regulators and others who conduct data review. The following videos introduce you to the CDASH model and the CDASHIG.


Versions

The latest versions of the Clinical Data Acquisition Standards Harmonization Implementation Guides (CDASHIGs) have been developed in reference to a specific CDASH model. However, the CDASH model is cumulative – each new release builds on the previous model. Therefore, the models are considered backward compatible.

Version Related
CDASHIG v2.3

CDASH Model v1.3
CDASH SAE Supplement v2.0
CDASHIG v2.2

CDASH Model v1.2
CDASH SAE Supplement v2.0
CDASHIG v2.1

CDASH Model v1.1
CDASH SAE Supplement v2.0
CDASHIG v2.0

CDASH Model v1.0
CDASH v1.1

CDASH Serious Adverse Event (SAE) Supplement v1.0

Therapeutic Area User Guides

Therapeutic Area User Guides (TAUGs) extend the Foundational Standards to represent data that pertains to specific disease areas. TAUGs include disease-specific metadata, examples and guidance on implementing CDISC standards for a variety of uses, including global regulatory submissions. The following video will introduce you to TAUGs and how they relate to CDISC Foundational Standards.

Controlled Terminology

Controlled Terminology is the set of codelists and valid values used with data items within CDISC-defined datasets. The following video introduces you to CDISC Controlled Terminology and how it is used with CDISC standards.

Traceability

Traceability is a fundamental element of data quality and a requirement for studies submitted to regulatory authorities. From data collection to final analysis, traceability plays a crucial role in ensuring the integrity of source data and in reinforcing clinical research results. The following video provides an introduction to implementing traceability in CDISC-compliant studies.

Regulatory Requirements

CDISC standards are required or recommended by several global regulatory agencies. Standardized data enables regulators to streamline the review process with a more consistent use of analysis tools to better view drug data and highlight areas of concern. The following video introduces you to regulatory requirements and the use of CDISC standards.

Team Guiding Principles

Statement:

CDASHIG metadata will be developed using the same Observation Classes and Domains as SDTMIG.

Rationale:

Using the same domain names for collection and tabulation builds in high-level traceability and gives implementers the opportunity to automate some SDTMIG dataset creation.

Key Benefits:

Regulatory reviewers appreciate traceability. Implementers appreciate efficiency and the ability to automate.


Statement:

When concepts are related but not identical, or when values are not identical (except for case), the names will be similar and shall indicate a degree of relatedness. For example, substance use duration may be collected using the CDASHIG variables SUCDUR and SUCDURU with the respective values of "5" and "YEARS", but submitted as SUDUR = "P5Y". 

Rationale:

Using the same variable name for data collection and data tabulation allows implementers to directly populate identical collection and tabulation variables.  

Key Benefits:

Efficiency and clear traceability.


Statement:

When developing the standard, consider the needs of all stakeholders (e.g., clinical team members, sites, clinical data managers, SDTM programmers, statisticians and statistical programmers) and balance the needs of each. 

Rationale:

CDISC develops standards that benefit all stakeholders. Decisions made in developing CDASH must weigh the cost-benefit ratio for all stakeholders.

Key Benefits:
  • Optimizing CDASH for all stakeholders supports wider adoption.
  • Weighing all viewpoints helps to respond to inquiries from stakeholder representatives during public review and beyond.

Statement:

CDASH will share value lists with SDTM controlled terminology codelists, using the CDISC Submission Values as much as possible, or synonyms where the CDISC Submission Values are not practical for data collection.

Rationale:

Using the same (or synonymous) values for data collection and submission results in greater transparency, traceability, and efficiency.

Key Benefits:

Efficiency and clear traceability.


Statement:

CDASH creates standardized questions that match the CDASH definition of the variable.

Rationale:

The basis for semantic interoperability is that every time we use the variable/question it means the same thing.

Key Benefits:

Semantic interoperability allows us to combine data across studies and get a meaningful result, and also makes data useful outside the context of a single study.

Standards in Development

Foundational

For current versions of the standards, please visit the Standards Home Page.


Standard Release Notes Projected Publication
ADaM Oncology Examples

Resolving Public Review Comments

 2024
ADaM v3.0

In Development

 2026
CT Relationships for SDTM v1.7, SDTMIG v3.3, SDTMIG-MD v1.1

Resolving Public Review Comments

 2024
SDTM v2.2

In Development

 2025
SDTMIG v4.0

In Development

 2025
SENDIG v4.0

In Development

 2025

Data Exchange

Therapeutic Areas

For current versions of the Therapeutic Area (TA) standards, please visit the TA Home Page.


Therapeutic Area Release Notes Projected Publication
Duchenne Muscular Dystrophy Therapeutic Area User Guide v1.0

Version 1.0 of the Duchenne Muscular Dystrophy Therapeutic Area User Guide (TAUG-DMD) was developed under the CFAST Program and the CDISC Standards Development Process. The TAUG-DMD describes the most common biomedical concepts relevant to Duchenne Muscular Dystrophy, and the necessary metadata to represent such data consistently with Terminology and  SDTM.

TA Standards extend the Foundational Standards to represent data that pertain to specific indications within disease areas. CDISC Standards specify how to structure the data; they do not specify what data should be collected or how to conduct clinical trials, assessments or endpoints.

Public Review Comments

CDISC posts Public Review comments and resolutions to ensure transparency and show implementers how comments were addressed in the standard development process.

TA Specifications

TA Specifications show how to modify TAUG examples for various versions of the SDTM and SDTMIG. These specifications assist the FDA and the Japanese PMDA with testing to enable support of the standards and inclusion in their respective Technical Conformance Guides.1,2

The specifications comprise five worksheets in an Excel workbook:

  • Read Me – Information on how to read the other worksheets
  • Summary – Table of Contents for the TAUG annotated with examples and the domains and variables they use
  • Known Issues – A list of modeling issues noted in the TAUG
  • Domains – Domains used and their status in different versions of the SDTMIG
  • Variables – Variables used and their status in different versions of the SDTM
  1. https://www.fda.gov/industry/fda-resources-data-standards/study-data-standards-resources
  2. https://www.pmda.go.jp/english/review-services/reviews/0002.html
 2024

Knowledge Base

Articles
A Short History of CDISC and SAS Transport Files
Are These Findings Just Repeats or Were They Scheduled at Time Points?
CDISC-Annotated CRF Repository in Japanese
Changing Event Severity
Concept Maps for a Finding with Increasing Levels of Detail
Concept Maps for Adverse Events with Increasing Levels of Detail
Concept Maps for Substance Administration with Increasing Levels of Detail
Domain vs. Dataset: What's the Difference?
How should I represent whether a physical exam was performed in SDTM?
Pre-specified Events and Pre-specified Findings
SDTM and CDASH: Why You Need Both
SDTM Timing Variables for Pre-study Findings
Sex and Gender
Special Values: "MULTIPLE" and "OTHER"
Study Subject Site Transfers Example
TAUG Examples of SDTM Domains
The Magic that Happens between CDASH and SDTM
Translating CDASH "PRIOR" and "ONGO" to SDTM relative timing variables
Use of Fast Healthcare Interoperability Resources (FHIR) in the Generation of Real World Evidence (RWE)
Use of HL7 FHIR as eSource to Pre-populate CDASH Case Report Forms using a CDISC ODM API
When Did That Happen? A Brief Guide to Representing Timing in SDTM.
Why is an Image like a Specimen?
Why Not Just Use SNOMED?
Why Would a Standards Development Organization Make Non-standard Variables Available on their Website?
Examples
Adverse Events (AE) with Device Event Reporting
Background Heart Failure Maintenance Medications aCRF
Body Sites of Psoriasis Involvement at Baseline aCRF
Death aCRF
Device Event Reporting 
Devices Used by Subjects to Manage Diabetes
Diabetes Complications aCRF
Diabetes History 1
End-Stage Renal Disease
Heart Failure Medical History aCRF
Historical Start Date of Menstruation
History of  Autoimmune Disease  (other than Diabetes) 
Hypoglycemia aCRF
Identification of Target Lesions and Measurements aCRF
Insulin Exposure  
Meal Tolerance Testing aCRF
On-Study Crohn's Disease Background Medication, Non-study Drugs
Orchidometer Examination
Pancreatic Cancer Medical History aCRF
Pancreatic Cancer Radiation Therapy aCRF
Pancreatic Cancer Study Treatment Infusion aCRF
Pancreatic Cancer Surgical History aCRF
Plaque Psoriasis Medical History aCRF
Prior Crohn's Disease -Dependency on Corticosteroid Treatments
Prior Psoriasis Treatments aCRF
Renal Replacement Therapy 1
Renal Replacement Therapy aCRF
Self-Monitoring Blood Glucose aCRF
Start Date of Menstruation During a Study 
Vaccination History aCRF
 Diabetic Ketoacidosis - Device In-Use  At Time of Event 
 Diabetic Ketoacidosis Adverse Events
 Pancreatic Cancer Stent Placement aCRF