You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »





The following are general conventions for variable population:

NumTabulation Variable UseImplementation
1Text Data Casing
  • 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).
2"Yes", "No", Values
  • 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.
3

--REFID

  • Values for --REFID are sponsor-defined and can be any alphanumeric strings the sponsor chooses, consistent with their internal practices.
4--STAT
  • In general observation class domains, --STAT will be populated with "NOT DONE" when data are not collected for the topic of the observation.
5


6

7





DErived records


Assumptions in this section are appliable to Interventions, Events, and Findings class domains and will be used with domain-specific assumptions as appropriate.

General assumptions for the population of values in tabulation variables are provided in this section. Assumptions in this section will be followed and complement more detailed assumptions provided in Domain Specifications.



The following assumptions will be implemented for Findings class domains. 

NumField or VariableGuidance
1Result Variables (--ORRES, --ORRESU, --STRESC, --STRESU, --STRESN) 

The following is applicable to results that are not collected via QRS instruments. Please refer to QS domain assumptions  

  • --ORRES will be populated with the result of the measurement or finding as originally collected or received, using controlled terminology where applicable.  
    • When applicable the unit associated the value of --ORRES will be populated in --ORRESU, using controlled terminology where applicable. 
  • Values in will be populated in --STRESC when --ORRES is populated. --STRESC is populated by:
    • Deriving numeric values in --ORRES to numeric values in standard units in --STRESC.
    • Assigning the value of --ORRES as the value of STRESC
  • Values will be populated in ---STRESN when --STRESC is populated with a numeric value. If the value of STRESC is not a numeric value, then the value of STRESN will 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.




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



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

2Derived Records
3

4

5

6

7

8

9

  • No labels