Versions Compared

Key

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

...

Prior to adding a custom field to a CRF, confirm that none of the data collection fields in this guide or in the CDASH Model fit the need. Once confirmed, a new collection field for a CRF will be categorized as one of the following:

  • Field for Data Cleaning, indicating a field that will support data cleaning only.
  • Direct Mapping, indicating a field that will map directly to a tabulation dataset variable.
  • No Direct Mapping, indicating a field that does not have a direct, one-to-one mapping to a tabulation dataset variable.

New data collection fields (not already defined in the CDASH Model) will fall under 1 of following categoriesImplementation of fields for each is described below.

Metadataspec
NumField CategoryImplementation
1
Fields used for data cleaning purposes only and not represented tabulation datasets (e.g., --YN).
Data CleaningThe field --YN with Question Text "
Were there
Were there any [interventions/events/findings]?"
 can be added to a domain
can be used for this purpose. Replace the
2
two dashes (--) with the
2
two-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
custom data-cleaning/operational variables using consistent naming conventions.
2
Fields with a direct mapping to a tabulation dataset variable.
Direct MappingIf a value can be collected exactly as it will be reported in the
SDTM
tabulation dataset (i.e., same value, same data type, same meaning, same controlled terminology), the
SDTMIG
tabulation variable name
should
will 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,
tabulation variable will align with tabulation variable and the meaning
should
will not be modified for data collection.
3
Fields without a direct one-to-one mapping to SDTM datasets. 

No Direct Mapping

  • 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.)

Pagenav