This implementation guide has been developed to assist in the following activities associated with the collection and compilation of data in a clinical trial.

The Clinical Data Acquisition Standards Harmonization (CDASH) Model, the CDASH Implementation Guide (CDASHIG), and the CDASHIG Metadata Table define basic standards for the collection of clinical trial data and how to implement the standard for specific case report forms. CDASH establishes a standard way to collect data in a similar way across studies and sponsors, so that data collection formats and structures provide clear traceability of submission data into the Study Data Tabulation Model (SDTM), delivering more transparency to regulators and others who conduct data review. The CDASH standard is part of the Clinical Data Interchange Standards Consortium (CDISC) Technical Road Map, which is designed to realize the vision of a set of beginning-to-end harmonized standards for the representation of data from clinical studies throughout the data lifecycle. The CDASH standard directly supports the production of clinical data collection instruments. Through this support, the standard also contributes to:

• Efficient development of research protocols
• Streamlined processes within medical research
• Development of a corporate library of standardized CRFs
• Use of metadata repositories
• Reporting and regulatory submission
• Data warehouse population
• Data archiving
• Post-marketing studies/safety surveillance

For more information, click on the following link: http://www.cdisc.org/strategies-and-goals.

There is growing recognition around the globe that industry standards promote data interchange, which is essential to effective partnering and information exchange between and among clinicians and researchers. Clinical care can more easily reap benefits through medical research findings, and more clinicians will be interested in conducting research if the research process can be integrated into their clinical care workflow. CDISC encourages the adoption of its global standards for clinical research, which should continue to be harmonized with healthcare standards, to provide a means for interoperability among healthcare and research systems such that medical research can support informed healthcare decisions and improve patient safety.

This document is intended to be used by persons 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 Standards Subject Matter Experts (SMEs), 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.

This document has been organized into the following sections:

• Section 1, Orientation
• Section 2, How to Use the CDASH Standard
• Section 3, General Assumptions for Implementing CDASH
• Section 4, Best Practice Recommendations
• Section 5, Conformance Rules
• Section 6, Other Information
• Section 7, CDASH Special-Purpose Domains
• Section 8, General Observation Classes
• Appendices

• Paper CRFs vs. Electronic CRFs: The term "CRF" used throughout this document refers to both paper and electronic formats, unless otherwise specified.
• Fields vs. Variables: Data collection "fields" refers to terms that are commonly on the CRF. Data collection "variables" refers to what is in a clinical database.
• Study Treatment: The phrase "study treatment" has been used instead of investigational/medicinal product, study drug, test article, medical device, etc., in order to include all types of study designs and products.
• Mechanisms for Data Collection: Different data collection mechanisms can be used to control how data are collected (e.g., tick boxes, check boxes, radio buttons, drop-down lists, etc.). For the purposes of this document, these terms will be used interchangeably.

CDASH is composed of the CDASH Model and the CDASH Implementation Guide (CDASHIG), with its associated CDASHIG Metadata Table. A domain is a collection of data points related by a common topic, such as adverse events or demographics. CDASHIG domains are aligned with SDTMIG domains for beginning-to-end traceability.

CDASH Model

The CDASH Model v1.0 provides a general framework for creating fields to collect information on CRFs and includes the model metadata, which shows the standard variables in the model. The CDASHIG provides information on the implementation of the CDASH Model and includes the CDASHIG Metadata Table, which details additional specifications for data collection variables within each domain.

The CDASH Model v1.0 provides root naming conventions for CDASHIG variables that are intended to facilitate mapping to the SDTMIG variables. The variables defined in the CDASH model follow the same "--XXXX" naming convention as the SDTM model. The two dashes are replaced by the domain code when applied to create the CDASHIG variable. For example, --DOSFRQ is the CDASH Model variable name to for Dosing Frequency per Interval in the Interventions Class. When a domain abbreviation is applied (e.g., "CM"), CMDOSFRQ is the CDASHIG variable for the frequency of the concomitant medication use. The CDASH Model includes metadata for variables used in each of the SDTM general observation classes, Timing variables, Identifier variables, variables for Special Purpose domains, and domain-specific variables. See Section 3.5 for specific information on the CDASH Model content.

CDASHIG

The CDASHIG provides general information on the implementation of CDASH standards. The CDASH standards include the CDASH Model and the CDASHIG, which includes the supporting CDASHIG Metadata Table. The informative content of the CDASHIG and the normative content metadata table comprise the CDASHIG and must be referenced together.

CDASHIG Metadata Table

The CDASHIG Metadata Table includes only those variables commonly implemented by a significant number of the organizations/companies that provided information/examples (e.g., Medical History, Adverse Events). Implementers can add appropriate variables to their CDASHIG domain using the associated General Observation class within the CDASH Model. The CDASHIG Domain Metadata illustrates the use of Question Text and Prompts employed by many sponsors. Implementers should reference the CDASH Model to see all available options for Question Text and Prompt for parameters and verb tenses that may be substituted.

The CDASHIG Metadata Table attributes provide building blocks for the development of a case report form and the underlying database or other data collection structure.

The key steps to developing CRFs using CDASH are as follows:

1. Each organization may maintain a corporate library of standardized CRFs. Determine the requirements for data domains from these (if applicable) or the protocol data collection requirements for the study.
2. Review the domains published in CDASHIG to determine which of the data collection domains and fields are already specified in the published domains.
3. As much as possible, the standard domains should be used to collect data in a manner that will be effective for data collection. Develop the data collection tools using these published, standard domains first.

4. Using the root variables and other CDASH metadata in the CDASH Model, add any additional variables that are needed to meet the requirements of data collection. Follow CDISC Variable-Naming Fragments (see the CDASHIG Glossary and Abbreviations) conventions, and CDASH root variable naming conventions where they exist (e.g., --DAT for dates, --TIM for times, --YN for prompts as described in the CDASH Model).

   Example: Replace "--" with the two-character domain code that matches the other variables in the same domain. For example, to add the --LOC variable to a Medical History CRF, the domain code is "MH", so the variable would become "MHLOC" in that domain.

5. The Question Text and Prompt columns in the CDASH Model provide different variations in the recommended text for asking the question on a CRF. For each question, the sponsor may elect to either use the Question Text or the Prompt on the CRF. Some text is presented using brackets [ ], parentheses ( ), and/or incorporating forward slashes. These different formats are used to indicate how the Question Text or Prompt may be modified by the sponsor.

   1. The text inside the brackets provides an option on the tense of the question, or text that can be replaced with protocol specific verbiage.

   2. The text inside the parentheses provides options (e.g., singular/plural) or text that may be eliminated.

   3. Text separated with a forward slash provides optional words which the sponsor may choose.

      Example: The CDASH variable, --PERF, from the CDASH Model has the following Question Text and Prompt.

      Question Text:

      [Were any/Was the] [--TEST/ topic] [measurement(s)/test(s)/examination(s)/specimen(s)/sample(s)] [performed/collected]?

      Prompt:

      [--TEST/Topic] [Measurement(s)/Test(s)/Examination(s)/Specimen(s)/Sample(s)] [Performed/Collected]?

      The sponsor wants to add a question to a CRF that asks whether a lab specimen was collected using a yes, no response.

      a) The sponsor selects the CDASH variable --PERF and adds the appropriate domain code. LBPERF

      b) Use either the Prompt or the full Question Text on the CRF.

      Question Text: Was the laboratory specimen collected?

      1. In the first set of brackets, the text option "Was the" is selected as the study required only one lab test to be performed. [Were any/Was the]
      2. In the second set of brackets, the text used is "laboratory" which is the topic of interest. [--TEST/Topic (laboratory)]
      3. In the third set of brackets, the text option "specimen" without the optional "s" is selected. [measurement(s)/test(s)/examination(s)/specimen(s)/sample(s)]
      4. In the fourth set of brackets, the text option "collected" is selected. [performed/collected]

      Prompt: Laboratory Specimen Collected

      1. In the first set of brackets, the text used is the topic of interest (i.e., laboratory). [--TEST/Topic (Laboratory)]
      2. In the second set of brackets, the text option "specimen" without the optional "s" is selected. [Measurement(s)/Test(s)/Examination(s)/Specimen(s)/Sample(s)]
      3. In the third set of brackets, the text option "collected" is selected. [Performed/Collected]
6. Create custom domains based on one of the General Observation Classes in the CDASH Model.

The CDASHIG Metadata Table attributes provide building blocks for the development of a case report form and the underlying database or other data collection structure.

1. The Study Data Tabulation Model (SDTM) and the SDTM Implementation Guide (SDTMIG) provide a standard for the submission of data. CDASH is earlier in the data flow and defines a basic set of data collection fields that are expected to be present on the majority of CRFs. SDTM and CDASH are clearly related. The use of CDASH data collection fields and variables is intended to facilitate mapping to the SDTM structure. When the data are identical between the two standards, the SDTMIG variable names are presented in the CDASHIG Metadata Table and should be used to collect the data. In cases where the data are not identical or do not exist in the SDTMIG, CDASH has created standardized data collection variable names.
2. The CDASHIG v2.0 content is based on the SDTMIG Version 3.2.
3. All SDTMIG "Required" variables have been addressed either directly through data collection or by determining what needs to be collected to derive the SDTMIG variable. In some cases, SDTMIG variable values can be obtained from data sources other than the CRF or are populated during the preparation of the submission datasets (e.g., --SEQ values).
4. CDASHIG Domains contain variables that may be used in the creation of the RELREC submission dataset. For example: CDASHIG variable CMAENO: "What [is/was] the identifier for the adverse event(s) related to this (concomitant) [medication/therapy]?" may be used to identify a relationship between records in the CM dataset and records in the AE dataset.
5. The CDASH standard also includes some data collection fields that are not included in the SDTMIG (e.g., "Were any adverse events experienced?" or "Were any (concomitant) [medication(s)/therapy(ies)] taken?"). These data collection fields are intended to assist in the cleaning of data and in confirming that no data are unintentionally missing. To facilitate the use of these types of fields, variable names are provided (e.g., AEYN, CMYN) in the CDASHIG Metadata Table to denote that they are data collection variables, but the SDTMIG Variable Name column is listed as N/A, and the Mapping Instruction column indicates that these CDASHIG variables are not included in the SDTM datasets.
6. The CDASHIG Findings domain (e.g., Drug Accountability (DA), ECG Test Results (EG) and Vital Signs (VS)) tables are presented in a structure that is similar to the SDTMIG, which is to list the variable names and some examples of the tests. Implementers are expected to include protocol-specific tests in a CRF presentation layout, using the appropriate values from the relevant CDISC Controlled Terminology codelists. For example, VSTEST values are used to name the test on the CRF, and the corresponding test code is determined from the VSTESTCD codelist. Implementers may use synonyms when the xxTEST values are long or not commonly recognized (e.g., ALT in place of Alanine Aminotransferase). Implementers should use the CDASHIG recommendations to identify the types of data to collect while referring to the SDTMIG and CDISC Controlled Terminology for additional metadata, (e.g., labels, data type, controlled terminology).
7. The CDASH standard has intentionally not reproduced other sections of the SDTM standard and implementers are asked to refer to the SDTM Model and SDTMIG on the CDISC website for additional information (http://www.cdisc.org/sdtm).
8. The CDASHIG data collection fields included in the CDASHIG Metadata Table are the most commonly used and should be easily identified by most implementers. Additional data collection fields may be necessary to capture therapeutic area (TA) specific data points as well as other data specified in the clinical study protocol or for local regulatory requirements. Reference the CDASH Model and CDISC Therapeutic Area User Guides for additional information.
9. Use the CDASH recommendations to develop company standards, taking into consideration the stage of clinical development and the individual therapeutic area requirements. To gain the greatest benefit from using the CDASH standard, CRFs should not be developed on a trial-by-trial basis within the implementer organization, but rather be brought into a study from a library of approved CRFs based on the CDASH Model and Implementation Guide, whenever practicable.
10. The CDASHIG is divided into sections of similar types of data and the CDASHIG Metadata Table is arranged in alphabetical order (by domain abbreviation) within their respective general observation class. CRF layout was not within the original scope of the CDASH project; however, to assist with standardization of CRF layout, data collection fields are presented within the CDASHIG Metadata Table in a logical order, and annotated example CRFs have been provided (if available). In addition, implementers are referred to Best Practice for Creating Data Collection Instruments (Best Practice Recommendations), for a discussion on best practices for ordering fields on a case report form.

In order to facilitate classification of the different types of data collection fields, the following categories were used:

• Highly Recommended (HR): A data collection field that should always be on the CRF (e.g., the data are needed to meet a regulatory requirement or are required to create a meaningful dataset).
• Recommended/Conditional (R/C): A data collection field that should be on a CRF based on certain conditions (e.g., complete date of birth is preferred, but may not be allowed in some regions; AE time should be captured only if there is another data point with which to compare it). For any recommended/conditional fields, the "condition" is described in the "Implementation Notes" portion of the CDASHIG Metadata Table.
• Optional (O): A data collection field that is available for use.

The CDASH team initially considered utilizing the SDTMIG Core Designations of Required, Expected, and Permissible to capitalize on prior understanding of these descriptive designations as well as to enable a consistent categorization across CDASH and SDTM standards. Yet, when the CDASHIG Metadata Table was constructed, it quickly became apparent that CDASHIG core designations would often differ from SDTMIG core designations due to the inherent differences between the manner in which data are collected (to ensure the most accurate data) and the structure in which data are reported and submitted. For example, a variable categorized as Required in the SDTMIG may not be required in the CDASHIG if it can be derived in the SDTM datasets (rather than be a field captured explicitly on a CRF). Also, the SDTMIG core designation of "Required" imposes a rule that the variable cannot be null. CDASHIG Core designations are not intended to impose any rules that require a field to be populated with data. They are only intended to designate which fields should be present on the CRF.

Adding new collection fields is often constrained by business rules, as well as by clinical data standards SMEs, clinical data management processes, and EDC systems. The naming conventions and other variable creation recommendations in CDASHIG are designed to allow collection of data regardless of subsequent inclusion in SDTM, as well as to consistently facilitate transforming the collected data into submission datasets.

Prior to adding any new fields to current domain models, the CDASH Model should be reviewed to see if there is a root field that will work for the data collection need.

New data collection fields (not already defined in a CDASH Model) will fall under one of following categories.

• Fields used for data cleaning purposes only and not submitted in SDTM datasets (e.g., --YN). The field --YN with Question Text "Were there any [interventions/events/findings]?" can be added to a domain for this purpose. Replace the two dashes (--) with the two-character domain code, and create the Question Text or Prompt using generic Question Text or Prompt from the CDASH Model as a base. Always create custom data cleaning/operational variables using consistent naming conventions.
• Fields with a direct mapping to an SDTMIG variable. If a value can be collected exactly as it will be reported in the SDTM dataset (i.e., same value, same datatype, same meaning, same Controlled Terminology), the SDTMIG variable name should be used as part of the data collection variable name in the operational database to streamline the mapping process. Any collection variable whose meaning is the same as an SDTMIG variable should be a copy of the SDTMIG variable, and the meaning should not be modified for data collection.
• Fields without a direct one-to-one mapping to SDTM datasets. If a study requires a field that is not identical to an SDTMIG field, for example the collected data type is different from the data type in the corresponding SDTMIG variable, or the SDTMIG variable is derived from collected data, the operational database should use a variable with a different name from the SDTMIG variable into which it will be mapped.
  
  • Example 1: A study collects Findings data in a denormalized format and then maps the data to the normalized SDTM structure. The --TESTCD values can be used as the CDASHIG variable names, and the corresponding --TEST value can be used as the prompt on the CRF (See Section 8.3 General CDASH Assumptions for Findings Domains for more information).
  • Example 2: Dates and times are collected in a local format, familiar to the CRF users, and then reported in the SDTM-specified ISO 8601 format. In the operational database, the CDASH variables --DAT and --TIM (if collected) map into the single SDTM variable (--DTC).
  • Example 3: If the mapping to SDTM is similar, but not direct, "C" can be included before the root variable name to indicate a "collected" version of the variable to which that data will map.

    For example, if an injection is to be administered to a subject's LEFT THIGH, RIGHT THIGH, LEFT ARM, or RIGHT ARM, the sponsor may create the variable EXCLOC. The SDTM mapping would split these into EXLOC and EXLAT. That would avoid having to split the collection of the data into two fields on the CRF.

This section provides an explanation of the columns used in the CDASH Model.

• Observation Class: This column contains the SDTM Class for the domain.
• Domain: This column contains the two-letter domain code.
• CDASH Variable: This column provides the CDASH root variable names (e.g., --ONGO, --DAT).
• CDASH Variable Label: This column contains a suggested root variable label that that may be used for the CDASHIG variable.
• Draft CDASH Definition: This column provides a draft definition of the root variable. This text may or may not mirror any text in the SDTM. Currently, there is a new CDASH/SDTM team creating variable definitions. Once these definitions are finalized, the CDASH definitions will be updated to harmonize with them.
• Question Text: This column in the CDASH Model contains the recommended question text for the data collection field. Question Text is a complete sentence. Some text is presented inside brackets [ ] or parentheses (). The text inside the brackets should be replaced with protocol-specified verbiage. The text inside the parentheses is optional. Text separated with a forward slash indicates optional wording from which the sponsor may choose.
• Prompt: This column in the CDASH Model contains the recommended prompt text for the data collection field. The Prompt is a short version of the question. Some text is presented inside brackets [ ] or parentheses (). The text inside the brackets should be replaced with protocol-specified verbiage. The text inside the parentheses is optional. Text separated with a forward slash indicates optional wording from which the sponsor may choose.
• Data Type: This column contains the simple data type of the CDASH variable (e.g., Char, Num, Date, or Time).
• SDTM Target: This column provides the suggested mapping to the SDTM root variable. When no direct mapping to an SDTM root variable is available, the column contains "N/A". When the column contains "SUPP--.QNAM", it means that the value represented in the CDASH variable shall be mapped to an SDTM Supplemental Qualifier. NOTE: CDASH variables noted as not having a direct map to SDTM variables (i.e., non standard variables) may have SDTM variable equivalents in future versions.
  
• Mapping Instructions: This column contains information on the suggested mapping of the root variable to the SDTM variable.
• Controlled Terminology Codelist Name: This column contains the Controlled Terminology (CT) codelist name {e.g., (LOC)} that is associated with the field. Certain variables (e.g., dates) use ISO formats as CT, however in CDASH these variables are generally not collected using the ISO CT. These variables are converted to the ISO format when the SDTM-based submission datasets are created.
• Implementation Notes: This column contains further information, such as rationale and implementation instructions, on how to implement the CRF data collection fields and how to map CDASH variables to SDTM variables.

Note: When multiple options are contained in a single cell, the options are separated by a semicolon.

This section provides an explanation of the columns used in the CDASHIG Metadata Table.

• Observation Class: This column contains the SDTM Class for the domain.
• Domain: This column contains the two-letter domain code.
• Data Collection Scenario: This column in the CDASHIG Metadata Table identifies the different data collection options in CDASH for the same domain and is best used for filtering the table. The information in this column provides the context for the CDASHIG Core Designations, e.g., denoting which fields should be present on the CRF. When only one data collection scenario is provided for the domain, the column contains "N/A".
• Implementation Options: When this column contains "Horizontal-Generic", a sampling of the CDASHIG metadata is provided as a template for the metadata of the CRF in a denormalized structure. When this column contains "Horizontal-Example", it represents a specific execution of CRF metadata in a denormalized structure.
• Order Number: This column provides a suggested order of CDASHIG variables to be displayed on a CRF.
• CDASHIG Variable: This column provides the CDASHIG variable names (e.g., CMONGO, AEDAT).
• CDASHIG Variable Label: This column provides the CDASHIG variable label.
• Draft CDASHIG Definition: This column provides a draft definition of the CDASHIG variable. This text may or may not mirror any text in the SDTMIG. Currently, there is a new CDASH/SDTM team creating variable definitions. Once these definitions are finalized, the CDASH definitions will be updated to harmonize with them.
• Question Text: This column in the CDASHIG Metadata Table provides the suggested text for the specific Domain. Implementers should refer to the CDASH Model to create alternative question text that may be used that meets the CDASH conformance rules. Question Text is a complete sentence. Some text is presented inside brackets [ ] or parentheses (). The text inside the brackets should be replaced with protocol-specified verbiage. The text inside the parentheses is optional. Text separated with a forward slash indicates optional wording from which the sponsor may choose.
• Prompt: This column in the CDASHIG Metadata Table provides the suggested text for the specific Domain. Implementers should refer to the CDASH Model to create alternative prompt text that may be used that meets the CDASH conformance rules The Prompt is a short version of the question. Some text is presented inside brackets [ ] or parentheses (). The text inside the brackets should be replaced with protocol-specified verbiage.
• Data Type: This column contains the simple data type of the CDASH variable (e.g., Char, Num, Date, or Time).
• CDASHIG Core: This column contains the CDASHIG core designations for basic data collection fields (i.e., Highly Recommended (HR), Recommended/Conditional (R/C), Optional (O)). See Section 3.3 for definitions of CDASH core designations.
• Case Report Form Completion Instructions: This column contains recommended example instructions for the clinical site on how to enter collected information on the CRF.
• SDTMIG Target: This column provides the suggested mapping to the SDTMIG variable name. It may help facilitate the creation of the SDTMIG variables needed for submission. When no direct mapping to an SDTMIG variable is available the column contains "N/A". When the column contains "SUPP--.QNAM", it means that that the value represented in the CDASH field shall be mapped to an SDTM Supplemental Qualifier. NOTE: CDASHIG variables noted as not having a direct map to SDTMIG variables (i.e., non standard variables) may have SDTM variable equivalents in future versions.
• Mapping Instructions: This column contains information on the suggested mapping of the CDASHIG variable to the SDTMIG variable. Mapping instructions in the CDASHIG Metadata Table provide more complete guidance than those present in the CDASH Model. When domain level metadata are not available, consult the Model for SDTM Mapping Instructions.
• SDTMIG Core: This column contains the SDTMIG core designations (i.e., Required (Req), Expected (Exp), and Permissible (Perm)). The CDASHIG core designations differ from SDTMIG core designations. A Required variable in the SDTMIG may not be Highly Recommended in the CDASHIG.
• Controlled Terminology Codelist Name: This column contains the Controlled Terminology (CT) codelist name {e.g., (LOC)} that is associated with the field. The SDTMIG indicates that certain variables (e.g., dates) use ISO formats as CT, however in CDASH these variables are generally not collected using the ISO CT. These variables are converted to the ISO format when the SDTM-based submission datasets are created.
• Subset Controlled Terminology/CDASH Codelist Name: This column contains the CDISC Controlled Terminology or CDASH Subset Codelist name that may be used for that specific variable (e.g., EXDOSFRM).
• Implementation Notes: This column contains further information, such as rationale and implementation instructions, on how to implement the CRF data collection fields and how to map CDASHIG variables to SDTMIG variables.

Note: When multiple options are contained in a single cell, the options are separated by a semicolon.

Collection of Dates: Collect dates in such a way to allow the sites to record only the precision they know. The system should also store only the collected precision. Any incomplete dates must remain incomplete with no imputation and no "zero-filling" of missing components.

Data collection and database processes should allow for the possibility of partial dates and times, since a partial date may be the most precise information that can be collected for some data. An example of when it may be necessary or appropriate to collect partial dates is found in the DM domain. In some countries, collection of a complete date of birth is restricted under privacy rules, so only a year, or year and month of birth might be collected. Other examples of commonly collected partial dates are found in CM and MH, where the subject may not remember the complete date of when they started to take a medication or when a significant medical history condition began.

If a full date is collected, the CDASH variable --DAT or all three date components (--DATYY, --DATMO, and --DATDD) should be included on the collection tool. If a partial date can be collected in a single field, the CDASH --DAT should be used. If a partial date must be collected as separate database fields to collect year, month and day, refer to the CDASH Model for examples of standard naming fragments (--YY, --MO, --DD, --TIM). The capabilities of individual software systems (e.g., EDC) will determine which variable names are needed. CDASH uses separate data collection fields for dates and times. If times are collected, it is expected that they will be used with the appropriate collected date to derive the related SDTM date variable in ISO8601 format.

Conversion of Dates for Submission: See section SDTMIG v3.2 Sections 4.1.4.1 and 4.1.4.2 for detailed information about converting dates and times from the collection format to the submission format using ISO 8601. A specific example of mapping birth date is shown here.

The SDTM date format allows this partial date to be submitted so the reviewer can see what was collected.

Imputation of Dates: If the missing parts of the date are imputed for analysis purposes, the imputed dates will be generated in the analysis data (ADaM) but not in the SDTM submission data sets.

Relative Timing variables are sets of variables that provide information about how the timing of the record relates to either the study reference period or another fixed point in time. The CDASH Relative Timing variables are collected for those observations where a date is either not collected or is not available. The CDASH set of variables serve as an indicator (or flag) that the observation's "start" was "prior" to the study reference period or prior to another fixed point in time OR that the observation's "end" was "after" or "ongoing" as of the study reference period or another fixed point in time. The CDASH variables of --PRIOR and --ONGO serve this purpose. How these CDASH "flags" are translated to SDTM (according to controlled terminology) depends on whether the comparison is against the protocol-defined study reference period or against another fixed point in time that may serve as the "reference" for the timing of the record. To emphasize, the collection of these CDASH relative timing variables are always dependent on the actual date either being prospectively "not collected" or not available. Much more information can be found under the "General Assumptions" for both Interventions and Events domains.

For all SDTM submissions, there is a defined period during which the subject is considered to be "on study". According to the SDTMIG v3.2, the start and end dates of the "on study" period are submitted in the variables RFSTDTC and RFENDTC. The defined period may be protocol-specific or set by company policy, SOPs, or other documented procedures. The "on study" period might be defined as being from the date/time of Informed Consent through the date/time of subject's completion of the study, or it might be from the date/time of first dose to the date/time of last dose. Regardless of how the "on study" period is defined, the dates (and optionally times) of the start and end of that period must be collected.

If there is a need to collect information about whether an observation of interest occurred prior to a reference point or milestone other than the beginning of the study, or was ongoing or continuing at some reference point or milestone in the study other than the end of the defined "on study" period, the date/time of that reference point or milestone should also be collected. If this date/time has been collected, reasonable comparisons can be made to that date/time with "prior", "coincident", "continuing", or "ongoing" questions.

The following steps should be taken to ensure observations of interest that occur over time can be related to the study period or to fixed point in time or a milestone in a meaningful way. Chart 1 below provides a representation of an intervention as it relates to the study reference period, and Charts 2 and 3 provide a representation of comparisons as it relates to other fixed points in time or a milestone.

Study Reference Period (Chart 1)

1. Define the "on study" period.(B-C). Once the overall "on study" period has been defined (B-C), collect the dates (/times) of the start of the study reference period (e.g., date of informed consent, date of first dose) and end of the study reference period (e.g., date of last contact, date of last dose), as part of the clinical data with their respective domains (e.g., DS, EX). These dates will map into the RFSTDTC (B) (start of Study Reference Period) and RFENDTC (C) (end of Study Reference Period) variables in the SDTMIG DM dataset.

2. Collected comparisons ((D, E) using CDASHIG variables (e.g., "prior", "ongoing") of when something started or ended in relation to the "on study" reference period (i.e., RFSTDTC-RFENDTC: (B-C). These CDASH variables are used to populate the SDTMIG variables--STRF and --ENRF variables when the SDTM-based datasets are created. (Note: these relative timing variables are only populated in the SDTM -based datasets when a date is not collected.).

Fix point in Time/Milestone (Charts 2, 3)

1. Define the fix point in time or milestone (B or C).The fix point in time or milestone can be a date or a description. This will map into either the SDTMIG variables (–STTPT or --ENTPT) when the SDTM-based datasets are created .
2. Collected comparisons (D or E) using CDASHIG variables (e.g., "prior", "ongoing") of when something started or ended in relation to the fixed point in time or milestone (B or C). These CDASH variables are used to populate the SDTMIG variables--STRTPT or --ENRTPT when the SDTM-based datasets are created.(Note: these relative timing variables are only populated in the SDTM -based datasets when a date is not collected).

For information about mapping what is collected in "prior", "ongoing", and "continuing" fields into the appropriate SDTMIG variables, see the SDTMIG V3.2 Section 4.1.4.7.

Submission data standards are required by some global regulators, and controlled terminology (CT) is part of the requirement. Using CT from the start during data collection builds in traceability and transparency, and reduces the problems associated with trying to convert legacy codelists and variables to the submission standards. CT can be used in the following ways during data collection:

1. To collect data using a standardized list of values (e.g., Mild, Moderate, Severe)
2. To ask a specific question on the CRF (e.g., Temperature)
3. To create a variable name in the database (e.g., TEMP for the collection of vital sign data when a unique variable name must be created for each vital sign result.)

Terminology applicable to CDASH data collection fields is either in production or under development by the CDISC Terminology Team. Production terminology is published by the National Cancer Institute's Enterprise Vocabulary Services (NCI EVS) and can be accessed via the following link: http://www.cancer.gov/cancertopics/terminologyresources/CDISC. The examples in this document use CDISC controlled terminology where possible, but some values that seem to be controlled terminology may still be under development at the time of publication, or even especially plausible "best guess" placeholder values. Do not rely on any source other than the CDISC value set in the NCI Thesaurus for controlled terminology.

In some cases it is more appropriate to use a subset of a published SDTM terminology list, rather than the entire list. To begin with an established subset of the SDTM terminology, go to https://www.cancer.gov/research/resources/terminology/cdisc and reference the CDASH terminology. These CDASH codelists have been subsetted from the complete SDTM terminology lists and are available to implementers as a way to quickly set up codelists for data collection. However, most implementers will also need to review the SDTM terminology to determine which other values are needed for their particular implementation. The CDASH terminology subset names are provided in the CDASHIG Metadata Table for easy reference.

Some codelists, such as Laboratory Test Codes (LBTESTCD), are extensible. This means that values that are not already represented in that list (either as a CDISC Submission Value, a synonym or an NCI preferred term) may be added as needed. Other codelists, such as AE Action Taken with Study Treatment, are non-extensible and must be used without adding any terms to the list. If gaps are indentified, sponsors should submit requests to add values to controlled terminology by using the New Term Request form found at http://ncitermform.nci.nih.gov/ncitermform/?version=cdisc.

In cases where a CDASH/CDASHIG variable has associated controlled terminology, the codelist is referenced in Controlled Terminology column in the CDASH Model and CDASHIG Metadata Table in this format: (codelist name).

CDASH Best Practices describe operational recommendations to support data collection, suggested CRF development workflow, and methods for creating data collections instruments. The first section, Best Practices for Creating Data Collection Instruments, is part of conformance to the CDASH Standard.

The recommendations are general principles that may be implemented during CRF form design and/or database set up in different ways, depending on the systems used.

Providing the clinical site with a consistent and clinically logical order of these fields will reduce data entry time and result in more reliable data. Therefore, the CRF should be quick and easy for site personnel to complete.

Clinical Operations staff should review the CRF for compatibility with common site workflow and site procedures.

When a binary response is expected, "Yes/No" responsesare preferred over "Check all that apply", becausea missing response could lead to a misinterpretation of critical data. For example, if AEsare determined to be serious based only upon checking the applicable serious criteria (e.g., Hospitalization, Congenital Anomaly, etc.), failure to check a criterion would delay identification of an SAE.

Conformance means that:

1. Core designations must be followed: All Highly Recommended and applicable Recommended/Conditional Fields must be present in the CRF or available from the operational database.
2. CDISC Controlled Terminology must be used: The CDISC Controlled Terminology that is included in the CDASHIG Metadata Table must be used to collect the data in the CRF. All codelists displayed in the CRF must use or directly map to the current published CDISC Controlled Terminology submission values, when it is available. Subsets of published Controlled Terminology, such as those provided in CDASH terminology, can be used.
   1. In Findings domains, values from the relevant CDISC Controlled Terminology lists must also be used to create appropriate Question Text, Prompts and/or variable names (e.g., If the question is about the subject's height, incorporate the value of "Height" from the VSTEST codelist as the Prompt on the CRF, and incorporate "HEIGHT" from VSTESTCD in the variable name).
3. Best practices must be followed: The design of the CRF must follow the Best Practices for Creating Data Collection Instruments and CRF Design Best Practices.
4. The wording of the CRF questions should be standardized: CDASH Question Text or Prompt must be used to ask the question.
   1. In cases where the data collection is done in a denormalized presentation on the CRF, the relevant CDISC controlled terminology should be used in the Question Text or Prompt as much as possible. It is acceptable to use synonym text that will directly map to one CDISC Submission Value, including an NCI Preferred Term, if the CDISC Submission Value is not appropriate for data collection. For example, "ALT" may be better than "Alanine Aminotransferase" as the prompt for this lab test. If there is no CDISC Controlled Terminology available, the Question Text or Prompt must be standardized by the implementing organization and used consistently. One of the basic purposes of CDASH is to reduce unnecessary variability between CRFs and to encourage the consistent use of variables to support semantic interoperability; therefore, Question Text and Prompt must be used verbatim.
   2. Similarly, where SDTMIG variables may exist in the operational database and the value conforms to Controlled Terminology, it is permissible to use a familiar synonym on the CRF without affecting conformance. An example may be on the Demographics page where SEX may be displayed as "Male" or "Female", while in the operational database, the controlled terminology values of "M" and "F" would be used.
   3. In some cases, CDASH Questions Text and Prompt allow for flexibility while still being considered conformant. See section 2.3 CRF Development Overview for further details on the usage of Question Text and Prompt.
   4. The CDASH Model Question Text may contain options for the tense, but if the option is not provided, the tense of the Question Text may be modified to reflect the needs of the study.
   5. For cases where the Question Text or Prompt cannot be used due to culture or language, or a CRF must be translated for language or cultural reasons, the implementer must ensure the translation is semantically consistent with the CDASH Question Text and Prompt in the CDASHIG Metadata Table.
   6. In cases where a more specific question needs to be asked than what is provided by Question Text or Prompt, CDASH recommends the use of a brief CRF Completion Instruction, as long as the instruction clarifies the data required by the study without altering the meaning of variable as defined by the standard. For example "Sex at birth" is not the same question as "Sex" (which is loosely defined as "reported sex").
5. Variable Names: The CDASHIG variable naming conventions should be used in the operational database, using a consistent syntax that includes the root variable name and/or controlled terminology, and any other standardized concepts that are needed to support efficient mapping of the collected value to SDTM datasets. The goals are to have beginning-to-end traceability of the variable name from the data capture system to the SDTM datasets, and to support automating electronic data capture (EDC) setup and downstream processes.
   1. It is recognized that particularly in an EDC system, the variable name of a data collection field, as well as the name in the underlying database, may have various "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.
   2. In cases where the data collection is done in a denormalized way, appropriate CDISC controlled terminology must be used when it is available. For example, when collecting Vital Signs results in a denormalized eCRF, the variable names can be created by using terms from the Vital Signs Test Code codelist. For example, Temperature result can be collected in a variable called TEMP or TEMP_VSORRES, Systolic Blood Pressure result, can be collected in a variable called SYSBP or SYSBP_VSORRES. When a particular system's constraints limit the variable name to 8 characters, a similar, consistent implementation that preserves either the normalized root variable (e.g., ORRES) or the controlled terminology (e.g., --TESTCD value) should be implemented.
   3. Whereas all CDASHIG defined variable names are 8 characters or less to accommodate SDTM limits on variable names, QNAMs, and --TESTCDs, the maximum length of a variable name that may be implemented is determined by the data management system used, not by CDASH.
6. Data Values and Format: Because an SDTM data programmer should be able to assume that data in an SDTMIG variable is SDTMIG compliant, the data output by the operational database into an SDTMIG variable ideally requires no additional processing. Minimal processing (e.g., changing case) is still conformant. This helps to ensure a quality deliverable, even if the SDTM data programmer is unfamiliar with data capture practices.
7. Questionnaires: In order to maintain the validity of a validated instrument, studies that include validated questionnaires, ratings, or scales must present the questions and reply choices in the manner in which these were validated. (Reference QRS - Questionnaires, Ratings and Scales).
   1. In some cases, this may result in CRFs that do not conform to CDASH Best Practices; however, restructuring these questionnaires should not be done because it could invalidate them.
   2. The use of such questionnaires in their native format should not be considered to affect conformance to CDASH.

Implementers must determine what additional data fields to add to address study-specific and therapeutic area requirements, and applicable regulatory and business practices. Refer to CDASHIG Section 3.4 (How to Create New Data Collection Fields When No CDASHIG Field Has Been Defined) for more information on how to create data collection fields that have not already been described in this implementation guide.

General Design Considerations for Completion Instructions

Whenever possible, details related to the completion of a single field should be placed with the field itself on the CRF. If this is not possible due to the medium and/or system being used to create the CRFs, then it is permissible to include the field-level instructions at the top of the form, in what is generally considered the form-level instruction area. In some cases, such as when the form-level instructions are very lengthy or include graphics or flowcharts, a separate CRF completion instruction guideline may be required.

General Content Considerations for Completion Instructions

When creating form-level instructions for a CRF, the following points should be considered:

• The instructions should include clear references to the time period for which data are to be reported for the study, or to specific time windows that are allowed.
• The instructions should provide references to protocol sections for the specifics of and/or limitations on the data to be reported.
• The instructions should include any special instructions for additional reporting or actions required beyond what is collected on the CRF.
• The instructions should include considerations on how data collected on one CRF might have an impact on data that are reported on a different CRF.
• The instructions should refer to any other forms that are related to the CRF being completed.

Should the sponsor choose, screen failure data are data collected for those who fail screening and who are not subsequently enrolled in the study. Section 10.1 of ICH E3 describes the reporting of subject disposition in the clinical study report. This section states that it may be "relevant to provide the number of patients screened for inclusion and a breakdown of the reasons for excluding patients during screening, if this could help clarify the appropriate patient population for eventual drug use." Although screen failure data may not be relevant for all studies, it is recommended that screen failure data be collected based on the needs of the protocol and drug development programs. Timely collection of screen failure data may also be used to identify eligibility criteria that contribute to enrollment challenges.

Using CDASH, the minimum data to be collected should include a subject identifier and reason(s) for screen failure. Typically, there is a reason on the End of Study form indicating "Screen Failure". This information allows overall summarization of all subjects screened/enrolled and when captured, provides easy subject accountability for the Clinical Study Report. Other data may be considered for collection, such as date of informed consent, sex, race, date of birth or age, or other data to further describe the reason for ineligibility (e.g., the lab value that was out of range).

SDTMIG does not provide a separate domain specifically for screen failure data and does not require that the screen failure data be included in SDTM. Data for screen failure subjects, if submitted, should be included in the appropriate SDTMIG domains. Refer to the SDTMIG for further guidance on submitting Screen Failure data.

Data Collection to Facilitate Coding

Adverse Events, Medical History, and Prior and Concomitant Medications are often coded to standard dictionaries (thesauri). There are many coding dictionaries, but this section will focus on the Medical Dictionary for Regulatory Activities (MedDRA®) and the World Health Organization Drug Dictionary (WHO-DD) as examples, since these are common coding dictionaries.

The SDTMIG variable AEDECOD is the dictionary-derived text description of AETERM (the reported term for the adverse event) or AEMODIFY (the modified reported term). When coding with MedDRA®, the AEDECOD is the Preferred Term and is a required variable. Corresponding SDTMIG variables CMDECOD (for medications) and MHDECOD (for medical history items) are permissible SDTMIG variables. These are the equivalent of the preferred term in the dictionary used for coding, and when data are coded these SDTMIG variables should be provided.

These --DECOD variables are not necessarily collected on CRFs. They are often determined from other collected variables (e.g., AETERM, CMTRT, and MHTERM). Conventions adopted in the collection of these reported terms can have an impact on the resulting --DECOD variables. If collected on a CRF, --DECOD values would be selected from sponsor-defined or CDISC controlled terminology.

CRF Designers should consult with medical coders, review relevant documentation, and ensure that all elements needed to facilitate the coding process are collected.

Coding Adverse Events and Medical History Items

Data managers are encouraged to enter into discussion with coding specialists and medical staff to develop guidance to sites in accordance with applicable coding conventions and other company/project agreements and requirements.

Reported terms are often coded without other information for the subject. Therefore, sites should be advised that "nothing can be assumed", and that the reported term should include all information relevant to the event being reported. For example, if "Congestion" is reported as an adverse event for a particular subject, together with several other pulmonary events, the coder cannot assume that the congestion is "Lung congestion", rather than congestion of some other organ (e.g., nose, ear, etc.). The reported term "Congestion" will need to be queried before it can be coded.

Medications

With regard to medications, the CDASH standard offers some guidance on the recording of medication names and on the use of additional Recommended/Conditional data collection fields (e.g., CMROUTE, CMINDC) to facilitate coding. See CDASHIG Section 8.1.1, Assumptions for Interventions Domains.

The purpose of coding medications is usually to provide a "Standardized Medication Name" (CMDECOD) and a "Medication Class" (CMCLAS). Most dictionaries facilitate the derivation of the Standardized Medication Name on identification of the medication that was taken and the reason taken.

It would be preferable to collect all active ingredients of a particular medication. In a clinical trial, however, this is impractical. There are numerous CRF design possibilities. When designing a collection tool, it is critical to ensure that the details appropriate to the trial and the sponsor's coding requirements are included. For example, betamethasone dipropionate is used topically; however, if the site records only betamethasone (which can be administered orally, as drops, or inhaled), the topical route of the drug will be lost. In this case, collecting route of administration (CMROUTE) or the indication (CMINDC) would provide the additional information needed to code this medication.

In summary, when medications are to be coded, the indication (CMINDC) and route (CMROUTE) or anatomical location (CMLOC) should be collected along with the medication name.

The SDTMIG includes three types of special-purpose datasets:

• Domain datasets (Demographics (DM), Comments (CO), Subject Elements (SE), and Subject Visits (SV) which contain subject-level data.
• Trial Design Model (TDM) datasets which contain trial-level data.
• Relationship datasets

These datasets are described in SDTMIG Section 2.3. CDASH does not currently contain information on Trial Design Model, or Relationship datasets. CDASH standards are for collection of subject-level data, therefore the collection of Trial Design domains is out of the scope for CDASH. CDASHIG contains information on these Special-Purpose Domains: Demographics (DM), and Comments (CO).

1. Each study must include the Demographics domain.
2. CDASH does not currently contain metadata information on SDTM Special-Purpose Domains (Subject Elements (SE) and Subjects Visits (SV)). The SDTM SE and SV domains are commonly derived/created during the SDTM dataset creation process. Each implementer has to determine the best practice within their organization for creating visits and collecting the information on any unplanned visits. See the SDTMIG Section 5 Subject Elements and Subject Visits for more information.

Description/Overview for the CDASHIG CO - Comments Domain

The CDASH IG Comments (CO) domain describes free text collected alongside other data on typical case report form (CRF) pages such as Adverse Events, when there is not a specified variable for the free text. The CDASHIG CO domain has no mandatory data elements for inclusion in a separate Comments CRF, and the recommendation is to avoid the creation of a General Comments CRF.

Specification for the CDASHIG CO - Comments Domain

Comments (CO)

Assumptions for the CDASHIG CO - Comments Domain

Solicited Comments versus Unsolicited Comments

Solicited comments are defined as those comments entered in free-text data collection fields (such as "Please comment") that are intentionally included on the CRFs. These data collection fields provide the site with a pre-defined space to further explain or clarify an associated record within the CRF. For example, the Vital Signs CRF may include a solicited comment data collection field that enables recording of free text, such as "reason for performing assessment out of window".

Unsolicited comments are those comments entered outside of pre-defined data collection fields (also referred to as "marginal" comments as they are sometimes written in margins of paper CRFs). These may include marginal CRF comments written by site staff, notes written by the subject on paper diaries, or additional information collected through an eDC system function which collects comments that are not included as data collection fields on the eCRF. Although such comments may be intended to reduce queries, in practice they often lead to clinical data not being entered into the correct data collection field and may cause additional work in the data management process. The collection of unsolicited comments should be discouraged. If they are allowed, they should be reviewed and resolved during the conduct of the study.

Some unsolicited comments may be intended to avoid queries, for example "subject visit was delayed due to his holidays", and may not be regarded as clinical data. When these comments are permitted during data collection, the sponsor should have a process by which the comments are reviewed and processed. This should include a method to query and move relevant data to the appropriate form.

The Investigative site should be trained to enter clinical data in the appropriate data collection fields rather than making marginal notes on the CRF, and to use appropriate methods and tools to communicate to the monitor information that should not be included in the clinical data.

Free Text versus Value List Fields

Clinical data must be entered in appropriate data collection fields; otherwise, there is a potential for data that should be entered on other CRFs to be hidden within the comment. For example, if a general comment of "subject visit was delayed as he had the flu" was captured, this would necessitate that someone review the data and query the site to enter "flu" in an Adverse Event CRF and not leave it as a comment. An additional concern with free text comments is the potential for inappropriate, or sensitive, information to be included within general comments data collection fields. For example, a comment could contain a subject's name or may have unblinding information.

Free text comments are also inefficient for processing due to their variable and unstructured nature; they offer limited or no value for statistical analysis, as they cannot be tabulated.

CRF development teams are encouraged to strive for data collection methods that maximize the use of pre-defined lists of responses rather than relying solely on free text comment fields. The recommendation is that CRF development teams consider what additional questions may be needed within a specific CRF, and what the typical responses would be. They can then create a standardized list of responses for those questions, and make the data collected more useful for analysis.

Considerations Regarding Usage of a General Comments CRF

Solicited comments often used to be collected on a General Comments CRF. In recent years though, most organizations have discontinued this practice.

The CDASHIG CO domain has no mandatory data elements and is not intended to encourage the creation of a General Comments CRF. The CDASHIG recommends against the use of a General Comments CRF. This recommendation is not meant to discourage investigators from providing unsolicited comments where they are appropriate, nor to discourage solicited free-text comment data collection fields that may appear within any CRF. Free text comment fields should be used to solicit comments where they are needed. When comments are collected, they should use a variable naming convention that is conformant to CDASH (e.g., COVAL may be used in any CRF because it is part of the SDTMIG specification).

Example CRF for the CDASHIG CO - Comments Domain

This CRF shows the use of a targeted comment to collect the reason a PK sample was drawn more than 5 minutes late.

Example 1

Example Data for the CDASHIG CO - Comments Domain

Examples are not available at this time.

Description/Overview for the CDASHIG DM - Demographics Domain

The Demographics (DM) CDASHIG domain includes essential data collection fields that describe each subject in a clinical study. The collection of some demographics data is useful to perform simple analyses based upon population stratification.

Privacy concerns surrounding the DM & SC data were taken into account when these domains were created. For example, there are optional CDASHIG variables to collect the components of birthdate (e.g., BRTHDD, BRTHMO, and BRTHYY); therefore, limited elements of birthday may be collected and later mapped to the SDTMIG variable BRTHDTC. This approach provides flexibility in categorizing some variables to facilitate compliance with local privacy issues.

Collection of Age versus Date of Birth

It is recognized that sponsors may collect the Age or Date of Birth of the subject. In studies that are multi-regional, sponsors may need to enable the collection of either in order to be compliant to local regulations. But only one or the other should be collected for any given subject. When only AGE is collected, the sponsor is left with a window of uncertainty of, at most, 365 days. Knowing the precise date of birth provides the ability to calculate accurately an age for any date, however a precise (and complete) date of birth may be seen as "personally identifying information" for some privacy oversight boards or governmental regulators.

Collect the date of birth to the extent that the local regulatory authorities will allow.

• The best method is to collect a complete date of birth, and derive age.
• When there are privacy concerns with collecting the complete date of birth, the recommendation is to collect year of birth at a minimum.
• In cases when neither of the above can be implemented (e.g., cultural or regional considerations) then Age and Age Unit should be collected, and Date of Collection should be collected or derived from the Visit Date.
• Only use the AGETXT variable in very rare cases when only an age range or age description can be determined.

Date of Birth should be implemented such that incomplete dates are enterable, as allowed by the data capture system.

See Section 3.6 Collection of Dates for more information.

Collection of Sex

The collection of some demographics data is useful to perform simple analyses based upon population stratification.

Collection of Ethnicity and Race

Within the United States of America, collect Ethnicity before Race, per FDA requirement. A secondary analysis is often made using the phenotypic race of the subject. Collect race if required for the protocol and not prohibited by local laws and regulations.

In 2016, the U.S. Office of Management and Budget (OMB) issued its revised recommendations for the collection and use of race and ethnicity data by Federal agencies. FDA follows this directive and now recommends "the use of the standardized OMB race and ethnicity categories for data collection in clinical trials for two reasons. The use of the recommended OMB categories will help ensure consistency in demographic subset analyses across studies used to support certain marketing applications to FDA and across data collected by other government agencies".

The Race values listed in the FDA Guidance are:

• American Indian or Alaska Native
• Asian
• Black or African American*
• Native Hawaiian or Other Pacific Islander
• White

*For studies where data are collected outside the U.S., the recommended categories are the same except for "Black" instead of "Black or African American".

CDASH provides only one variable for Race. When the sponsor captures more than one race, the sponsors will need to create non-standard variables to store the collection of the multiple Races and map appropriately to the SDTMIG DM domain.

Race Other has been included as a free-text field to capture responses. The use of this variable is optional and should be used with caution because, when submitting data to the FDA, the FDA requires that all races be mapped to the five standard races recognized by the FDA, and providing an Other, Specify field might lead to mapping errors or difficulties. RACE is R/C because some sponsors prefer to derive values that are compliant with the codelist RACE (e.g., as derived from values collected in CRACE).

The category of ethnicity is similar to race but, as defined by the CDC, is an arbitrary classification based on cultural, religious, or linguistic traditions; ethnic traits, background, allegiance, or association. In a fairly heterogeneous country, such as in the U.S., ethnicity data might be useful only to confirm that ethnic groups are not being discriminated against by being unfairly excluded from clinical research. Other regulatory bodies may expect the reporting of ethnicity values (different than the U.S. FDA) which more appropriately reflect the population of their areas (e.g., Japanese for MHLW reporting to Japan). These may be collected using the CETHNIC variable with its corresponding codelist, ETHNICC.

If more detailed information on race or ethnicity are required to further characterize the study subject, it is recommended that the presented choices be "collapsible" up to one of the five designations for race, as well as the two categories for representing ethnicity, as needed for reporting to FDA under its guidance. When these more detailed categorizations are desired, the use of race and ethnicity vocabulary tables located within Health Level Seven's Reference Information Model Structural Vocabulary Tables is recommended, as they are designed to collapse up in this manner. For the collection of this added detail or granularity, as the sponsor may require, CDASH provides the variables CRACE and CETHNIC, respectively.

Source: Collection of Race and Ethnicity Data in Clinical Trials; October 26, 2016.

Collection of Special Optional Fields in Demographics

The CDASHIG allows for collection of the Date of Informed Consent using the variable RFICDAT. If a sponsor chooses to collect Informed Consent using this variable, the data should not also be collected using DSSTDAT from the DS Domain. The data from RFICDAT would then be mapped to the SDTMIG variable DSSTDTC and the companion variables (e.g., DSTERM, DSDECOD) must be populated accordingly.

The CDASH Model also defines a field for Death Date (DTHDAT) as a timing variable. It may be collected on any CRF deemed appropriate by the sponsor. The SDTMIG variables DTHDTC and DTHFL are mapped to the DM domain during the SDTM submission dataset creation process. The CDASH field Death Date may be mapped to other SDTMIG domains, as deemed appropriate by the sponsor (e.g., DS).

See Best Practice in Section 4.1.2 of the CDASHIG for additional guidance recommending that the same data not be collected more than one time per subject.

Specification for the CDASHIG DM - Demographics Domain

Demographics (DM)

Assumptions for the CDASHIG DM - Demographics Domain

The CDASHIG DM domain is a special-purpose domain that collects specific data elements that are mapped to the SDTMIG DM domain. Additional data elements that are not within the scope of the Demographics must be mapped to other domains.

Example CRF for the CDASHIG DM - Demographics Domain

Example 1

Example 2

Example Data for the CDASHIG DM - Demographics Domain

Examples are not available at this time.

This section reflects common practices implemented by a significant number of the organizations/companies that provided information/examples. Most subject-level data collected during a study are represented using one of the three SDTM general observation classes. Section 8.1 includes the CDASH Intervention domains, Section 8.2 includes the CDASH Events domains, and Section 8.3 includes the CDASH Findings Domains. Within each domain class, the domains are presented in alphabetical order. Readers should refer to Section 6 of the SDTMIG for additional information on these classes. Within each domain, a link is provided to the CDASHIG Domain Metadata table. The CDASHIG Domain Metadata tables include the variables that are commonly used by a significant number of the organizations/companies that provided information/examples. Implementers may add other variables from the CDASH model as needed. Other variables can be added if needed following the instructions in Section 3.4, How to Create New Data Collection Fields When No CDASHIG Field Has Been Defined.

The Interventions class includes CDASH domains that define collection standards for investigational treatments, therapeutic treatments, and procedures that are intentionally administered to the subject either as specified by the study protocol (e.g., exposure), coincident with the study assessment period (e.g., concomitant medications), or self-administered by the subject (such as alcohol, tobacco, or caffeine).

1. CDASH --YN variables with the question text "Were there any interventions?" (e.g., "Were there any procedures?" or "Were there any concomitant medications?") are intended to assist in the cleaning of data and in confirming that there are no missing values. These variables are not included as part of the SDTM Intervention Domains for submission and are annotated as NOT SUBMITTED on the CRF.
2. CDASH --CAT and/or -SCAT are generally not entered on the CRF by the sites. Implementers may pre-populate and display these category values to help the site understand what data should be recorded on the CRF. Implementers may also pre-populate hidden variables with the values assigned within their operational database. Categories and subcategories are determined per protocol design, and could be populated during the SDTM submission dataset creations.
3. Date and Time variables
   1. CDASH date variables (e.g., --DAT, --STDAT, --ENDAT) are concatenated with the CDASH Time variables (e.g., --TIM, --STTIM, --ENTIM (if time is applicable) into the appropriate SDTM --DTC variables (e.g., --DTC, --STDTC, --ENDTC) using the ISO 8601 format.
   2. Collecting the time an intervention was started is only appropriate if it can be realistically determined and if there is a scientific reason for needing to know this level of detail. An example is where the subject is under the direct care of the site at the time the intervention was started, and the study design is such that it is important to know the intervention start time with respect to dosing.
4. CDASH variable -- REASND is used with SDTM variable --STAT only. The value "NOT DONE" in --STAT indicates that the subject was not questioned about the intervention or data was not collected. It does not mean that the subject had no interventions.
5. Coding
   1. When free text intervention treatments are recorded, the location may be included in the --TRT variable to facilitate coding (e.g., Liver Biopsy). Location is collected when the sponsor needs to identify the specific anatomical location of the intervention. This location information does not need to be removed from the verbatim --TRT when the SDTMIG submission datasets are created, but the --LOC variable will need to be populated with the anatomical location. Reference the SDTMIG for more information.
   2. --ATC1 through --ATC5, --ATC1CD through --ATC5CD. These Non-Standard (or SUPPQUAL) Variables are used only when the intervention is coded using the Anatomical Therapeutic Chemical Classification System. The numbers indicate the anatomical main group: "1" = the anatomical main group, "2" = the therapeutic main group, "3" = the therapeutic/pharmacological subgroup, "4" = chemical/therapeutic/pharmacological subgroup, "5" = chemical substance.
   3. The implementer may also add the MedDRA coding elements as Non-Standard Variables to the Intervention domain if this dictionary is used for coding.
6. Location (--LOC) and related variables (--LAT, --DIR, -- PORTOT)
   1. Because the complete lists of controlled terminology for these variables may be too extensive to be relevant for a particular study CRF, sponsors may choose to include only subsets of the controlled terminology on the CRF.
   2. --LOC could be a defaulted or hidden field on the CRF for pre-specified [--TRT]/Intervention Topic].
7. Relative Timing Variables (See SDTMIG Section 4.1.4.7 for more information and details)
   1. For each study, the sponsor defines the study reference period in the DM domain using SDTMIG variables RFSTDTC and RFENDTC. Other sponsor-specified reference time points can be defined for other data collection situations. The CDASH variables --PRIOR and --ONGO may be collected in lieu of a "start date" or an "end date".
   2. The CDASH variable --PRIOR is used to indicate if the --TRT (the topic item) started prior to either the study reference period or another sponsor-defined reference time point. When the study reference period is used as the anchor, --PRIOR may be used to derive a value (from the controlled terminology codelist STENRF) into the SDTM relative timing variable --STRF. When populating --STRF, if the value of --PRIOR is "Y", the value of "BEFORE" may be mapped to --STRF. The value in DM.RFSTDTC serves as the anchor for --STRF.
      
      When a reference time point is used instead of the study reference period, --PRIOR may be used to derive a value into the SDTM relative timing variable --STRTPT. If the value of --PRIOR is "Y", the value of "BEFORE" may be derived into --STRTPT. Note: --STRTPT must refer to the "time point anchor" as described in --STTPT. The value in --STTPT can be either text (e.g., "VISIT 1") or a date (in ISO 8601 format).
   3. The CDASH variable --ONGO is used to indicate if the value in --TRT is continuing beyond the study reference period or beyond another sponsor-defined reference time point. When the study reference period is used as the anchor, --ONGO may be used to derive a value into the SDTM relative timing variable --ENRF. If the value of --ONGO = "Y", the value of "AFTER" may be mapped to --ENRF.
      
      When a reference time point is used instead of the study reference period, --ONGO may be used to derive a value into the SDTM relative timing variable --ENRTPT. If the value of --ONGO is "Y", the value of "ONGOING" may be mapped to --ENRTPT. Note: --ENRTPT must refer to the "time point anchor" as described in --ENTPT. The value in --ENTPT can be either text (e.g., "TRIAL EXIT") or a date (in ISO 8601 format).

Description/Overview for the CDASHIG CM - Prior and Concomitant Medications Domain

The same basic data collection variables should be collected for all medications/treatments/therapies (Prior, General Concomitant Medications, and Medications of Interest). If additional fields are needed to collect other data about a medication of interest, those should be added as nonstandard fields. Note: Sponsor may use terms like "concomitant medications", "treatments", or "therapies" as appropriate for the study. The text below may use one of these terms, but sponsors can always use the term most appropriate for their study.

The term "Prior" refers to medications/treatments that were started before study participation, since limited information may be available on prior medications taken by a subject; the core requirements were constrained to reflect this limitation.

Sponsors should define the appropriate collection period for prior and concomitant medications/treatments in the study protocol.

Specification for the CDASHIG CM - Prior and Concomitant Medications Domain

Concomitant Medications (CM)

Assumptions for the CDASHIG CM - Prior and Concomitant Medications Domain

1. General medications/treatments are defined as any medications/treatments reported by a subject when asked if they have taken any medications in an open-ended way that does not ask about any specific drug. Additional information might be sourced by referring to a subject's medical record.
2. Medications of interest are defined as any medications or classes of drugs specifically mentioned in the protocol and were not the primary focus for determining the CDASHIG Core designations for the domain (e.g., excluded medications, drugs requiring a washout period prior to dosing in study, or rescue medications).
3. As with all the data collection variables recommended in the CDASH standard, it is assumed that sponsors will add other data variables as needed to meet protocol-specific and other data collection requirements (e.g., TA-specific data elements and others as required per protocol, business practice and operating procedures).
4. The CMOCCUR field provides a structure for capturing the occurrence of specific medications of interest.
5. If sponsors wish to capture non-pharmacological therapies (e.g., Surgery procedures, aromatherapy, massage, acupuncture), they can use the PR domain.

Example CRF for the CDASHIG CM - Prior and Concomitant Medications Domain

Example 1

Example Data for the CDASHIG CM - Prior and Concomitant Medications Domain

Examples are not available at this time.

Description/Overview for the CDASHIG EC - Exposure as Collected and the CDASHIG EX - Exposure Domains

In the SDTMIG, the Exposure (EX) domain is used to represent exposure to study treatment as described in the protocol. The Exposure as Collected (EC) domain is used to represent the data as collected on the CRF. The CDASHIG EC domain is used in a study when the SDTMIG EX domain cannot be directly populated with the data collected on the CRF.

CDASHIG EC is used when:

1. An alias for the actual treatment name is used (e.g., the study is masked) rather than the actual treatment name (e.g., the study is open label).
2. Exposure data are collected in non-protocol-specified units (e.g., tablets).
3. Scheduled and/or missed doses are collected.
4. Planned doses (e.g., a calculation based on body weight) are collected in addition to actual doses given.

A sponsor may choose to always collect exposure data using the CDASHIG EC domain.

Extensive discussion of the use of the EC and EX domains, including examples of data collection, is available in the SDTMIG.

Specification for the CDASHIG EC - Exposure as Collected and the EX - Exposure Domains

Exposure as Collected (EC)

Exposure (EX)

1. If the SDTMIG EC dataset would be an exact duplicate of the SDTMIG EX dataset, then the sponsor may choose to collect data using either the CDASHIG EC or EX domain. (See the SDTMIG for additional information on submission.)
2. The collected --TRT value is the name of the study treatment that is known to the subject or investigative site (e.g., ECTRT = "TABLET A" when EXTRT= <treatment name>).

3. If dosing data are collected in non-protocol-specified units, the data are collected in CDASHIG EC dataset, then programmatically converted to the protocol-specified units when the data are mapped to the SDTMIG EX domain.

   Dosing units specified in the protocol	Dosing information as collected on the CRF and represented in EC	Representation in EX
   200 mg tablet	2 tablets	400 mg
   100 mg capsule	1 capsule	100 mg
   5 mg/kg	99 mL	5 mg/kg

4. If a treatment is such that start and stop times are not required, and only one dosing date is collected, then the collected dosing date will map to both the start date (--STDTC) and end date (--ENDTC) in the submitted exposure dataset(s).
5. If scheduled dosing is collected, the ECMOOD variable may be used to distinguish between "SCHEDULED" and "PERFORMED" dosing records. The sponsor may choose to use this variable to capture multiple scheduled dosing records, if needed.
6. ECOCCUR:
   1. ECOCCUR value of "N" indicates a dose was not taken, not given, or missed.
   2. ECOCCUR is generally not applicable for Scheduled records.
   3. ECOCCUR = "N" is the standard representation of the collected doses not taken, not given, or missed.
7. Dose amount variables (e.g., ECDOSE, ECDOSTXT) must not be set to zero (0) as an alternative method for indicating doses not taken, not given, or missed.

Example CRFs for the CDASHIG EC- Exposure as Collected and the CDASHIG EX - Exposure Domains

Example 1

Example 2

Example 3

Example Data for the CDASHIG EC - Exposure as Collected Domain

Examples are not available at this time.

Description/Overview for the CDASHIG PR - Procedures Domain

The Procedures domain should be used to collect details describing a subject's therapeutic and diagnostic procedures conducted before, during, and/or after the study. Measurements obtained from procedures are to be represented in the appropriate Findings domain(s). For example, the details of an endoscopy (e.g., date and time of start and stop) are represented in the PR domain, while microscopic results would be represented in the Microscopic (MI) domain.

Specification for the CDASHIG PR - Procedures Domain

Procedures (PR)

Assumptions for the Procedures CDASHIG Domain Model

1. Information on procedures is generally collected in one of two ways, either by recording free text or using a pre-specified list of terms.
2. Since the solicitation of information on specific therapeutic and diagnostic procedures may affect the frequency at which they are reported, the fact that a specific procedure was solicited may be of interest to reviewers. PROCCUR is used to indicate whether a pre-specified procedure occurred. A value of "Y" indicates that the procedure occurred and "N" indicates that it did not. If a procedure was not pre-specified, the value of PROCCUR should not be collected.

Example CRFs for the CDASHIG PR - Procedures Domain

Example 1

Example 2

Example Data for the CDASHIG PR - Procedures Domain

Examples are not available at this time.

Description/Overview for the CDASHIG SU - Substance Use Model

This domain is used to collect information on substance use when this information is relevant to the assessment of the efficacy and safety of therapies. The amount of information collected for this domain depends upon the sponsor's protocol. In many protocols, only information on the use of the substance is required. In this case, many of the variables in this domain would not be collected (e.g., duration, amount).

CDASH recommends the use of the more descriptive CDASHIG variable SUNCF with responses of "Never", "Current", or "Former" for each substance use type, rather than a simple "No/Yes" response. Based on the wide variability of protocol definitions of use, the specific definitions and timeframes for the SUNCF responses would be sponsor/protocol-defined. By using the SUNCF response categories for usage, a number of questions about use and frequency can be collapsed, in turn decreasing the number of data points required in the SU Domain. More detailed information about duration, amount, and start and end dates are optionally captured.

Specification for the CDASHIG SU- Substance Use Model

Substance Use (SU)

Assumptions for the CDASHIG SU- Substance Use Model

1. Categories SUCAT and SUSCAT
   1. Sponsors may require different types of substance use data (e.g., illicit drug use, cigarettes, etc.) to be collected; the value for category may be pre-printed on the CRF.
   2. SUCAT and SUSCAT should not be redundant with SUTRT. For example, if a more detailed type of substance usage is collected on the CRF (e.g., "CIGARETTES", "CIGARS"), SUCAT should be "TOBACCO" and SUTRT could be "CIGARETTES", "CIGARS". If the sponsor does not solicit responses about specific types of substance used, on the CRF (e.g., "CIGAR", "CIGARETTE"), the value of SUTRT is the more general description of the substance, (e.g., "TOBACCO") and SUCAT is generally null. This practice avoids assigning the same value to both SUTRT and SUCAT. However for consistency across studies, the sponsor may elect to repeat the values of SUTRT in SUCAT.
2. The SDTMIG variable SUPRESP should be pre-populated to the value of "Y" when information about the use of a specific substance is solicited on the CRF.
3. Relative Timing Variables
   1. Relative timing variables are used to represent collected data in the SDTM tabulations in those cases where a Start Date or an End Date has not been collected, but some indication of when/if the intervention or event started or ended has been collected. In the CDASHIG SU domain, if the CDASHIG variable SUNCF (with the possible responses of "Never", "Current", or "Former") is used, the collected values may be used to derive a value into an SDTMIG relative timing variable to represent when the person started or stopped using the substance relative to either a time point or to a period of time in the study.
      
      For example, if the value collected in SUNCF is "Current", the value of "ONGOING" may be represented in the SDTMIG Variable SUENRTPT to indicate that the person was still using cigarettes as of the time point described in SUENTPT. It is recommended that the sponsor collect either a date or a description of a time point that will be used in conjunction with relative timing variables. See SDTMIG Section 4.1.4.7 for more information about relative timing variables.
      
      If the actual, complete start date or end date of the substance use has been collected, there is no need to use relative timing variables.
4. Start and End Dates
   1. Start and end dates can be collected if this level of detail is required by the protocol. Partial dates can be collected where the subject may not remember the complete date of when substance use started or ended. The sponsor may choose to capture a complete date or any variation thereof (e.g., month & year or year, etc.).
   2. Sponsors may elect to capture only a start date, or only an end date, and use the associated SDTMIG relative timing variables to represent information about the date not collected.
   3. If the sponsor is only interested in collecting whether or not the subject is consuming a particular substance, start and end dates are optional and may be omitted, and SUNCF may be collected as described above.
5. Coding
   1. Coding may be performed if deemed necessary by the sponsor. The SDTMIG variable SUDECOD is a permissible variable in the SDTMIG SU Domain.
   2. Coding variables are not usually displayed on CRFs. If a sponsor chooses to display coding on the form, CDASH does not advocate using that as a field for entry by site personnel.

Example CRF for the CDASHIG SU- Substance Use Model

Example 1

Example 2

Example Data for the CDASHIG SU- Substance Use Model

Examples are not available at this time.

The Events class includes CDASH domains that define standards for the collection of occurrences or incidents occurring during a trial (e.g., "adverse events" or "disposition") or prior to a trial (e.g., "medical history").

1. CDASH --YN variables with the question text "Were there any <events>?" (e.g., "Were there any adverse events?" or "Were there any healthcare encounters?") are intended to assist in the cleaning of data and in confirming there are no missing values. These questions can be added to any CRF in order to capture this information.
2. CDASH --CAT and/or -SCAT are generally not entered on the CRF by the sites. Implementers may pre-populate and display these category values to help the site understand what data should be recorded on the CRF. Implementers may also pre-populate hidden variables with the values assigned within their operational database. Categories and subcategories are typically self-evident from the protocol design, and could be populated during the SDTM dataset creation.
3. Date and Time variables
1. CDASH date variables (e.g., --DAT, --STDAT,--ENDAT) are concatenated with the CDASH Time variables (e.g., --TIM, --STTIM, --ENTIM (if time is collected) into the appropriate SDTM --DTC variables (e.g., --DTC, – STDTC, --ENDTC) using the ISO 8601 format.
2. Collecting the time of an event is only appropriate if it can be easily obtained and if there is a scientific reason, such as the need to know the order of events (i.e., the adverse event started after dosing). An example of this would be a study where the subject is confined to a Phase 1 unit and under the direct care of the unit staff at the time that the event started or using time to tie together dosing and PK sample collection.
4. CDASH --COCCUR variable is used only if a specific event is solicited (pre-printed) on the CRF and the CRF elicits a response from the CDASH Codelist --COCCUR. As of the time of publication, the CDASH Controlled Terminology includes values that indicate that the data was not collected (Not Done). Whereas the SDTM Controlled Terminology for --OCCUR only includes the "N"," Y", and "UNKNOWN" responses. If the CDASH variable --OCCUR was used, the CRF would require a second question to indicate that the data was not collected. In STDM, the CDASH --COCCUR variable will be mapped to the SDTM variable --OCCUR and --STAT variables. Responses of "Y" or "N" map directly to SDTM --OCCUR. Responses of "NOT DONE" or "NOT COLLECTED" map to SDTM --STAT as "NOT DONE". --COCCUR is not used if the events are not pre-specified.
5. CDASH variable --REASND is used in conjunction with SDTM variable --STAT. The value "NOT DONE" in --STAT indicates that the subject was not questioned about the event or data was not collected. It does not mean that the subject had no events.
6. Coding
1. The CDASH variables used for coding are not data collection fields that will appear on the CRF itself. Sponsors will populate these through the coding process.
2. When free text event terms are entered, the location may be included in --TERM to facilitate coding and further clarify the event. This location information does not need to be removed from the verbatim term when the SDTM submission datasets are created.
3. The CDASH variables --LLT, --LLTCD, --PTCD, --HLT, --HLTCD, --HLGT, --HLGTCD, --SOC, and --SOCCD are only applicable to events coded in MedDRA.
7. Location (--LOC, --LAT, --DIR, --PORTOT)
1. Location is collected when the sponsor needs to identify the specific anatomical location of the event.
2. Implementers may collect the location information using a subset list of CT on the CRF. Location variables can be pre-populated as needed. There is currently some overlap across the LOC, LAT, and DIR variables for controlled terminology. While the overlap exists, ensure that this overlap for these variables is not part of database design.

Description/Overview for the CDASHIG AE- Adverse Events Domain

The Adverse Events dataset includes clinical data describing "any untoward medical occurrence in a patient or clinical investigation subject administered a pharmaceutical product and which does not necessarily have to have a causal relationship with this treatment" (ICH E2A). In consultation with regulatory authorities, sponsors may extend or limit the scope of adverse event collection (e.g., collecting pre-treatment events related to trial conduct, not collecting events that are assessed as efficacy endpoints). The events included in the AE dataset should be consistent with the protocol requirements. Adverse events may be captured either as free text or via a pre-specified list of terms. The structure of the SDTMIG AE domain is one record per adverse event per subject. It is the sponsor's responsibility to define an event. This definition may vary based on the sponsor's requirements for characterizing and reporting product safety and is usually described in the protocol.

As with all the data collection variables recommended in CDASH, it is assumed that sponsors will add other data variables as needed to meet protocol-specific and other data collection requirements (e.g., TA-specific data elements and others as required per protocol, business practice, and operating procedures). Sponsors should define the appropriate collection period for adverse events.

Specification for the CDASHIG AE- Adverse Events Domain

Adverse Events (AE)

Assumptions for the CDASHIG AE- Adverse Events Domain

1. CDASHIG AEYN variable with the question text "Were any adverse events experienced?" is intended to assist in the cleaning of data and in confirming that there are no missing values. This CDASHIG variable is not included as part of the SDTMIG AE domain for submission. This question is annotated as "NOT SUBMITTED" on the CRF.
2. Categories AECAT and AESCAT
   1. AECAT and AESCAT should not be redundant with the dictionary coding provided by AEDECOD and AESOC (i.e., they should provide a different means of defining or classifying AE records).
   2. AECAT and AESCAT are intended for categorizations that are defined in advance. Forexample, a sponsor may have a separate CRF page for AEs of special interest and then another page for all other AEs. In cases where a category of AEs of special interest resembles a part of the dictionary hierarchy (e.g., "CARDIAC EVENTS"), the categorization represented by AECAT and AESCAT may differ from the categorization derived from the coding dictionary.
3. Presence or Absence of Events
   1. Adverse Events are most often collected as free-text, spontaneously reported adverse events. There may be cases where the occurrences of specific adverse events are solicited, per protocol requirements. In that case, the pre-specified adverse events would be listed on the CRF with a "Yes/No" question (AEOCCUR) asking about the occurrence of each one.
   2. The CDASHIG variable AEOCCUR does not map directly to an SDTM variable. Since the SDTM AE domain is intended to hold only Adverse Events that actually happen, all values collected in AEOCCUR for pre-specified AEs should be submitted in a Findings About Adverse Events data set (FAAE) where FAORRES=the value of AEOCCUR where FATESTCD="OCCUR". In addition, where AEOCCUR="Y", there should be a corresponding record in the AE domain.
   3. It's important to reiterate the distinction between Adverse Events and Clinical Events, especially if there may be pre-specified terms. In consulting with regulatory authorities, certain events (e.g., events associated with protocol endpoints) may simply be Clinical Events. (See the CDASHIG Section 8.2 Clinical Events for more details.)
4. Coding
   1. AEDECOD is the preferred term derived by the sponsor from the coding dictionary. It is a required SDTMIG variable and must have a value. It is expected that the reported term (AETERM) will be coded using a standard dictionary such as MedDRA. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the define.xml external codelist attributes.
   2. AEMODIFY is a permissible SDTMIG variable and should be included if the sponsor's coding procedure permits modification of a verbatim term. The modified term is listed in AEMODIFY. The variable should be populated as per the sponsor's coding procedure.
   3. The CDASHIG elements AELLT, AELLTCD, AEPTCD, AEHLT, AEHLTCD, AEHLGT, AEHLGTCD, AEBDSYCD, AESOC, and AESOCCD are only applicable to events coded in MedDRA. These items are not expected for non-MedDRA coding.
5. Relative Timing Variables
   1. AEONGO field does not map directly to an SDTMIG variable. It may be used to derive a value into an SDTMIG relative timing variable such as AEENRF or AEENRTPT when no end date is recorded. When populating AEENRF, if the value of AEONGO is "Y", a value (from the values "DURING", "AFTER" or "DURING/AFTER" as is appropriate to the study) may be derived. When populating AEENRTPT, if the value of AEONGO is "Y", the value of "ONGOING" may be derived. Note: AEENRTPT must refer to a "time point anchor" described in AEENTPT.
   2. Note AEONGO is a special use case of "Yes/No" where the question is usually presented as a single possible response of "Yes" in conjunction with another question, as in this case, an end date. AEONGO is completed to indicate that the AE has not resolved at the time of data collection, and thus no end date is collected. In some cases the ongoing status may be determined from AE Outcome. The purpose of collecting this field is to help with data cleaning and monitoring, since this field provides further confirmation that the end date was deliberately left blank.
6. CDASHIG Action Taken Variables
   1. CDASHIG variables AEACN, AECONTRT, AEACNDEV, AEACNOYN, and AEACNOTH are used to collect the action taken as the result of an AE.
   2. CDASHIG AEACN describes changes to the study treatment as a result of the event. AEACN is specifically for the relationship to study treatment using controlled terminology. It is expected that a response would be provided for this question for all AEs.
   3. AEACNOTH describes Other Action(s) taken in response to the adverse event that are unrelated to study treatment dose changes or other non-study treatment given because of this adverse event. This field is usually collected as a free text field. Example: Treatment Unblinded, Primary Care Physician Notified. If possible/desired, the sponsor can create sponsor-defined controlled terminology. The CDASHIG variable AEACNOYN is used in conjunction with AEACNOTH to assist in the cleaning of data and in confirming that AEACNOTH is not missing. AEACNOYN is not included as part of the SDTMIG AE Domain for submission and is annotated as NOT SUBMITTED on the CRF. The CDASHIG variable AEACNOYN should only be used on the AE CRF.
   4. AECONTRT indicates if any non-study treatments were received because of this adverse event using the NY Controlled terminology. If "Yes" is answered for this question, any drugs used are recorded on the Concomitant Medications CRF and any procedures performed are recorded on the Procedure CRF. On the Concomitant Medications CRF, the CDASHIG variable CMAENO or on the Procedures CRF the CDASHIG variable PRAENO can be collected to identify the adverse event associated with this treatment by recording the appropriate AESPID. RELREC can be used to identify this relationship.
   5. AEACNDEV describes action taken with respect to a device in a study, which may or may not be the device under study. This field is usually collected as a free text field. If possible/desired, the sponsor can create sponsor-defined controlled terminology. FDA Medical Device Reporting (MDR) guidelines provide CT for the reporting of device problems.
7. Serious Adverse events
   1. If the details regarding a Serious AE are collected in the clinical database, then it is recommended that a separate "Yes/No" variable be defined for each Serious AE type (AESCAN, AESCONG, AESDISAB, AESDTH, AESHOSP, AESLIFE, AESOD, AESMIE).
   2. The sponsor should check if the regulatory agencies to which the data will be submitted require the collection of this data (see FDA Study Data Technical Conformance Guide). The serious categories "Involves cancer" (AESCAN) and "Occurred with overdose" (AESOD) are not part of the ICH definition of a serious adverse event, but these categories are available for use in studies conducted under guidelines that existed prior to the FDA's adoption of the ICH definition.
8. CDASHIG variables AESEV, AETOXGR
   1. In studies using a standard toxicity scale such as Common Terminology Criteria for Adverse Events v3.0 (CTCAE), published by the NCI (National Cancer Institute) at http://ctep.cancer.gov/reporting/ctc.html, AETOXGR should be used instead of AESEV. In most cases, either AESEV or AETOXGR is populated but not both.
   2. There may be cases when a sponsor may need to populate both variables. Whichever is used, the sponsor is expected to provide the dictionary name and version or standard toxicity scale name and version used to map the terms utilizing the define.xml external codelist attributes.
9. CDASHIG variable DTHDAT
   1. The CDASH Model allows the Date of Death to be collected on any CRF deemed appropriate by the Sponsor. Death Date is mapped to other SDTMIG domains, as deemed appropriate by the sponsor (e.g., DM, DS).
   2. The death date should only be collected on one form.

Adverse Events are most often collected as free text, spontaneously reported adverse events. There may be cases where the occurrences of specific adverse events are solicited, per protocol requirements. In that case, the pre-specified adverse events would be listed on the CRF with a "Yes/No" question (AEOCCUR) asking about the occurrence of each one.

Example CRF for the CDASHIG AE- Adverse Events Domain

Example 1

Example Data for the CDASHIG AE- Adverse Events Domain

Examples are not available at this time.

Description/Overview for the CDASHIG CE - Clinical Events Domain

The Clinical Events domain includes clinical events of interest that would not be classified as adverse events. The clinical events included in the CE dataset should be consistent with the protocol requirements. Clinical events may be captured either as free text or via a pre-specified list of terms. The structure of the CE domain is one record per clinical event per subject. It is the sponsor's responsibility to define a clinical event and the event is usually described in the protocol.

As with all the data collection variables recommended in CDASH it is assumed that sponsors will add other data variables as needed to meet protocol-specific and other data collection requirements (e.g., TA-specific data elements and others as required per protocol, business practice and operating procedures). Sponsors should define the appropriate collection period for clinical events.

Specification for the CDASHIG CE - Clinical Events Domain

Clinical Events (CE)

Assumptions for the CDASHIG CE - Clinical Events Domain

1. The determination of events to be considered clinical events versus adverse events should be done carefully and with reference to regulatory guidelines or consultation with a regulatory review division. Please note that all reportable adverse events that would contribute to AE incidence tables in a clinical study report must be included in the AE domain. Adverse event data should not be commingled with clinical event data. The collection of write-in events on a Clinical Events CRF should be considered with caution.
2. Events considered to be clinical events may include episodes of symptoms of the disease under study (often known as signs and symptoms), or about events that do not constitute adverse events in themselves, though they might lead to the identification of an adverse event. For example, in a study of an investigational treatment for migraine headaches, migraine headaches may not be considered to be adverse events per protocol. The occurrence of migraines or associated signs and symptoms might be reported in CE.
3. Some clinical events may escalate (e.g., increase in duration, severity) and require additional collection in AE. This should be clearly defined in the protocol.
4. The CDASHIG variable, CEYN, with the question text "Were any clinical events experienced?" is intended to assist in the cleaning of data and in confirming that no data are unintentionally missing. This CDASHIG variable is not included as part of the SDTM Event Domain for submission. This field is annotated as NOT SUBMITTED on the CRF.
5. Categories CECAT and CESCAT should not be redundant with the domain code or dictionary classification provided by CEDECOD and CESOC (i.e., they should provide a different means of defining or classifying CE records).
6. Presence or Absence of Events: The CDASHIG variable CEOCCUR is used to record whether a subject had a pre-specified clinical event. Example: "Does the subject have a fever?"
7. Coding
   1. CEDECOD is the preferred term derived by the sponsor from the coding dictionary. It is permissible to code CETERM using a standard dictionary such as MedDRA. The sponsor is expected to provide the dictionary name and version used to map the terms utilizing the define.xml external codelist attributes.
   2. CEMODIFY is a permissible variable and should be included if the sponsor's coding procedure permits modification of a verbatim term. The modified term is listed in CEMODIFY. The variable should be populated as per the sponsor's coding procedure. The CDASHIG elements CELLT, CELLTCD, CEPTCD, CEHLT, CEHLTCD, CEHLGT, CEHLGTCD, CEBDSYCD, CESOC, and CESOCCD are only applicable to events coded in MedDRA. These items are not expected for non-MedDRA coding.
8. Relative Timing Variables
   1. CEONGO field does not map directly to an SDTMIG variable. It may be used to derive a value into an SDTMIG relative timing variable such as CEENRF or CEENRTPT when no end date is recorded. When populating CEENRF, if the value of CEONGO is "Y", a value (from the values "DURING", "AFTER" or "DURING/AFTER" as is appropriate to the study) may be derived.
   2. When populating CEENRTPT, if the value of CEONGO is "Y", the value of "ONGOING" may be derived. CEENRTPT must refer to a "time point anchor" described in CEENTPT.
9. CEONGO is a special use case of Yes/No where the question is usually presented as a single possible response of Yes in conjunction with another question, as in this case, an end date. CEONGO is completed to indicate that the CE has not resolved at the time of data collection, and thus no end date is collected. The purpose of collecting this field is to help with data cleaning and monitoring, since this field provides further confirmation that the end date was deliberately left blank.

Example CRF for the CDASHIG CE- Clinical Events Domain

See Example CRF 5: Hypoglycemia as referenced in CDISC Therapeutic Area Data Standards User Guide for Diabetes (Version 1.0)
http://www.cdisc.org/sites/default/files/members/standard/ta/diabetes/taug-diabetesv101.pdf