TLFs in Clinical Trials: How Tables, Listings and Figures Map to Your SAP

A clinical trials TLF can look correct yet report the wrong population, denominator or treatment contrast. Tables, listings and figures (TLFs) are the outputs of the statistical analysis:

• Tables summarise demographics, efficacy results, laboratory values and treatment-emergent adverse events.
• Listings show participant- or record-level detail, such as each adverse event’s term, onset, severity and relationship to treatment.
• Figures present Kaplan–Meier curves, mean change over time and forest plots.

These outputs often share populations, endpoint definitions and derivations, so their relationship must stay traceable when they represent the same planned analysis.

The statistical analysis plan defines the planned analyses: endpoints, populations, methods, treatment comparisons and missing-data approaches. ADaM datasets supply the records and variables to implement them, TLF specifications define output-specific programming rules, and shells set out the intended presentation (Figure 1).

CDISC describes ADaM as supporting “traceability among analysis results, analysis data, and data represented in the Study Data Tabulation Model”, and its traceability examples show how a reviewer can follow a result back to source data [1, 2]. SAP-to-TLF traceability applies the same idea to each output.

Table 1 is a practical review framework we propose, not a regulatory standard. It turns the traceability chain into a repeatable review, and reviewers can step back to an earlier stage whenever a discrepancy points to the definition, dataset or program rather than the presentation.

Consider a hypothetical trial comparing Treatment A with Treatment B on change from baseline at Week 12, reporting an adjusted difference, 95% confidence interval and p-value. A traceability record should name the requirement and the evidence that it was met (Table 2), and link to the controlled files rather than just list their names.

Suppose the output reports an adjusted mean difference of −2.4 units (95% CI −4.1 to −0.7; p = 0.006). These values are illustrative. The reviewer should:

1. Confirm the model, population, treatment coding and contrast against the SAP.
2. Verify the records and derived variables supplied to the model.
3. Reproduce or independently verify the estimate and standard error.
4. Check the confidence interval, including degrees of freedom and critical value.
5. Check that the p-value matches the test statistic and is consistent with the interval.
6. Record the evidence and resolve discrepancies before release.

Here the interval is symmetric around −2.4 (half-width 1.7), implying a standard error of about 0.87 and z ≈ 2.8, which is consistent with p ≈ 0.006. A matching estimate alone is not enough if the wrong population or contrast was used.

The three documents have related but distinct responsibilities (Table 3). If the SAP specifies change from baseline but the shell labels the result as the observed Week 12 value, the programmer should not silently pick one. The responsible statistician resolves it through change control, and the affected specifications, programs and outputs are updated and rechecked.

SDTM standardises how clinical study data are tabulated; ADaM provides analysis-ready datasets and traceability back to SDTM [1, 3]. For a Week 12 endpoint, the analysis dataset may hold baseline and post-baseline records, change-from-baseline variables, treatment and population flags. Demographic tables, adverse event summaries and survival analyses usually draw on other datasets, so establish which dataset supports each output. Our SDTM vs ADaM guide works through a derivation. For regulatory submissions, follow the applicable study-data standards, such as the FDA Study Data Technical Conformance Guide [5]; these need not apply to every internal reporting package.

Reporting procedures automate layout, but no software can resolve an ambiguous endpoint or conflicting definitions. Clinical trial TLF QC should test statistical correctness, alignment with the specification and presentation (Table 4). ICH E6(R3) expects changes to source records to be traceable and quality control to be applied with a risk-based approach at each stage of data handling [4]. Independent programming, where required, gives a different check from reviewing the original code.

Worked example: wrong population. The SAP specifies the full analysis set, but the program selects records with a flag for another population. The table looks plausible. Applying the five stages: confirm the population in the SAP; inspect the population flags; find the wrong selection criterion; reconcile expected and actual counts; then regenerate and recheck every output that uses the same rule. These TLF programming errors are caught by reconciling counts, not by reading the table.

Reliable TLFs need more than correct formatting. A requirement-level traceability record, statistical checks and documented discrepancy resolution let reviewers connect every number to the approved analysis.