Table, Listing, and Figure (TLF) Development Basics

Introduction

Clinical trials generate large amounts of statistical information. The final clinical study report, regulatory submission, and internal study reviews must transform that information into outputs that investigators, statisticians, clinicians, regulators, and other reviewers can interpret efficiently.

The primary mechanism for presenting these results is the Table, Listing, and Figure, commonly abbreviated as TLF.

A TLF is more than a formatted statistical result. A well-designed output communicates the study population, treatment groups, analysis method, endpoint definition, time point, and resulting evidence in a standardized and reproducible form.

What Are Tables, Listings, and Figures?

The three major TLF categories serve different purposes.

Tables

Tables are generally used when the reader needs a concise summary of a population, endpoint, treatment comparison, or safety event.

Examples include:

• Demographic and baseline characteristics
• Disposition of subjects
• Primary efficacy results
• Secondary efficacy results
• Adverse event summaries
• Laboratory shift tables
• Vital-sign summaries
• Exposure summaries

Listings

Listings provide more granular information than tables. They commonly display individual subjects or individual records.

For example, a serious adverse-event listing might contain:

• Subject identifier
• Treatment group
• Adverse-event term
• Start and stop dates
• Severity
• Relationship to treatment
• Seriousness
• Outcome

Listings are particularly useful for reviewing individual patient profiles, important safety events, protocol deviations, deaths, and other events where aggregate summaries may not be sufficient.

Figures

Figures allow investigators and reviewers to recognize patterns that may be difficult to see in a numerical table.

Common examples include:

• Kaplan–Meier survival curves
• Mean profiles over time
• Boxplots
• Forest plots
• Waterfall plots
• Scatterplots
• Subject-level laboratory profiles

The TLF Development Lifecycle

TLFs are usually developed through a sequence of planning, programming, review, validation, and production steps.

TLF Shells

A TLF shell is a specification for what the final output is expected to contain before the actual study results are populated.

The shell serves as a bridge between the SAP and the statistical programming.

For example, an efficacy table shell might specify:

From the SAP to the TLF

The SAP defines the statistical methods. The TLF shell translates those methods into specific outputs.

Consider a SAP statement such as:

The corresponding TLF might need to display:

• Number of subjects analyzed
• Baseline value
• Week 24 value
• Change from baseline
• Treatment-group summaries
• Between-group comparison
• Confidence interval
• P-value

Thus, the TLF is not an independent statistical exercise. It is the operational implementation of the analysis defined in the SAP.

Analysis Populations

One of the most important decisions in TLF development is determining which subjects belong in each output.

Common analysis populations include:

The exact definitions are study-specific and should be taken from the protocol, SAP, or relevant population specifications.

Treatment Groups and Denominators

Treatment columns are another fundamental component of TLF development.

Suppose a study contains:

• Placebo
• Low-dose treatment
• High-dose treatment
• Total

The TLF must clearly identify which subjects contribute to each column.

For a proportion:

The denominator is therefore critical.

For example, if 8 of 50 subjects experience an event:

But if only 40 subjects have post-baseline assessments and the analysis specifies that the denominator is the number evaluable at that time point, the appropriate denominator may instead be 40.

Descriptive Statistics

Many clinical-trial TLFs summarize continuous variables using a standard set of descriptive statistics.

The mean is calculated as:

The sample standard deviation is:

A TLF specification should make clear which statistics are required and how they should be displayed.

Categorical Summaries

Categorical variables are commonly displayed as counts and percentages.

For example:

The displayed percentage is generally based on the appropriate denominator specified for the analysis.

Programmers must also consider whether subjects can contribute to more than one category. This is especially important for adverse-event tables.

Inferential Statistics in TLFs

Many TLFs contain both descriptive and inferential statistics.

For example, a treatment comparison might include:

• Adjusted treatment difference
• Standard error
• 95% confidence interval
• P-value

A confidence interval for a treatment difference can be represented generally as:

where \(\widehat{\Delta}\) is the estimated treatment difference, \(SE(\widehat{\Delta})\) is its standard error, and \(c\) is the appropriate critical value for the specified confidence level and analysis.

The precise method may instead involve a model such as ANCOVA, MMRM, logistic regression, Cox regression, or another prespecified method.

Visit Structure

Longitudinal clinical-trial outputs frequently organize results by visit.

The programmer must determine how visits are derived and which records represent the analysis value for each subject at each visit.

This becomes particularly important when there are:

• Unscheduled visits
• Repeated measurements
• Windowed visits
• Early termination visits
• Post-baseline assessments
• Multiple records on the same date

Missing Data

Missing data can substantially affect TLF results.

For example, suppose 100 subjects are randomized but only 82 have a Week 24 assessment.

A table may therefore show:

rather than:

The appropriate approach depends on the endpoint and analysis method.

Possible approaches include:

• Observed-case analysis
• Mixed-effects models
• Multiple imputation
• Nonresponder imputation
• Last observation carried forward
• Worst-case or tipping-point analyses

The TLF should communicate the analysis actually performed rather than implicitly suggesting that missing observations were analyzed as though they were observed.

Table Titles and Numbering

Clinical-trial outputs are normally assigned unique identifiers.

For example:

The numbering convention is study-specific. The important requirement is that every output can be uniquely identified, tracked, reviewed, and reproduced.

Footnotes and Abbreviations

Footnotes provide information that is necessary to correctly interpret an output.

A well-designed table may contain footnotes describing:

• The analysis population
• The statistical method
• Missing-data handling
• Multiplicity adjustments
• Rounding conventions
• Definitions of abbreviations
• Special counting rules
• Confidence-interval methodology

For example:

Footnotes should explain information that cannot be understood reliably from the table itself.

Programming a TLF

Once the shell has been approved, the programmer converts the specification into executable statistical programming.

A typical workflow is:

Example: Building a Simple Efficacy Table

Suppose a study compares placebo with Treatment A and evaluates change from baseline in a continuous endpoint at Week 24.

The shell might require:

The output communicates several distinct pieces of information:

• How many subjects contributed data
• Whether the treatment groups were comparable at baseline
• The observed Week 24 values
• The within-subject change
• The model-based treatment comparison
• The uncertainty around the treatment comparison
• The statistical evidence against the null hypothesis

Figures and Graphical TLFs

Figures require many of the same decisions as tables, but also require explicit choices about graphical encoding.

For example, a longitudinal mean-profile figure may contain:

• Time on the x-axis
• Change from baseline on the y-axis
• One line for each treatment group
• Error bars representing the specified uncertainty measure
• A legend identifying treatment groups
• A population and endpoint definition

A simple treatment profile might be represented conceptually as:

where \(t\) denotes the visit and \(n_t\) is the number of subjects contributing to the analysis at that visit.

Listings and Subject-Level Traceability

Listings are especially important when reviewers need to trace an aggregate result back to individual subjects.

For example, if a table summarizes serious adverse events, a corresponding listing might contain the individual records contributing to that summary.

This relationship between aggregate outputs and subject-level records is an important component of clinical-trial data traceability.

Traceability

A high-quality TLF should be traceable through the analysis pipeline.

Conceptually, the chain is:

The further a programmer moves away from the source data, the more important it becomes to understand the derivations that produced the displayed result.

Quality Control of TLFs

TLF QC should address both the statistical result and the presentation.

A QC process may include:

Independent Programming QC

For important clinical-trial outputs, an independent programmer may reproduce the results using a separate programming approach.

The objective is not necessarily to recreate every line of the production program. Instead, the QC programmer should independently verify the critical logic and resulting values.

For example, if a table reports: