CDASH CDISC Data ManagementThe Clinical Data Acquisition Standards Harmonization (CDASH) defines basic standards for the collection of clinical trial data. CROS NT explores the importance of CDASH standards for the Clinical Data Manager.

The CDASH standard is part of the Clinical Data Interchange Standards Consortium (CDISC), which is designed to realize the vision of a set of end-to-end harmonized standards for the collection and submission of data from clinical studies.

The set of standards has been, and will continue to be, developed to support the streamlining of processes within medical research from the production of clinical research protocols through to reporting and/or regulatory submission.

What are the purposes of CDASH?

  • Support the integration of research into the clinical workflow as there is growing recognition worldwide that proprietary standards prevent data interchange which is essential for effective partnering and information exchange between clinicians and researchers. More clinicians will be interested in conducting research if the process can be streamlined by integrating it into their workflow.
  • Develop content standards for a basic set of global, industry-wide CRF fields to support clinical research. These CRF standards apply across most therapeutic areas and phases of clinical development (Phases I-IV)

CDASH is intended to be used by the team involved in the planning, collection, management and analysis of clinical trials and clinical data, including: Clinical Investigators, Medical Monitors, Clinical Research Associates (Monitors), Clinical Research Study Coordinators, Clinical Data Managers, Clinical Data and Statistical Programmers, Biostatisticians, Drug Safety, Case Report Form (CRF) Designers and other functions tasked with the responsibility to collect, clean and ensure the integrity of clinical trial data.

There are two levels of CDASH conformance.

Tier I Level

Conformance is evaluated at individual CRF levels as follows:

  • Ensuring all highly recommended and relevant Recommended/Conditional fields for any CDASH domain your study requires are present
    • Check the information in the CDASH Standards to understand when a R/C field is appropriate
    • You do not need to include all CDASH domains in your study in order to be compliant
  • You should only use CDASH domains which are needed
    • If an individual study does not include the collection of Inclusion/Exclusion exceptions because none were allowed, the CRF does not have to be created for the study
    • If you are not using the CRF to reconcile electronic transfers of ECG data, it is not necessary to include a form for the CDASH EG domain
  • Use CDISC Controlled Terminology
    • It is acceptable to use only a subset of the full CT list
    • CDASH provides examples of common CT subsets taken from a full list as published in CDISC CT
    • You are not required to use those same subsets, they are provided as a “starting point” in case you had no existing code lists to use
    • Follow CDISC best practices
  • Use CDASH Question Texts or Prompts
    • Either the full grammatically correct question text or the shorter prompt is permitted, or a semantically consistent equivalent
    • When space is limited, a prompt may be more appropriate but both should not be used on a CRF
    • When very clear descriptions are required, the question text may be more appropriate
    • Special considerations are made for protocol-specific prompts, languages and culture
  • CDASH is meant to eliminate unnecessary variations in CRFs:
    • Usually each study will have some fields that need to be added
    • Therapeutic areas have unique types of data
    • Oncology needs are different from cardiovascular needs
    • Excluding optional fields does not violate conformance
    • Adding fields that are not defined in CDASH is permitted, but they should follow the details in the User Guide under Tier 2 conformance

Tier II Level

Conformance is focused on the operational implementation of CDASH standards:

  • Details are in the User Guide only
  • Tier I conformance rules must be met first, plus:
    • Operational database users CDASH naming conventions
  • Addresses efficiency in mapping operational databases to submission data
  • Facilitates data warehouse building
  • Simplifies transmission and sharing of data between partners
  • CDASH naming conventions:
    • The goal is to have end-to-end traceability of the variable name from the data capture system to the SDTM datasets
    • In some EDC systems, the variable name may have “system” components that become part of the item’s identifier. EDC systems, prior to exporting data in a defined format, may require the variable name to include such database “references” as the EDC page name, the item “group” name, or perhaps a combination. An example could be: <refname>CONMED_IG_CM.IT_CMINDC (As long as the CDASH variable name is part of the system components, the CRF is considered Tier II compliant as the CDASH variable name = CMINDC)
  • Variable Naming Conventions
    • Requires an understanding of SDTM
      • In this case, there is a need to understand where a field will be stored in SDTM
      • CDASH standards Appendix E and SDTMIG v3.1.3 Appendices C1, C5 and D contain variable naming fragments
    • If collected exactly as needed for SDTM, use the SDTM variable name
      • For example: if collecting anatomical location for a Medical History term, this goes to MHLOC in STDM, add question “Location of Medical History Term” and store the data in a variable called MHLOC

CROS NT is a CDISC Gold Member, meaning it has constant access to new data standards and new documentation regarding CDISC standards. CROS NT has helped many companies incorporate CDASH, SDTM and ADaM standards into their organizations and mapped legacy studies to create the necessary consistency in formats.