Understanding USDM: The End of the TFL?

From Documents to Data

The Current State: Protocol as PDF

Today’s clinical trial lifecycle typically starts with a PDF protocol:

Study objectives described in prose
Endpoints buried in text
Visit schedules embedded in tables
Analysis populations described narratively

Statistical programmers and data standards teams then translate this human-readable document into SDTM domain structures, ADaM datasets, SAS programs for derivations, and manually designed TFL shells. This translation is manual, interpretive, and error-prone.

USDM Changes the Starting Point

USDM flips this model on its head. Instead of a PDF being the primary artifact, the protocol becomes structured data.

At a high level, USDM captures:

Study design (arms, epochs, visits)
Populations and eligibility
Estimands and endpoints
Schedule of Activities (SoA)
Interventions and assessments

The protocol is no longer read — it is queried.

Figure 1: Traditional vs USDM-Driven Workflow


Traditional ModelPDF Protocol
   ↓ (interpretation)
SAP
   ↓
Mock TFL Shells
   ↓
SAS Code
   ↓
TFL Outputs


USDM ModelUSDM (Structured Study Model)
   ↓
Automated Metadata Layer
   ↓
Auto-Generated ADaM + Analysis Definitions
   ↓
Dynamic TFL Outputs

The Automation Potential

Digitized Schedule of Activities

One of the most powerful components of USDM is the digitized Schedule of Activities (SoA). Instead of a static table in a protocol, visits, time points, and assessments are modeled explicitly.

This enables:

Automatic generation of visit structures in SDTM and ADaM
Consistent handling of unscheduled visits
Programmatic derivation of analysis windows
Reduced reconciliation between protocol, SDTM, and TFLs

Example: Visit Structure Automation

If USDM defines visit name, planned study day, window rules, and required assessments, then ADaM visit variables (AVISIT, AVISITN, ADY), analysis window flags, and visit-based summaries can all be systematically generated.

**Table 1: Manual vs USDM-Driven Processes**
Area	Traditional Approach	USDM-Driven Approach
Protocol	PDF document	Structured data model
Visit mapping	Hard-coded in SAS	Generated from SoA
Endpoint definitions	SAP text	Machine-readable estimands
TFL shells	Manually mocked	Metadata-driven
Traceability	Reviewer-dependent	End-to-end lineage

What Does This Mean for TFLs?

The Myth: “TFLs Will Disappear”

TFLs are not going away. Regulators still expect summary tables, patient-level listings, and interpretable figures. Human-readable outputs remain essential for decision-making.

The Reality: Mock Shells Are Dying

What is disappearing is the manual creation of static shells, copy-paste layouts, and one-off SAS programs. In a USDM-enabled world:

Table structure derives from estimands
Rows and columns derive from analysis metadata
Footnotes derive from methods and populations
Revisions propagate automatically