cSDRG and ADRG: The Clinical Submission Reviewer’s Guides Explained

What each reviewer’s guide documents, how the cSDRG and ADRG differ, why both are PHUSE templates the FDA recommends — and how the ADRG’s dataset-overview table is generated from your analysis package, not transcribed by hand

A submission’s XPT datasets and Define-XML metadata still need the human document that tells a reviewer how to read the package: the reviewer’s guide. This lesson explains the two of them — the cSDRG (clinical Study Data Reviewer’s Guide) for the SDTM tabulations and the ADRG (Analysis Data Reviewer’s Guide) for the ADaM analysis datasets. It walks the sections of each as reference tables, draws the cSDRG-vs-ADRG distinction, is precise that both are PHUSE community templates (not FDA-authored forms) that the FDA recommends, and shows a runnable example that generates the ADRG’s Analysis Dataset Overview straight from the analysis package on real pharmaverse ADaM data — so the table is computed, not transcribed.

TipKey takeaways

• A reviewer’s guide is the human narrative that ships beside the machine metadata. The Define-XML is metadata a validation tool reads; the reviewer’s guide is the plain-language document that tells a reviewer how to read the package and why the sponsor made the choices they did.
• There are two of them, one per standard. The cSDRG (clinical Study Data Reviewer’s Guide) travels with the SDTM tabulation package (csdrg.pdf); the ADRG (Analysis Data Reviewer’s Guide) travels with the ADaM analysis package (adrg.pdf).
• Each has a fixed section skeleton. The cSDRG has four core sections (introduction, protocol, subject data, conformance); the ADRG has seven — its unique additions are cross-dataset Analysis Considerations, the Analysis Data Creation narrative that traces ADaM back to SDTM, and the Submission of Programs inventory.
• Both are PHUSE templates, not FDA forms. They are community deliverables from PHUSE (the Pharmaceutical Users Software Exchange), and the FDA recommends — does not mandate a specific form for — a reviewer’s guide in its conformance guidance. Be exact about that boundary.
• The ADRG’s dataset overview is generated, not typed. Section 5’s table of datasets, labels, and record counts comes straight from the analysis package — this lesson computes it from real ADaM data.

Introduction

You have exported the XPT (SAS Transport version 5) datasets and written a Define-XML for each standard. A reviewer can now open the metadata and see every variable, codelist, and derivation. But the metadata does not answer the questions a reviewer actually asks first: why is this domain split in two? why does this validation rule still fire, and is it a problem? how was the primary endpoint derived, and which program made it? Those answers live in a human document that ships beside the datasets — the reviewer’s guide.

There are two, and knowing which is which is the whole point of this lesson. The cSDRG — the clinical Study Data Reviewer’s Guide — accompanies the SDTM (Study Data Tabulation Model) tabulation package. The ADRG — the Analysis Data Reviewer’s Guide — accompanies the ADaM (Analysis Data Model) analysis package. Both are PHUSE (Pharmaceutical Users Software Exchange) community templates, both are human-readable PDFs, and both do for the reviewer’s understanding what the Define-XML does for the reviewer’s tools.

This lesson walks the sections of each guide, draws the distinction between them, places them in the FDA’s expectation, and closes on a runnable example: the ADRG’s Analysis Dataset Overview table, generated straight from a real analysis package rather than transcribed by hand.

What a reviewer’s guide is (and why the metadata is not enough)

The Define-XML is exhaustive but silent. It records that a variable exists, its type, its codelist, its derivation id — but it does not explain. It cannot tell a reviewer that two adverse-event domains were split for a legacy-conversion reason, that an outstanding validator warning is a known false positive, or that the primary efficacy dataset uses a windowing convention worth reading before the tables. A reviewer’s guide is where the sponsor says those things in plain language.

So every submission pairs each standard’s machine metadata with a human narrative:

• the SDTM tabulation package gets the cSDRG (csdrg.pdf) beside its define.xml;
• the ADaM analysis package gets the ADRG (adrg.pdf) beside its define.xml.

The Define-XML is read by a tool; the reviewer’s guide is read by a person. The two are complementary, and a well-assembled package always ships both.

The cSDRG: the SDTM reviewer’s guide

The cSDRG orients the reviewer to the collected, tabulated data. It describes the study at a high level, names the standards and versions used, records the sponsor’s data decisions, and — its most distinctive job — explains the SDTM conformance findings: which validator issues remain outstanding and why each is acceptable. Its structure follows the PHUSE template’s four core sections plus appendices:

#	Section	What it contains
1	Introduction	Purpose of the guide; the study-data standards and versions used — SDTMIG (SDTM Implementation Guide), controlled terminology, Define-XML
2	Protocol Description	Protocol number and title; the protocol design in brief
3	Subject Data Description	The SDTM domains submitted, dataset-level notes, and the sponsor’s data decisions
4	Data Conformance Summary	The conformance inputs (validator and rule-set versions); the outstanding findings with an explanation for each
—	Appendices	Conformance-issue detail; a legacy-data-conversion (LDCP) appendix when a legacy conversion applies

Section 4 is the reason the cSDRG matters. A tabulation package almost never validates perfectly clean, and a reviewer needs to know which residual warnings the sponsor has judged acceptable and why. The cSDRG is where that judgement is stated and defended.

The ADRG: the ADaM reviewer’s guide

The ADRG does the same job for the analysis datasets, and it carries more because analysis data is derived. Beyond describing the datasets and their conformance, it explains cross-dataset analysis conventions, narrates how the ADaM was built from the SDTM, carries the analysis-results metadata (the traceability from a result back to the dataset and, through it, to SDTM), and inventories the programs submitted. Its canonical structure is seven sections plus optional appendices:

#	Section	What it contains
1	Introduction	Purpose; acronyms; the ADaM, SDTM, and Define-XML versions; the source data
2	Protocol Description	Protocol number, title, and versions; protocol schema; the study populations
3	Analysis Considerations Related to Multiple Analysis Datasets	Cross-dataset conventions — planned-vs-actual treatment variables, visit windowing, imputation rules
4	Analysis Data Creation and Processing Issues	How the ADaM was built; split-dataset reassembly; intermediate datasets; variable conventions — the SDTM→ADaM narrative
5	Analysis Dataset Overview	A table of every ADaM dataset: name, label, class/structure, key variables (← generated below)
6	Data Conformance Summary	Validator inputs and versions; outstanding issues with explanations; conformance status
7	Submission of Programs	The program inventory — ADaM programs, TLF (tables, listings, and figures) programs, and macro/utility programs
—	Appendices	Optional study-specific detail

Three of these have no cSDRG equivalent, and they are what a reviewer opens the ADRG for: Section 3 (the analysis conventions that span datasets), Section 4 (the ADaM-from-SDTM creation narrative that makes the derivations traceable in prose), and Section 7 (the map of which submitted program produces which output). The analysis-results metadata — the chain from a reported result to the analysis dataset and the SDTM source behind it — is the ADRG’s traceability contribution, the narrative companion to the value-level metadata the Define-XML holds.

cSDRG vs ADRG: which is which

Same idea, different standard. The table pins the distinction:

	cSDRG	ADRG
Ships with	The SDTM tabulation package (csdrg.pdf)	The ADaM analysis package (adrg.pdf)
Documents	Collected, tabulated data — domains, sponsor decisions, SDTM conformance	Derived analysis data — derivations, conventions, traceability, program inventory
Unique to it	SDTM conformance explanations; the subject-data description	Cross-dataset Analysis Considerations (Sec 3); the SDTM→ADaM creation narrative (Sec 4); Submission of Programs (Sec 7)
Partner metadata	SDTM define.xml	ADaM define.xml

The mnemonic that keeps them straight: the define.xml is machine-readable metadata that lives with the dataset; the reviewer’s guide is the human narrative that lives with the reviewer. The cSDRG explains the tabulations; the ADRG explains the analysis. Confusing the two — handing a reviewer an ADRG that describes SDTM domains, or a cSDRG that discusses analysis derivations — is a real, and common, packaging mistake.

Both are PHUSE templates, not FDA forms

Get this boundary exactly right, because it is easy to overstate. Neither guide is a CDISC standard, and neither is an FDA-authored form. Both are community deliverables published by PHUSE (the Pharmaceutical Users Software Exchange), each shipped as a package — a fillable template, completion guidelines, worked examples, and (for the cSDRG) traceability and legacy-conversion appendix guidance:

• the cSDRG package (the completion guidelines describe the four-section template above; the single-study cSDRG has an integrated variant, the icSDRG, for pooled data);
• the ADRG package (the template PHUSE describes as “optional but highly recommended”).

The section skeletons in this lesson are those templates. The primary references for the sections are the PHUSE conference papers behind them — CD13 (PhUSE 2015) for the ADRG and PP09 (CSS-US 2014) for the cSDRG. Because these are living community templates, the exact wording and version evolve; treat the tables above as the stable skeleton, and the linked packages as the authoritative source of the current form.

What the FDA expects

The FDA does not publish a reviewer’s-guide form; it states an expectation. The Study Data Technical Conformance Guide (STDCG) — the FDA’s technical specifications for submitted study data — recommends a Study Data Reviewer’s Guide as an integral part of a standards-compliant submission, and a later revision added a subsection for the analysis-data (ADRG) case; a sponsor’s Study Data Standardization Plan typically references preparing both. The community reference DS02 (PHUSE US 2020) summarizes the same expectation from the industry side.

So the precise statement is: the reviewer’s guides are PHUSE community templates that the FDA recommends (not agency forms it mandates), and in practice they are a standard, expected part of every study-data submission. Ship them.

Note

The FDA STDCG landing page is the authoritative pointer; the guide itself is a versioned PDF linked from it. The PP09 and DS02 papers restate the STDCG’s reviewer’s-guide expectation and are the easiest primary reading for the section-level detail.

Generate the ADRG’s dataset overview from the analysis package

The ADRG’s Section 5, Analysis Dataset Overview, is a table of every ADaM dataset with its label and its size. It is the one part of the guide you should never type by hand: transcribing dataset labels and record counts into a PDF invites a mismatch between the guide and the data it describes. Generate it from the analysis package instead, so the numbers are the data’s numbers.

The block below reads each real ADaM dataset from pharmaverseadam (a public pharmaverse example package), pulls its dataset label from the label attribute, and counts its records, variables, and unique subjects (USUBJID). It is self-contained base R — read it top to bottom: for each dataset name, load it, then assemble one summary row; do.call(rbind, ...) stacks the rows into the overview table.

library(pharmaverseadam)

# The ADaM datasets this analysis package ships
datasets <- c("adsl", "adae", "advs", "adlb", "adtte_onco")

overview <- do.call(rbind, lapply(datasets, function(nm) {
  data(list = nm, package = "pharmaverseadam")   # load the dataset by name
  x <- get(nm)
  data.frame(
    Dataset   = toupper(nm),
    Label     = attr(x, "label"),                # the dataset label the ADRG reports
    Records   = nrow(x),
    Variables = ncol(x),
    Subjects  = length(unique(x$USUBJID)),       # distinct subjects contributing
    stringsAsFactors = FALSE
  )
}))

print(overview, row.names = FALSE)

    Dataset                               Label Records Variables Subjects
       ADSL              Subject Level Analysis     306        55      306
       ADAE             Adverse Events Analysis    1191       107      225
       ADVS                Vital Signs Analysis   65032       105      254
       ADLB                 Laboratory Analysis   83652       115      254
 ADTTE_ONCO Time to Event Analysis for Oncology     512        20      254

Read the result as the reviewer would. ADSL (the Subject-Level Analysis Dataset) has one record per subject — 306 records, 306 subjects — the one-row-per-subject structure a reviewer expects. ADAE (adverse events) has 1,191 records across 225 subjects: many events per subject, and fewer subjects than ADSL because not everyone had an event. ADVS (vital signs) and ADLB (laboratory) are large, repeated-measures datasets — tens of thousands of records — while ADTTE_ONCO (time-to-event for oncology) is one analysis record per subject per endpoint. That shape — records far exceeding subjects for findings data, records equal to subjects for subject-level data — is exactly what Section 5 exists to communicate, and it is now computed from the package, not transcribed.

Section 6’s Data Conformance Summary is generated the same way: rather than hand-listing conformance issues, you check each dataset against its Define-XML spec — metacore reads the define.xml into a spec object and metatools::check_variables() compares each dataset’s columns to it — and the guide reports the resulting findings with explanations. (The companion Define-XML lesson walks that read-and-check loop in full.) The principle is the same across the ADRG’s data-driven sections: the guide describes the package, so let the package produce the description.

🟢 With an AI agent

Ask Prova “I need to write the ADRG’s Analysis Dataset Overview — read each of my ADaM datasets and build a table of dataset, label, records, variables, and subject count.” — it answers grounded in this pillar’s lessons, with runnable pharmaverse code you can try on example data. The runtime is the judge. Ask Prova →

Common issues

Confusing the cSDRG for the ADRG (or vice versa). They are not interchangeable. The cSDRG describes the SDTM tabulation data — domains, sponsor decisions, SDTM conformance findings — and ships in tabulations/sdtm/. The ADRG describes the ADaM analysis data — derivations, cross-dataset conventions, the SDTM→ADaM creation narrative, and the program inventory — and ships in analysis/adam/. If a guide is discussing analysis derivations, it is an ADRG; if it is explaining SDTM domains and validator findings, it is a cSDRG.

Thinking the guides are FDA-authored standards. They are PHUSE community templates, not CDISC standards and not FDA forms. The FDA recommends a reviewer’s guide in its conformance guidance; it does not publish or mandate a specific form. Cite the PHUSE package as the source of the template and the STDCG as the source of the expectation — do not describe either guide as an FDA or CDISC standard.

Forgetting the ADRG’s Submission of Programs section. Section 7 is easy to overlook and is one of the ADRG’s distinctive jobs: it inventories the submitted programs — ADaM programs, TLF programs, and macro/utility programs — so a reviewer can map each output back to the code that produced it. An ADRG that describes the datasets but omits the program inventory is incomplete.

Frequently asked questions

NoteWhat is an ADRG?

The ADRG (Analysis Data Reviewer’s Guide) is a human-readable PDF that accompanies the ADaM analysis datasets in a submission. It gives a reviewer the context the datasets and Define-XML alone cannot: how the ADaM was derived from SDTM, the analysis conventions that span datasets, the analysis-results metadata that traces a result back to its data, a data-conformance summary, and an inventory of the submitted programs. It follows a PHUSE template and has seven canonical sections plus optional appendices.

NoteWhat is a cSDRG?

The cSDRG (clinical Study Data Reviewer’s Guide) is the reviewer’s guide for the SDTM tabulation package. It describes the study, the standards and versions used, the SDTM domains submitted and the sponsor’s data decisions, and — its most important job — explains the outstanding SDTM conformance findings so a reviewer knows which validator issues remain and why each is acceptable. It follows a PHUSE template with four core sections plus appendices.

NoteWhat is the difference between the cSDRG and the ADRG?

They cover different standards. The cSDRG documents the SDTM tabulation data (collected domains, sponsor decisions, SDTM conformance) and ships in tabulations/sdtm/; the ADRG documents the ADaM analysis data (derivations, cross-dataset conventions, traceability, and the program inventory) and ships in analysis/adam/. Unique to the ADRG are its cross-dataset Analysis Considerations, its SDTM→ADaM creation narrative, and its Submission of Programs inventory. Each guide pairs with its own standard’s define.xml: the cSDRG explains the tabulations, the ADRG explains the analysis.

NoteWhat is analysis-results metadata?

Analysis-results metadata is the documented chain from a reported analysis result back to the analysis dataset that produced it and, through that dataset, to the SDTM source data. It is the traceability layer that lets a reviewer follow a number in a table to the ADaM records and derivations behind it without reading code. In a submission it is carried by the ADRG’s narrative (the Analysis Data Creation section and the analysis descriptions) alongside the value-level metadata in the ADaM Define-XML.

NoteIs a reviewer’s guide required by the FDA?

Not as a mandated form. The cSDRG and ADRG are PHUSE community templates, and the FDA recommends a reviewer’s guide as an integral part of a standards-compliant study-data submission in its Study Data Technical Conformance Guide. In practice a reviewer’s guide is a standard, expected part of every study-data submission — so you ship one for each standard (a cSDRG for SDTM, an ADRG for ADaM) — but it is an FDA recommendation filled with a PHUSE template, not an FDA-authored form.

Test your understanding

ImportantYour turn: build the ADRG dataset-overview row for ADSL

Using pharmaverseadam, read the adsl dataset and build a single-row data frame with the columns the ADRG’s Analysis Dataset Overview reports: Dataset, Label, Records, Variables, and Subjects. Which attribute holds the dataset label, and how do you count distinct subjects?

TipHint

Load one dataset with data("adsl", package = "pharmaverseadam"). The dataset label is stored in the object’s "label" attribute — reach it with attr(adsl, "label"). Records are nrow(), variables are ncol(), and distinct subjects are length(unique(adsl$USUBJID)).

TipSolution

library(pharmaverseadam)

data("adsl", package = "pharmaverseadam")

adsl_row <- data.frame(
  Dataset   = "ADSL",
  Label     = attr(adsl, "label"),          # "Subject Level Analysis"
  Records   = nrow(adsl),                    # 306
  Variables = ncol(adsl),                    # 55
  Subjects  = length(unique(adsl$USUBJID)),  # 306
  stringsAsFactors = FALSE
)
print(adsl_row, row.names = FALSE)

attr(adsl, "label") returns the dataset label the ADRG reports, and length(unique(adsl$USUBJID)) counts the distinct subjects. For ADSL, records equal subjects (306 = 306) because it is one row per subject — the subject-level structure. Wrapping this row-builder in a loop over every ADaM dataset (as the lesson does) produces the whole Section 5 table, computed from the package rather than transcribed.

NoteQuick check: which statement about the reviewer’s guides is correct?

A. The cSDRG and ADRG are FDA-authored forms that a sponsor must fill in exactly as published. B. The cSDRG describes the SDTM tabulation package and the ADRG describes the ADaM analysis package; both are PHUSE templates the FDA recommends. C. A submission ships one combined reviewer’s guide covering both SDTM and ADaM.

TipShow answer

B. The cSDRG is the reviewer’s guide for the SDTM tabulation package and the ADRG is the guide for the ADaM analysis package; both are PHUSE community templates, and the FDA recommends a reviewer’s guide (it does not publish a mandated form). A overstates the FDA’s role — the guides are PHUSE deliverables, not FDA forms. C is wrong: each standard gets its own guide (cSDRG with the SDTM package, ADRG with the ADaM package), just as each standard gets its own define.xml.

Conclusion

A submission’s datasets and Define-XML tell a reviewer’s tools what is there; the reviewer’s guides tell the reviewer how to read it. There are two, one per standard: the cSDRG accompanies the SDTM tabulation package and explains the collected data and its conformance findings, while the ADRG accompanies the ADaM analysis package and adds what analysis data needs — cross-dataset conventions, the SDTM→ADaM creation narrative, the analysis-results metadata, and the program inventory. Both are PHUSE community templates that the FDA recommends — not FDA-authored forms — so state that boundary precisely. And treat the ADRG’s data-driven sections the way this lesson treated Section 5: generate the dataset overview from the analysis package so the guide reports the data’s own numbers, never a hand-typed copy.

Note

This lesson is reproducible: every result on this page was produced by the code shown — copy any block and run it to reproduce them. The runtime is the judge.

References

• PHUSE cSDRG Package — the clinical Study Data Reviewer’s Guide template, completion guidelines, and examples.
• PHUSE ADRG Package — the Analysis Data Reviewer’s Guide template and completion guidelines.
• PHUSE — the Pharmaceutical Users Software Exchange, the community that publishes both reviewer’s-guide templates.
• Hughes, Analysis Data Reviewer’s Guide (Paper CD13), PhUSE 2015 — the primary reference for the ADRG’s seven sections.
• Study Data Reviewer’s Guide (Paper PP09), PhUSE CSS-US 2014 — the reference for the cSDRG sections and the FDA STDCG §2.2 reviewer’s-guide expectation.
• Solanki & Low, What You Need to Know About Submitting Data to the FDA (Paper DS02), PHUSE US Connect 2020 — a community summary of the study-data package and the reviewer’s-guide expectation.
• FDA Study Data Technical Conformance Guide — the FDA’s technical specifications for submitted study data, which recommend a Study Data Reviewer’s Guide.
• pharmaverseadam — the public pharmaverse ADaM example datasets used to generate the Analysis Dataset Overview.

Related lessons

• eCTD submission anatomy — the Module-5 map that places the cSDRG and ADRG beside their datasets. · Define-XML with metacore and metatools — the machine-readable metadata each reviewer’s guide partners, and the metatools::check_variables() loop the ADRG’s conformance summary reports. · Export an XPT file in R with xportr — writing the .xpt datasets the guides describe. · SDTM conformance checks in R — validating the tabulation data whose findings the cSDRG explains. · Create ADSL in R with admiral — deriving the analysis dataset the ADRG documents.
• Where this fits: export the datasets to XPT → write the Define-XML metadata → write the cSDRG and ADRG reviewer’s guides (you are here) → bundle the R programs with pkglite and reproduce an R Consortium FDA pilot end to end. · Submission packaging — the full series. · Pharma & Clinical — the pillar.

Was this page helpful?

Prove you can do it. Master the whole Clinical Programming in R (pharmaverse) series — track your path, build projects, and earn a certificate.

Start free →

Go Pro — unlimited Prova on your own data and a verifiable certificate that proves the skill.

from $15/mo billed yearly

Go Pro →

✓ You're Pro — keep going. The runtime is the judge.

Get new R & Python lessons by email

Practical, reproducible, no spam. Unsubscribe anytime.

Double opt-in. We never share your email.

Share this pageXLinkedInRedditHN