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.

• It is important to identify the records used in or excluded from analysis. Should records used in the analysis be identified via flags or by unique values of analysis timepoint window description AVISIT?
• The ADaM methodology is to use an analysis flag (ANLzzFL) to indicate the records that fulfill specific requirements for 1 or more analyses. For example, ANLzzFL = Y indicates records meeting the requirements for analysis and is blank (null) in other records, such as a duplicate record that was not the one selected for analysis, or pre-specified post-study timepoints not included in the analysis. This allows multiple records within a parameter with the same value of AVISIT. However, it also requires flags to be added to the dataset to be used in selecting appropriate records for analysis. Understanding of the flags is required for correct analysis results to be generated. In addition to ANLzzFL, additional flags might also be required, such as record-based population flags (e.g., ITTRFL, PPROTRFL).
• Note that there can be multiple ANLzzFL variables. In this case, it will be imperative to have clear and robust metadata to indicate the basis for the creation and population of each ANLzzFL variable.

• It is not uncommon in the statistical analysis of clinical trials to conduct analyses based on multiple populations of interest. The population of interest can be defined either at the subject level, the record (measurement) level, or both. For example, when defining an analysis population, a subject may be included in one analysis population (e.g., intent-to-treat), but excluded from another analysis population (e.g., per-protocol). Analysis populations may also be defined using characteristics of individual measurements. For example, a measurement that was assessed outside of a pre-specified time window for a particular visit may not be included in a per-protocol visit-level population. In this section, it is assumed that the definition of a record-level analysis population is dependent on the definition of the subject-level population. In other words, if a subject is excluded from the subject-level per-protocol population, then none of that subject's records would be candidates for inclusion within the record-level per-protocol population. Given the variety of possible population definitions, the same record in an analysis dataset could be included in one analysis and excluded from another, depending on characteristics of the subject as a whole and the characteristics of the individual measurement. Therefore, the issue becomes how best to select records for each analysis.
• The ADaM methodology for this analysis issue is to create a single ADaM dataset that can be used to perform multiple analyses using population flag variables to identify records that are used for each type of analysis. An advantage of this approach is that this single ADaM dataset can be used for multiple analyses. Flag variables obviate the need to replicate records for each type of analysis. This approach promotes efficiency in the operational aspects of electronic submissions, clarity of analyses, and ease in comparing selected values for each population. This approach does, however, require that clear metadata be provided for the flag variables so that each specific analysis can be reproduced accurately. Below are several examples of the use of population flag variables to identify records used for different analyses.