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 belowin 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 existing domain fields. 

If a logically related grouping of data is in scope for a domain defined in this guide, but not all data can be represented using the domain variables, then data may be represented by adding variables from the SDTM to the domain or by using a Supplemental Qualifier dataset related to the domain. Prior to adding variables from the SDTM or considering a Supplemental Qualifier dataset, confirm that none of the existing domain variables will fit the need. Variables may be added to a domain and Supplemental Qualifier datasets may only used when data are different in nature and are not in scope for existing domain variables.  

Once confirmed, determine whether adding a variable from the SDTM will fit the need. If adding a variable from the SDTM meets the need, then a Supplemental Qualifier dataset will not be implemented. Supplemental Qualifier datasets will only be implemented for domains when data are not in scope for a variable defined in the SDTM. 

The overall process for extending a domain is as follows:

...

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

...

1. Include applicable Identifier variables.
2. Include applicable Qualifier variables in alignment with the SDTM General Observation Classes.
3. Include applicable Timing variables.
4. Apply the domain code to the variables as appropriate by replacing all variable prefixes (shown in the SDTM as “--“) with the domain code.
5. Set the order of variables consistent with the order defined in the SDTM.
6. Adjust the labels of the variables only as appropriate to convey their meaning in the context of the data in domain. Use title case for all labels.

7. Ensure that appropriate standard variables are being properly applied by comparing their use in the domain to their use in related TIG domains.

1. usage restrictions.

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

...

Place any non-SDTM variables in a Supplemental Qualifier dataset when variables cannot be selected from the SDTM. 

Adding Fields from the CDASH Model

The overall process for extending a domain is as follows:

During the development of conformant CRFs the tabulation domain to which the collected data will be mapped must be determined. The choice of the domain will be based on  to use does not depend upon the mode of transmission, the methodology used to generate the data, the medium used to store the data, the person who recorded the data, or the subject described by the data. The SDTMIG domain to be used affects what CDASH variable names, question texts, prompts, controlled terminology, and so on, to use. CDASH suggests a format to be presented to those entering the data, but it does not dictate any data structure in which to store the collected data (often referred to as a data management operational database).

Creating New Fields

...

1. 1. collection field, determine whether the data will be used for an operational use case (e.g.,

...

1. 1. data cleaning

...

1. 1. ) or are

...

1. 1. to be represented in a tabulation dataset. In general, new data collection fields (not already defined in the CDASH Model) will fall in

...

1. 1. 1 of following categories:

...

1. 1. 1. a field used for operational,

...

1. 1. 1. data cleaningpurposes only

...

1. 1. 1. ;

...

1. 1. 1. a field used to collect data that have

...

1. 1. 1. direct mappingto a target variable in the tabulation dataset

...

1. 1. 1. ; or

...

1. 1. 1. a field used to collect data that have

...

1. 1. 1. no direct mapping to a target variable in the tabulation dataset.

Prior to adding a custom field to a CRF, confirm that none of the collection fields in this guide or in the CDASH Model fit the need.

...

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

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.