Page History

Guidance in this section will be used with detailed guidance in Section 2.7.6, Metadata for Individual Health to implement collection standards.

Timing Variables: Collection, Conversion, and Imputation of Dates - CDASH Model 1.2 and Implementation Guide 2.2 - Wiki (cdisc.org)

Collection of Dates

Collect dates in such a way as to allow sites to record only the precision they know. The system should also store only the collected precision. Any incomplete dates must remain incomplete with no imputation and no “zero-filling” of missing components.

Data collection and database processes should allow for the possibility of partial dates and times, because a partial date may be the most precise information that can be collected for some data. (For an example of when it may be necessary or appropriate to collect partial dates, see Section 7.3, DM - Demographics.) In some countries, collection of a complete date of birth is restricted under privacy rules, so only a year (or year and month) of birth might be collected. Other examples of commonly collected partial dates occur in the Concomitant Medications (CM) and Medical History (MH) domains, where subjects might not remember the complete date of when they started to take a medication or when a significant medical history condition began.

If a full date is collected (or expected), the CDASH variable --DAT or all 3 date components (i.e., --DATYY, --DATMO, --DATDD) should be included on the collection tool. If a partial date can be collected in a single field, the CDASH --DAT should be used. If a partial date must be collected as separate database fields to collect year, month, and day, refer to the CDASH Model for examples of standard naming fragments (--YY, --MO, --DD, --TIM). The capabilities of individual software systems (e.g., EDC) will determine which variable names are needed. CDASH uses separate data collection fields for dates and times. If times are collected, it is expected that these will be used with the appropriate collected date to derive the related SDTM date variable in ISO 8601 format.

The following guidance...

Change title or "For" category

...

• Implement collection of dates such that individuals involved in data can only record the data to precision collected. 

  • The system should also store only the collected precision.

  • Any incomplete dates must remain incomplete with no imputation and no “zero-filling” of missing components.

  • Data collection and database processes should allow for the possibility of partial dates and times, because a partial date may be the most precise information that can be collected for some data. 

    If a full date is collected (or expected), the CDASH variable --DAT or all 3 date components (i.e., --DATYY, --DATMO, --DATDD) should be included on the collection tool. If a partial date can be collected in a single field, the CDASH --DAT should be used. If a partial date must be collected as separate database fields to collect year, month, and day, refer to the CDASH Model for examples of standard naming fragments (--YY, --MO, --DD, --TIM).

  • The capabilities of individual software systems (e.g., EDC) will determine which variable names are needed. CDASH uses separate data collection fields for dates and times. 

...

Imputation of Dates

The visit date variable (VISDAT) can be applied to all observations for a given visit (if appropriate), or specific date and timing fields may be included for a specific observation in the body of the CRF. When the visit date is used to reflect the timing of an observation, the appropriate timing variable for that tabulation dataset may be populated with the CDASH Visit Date. 

...

This is from best practices - questionnaires and prompts

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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").

Best practices - variable naming

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.

Relative Timing Variables (SEE SECTION 3.7)

Relative timing variables are sets of variables that provide information about how the timing of the record relates to either the study reference period or another fixed point in time. CDASH relative timing variables are collected for observations where a date either is not collected or is not available. The CDASH set of variables serve as an indicator (or flag) that the observation's "start" was prior to the study reference period or prior to another fixed point in time OR that the observation's "end" was after or ongoing as of the study reference period or another fixed point in time. The CDASH variables of --PRIOR and --ONGO serve this purpose. How these CDASH flags are translated to SDTM (according to controlled terminology) depends on whether the comparison is against the protocol-defined study reference period or against another fixed point in time serving as the "reference" for the timing of the record. To emphasize, collection of these CDASH relative timing variables is always dependent on the actual date either being prospectively not collected or not available. For more information, see Section 8.1.1, General CDASH Assumptions for Interventions Domains, and Section 8.2.1, General CDASH Assumptions for Events Domains.

For all SDTM submissions, there is a defined timeframe (the study reference period). According to SDTMIG, the start and end dates of the study reference period are submitted in the variables RFSTDTC and RFENDTC. The defined period may be protocol-specific or set by company policy, standard operating procedures, or other documented procedures. The study reference period might be defined as being from the date/time of informed consent through the date/time of subject's completion of the study, or it might be from the date/time of first dose to the date/time of last dose. Regardless of how the study reference period is defined, the dates (and optionally times) of the start and end of that period must be collected.

If there is a need to collect information about whether an observation of interest occurred prior to a reference point or milestone other than the beginning of the study reference period, or was ongoing or continuing at some reference point or milestone in the study other than the end of the defined study reference period, the date/time of that reference point or milestone should also be collected. If this date/time has been collected, reasonable comparisons can be made to that date/time with “prior”, “coincident”, “continuing”, or “ongoing” questions.

Study reference period figure