Identification of Records Used for Analysis

Records Used in a Timepoint Imputation Analysis

• This section considers the issue of how to identify records used in a timepoint-related imputation analysis as well as how to represent data imputed for missing timepoints in an ADaM dataset. LOCF (Last Observation Carried Forward) is one of the most commonly used timepoint-related imputation analyses and is therefore specifically mentioned. However, the methodology is general and is not restricted to LOCF analysis. WOCF (Worst Observation Carried Forward) analysis is also mentioned to emphasize the generalizability.
• When an analysis timepoint is missing, the ADaM methodology is to create a new record in the ADaM dataset to represent the missing timepoint and identify these imputed records by populating the derivation type variable DTYPE.
• For example, when an LOCF/WOCF analysis is being performed, create LOCF/WOCF records when the LOCF/WOCF analysis timepoints are missing, and identify these imputed records by populating the derivation type variable DTYPE with values LOCF or WOCF. All of the original records would have null values in DTYPE. It would be very simple to select the appropriate records for analysis by selecting DTYPE = null for Data as Observed (DAO) analysis, DTYPE = null or LOCF for LOCF analysis, and DTYPE = null or WOCF for WOCF analysis. This approach would require understanding and communicating that if the DTYPE flag were not referenced correctly, the analysis would default to using all records, including the DAO records, plus the records derived by LOCF and WOCF. To perform a correct DAO analysis, one would need to explicitly select DTYPE = null.

• Many statistical analyses require the identification of a baseline value. This section describes how a record used as a baseline is identified.
• The ADaM methodology is to create a baseline flag column to indicate the record used as baseline (the record whose value of AVAL is used to populate the BASE variable). This method does not require duplication of records in the event that the baseline record is not derived.
• Although a baseline record flag variable ABLFL is created and used to identify the record that is the baseline record, this does not prohibit also providing a record with a unique value of AVISIT (e.g., "Baseline"), designating the baseline record used for analysis, even if redundant with another record. For more complicated baseline definitions (functions of multiple records), a derived baseline record would have to be created as described in ADD LINK Section 4.2.1.3, Rule 3. This methodology requires that clear metadata be provided for the baseline record variable so that the value can be reproduced accurately.

• When analysis involves cross-timepoint derivations such as endpoint, minimum, maximum, and average post-baseline, questions such as "Should distinct records with unique value of AVISIT always be created even if redundant with an observed value record?" or "Should these records just be flagged?" need to be considered.
• The ADaM methodology is to create a new record with a unique value of AVISIT in cases where analysis is based on AVISIT. The advantage of this approach is that it is simple and analysis-friendly. It is recognized that such new records might be redundant with observed records for some kinds of conceptual timepoint definitions .Always creating a record with a unique value of AVISIT designating the record used for analysis (e.g., "Endpoint," "Post-Baseline Minimum," "Post-Baseline Maximum") has the advantage that once the AVISIT values are understood, producers, consumers, and software can rely on these values of AVISIT. This approach represents the general case because any such cross-timepoint derivation can be represented in a new record with a unique AVISIT description. The disadvantage is that the dataset would contain more records, and conventions would have to be communicated and understood.
• In cases where analysis is not based on AVISIT, either solution is valid. It is recognized that in cases where the AVISIT values are not defined in the analysis documentation, adding a flag may be more appropriate. Which methodology is appropriate for situations where an "analysis visit" value is not defined can be driven by how the analysis will be performed. In cases where only a subset of data is analyzed (e.g., only on treatment minimum values), then flagging the values that qualify for analysis might be a better choice than creating an additional record to contain the minimum value. However, where the subset of data is analyzed within the context of a greater pool of data, creating an additional record to contain the minimum value would help facilitate analysis-ready usage and review.