Page History
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 | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
...
|
- 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 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
Overview
Content Tools