Page History

How to Create New Data Collection Fields When No CDASHIG Field Has Been Defined

Collection metadata can be extended when new data collection fields

 The naming conventions and other variable creation recommendations in CDASHIG are designed to allow collection of data regardless of subsequent inclusion in the SDTM, as well as to consistently facilitate transforming the collected data into submission datasets.

Prior to adding any new fields to a sponsor's study CRF, 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 the CDASH Model) will fall under 1 of following categories.

• Fields used for data cleaning purposes only and not submitted in SDTM datasets 

Metadata tables in this guide may be extended in cases where...

From Timing Variables: Collection, Conversion, and Imputation of Dates - CDASH Model 1.2 and Implementation Guide 2.2 - Wiki (cdisc.org)

Timing Variables

...

• (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 2 dashes (--) with the 2-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 data type, same meaning, same controlled terminology), the SDTMIG variable name should be used as the data collection variable name in the operational database to streamline the mapping process. Extensions may be appended if needed to create a unique variable name in the collection database. 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 (e.g., 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.1, 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, which would avoid having to split the collection of the data into 2 fields on the CRF.

  • An SDTM variable that is not defined in the SDTM version being used by the sponsor can be included as a non-standard variable (NSV)/supplemental qualifier.

  • If a study requires a field that is not defined in CDASH and the SDTM with the same meaning or intent (e.g., would map to SDTM SUPP--), a unique name should be assigned based on sponsor business rules using CDASH naming fragments (e.g., --DAT, --TIM) as appropriate and CDISC variable naming fragments where possible. (See the SDTMIG appendices.)

...

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 the Events or Interventions general observation class, this could be the start date of the event or intervention. In Findings domains, the collected timing variables generally refer to the date of the test result itself. However, in Findings domains where the result is based on a specimen—such as Laboratory Test Results (LB), Microbiology Susceptibility (MS), Microbiology Specimen (MB), Microscopic Findings (MI), or Pharmacokinetics Concentrations (PC) (Sampling)—the date of the specimen collection associated with the test result is used.

The CDASH Model defines Death Date (DTHDAT) as a timing variable; this is not included as a timing variable in the SDTMIG. It was included as a timing variable in CDASH, as it may be collected on any CRF deemed appropriate by the sponsor, but should only be collected once.

Visits 

Protocols define visits in order to describe assessments and procedures that are to be performed. Visits are typically described using the timing variables VISIT and VISITNUM. The date of the visit is typically collected in the CDASH timing variable VISDAT, which is the date the visit occurred (or started). 

OLD text

CDASH Model v1.2 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.

CDASH Model v1.2 provides root-naming conventions for CDASHIG variables, intended to facilitate mapping to SDTMIG variables. The variables defined in the CDASH Model follow the same "--XXXX" naming convention as in the SDTM. The 2 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.1 for specific information on this content.  

Mapping instructions in the CDASHIG metadata tables provide more complete guidance than that in the CDASH Model. When domain-level metadata are not available, consult the CDASH Model for SDTM mapping instructions.

Implementers must refer to the CDASH to create alternative text that may be used that meets CDASH conformance rules.

All domains should have at least one timing variable - CDASH section 3.6

...