Creation of Derived Columns Versus Creation of Derived Rows

The three conditions of Rule 1 for when a function of AVAL and BASE should be added as a column (i.e., a function column) are:

1. The function is of AVAL and, optionally, BASE, on the same row; and
2. The function is parameter-invariant; and
3. The function does not involve a transform of BASE.

The remainder of the discussion of this rule is devoted to explaining these conditions.

PARAM uniquely describes the contents of AVAL or AVALC. Often, AVAL itself is not the value that is needed for analysis. For example, in a change from baseline analysis, it is the change from baseline CHG that is analyzed. The change from baseline column CHG should be created according to Rule 1 because it satisfies the three conditions:

1. CHG is derived from AVAL and BASE on the same row.
2. The same calculation applies on all rows in the dataset on which CHG is populated (the function CHG=AVAL-BASE does not vary according to PARAM). This second condition is known as the property of parameter-invariance; unless listed in ADD LINK Section 3, Standard ADaM Variables, a function of AVAL (and optionally BASE) may not be derived as a column if it is parameter-variant (i.e., is calculated differently for different parameters).
3. In the function CHG=AVAL-BASE, BASE is not transformed.

The intent is to use the standard columns as much as possible, to keep the structure as standard as possible, and avoid undue "horizontalization," while still permitting efficient use of function columns.

• If the intention is to redefine AVAL, BASE, CHG, etc. in terms of a transform of AVAL, then a new parameter must be added in which PARAM describes the transform. The creation of a new parameter results, by definition, in the creation of a new set of rows.
• For example, as described in the discussion of Rule 1, in a change from baseline analysis of the logarithm of weight, AVAL should contain the log of weight, BASE should contain the baseline value of the log of weight, and CHG should contain the difference between the two. PARAM should contain a description of the transformed data contained in AVAL, e.g., "Log10 (Weight (kg))". In this way the ADaM standard accommodates an analysis of transformed data in the standard columns without creating a multiplicity of new special-purpose columns.
• A related application of Rule 2 is in the case where it is necessary to support analysis and reporting in two different systems of units. In SDTM Findings domains such as LB, QS, EG, and so on, the --STRESN column is the only numeric result column, and is also the only standardized numeric result column. The --ORRES column contains a character representation of the collected result, in the collected units specified in the --ORRESU column. The --ORRES column is not standardized. So for example, if data are typically collected in conventional units, SDTM cannot accommodate standardized data in both conventional units and the International System of Units (SI). In SDTM, for any given --TEST, a producer can standardize in one system of units but not two. If one wishes to be able to analyze standardized results in both conventional units and in SI units, a transform in an ADaM dataset is needed. In each such case, a new parameter must be created in order to accommodate standardized data in the other system of units.
• The description in the PARAM column must contain the units, as well as any other information such as location and specimen type that is needed to ensure that PARAM uniquely describes what is in AVAL, and differentiates between parameters as needed. PARAM cannot be the same for different units.
• When a record is derived from a single record in the dataset, retain on the derived record any variable values from the original record that do not change and that make sense in the context of the new record (e.g., --SEQ, VISIT, VISITNUM, --TPT, covariates, etc.).

• For analysis purposes, there is often a need to impute missing data, or to create a derived conceptual timepoint. Such derivations should result in the creation of new derived records within the same parameter.
• As a general rule, when a record is derived from a single record in the dataset, retain on the derived record any variable values from the original record that do not change and that make sense in the context of the new record (e.g., --SEQ, VISIT, VISITNUM, --TPT, covariates). When a record is derived from multiple records, retain on the derived record all variable values that are constant across the original records, that do not change, and which make sense in the context of the new record. Note that there are situations when retention of values from an original record or records would make no sense on the derived record; in such cases, do not retain those values.
• For example, suppose that the analysis endpoint value is defined as the average of the last two available post-baseline values. In this case, a new row should be added, with a corresponding description in AVISIT, and the DTYPE (derivation type) column should contain a description on that row such as "AVERAGE" to indicate both that the row was derived, and also the derivation method. The metadata associated with AVISIT=Endpoint should adequately describe which records are used in the definition of the average. Note that even though the set of records for the log transformation of weight are derived, DTYPE is not populated for every row. DTYPE should be used to indicate rows that are derived within a given value of PARAM and is not to be used as an indication of whether the record exists in SDTM.
• An extension of Rule 3 is necessary in the case where there is record-level population flagging. For example, assume the SAP states that if the subject is off drug for 7 days prior to a visit, the measurement collected at that visit is not included in the per-protocol analysis. Then, for some subjects, the last two available values may be different for Intent-to-Treat and for Per-Protocol analyses, so that the calculated endpoint averages would be different. For such subjects, two distinct derived endpoint rows would be needed, the appropriate row for each analysis indicated by the record-level population flags ITTRFL and PPROTRFL.

• There is often a need to derive for analysis a parameter that was not collected. Such parameters may be quite complex functions of data from multiple SDTM domains and domain classes. Rule 5 addresses the case where a parameter is derived from other parameters already present in the dataset.
• For example, a questionnaire total domain score is calculated as a function of more than one observed question. The total domain score should be added as a new parameter, with its corresponding set of derived rows. For this derived parameter, the value of PARAM could be "Total Domain Score", and the value of the total domain score would be stored in the standard AVAL column, the baseline value would be stored in the standard BASE column, change from baseline would be stored in CHG, as usual.