How to Populate Variables

• Variables subject to controlled terminology will be populated with the exact value for the controlled term, including term casing.
• Otherwise, text data will be represented in upper case (e.g., NEGATIVE).

• For variables where the response is "Yes" or "No", both "Y" and "N" will be   
• Variables where the response is "Yes" or "No" ("Y" or "N") should normally be populated for both "Y" and "N" responses. This eliminates confusion regarding whether a blank response indicates "N" or is a missing value. However, some variables are collected or derived in a manner that allows only 1 response, such as when a single checkbox indicates "Yes". In situations such as these, where it is unambiguous to populate only the response of interest, it is permissible to populate only 1 value ("Y" or "N") and leave the alternate value blank. An example of when it would be acceptable to use only a value of "Y" would be for Last Observation Before Exposure Flag (--LOBXFL) variables, where "N" is not necessary to indicate that a value is not the last observation before exposure.

--SEQ

• Values in --SEQ will uniquely identify a record for a given USUBJID or SPTOBID within a domain.
• Conventions for establishing and maintaining --SEQ values are applicant-defined. Values may or may not be sequential depending on data processes and sources.

--REFID

• Values for --REFID are sponsor-defined and can be any alphanumeric strings the sponsor chooses, consistent with their internal practices.

• --STAT will be populated with "NOT DONE" when a value 

The --ORRES variable contains the result of the measurement or finding as originally received or collected. --ORRES is an expected variable and should always be populated, except (1) when --STAT = "NOT DONE" (because there is no result for such a record) or (2) for derived records.

Note: Records with --DRVFL = "Y" may combine data collected at more than 1 visit. In such cases, sponsors must define the value for VISITNUM, addressing the correct temporal sequence. If a new record is derived for a dataset by the sponsor or their agent (e.g., a CRO), then that new record should be flagged as derived.
For example, in electrocardiogram (ECG) data, if a corrected QT interval value derived in-house by the sponsor were represented in an SDTM record, then EGDRVFL would be "Y". If a corrected QT interval value was received from a vendor or was produced by the ECG machine, the derived flag would be null.

When --ORRES is populated, --STRESC must also be populated, regardless of whether the data values are character or numeric. The variable --STRESC is populated either by the conversion of values in --ORRES to values with standard units, or by the assignment of the value of --ORRES, as in the Physical Examination (PE) domain, where --STRESC could contain a dictionary-derived term. A further step is necessary when --STRESC contains numeric values. These are converted to numeric type and written to --STRESN. Because --STRESC may contain a mixture of numeric and character values, --STRESN may contain null values, as shown in the following figure.

Figure. Original to Standardized Results

When the original measurement or finding is a selection from a defined codelist, in general, the --ORRES and --STRESC variables contain results in decoded format (i.e., the textual interpretation of whichever code was selected from the codelist). In some cases where the code values in the codelist are statistically meaningful standardized values or scores, which are defined by sponsors or by valid methodologies such as SF36 questionnaires, the --ORRES variables will contain the decoded format, whereas the --STRESC variables as well as the --STRESN variables will contain the standardized values or scores.

Occasionally data that are intended to be numeric are collected with characters attached that cause the character-to-numeric conversion to fail. For example, numeric cell counts in the source data may be specified with a greater than (>) or less than (<) sign attached (e.g., >10,000, <1). In these cases, the value with the greater than (>) or less than (<) sign attached should be moved to the --STRESC variable, and --STRESN should be null. The rules for modifying the value for analysis purposes should be defined in the analysis plan and a numeric value should only be imputed in the ADaM datasets. If the value in --STRESC has different units, the greater than (>) or less than (<) sign should be maintained. See Example 1, Rows 11 and 12

• Categories and subcategories are determined per protocol design and values are generally not entered via CRF.
• Implementers may:
  • Pre-populate and display category values to help individuals involved in data collection understand what data should be recorded on the CRF.
  • Pre-populate hidden variables with the values assigned within their operational database.
  • Populate values directly in the tabulation dataset during dataset creation.

• --PERF defines - variables to record whether an assessment has been performed/collected. --REASND is used to collect a reason why an assessment was not done.
• --PERF has the Question Text "[Were any/Was the] [--TEST/ topic] [measurement(s)/test(s) /examinations (s)/specimen(s) /sample(s) ] [performed/collected]?" are intended to assist in the cleaning of data and in confirming that there are no missing values.
• --PERF may be used at the page, panel, or question level.
• --PERF may be used during the creation of tabulaton datasets to derive a value into the SDTM variable --STAT. The implementer can use a combination of --CAT, --SCAT, with the --TESTCD= "--ALL" and --TEST= "<Name of the CRF module>" to represent what tests were not performed.
• Applicants must decide how to model each test not performed (e.g., to denote that all tests were not performed using TESTCD = "–ALL").
• --STAT has the Question Text "Was the [--TEST] not [completed/answered/done/assessed/evaluated]?; Indicate if (the [--TEST] was) not [answered/assessed/done/evaluated/performed]." This is intended to be used to collect a simple "NOT DONE" check box at the page, panel, or question level.
• --REASND is used with SDTM variable --STAT only. The value NOT DONE in --STAT indicates that the findings test was not performed. 

• --SPID may be populated by the applicant's data collection system. If collected, it can be beneficial to use an identifier in a data query to communicate clearly to the site the specific record in question.
• This field may be populated by the applicant's data collection system.

• Time will be collected if there is a scientific or regulatory reason to collect this level of detail and the time can be realistically determined. 
  • Metadata tables generally include --DAT and --TIM will be added from the CDASH Model as appropriate.     
• Collection variables for date and time (e.g., --DAT, --TIM) will be used to collect the date or date and time that the test was performed, or the specimen was collected. The start and end dates and times (e.g., for specimen collection) will be collected as appropriate.
• The date of collection of a test can be derived from the date of visit. In such cases, a separate date of observation field is not required to be present on the CRF.
• Date and time variables will not be used to collect dates that are the result of a tests. Test results will be collected using --ORRES.

• In metadata tables, many of the Findings class domains are presented in a normalized structure (1 record for each test) similar to a tabulation dataset, even though many data management systems hold the data in a denormalized structure (1 variable for each test).
• When implementing collection standards in a denormalized structure, create variable names for the Findings --TEST and/or --TESTCD values. To do this:
  • Define the denormalized variable names using available CDISC Controlled Terminology for --TESTCD; or
  • When a system allows more than 8-character variable names, the following naming convention can be used: <--TESTCD>_<-- tabulation variable name> where --TESTCD is the appropriate CT for the test code (e.g., DIABP_VSORRES, DIABP_VSLOC).
• In the horizontal (denormalized) setting, collection variables such as --PERF, --LOC , and --STAT can be collected once for the whole horizontal record and applied to all of the observations on that record, or collected per test using collection variables, such as <--TESTCD>_--PERF. When tabulation datasets are created, any variables collected for the entire horizontal record will be mapped to each vertical record per tabulation guidance.
• In the horizontal (denormalized) setting, an identifier (e.g., --GRPID) can be used to identify all --TESTCD for the same collection record. This supports mapping of data collected in a horizontal setting to tabulation datasets and creation of RELRECs.

• The value in --TEST will be 40 characters or less.
• The corresponding codelist value for the short test name, 8 characters or less, will be populated in the tabulation variable --TESTCD.
• Variable --TESTCD should be used to create a variable name and --TEST be used as the Prompt on the CRF.
• Both --TESTCD and --TEST are recommended for use in the operational database.
• Variable --ORRES is used to collect test results or findings in the original units per controlled terminology in character format. 
• If results are modified for coding, the --MODIFY variable contains the modified text.
• Variables --ORNRLO and --ORNRHI and --NRIND are used when normal or reference ranges are collected for results. 
• Standardization of the original results and/or normal/reference ranges will be performed during the creation of tabulation datasets. 

• Location variables are used to collect the location of the test.
• Applicants may collect location data using a subset list of controlled terminology on the CRF.
• Applicants may pre-populate hidden variables with values assigned within their operational database.
• There is currently some overlap across controlled terminology for LOC, LAT, and DIR. While the overlap exists, ensure that this overlap is not part of database design. 

• Variables --ORRES, --RES, --DESC, and --RESOTH are used to collect results. It is recommended that: 
  • --ORRES is used when the result is collected using a single question. The result will map directly to the tabulation variable --ORRES.
  • --RES and --DESC are used when a pair of questions are asked to collect the result; a question to collect the result with a follow-up question for a description of the result. For example, the question “Is the <condition> [absent/present]?" with a follow-up question “What is the finding that was observed?
  • --RES and --RESOTH are used when a question is asked that allows the selection of a pre-specified finding, with a follow-up question to ask about the pre-specified response "OTHER". For example, the question "What is the result?" with a set of prespecified responses, including the choice “OTHER” with the follow-up question “Specify, Other”.

• The Findings About Events and Intervention domains use the same root variables as the Findings domain, with the addition of the --OBJ variable.