How Standards Work Together

In draft

Standards in this guide are end-to-end implementations of CDISC models 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.

CDASH Model Known Issues

The CDASH Model aligns with and is structured similarly to the SDTM. The CDASH Model organizes data into 
classes, which represent meaningful groupings of data in clinical research. It defines CDASH metadata for identifier 
variables, timing variables, general observation class variables (Events, Interventions, and Findings), domainspecific variables, and special-purpose domain variables.
The current CDASH Model represents Identifier, Timing, and Domain-specific variables in the metadata as an 
Observation Class. This does not align with the SDTM. This will be revised in a future version of the CDASH 
Model

From CDASH IG 

The timing variables included in CDASH Model Section 2.7, Timing (https://www.cdisc.org/standards/foundational/cdash) are available for use in any CRF based on 1 of the 3 general observation classes, except where specific domain restrictions are noted in the SDTMIG. In general, all domains based on the 3 general observation classes should have at least 1 timing variable.

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.