Relationships Between Standards

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.

1. 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 submitted data can be collected as represented in an SDTM dataset, with no transformations or derivations, the SDTMIG variable names are presented in the CDASHIG metadata table and should be used to collect the data. In cases where the collected data must be transformed or reformatted prior to inclusion in an SDTM dataset, or where a corresponding SDTMIG variable does not exist, CDASH has created standardized data collection variable names. 
2. CDASHIG Version 2.2 content is based on SDTMIG Version 3.3. Please note that SDTMIG v3.3 is associated with SDTM v1.7.
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. 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.
5. 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.
6. 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).
7. 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).
8. 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.
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 CDASHIG, whenever practicable. 
10. 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.