Page History

Conformant collection and representation of tobacco product data is ensured by full adherence to standards per this guide. Conformance to standards is assessed by confirming implementation of standards per this guide and by evaluating tabulation and analysis data in relation to conformance rules.

The following table illustrates minimum conformance to standards for data collection using CRFs.

Determining whether a product faithfully implements a standard or specification is essential to creating robust, interoperable solutions. 

Data Collection

The following guidelines should be followed to ensure implementation of CDASH compliant CRFs

1. 1. In Findings domains, values from the relevant CDISC CT lists must also be used to create appropriate Question Text, Prompts, and/or variable names. For example, if the question is about the subject's height, incorporate the value of "Height" from the VSTEST codelist as the prompt on the CRF, and incorporate "HEIGHT" from VSTESTCD in the variable name.

1. The design of the CRF must follow guidance in Section 4.1, Best Practices for Creating Data Collection Instruments, and Section 4.2, CRF Design Best Practices.

1. In cases where the data collection is done in a denormalized presentation on the CRF, the relevant CDISC CT should be used in the question text or prompt as much as possible. It is acceptable to use synonym text that will directly map to a CDISC submission value (including an NCI Preferred Term), if the CDISC submission value is not appropriate for data collection. For example, "ALT" may be better than "Alanine Aminotransferase" as the prompt for this lab test. If there is no CDISC CT available, the question text or prompt must be standardized by the implementing organization and used consistently. One of the basic purposes of CDASH is to reduce unnecessary variability between CRFs and to encourage the consistent use of variables to support semantic interoperability; therefore, Question Text and Prompt must be used verbatim. 
2. Similarly, where SDTMIG variables exist in the operational database and the value conforms to controlled terminology, it is permissible to use a familiar synonym on the CRF without affecting conformance. For example, on the Demographics page, SEX may be displayed as "Male" or "Female", whereas in the operational database the controlled terminology values of "M" and "F" would be used.
3. In some cases, CDASH Question Text and Prompt allow for flexibility while still being considered conformant. See Section 2.3, CRF Development Overview, for further details on the usage of Question Text and Prompt.
4. CDASH Model Question Text may contain options for the tense; if the option is not provided, the tense of the Question Text may be modified to reflect the needs of the study.
5. In cases where the CDASH Question Text or Prompt cannot be used due to culture or language, or a CRF must be translated for language or cultural reasons, the implementer must ensure the translation is semantically consistent with the CDASH Question Text and Prompt in the CDASHIG metadata table.
6. In cases where a more specific question needs to be asked than that provided by Question Text or Prompt, CDASH recommends the use of a brief CRF Completion Instruction, as long as the instruction clarifies the data required by the study without altering the meaning of variable as defined by the standard. For example, "Sex at birth" is not the same question as "Sex" (which is loosely defined as "reported sex").

1. Use a consistent syntax that includes the root variable name and/or controlled terminology, and any other standardized concepts that are needed to support efficient mapping of the collected value to SDTM datasets. The goals are to have beginning-to-end traceability of the variable name from the data capture system to the SDTM datasets, and to support automating electronic data capture (EDC) set-up and downstream processes.

   1. It is recognized that (particularly in an EDC system) the variable name of a data collection field, as well as the name in the underlying database, may have various “system” components that become part of the item’s identifier. EDC systems, prior to exporting data in a defined format, may require the variable name to include such database “references” as the EDC page name, the item “group” name, or perhaps a combination.

   2. In cases where the data collection is done in a denormalized way, appropriate CDISC CT must be used when it is available.

      1. For example, when collecting vital signs results in a denormalized eCRF, the variable names can be created by using terms from the Vital Signs Test Code codelist. For example, temperature result can be collected in a variable called TEMP or TEMP_VSORRES; systolic blood pressure result can be collected in a variable called SYSBP or SYSBP_VSORRES. When a particular system’s constraints limit the variable name to 8 characters, a similar, consistent implementation that preserves either the normalized root variable (e.g., ORRES) or the controlled terminology (e.g., --TESTCD value) should be implemented.

      2. Other variable patterns that intentionally connect the data collection variable to the target SDTMIG variable are also acceptable.  For example, targetDataset_targetVariable[_optionalTopic] is acceptable. Examples of this pattern include DM_AGE, DM_AGEU, VS_VSORRES_TEMP, VS_VSORRESU_TEMP, SUPPAE_QVAL_AEDIS.

   3. Whereas all CDASHIG defined variable names are 8 characters or fewer to accommodate SDTM limits on variable names, QNAMs, and --TESTCDs, the maximum length of a variable name that may be implemented is determined by the data management system used, not by CDASH. 

   4. When collecting data in a horizontal manner, to facilitate transformation to SDTM datasets, when possible it is recommended to create denormalized CDASH variables in the data collection system by incorporating the SDTMIG variable name target and/or the controlled terminology (e.g., --TESTCD) as part of the CDASH variable names. The domain-level metadata labeled as "Horizontal-Generic" in the Implementation Options column of the CDASHIG metadata tables are examples of how to implement this. There is no conformance requirement implied by these examples.

1. Data output by the operational database into an SDTMIG variable should require no additional processing if the CDASHIG and SDTMIG variable names are the same. 

1. An SDTM data programmer should be able to assume that data in an SDTMIG variable is SDTMIG-compliant. Minimal processing (e.g., changing case) does not affect conformance. This helps to ensure a quality deliverable, even if the programmer is unfamiliar with data capture practices.

1. his must be followed to maintain the validity of a validated instrument. (See Section 8.3.12, QRS - Questionnaires, Ratings, and Scales).
   1. In some cases, this may result in CRFs that do not conform to CDASH best practices; however, restructuring these questionnaires should not be done because it could invalidate them.
   2. The use of such questionnaires in their native format should not be considered to affect conformance to CDASH.