Page History

Standards in this guide are end-to-end implementations of CDISC models which are designed to ensure the traceability and transparency of data across activities in the data lifecycle. Implementation of models per this guide in relation to activities which support collection, tabulation, analysis, and exchange of data are further described in the table below.

...

• Product Impact on Individual Health

...

• Product Description
• Nonclinical
• Product Impact on Individual Health

...

• Product Description
• Product Impact on Individual Health
• Product Impact on Population Health

...

Defines a basic set of data collection fields that are expected to be present on the majority of CRFs.

The TIG provides instructions and recommendations to implement these models for the collection, representation, and exchange of tobacco product data. Controlled terminology and formats support implementation of all models. Standards for data exchange are applicable to all use cases and allow for the exchange of metadata for CRFs, tabulation datasets, and analysis datasets. 

The following table describes implementation of CDISC models with supporting standards and TIG sections.

...

• Domains...
• When data can be collected as it will be represented in a tabulation dataset, with no transformations or derivations, the TIG SDTM variable names are presented in the TIG CDASH to collect the data.
• In cases where collected data must be transformed or reformatted prior to inclusion in a tabulation dataset, or where a corresponding SDTMIG variable does not exist, CDASH has created standardized data collection variable names. 

In this guide, 

1. 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).
2. CDASHIG domains contain variables that may be used in the creation of the RELREC submission dataset. RELREC is an SDTM dataset that describes relationships between records for a subject within or across domains, and relationships of records across datasets. The specific set of identifiers necessary to properly identify each type of relationship is collected in each dataset to support merging the data.  Collected data may be across records within a domain, records in separate domains, and/or in sponsor-defined variables. For example, the CDASHIG variable CMAENO—having a question text of "What [is/was] the identifier for the adverse event(s) related to this (concomitant) [medication/therapy]?"—may be used to collect data that identifies a relationship between records in the CM dataset and records in the AE dataset.
3. The CDASH standard includes some data collection fields that are not in the SDTMIG (e.g., “Were any adverse events experienced?”, “Were any medication(s) taken?”, "Was the medication taken prior to study start?", “Was the medication ongoing?”). These fields support site-friendly data collection and help with data cleaning/data monitoring by providing verification that other fields on the CRF were deliberately left blank. For use of a field with this intent in an electronic data capture (EDC) system, a CDASH variable name is provided in the CDASHIG metadata table (e.g., AEYN, CMYN, CMPRIOR, CMONGO). When the CDASHIG field is confirming that data collection is not expected in other records (e.g., AEYN, CMYN), the corresponding SDTMIG Variable Name column indicates “N/A” and the Mapping Instruction column indicates that “this field is NOT SUBMITTED.”  When the CDASHIG field is confirming that data collection is not expected in another date field (e.g., CMPRIOR, CMONGO), the SDTMIG Variable Name lists the applicable SDTM timing variables and Mapping Instructions.
4. The CDASHIG Findings domain (e.g., Drug Accountability (DA), ECG Test Results (EG), 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).
5. The CDASH standard has intentionally not reproduced other sections of the SDTM standard and implementers are asked to refer to the SDTM and SDTMIG for additional information (both available on the CDISC website at http://www.cdisc.org/sdtm).
6. The CDASHIG data collection fields included in the CDASHIG metadata tables are the most commonly used and should be easily identified by most implementers. Additional data collection fields may be necessary to capture therapeutic area-specific data points as well as other data specified in the clinical study protocol or for local regulatory requirements. Reference the CDASH Model and relevant CDISC therapeutic area user guide(s) for additional information.
7. The CDASHIG is divided into sections of similar types of data and the CDASHIG metadata tables are arranged in alphabetical order (by domain abbreviation) within the 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 tables in a logical order, and annotated example CRFs have been provided (if available). In addition, implementers are referred to Section 4.1, Best Practices for Creating Data Collection Instruments, for a discussion on best practices for ordering fields on a CRF.

...

CDISC CDASH Model

• In this guide, the CDASH Model is implemented to support development of CRFs for the Product Impact on Individual Health use case only. The CDASH Model is the earliest model implemented for this use case.
• The CDASH Model defines a basic set of data collection fields that are expected to be present on the majority of CRFs.
• The use of CDASH data collection fields and variables facilitates mapping to tabulation datasets implemented from the SDTM.
• When data can be collected as it will be represented in a tabulation dataset, with no transformations or derivations, the TIG SDTM variable names are presented in the TIG CDASH to collect the data.
• In cases where collected data must be transformed or reformatted prior to inclusion in a tabulation dataset, or where a corresponding SDTMIG variable does not exist, CDASH has created standardized data collection variable names. 

CDISC SDTM

• The SDTM is implemented for use cases

...