ADaM IN PRACTICE · A TECHNICAL SERIES FOR CLINICAL TRIAL STATISTICAL PROGRAMMERS

Abstract

When an FDA reviewer picks a number from a submitted table and asks where it came from, the package must answer without the study team in the room. Many packages cannot. Define.xml methods that say "derived per SAP", derivation chains that hop through undocumented intermediate steps, and reviewer guides that merely restate metadata all break the path from analysis value back to collected data. This article treats traceability as an engineered property with two layers. Metadata traceability lives in define.xml method text that encodes the actual decision rules. Data-point traceability lives in the datasets themselves: parameters derived visibly from parameters, SRCDOM, SRCVAR, and SRCSEQ keys on derived records, honest DTYPE values, and intermediate datasets that shorten the path when chains grow long. The ADRG then ties the layers into a narrative with a dependency diagram, worked derivation walkthroughs, and record counts that reconcile against the CSR. The takeaway: traceability is not a compliance attribute of the datasets; it is the product, and it should be audited by walking real values backward before submission.

1. Introduction

The ADaM model puts traceability first among its fundamental principles, and the FDA Study Data Technical Conformance Guide restates it from the reviewer's side: the review team must be able to reproduce an analysis and understand how each derived value was constructed. In practice the standard is concrete and unforgiving. A reviewer selects a value from a display and asks for the records it came from and the rule that produced it. Every such question that cannot be answered from the submitted package alone costs review time, and on the studies that matter it costs trust. Yet the most common failures are not exotic: vacuous method text, multi-hop parameter derivations with no visible chain, missing source keys, and reviewer guides that never tell the story of how the datasets fit together.

This article works through the traceability toolkit in the order a reviewer encounters it. Section 2 defines what a reviewer means by traceability and distinguishes the two mechanisms ADaM provides, metadata traceability and data-point traceability. Section 3 shows what define.xml method text looks like when it actually encodes the derivation. Section 4 covers parameter derivation chains, including parameters derived from parameters, the SRC triplet, and honest use of DTYPE. Section 5 makes the case for submitting intermediate datasets when the chain grows too long for method text. Section 6 turns to the ADRG narrative that reviewers actually read. Section 7 extends the patterns to changing data: cutoffs, re-locks, and controlled terminology uplifts. Section 8 describes a pre-submission audit that tests the package the way a reviewer will, and Section 9 concludes.

2. What a reviewer means by traceability

Traceability is the property the ADaM model v2.1 puts first among its fundamental principles: the ability to understand the relationship between an analysis value and its predecessors, all the way back to collected data. The FDA Study Data Technical Conformance Guide restates it from the reviewer’s side: analysis datasets should allow the reviewer to reproduce the analysis and understand how derived values were constructed. In practice the review team asks a very concrete question: for this number in Table 14.2.1, show me the records it came from and the rule that produced it. Every traceability decision you make should be evaluated against how quickly that question can be answered.

ADaM distinguishes two mechanisms. Metadata traceability describes the relationship in documentation: define.xml derivation methods, origins, and comments explain how a variable or parameter is computed. Data-point traceability puts the relationship in the data itself: variables on each record identify the specific predecessor rows that produced it. Metadata traceability is always required. Data-point traceability is required, per ADaMIG v1.3, whenever it is practical and feasible, and reviewers have made clear through information requests that for complex derivations, feasibility is assumed.

Table 1. The two traceability layers. They are complements, not alternatives.

3. Metadata traceability that says something

The most common traceability defect in submitted define.xml files is not absence but vacuity. A method that reads “Derived as per SAP Section 9.4” is metadata-shaped, not metadata. The FDA’s technical rejection criteria will not catch it; the review clock will. Compare the two versions below for ADTTE.CNSR in a Phase III oncology study:

<!-- Vacuous -->

<def:MethodDef OID="MT.ADTTE.CNSR" Name="CNSR derivation" Type="Computation">

<Description><TranslatedText xml:lang="en">

Censoring flag derived per SAP.

</TranslatedText></Description>

</def:MethodDef>

<!-- Reviewable -->

<def:MethodDef OID="MT.ADTTE.CNSR.PFS" Name="CNSR for PARAMCD=PFS" Type="Computation">

<Description><TranslatedText xml:lang="en">

CNSR=0 if documented PD per RECIST 1.1 (ADRS.PARAMCD='OVRLRESP',

AVALC='PD') or death from any origin (ADSL.DTHDT) on/before data cutoff.

CNSR=1 if censored at last adequate tumor assessment (ADRS records with

ANL01FL='Y'); CNSR=2 if no post-baseline assessment (censored at

randomization); CNSR=3 if new anticancer therapy preceded event.

EVNTDESC/CNSDTDSC record the applied rule per record.

</TranslatedText></Description>

</def:MethodDef>

The second version costs ten minutes and encodes the full decision table. Note that it is written against analysis datasets (ADRS, ADSL), not raw SDTM, which brings us to derivation chains.

4. Parameter derivation chains: derived from derived

Modern endpoints are rarely one hop from collected data. A typical oncology chain: RS (collected overall responses) → ADRS (responses with analysis flags, missed-assessment handling) → ADTTE (PFS with event/censor logic) → the KM table. Each hop is individually simple; the composition is where reviewers get lost, and where information requests are born.

Three patterns keep chains reviewable. First, derive parameters from parameters, visibly. When PARAMCD=TUMSUM (sum of target lesion diameters) feeds PARAMCD=PCHGNAD (percent change from nadir), keep both in the same BDS dataset and reference the input parameter by name in the method for the output parameter. A reviewer can then follow the chain inside one dataset. Second, when a derivation consumes many records to produce one, carry the source keys. SRCDOM, SRCVAR, and SRCSEQ on the derived record point to the specific predecessor (e.g., SRCDOM='ADRS', SRCVAR='ADT', SRCSEQ=14 identifying which assessment supplied the censoring date). Third, use `DTYPE` honestly. Imputed, LOCF, or averaged records must be distinguishable from observed ones. A DTYPE populated only where a checker forces it is a traceability failure that conformance tools cannot see.

Table 2. Data-point traceability patterns by derivation shape.

5. Intermediate datasets: submit the middle of the chain

When the distance between SDTM and the analysis dataset becomes too large for method text (response assessment algorithms, PK-derived exposure metrics, adjudication reconciliation), the correct tool is an intermediate analysis dataset, submitted alongside the rest. ADaMIG v1.3 explicitly supports intermediate datasets as a traceability device, and the Technical Conformance Guide accommodates them; the practical requirements are that they be described in define.xml, listed in the ADRG with their role, and flagged as not directly supporting displays (so the reviewer knows why no output references them).

In a recent Phase III trial with a blinded independent central review (BICR), the sponsor submitted ADRESP (an intermediate dataset reconciling investigator and BICR response calls, one record per subject per assessment per reader) between RS and ADTTE. The event/censor logic in ADTTE then referenced ADRESP records by SRCSEQ. During review, the agency’s question about a discrepant progression date was answered by pointing to two rows in ADRESP; without it, the answer would have required re-executing the reconciliation algorithm from raw data. That is the difference between a same-day response and a two-week fire drill.

Resist two temptations. Do not submit every scratch dataset your pipeline produces. An intermediate dataset earns its place only when it materially shortens the path from result to source. And do not let intermediates become a dumping ground that hides logic; each one needs the same metadata discipline as any analysis dataset.

6. The ADRG narrative: the map reviewers actually read

Define.xml is consulted; the Analysis Data Reviewer’s Guide is read. Section 5 (Analysis Data Creation and Processing Issues) is where the chain becomes a story: which datasets exist, in what order they are built, and where the analytically dangerous derivations live. The strongest ADRGs we have audited share three habits:

• A data dependency diagram, one figure showing SDTM domains, intermediate datasets, and analysis datasets with arrows. Reviewers reference it constantly; PHUSE ADRG templates include it for a reason.
• Derivation walkthroughs for the top three risk areas only. Primary endpoint, key censoring logic, and any imputation, written as worked logic (“a subject with no post-baseline assessment is censored at randomization; 14 such subjects exist”), including record counts that let the reviewer verify they are looking at the same data.
• Explicit cross-references from each walkthrough to the define.xml methods and, where applicable, the intermediate dataset that carries the detail. The ADRG should never duplicate the define. It should route through it.

Counts are the underrated ingredient. “ADTTE contains 612 records for PARAMCD=PFS; 287 events (CNSR=0), 325 censored, of which 41 by rule C3 (new therapy)” gives the reviewer an immediate reconciliation target against the CSR tables. When the numbers tie out on day one, everything downstream is read with more trust.

7. Traceability under change: cutoffs, re-locks, and CT uplifts

The patterns above assume a static snapshot; real programs are not static. Interim analyses, safety updates, and 120-day safety submissions mean the same derivation chain executes against multiple data cutoffs, and traceability must now answer a second-order question: which version of the data produced this number. Three practices keep versioned chains reviewable. First, the data cutoff is data, not configuration: carry the cutoff date in ADSL (or document it prominently in the ADRG) and ensure every dataset in the chain was generated against the same snapshot. The record-count tripwires described below will catch a partially refreshed chain faster than any human. Second, when a re-lock changes upstream records, regenerate the entire chain rather than patching downstream datasets; a hand-corrected ADTTE that no longer derives mechanically from its ADRS is a traceability lie that will surface the first time the agency re-executes your logic. Third, dictionary and CT uplifts (MedDRA versions between an interim and final lock, quarterly ADaM CT updates) must be pinned per deliverable and stated in the ADRG. A CNSDTDSC vocabulary that silently shifted between the interim and final CSR package is exactly the kind of discrepancy that turns a routine question into a records request.

Multi-study contexts raise the stakes again. In an ISS/ISE, pooled datasets add a second derivation layer on top of study-level ADaM, and the FDA's expectation, reiterated in Technical Conformance Guide updates, is that pooled analysis datasets trace to the study-level datasets, not directly to re-pooled raw data. The SRC triplet generalizes naturally: SRCDOM can name a study-level analysis dataset, and a pooled ADRG documents the mapping decisions (re-coded treatment arms, re-derived baselines, harmonized visit windows) with the same decision-table discipline used within a study.

8. A pre-submission traceability audit

Traceability erodes silently: a dropped --SEQ here, a merge that loses the source date there. Before database lock hardens into submission, run a deliberate audit: pick five subjects and three results per key display (primary endpoint, key secondary, one safety table) and walk each value backward through ADaM to SDTM using only submitted artifacts: datasets, define.xml, ADRG. No study programs, no tribal knowledge. Anything you needed that was not in the package is a gap. CDISC CORE and the ADaM conformance rules (v5.0) will verify the mechanical layer (SRCVAR values that name real variables, DTYPE terminology, define/dataset consistency), but no rules engine can judge whether your method text is reviewable. Only the walk-back does that.

Traceability is not a compliance attribute; it is the product. The datasets exist so that a skeptical third party can connect a published number to a collected observation without you in the room. Build every dataset as if the reviewer will attempt exactly that, because on the studies that matter, they will.

9. Conclusion

The thread running through every section is a single test: can a skeptical third party connect a published number to a collected observation using only what was submitted? Metadata traceability passes that test when define.xml methods encode the real decision rules against the real input datasets. Data-point traceability passes it when derived records carry their source keys, when parameters build visibly on parameters, and when intermediate datasets are submitted wherever the chain is too long for method text. The ADRG binds the package together with a data dependency diagram, worked walkthroughs of the risky derivations, and record counts that tie out against the CSR on day one.

The practical program is short. Write method text that a reviewer can execute mentally. Carry SRCDOM, SRCVAR, and SRCSEQ where many records collapse into one. Pin cutoffs, dictionary versions, and controlled terminology per deliverable, and regenerate the whole chain after any re-lock. Then, before submission, walk real values backward from display to SDTM using only the package itself. Traceability that survives review is never an accident; it is designed in, one derivation at a time.

References

CDISC Analysis Data Model (ADaM) v2.1, Section 3 (Traceability), and ADaM Implementation Guide v1.3, CDISC, November 2021.

CDISC Define-XML v2.1 Specification, CDISC, 2019.

FDA Study Data Technical Conformance Guide (current edition), fda.gov/industry/study-data-standards-resources.

PHUSE Deliverables: Analysis Data Reviewer’s Guide (ADRG) Template and Completion Guidelines, phuse.global.

CDISC ADaM Conformance Rules v5.0; CDISC Open Rules Engine (CORE), github.com/cdisc-org/cdisc-rules-engine.

PharmaSUG proceedings, Data Standards and Submission Standards tracks (lexjansen.com), numerous papers on ADaM traceability and intermediate datasets, 2018–2025.