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:
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.
- Refer to both the CDASH Model and Appendix C, CDASH Model Metadata Tables.
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.
- Select variables from the SDTM when fields from the CDASH Model cannot be used. Selection of variables must align with SDTM usage restrictions.
Create a new applicant-defined collection field when fields in the CDASH Model and variables from the SDTM cannot be used.
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
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.
...
data collection fields (not already defined in the CDASH Model) will fall
...
in 1 of following categories:
a field used for operational, data cleaningpurposes only;
a field used to collect data that have direct mappingto a target variable in the tabulation dataset; or
a field used to collect data that have no direct mapping to a target variable in the tabulation dataset.
The following table provides implementation guidance aligned with both the category of the field and target variable.
| Metadataspec |
|---|
| Num | Field Category | Target Tabulation Variable | Implementation |
|---|
Fields used for data cleaning purposes only and not submitted in SDTM datasets (e.g., --YN). |
|---|
| 1 | Data cleaning | NA | The 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 dashes (--) with the 2-character domain code |
, Question Text Prompt Question Text Prompt | prompts from the CDASH Model as a base. Always create |
custom data| custom data-cleaning/operational variables using consistent naming conventions. |
Fields with a direct mapping to a tabulation dataset variable. | If 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 should will be used as the data collection variable name in the operational database to streamline the mapping process. |
Extensions Characters may be appended |
if 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 |
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. | If a study requires a field that is not identical to an SDTMIG field 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 |
SDTMIG , SDTMIG tabulation variable is derived from the collected |
datavalue, then the operational |
database should database should use a collection variable with a different name from |
the SDTMIG tabulation 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.
No | If a field does not align with a tabulation variable, |
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 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 |
. (See the SDTMIG appendices.) |
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.