| Num | Convention |
|---|
| 1 | Numeric date, time, and datetime variables should be formatted, so as to be human-readable with no loss of precision. |
| 2 | Variables whose names end in DT are numeric dates. |
| 3 | Variables whose names end in DTM are numeric datetimes. |
| 4 | Variables whose names end in TM are numeric times. |
| 5 | If a *DTM and associated *TM variable exist, then the *TM value must match the time part of the *DTM value when the *DTM variable is populated. If a *DTM and associated *DT variable exist, then the *DT value must match the date part of the *DTM value when the *DTM variable is populated. |
| 6 | Names of timing start variables end with an S followed by the characters indicating the type of timing (i.e., SDT, STM, SDTM), unless otherwise specified elsewhere in the predefined ADaM variables sections. |
| 7 | Names of timing end variables end with an E followed by the characters indicating the type of timing (i.e., EDT, ETM, EDTM), unless otherwise specified elsewhere in the predefined ADaM variables sections. |
| 8 | Variables whose names end in DY are relative day variables. In the ADaM as in the SDTM, there is no day 0. If there is a need to create a relative day variable that includes day 0, then its name must not end in DY. |
| 9 | ADaM relative day variables need not be anchored by DM.RFSTDTC. The anchor (i.e., reference) date variable must be indicated in the variable-level metadata for the relative day variable. The anchor date variable should also be included in ADSL or the current ADaM dataset to facilitate traceability. Similarly, anchor time variables used to calculate values for ADaM relative time variables must be indicated in the variable-level metadata for the relative time variable, and must be included in ADSL or the current ADaM dataset. Note that it is possible to have different definitions for a relative day (or time) variable (e.g., ADY) in separate datasets, using different anchor dates (or times). For example, the derivation of ADY for product evaluation datasets might be different from that for safety datasets. |
| 10 | Section 2.9.3.5, Variable Naming Fragments, presents standard suffix naming conventions for producer-defined supportive variables containing numeric dates, times, datetimes, and relative days, as well as date and time imputation flags. These conventions are applicable to all ADaM datasets. The asterisk that appears in a variable name in the table must be replaced by a suitable character string, so that the actual variable name is meaningful and complies with the restrictions noted in Section 2.9.3.1, General Variable Conventions. |
| 11 | The reader is cautioned that the root or prefix (represented by *) of such producer-specified supportive ADaM date, time, and datetime variable names must be chosen with care, to prevent unintended conflicts among other such names and standard numeric versions of possible SDTM variable names. In particular, potentially problematic values for producer-defined roots/prefixes (*) include: - One-letter prefixes. For an example of the problem, if * is Q, then a date *DT would be QDT; however, a starting date *SDT would be QSDT, which would potentially be confusing if the producer intended QSDT to be something other than the numeric date version of the SDTM variable QSDTC.
- Two-letter prefixes, except when intentionally chosen to refer explicitly to a specific SDTM domain and its --DTC, --STDTC, and/or --ENDTC variables. For an example of an appropriate intentional use of a 2-letter prefix, if * is LB, then *DT is LBDT, the numeric date version of SDTM variable LBDTC. For an example of the problem, if * is QQ, then a date *DT would be QQDT, which would potentially be confusing if the producer intended QQDT to be something other than the numeric date version of a potential SDTM variable QQDTC.
- Three-letter prefixes ending in S or E. For an example of the problem, if * is QQS, then a date *DT would be QQSDT, which would potentially be confusing if the producer intended QQSDT to be something other than the numeric date version of a potential SDTM variable QQSTDTC.
|
| 12 | In general, all 3 of *DT, *TM, *DTM are not required. Include only the *DT, *TM, and *DTM variables needed for analysis or review. However, when a *DTM variable exists, it is good practice to include a corresponding *DT variable.
For more information regarding date and time variable conventions, refer to Section 2.9.3.2, Timing Variable Conventions. |