Versions Compared

Old Version 9

changes.mady.by.user Christine Connolly

Saved on

compared with

New Version Current

changes.mady.by.user Christine Connolly

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

If data are in scope for a domain defined in this guide but not all data can be collected using the domain's collection fields, then collection fields may be added to the applicant's CRF from the CDASH Model, the SDTM, or created by the applicant using guidance in the TIG.

Prior to adding fields from the CDASH Model, the SDTM, or considering a new applicant-defined collection field, confirm that none of the fields in the domain will fit the need. Fields may be added from the CDASH Model, the SDTM, or created only when data are different in nature and are not in scope for collection fields in this guide.

Once confirmed, the overall process for extending metadata is as follows:

  1. 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.

    1. Refer to both the CDASH Model and Appendix C, CDASH Model Metadata Tables.

    2. Follow 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) and align with CDISC NSV Registry conventions as applicable.

  2. Select variables from the SDTM when fields from the CDASH Model cannot be used. Selection of variables must align with SDTM usage restrictions.

  3. Create a new applicant-defined collection field when fields in the CDASH Model and variables from the SDTM cannot be used.

    1. When creating a new applicant-defined collection field, determine whether the data will be used for an operational use case (e.g., data cleaning) or are to be represented in a tabulation dataset. In general, new data collection fields (not already defined in the CDASH Model) will fall in 1 of following categories:

      1. a field used for operational, data cleaningpurposes only;

      2. a field used to collect data that have direct mappingto a target variable in the tabulation dataset; or

      3. a field used to collect data that have no direct mapping to a target variable in the tabulation dataset.

    2. The following table provides implementation guidance aligned with both the category of the field and target variable.

Metadataspec
NumField CategoryTarget Tabulation VariableImplementation
1Data cleaningNAThe field --YN with Question Text "Were there any [interventions/events/findings]?" can be used 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 prompts from the CDASH Model as a base. Always create custom data-cleaning/operational variables using consistent naming conventions.
2Direct mappingYes

If a value can be collected exactly as it will be reported in the tabulation dataset (i.e., same value, same data type, same meaning, same controlled terminology), the tabulation variable name will be used as the data collection variable name in the operational database to streamline the mapping process. Characters may be appended to the data collection variable name if needed to create a unique variable name in the collection database. Any collection variable whose meaning is the same as tabulation variable will align with tabulation variable and the meaning will not be modified for data collection.

3

No direct mapping


Yes

If a value cannot be collected in alignment with the tabulation dataset variable (e.g., collected data type is different from the data type in the corresponding tabulation variable) or if the tabulation variable is derived from the collected value, then the operational database should use a collection variable with a different name from tabulation variable into which it will be mapped.

No

If a field does not align with a tabulation variable, a unique name should be assigned based on applicant business rules using CDASH naming fragments (e.g., --DAT, --TIM) as appropriate and CDISC variable naming fragments, found in the CDISC NSV Registry, where possible. 

If data are not in scope for a domain in this guide, a custom domain can be used. An existing domain may help in selecting the fields and terminology needed for the custom domain. The custom domain must be based on one of the SDTM general observation classes. See Section 2.8.3 How to Create New Specifications for further information.

Pagenav

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

Implementers must determine what additional data fields to add to address study-specific and therapeutic area requirements, and applicable regulatory and business practices. See 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.