A regulatory submission package is not judged only by whether the datasets validate. Reviewers also need to understand what was submitted, how the datasets were built, which standards were used, what decisions were made, and how to navigate important study-specific issues.

That is where Define-XML, the ADRG, and the SDRG become critical.

These documents and metadata files are sometimes treated as final deliverables that are assembled after the datasets are nearly complete. That approach creates risk. Submission documentation should be developed alongside SDTM, ADaM, analysis outputs, and validation review. Otherwise, sponsors may discover late that key decisions are not documented, metadata are inconsistent, or reviewer explanations are incomplete.

Define-XML: the metadata backbone

Define-XML provides structured metadata for submitted datasets. It describes datasets, variables, controlled terminology, origins, derivations, value-level metadata, comments, and relationships needed to interpret the data package.
For SDTM and ADaM datasets, Define-XML helps reviewers understand what each dataset contains and how each variable should be interpreted. It also supports machine-readable review workflows.
A strong Define-XML file should be accurate, complete, and consistent with the datasets and reviewer guides. It should not simply list metadata. It should explain the package in a way that supports review.

Important Define-XML considerations include:

• Accurate dataset and variable labels.
• Clear variable origins.
• Complete controlled terminology references.
• Meaningful derivation descriptions for analysis variables.
• Value-level metadata where needed.
• Comments that clarify complex or study-specific decisions.
• Consistency between metadata, datasets, programs, and reviewer guides.

When Define-XML is weak, reviewers may struggle to understand otherwise valid data.

SDRG: explaining the tabulation package

The Study Data Reviewer’s Guide, or SDRG, helps explain the SDTM package. It provides context around submitted tabulation datasets, standards used, validation findings, domain-level decisions, and study-specific implementation details.
The SDRG is especially important when the SDTM implementation includes complexity that may not be obvious from datasets alone. Examples include non-standard domains, supplemental qualifiers, relationship records, external data decisions, known validation messages, protocol deviations, or study-specific mapping assumptions.
The SDRG should help reviewers distinguish between true data issues and expected implementation decisions.

A useful SDRG may address:

• Standards and controlled terminology versions.
• Dataset inventory.
• Study design considerations.
• Important mapping assumptions.
• Known conformance findings and explanations.
• External data handling.
• Trial design domains.
• Supplemental qualifiers and relationship records.
• Data issues that may affect interpretation.

The SDRG should be concise but specific. Generic language rarely helps reviewers.

ADRG: explaining the analysis package

The Analysis Data Reviewer’s Guide, or ADRG, explains the ADaM package and analysis-related decisions. It helps reviewers understand analysis datasets, key derivations, population flags, endpoint logic, sensitivity analyses, and any issues that affect interpretation of analysis data.
The ADRG is not a replacement for the SAP or Define-XML. It serves a different purpose: it helps reviewers navigate the analysis data package efficiently.
A strong ADRG may include:

• Analysis dataset inventory.
• ADaM standards and controlled terminology versions.
• Key analysis populations.
• Important derivations.
• Endpoint-specific considerations.
• Traceability from ADaM to SDTM.
• Known validation findings and explanations.
• Explanation of non-standard analysis structures.
• Notes on integrated summaries, if applicable.

When the ADRG is well written, it reduces ambiguity and supports efficient review of analysis results.

Why documentation should begin early?

Submission documentation should not be left until the end. The best reviewer documentation reflects decisions made throughout the study and programming lifecycle.
For example, if an SDTM mapping decision is made because source data do not align neatly with a standard domain, the rationale should be captured when the decision is made. If an ADaM derivation is complex because of an estimand, censoring rule, or intercurrent event strategy, that explanation should be developed with the statistician and not reconstructed months later.
Early documentation helps prevent inconsistencies between specifications, datasets, metadata, programs, and reviewer guides.

Common documentation issues

Sponsors often encounter documentation issues such as:

• Define-XML metadata that do not match submitted datasets.
• Derivations described differently in the SAP, ADaM specifications, and Define-XML.
• Validation findings listed without meaningful explanation.
• SDRG content that does not explain study-specific SDTM decisions.
• ADRG content that does not explain key analysis assumptions.
• Incomplete value-level metadata.
• Missing controlled terminology version information.
• Unclear origins for derived or assigned variables.

Reviewer guides written too generically to be useful.These issues can make a package harder to review even when the underlying programming is strong.

The role of cross-functional review

Define-XML, ADRG, and SDRG development requires input from several functions.
Statistical programmers understand the datasets, metadata, validation findings, and technical implementation. Biostatisticians understand endpoint logic, analysis populations, sensitivity analyses, and statistical methods. Data managers understand source data, coding, reconciliation, and data quality issues. Regulatory teams understand submission expectations and eCTD requirements.
When these functions review documentation together, the final package is more coherent.

Documentation and validation findings

Validation findings require careful handling. Some findings indicate issues that should be corrected. Others may reflect acceptable study-specific decisions that require explanation. The reviewer guides should make this distinction clear.
A weak response is to list validation messages without context. A stronger response explains why the finding occurred, whether it affects interpretation, what action was taken, and where relevant, why the submitted approach is appropriate.
This is where experience matters. Automated validation is essential, but it does not replace expert review.

How Bioforum Supports Submission Readiness

Bioforum supports submission package documentation across Define-XML, ADRG, SDRG, SDTM, ADaM, TFLs, ISS and ISE integrations, and independent quality review. Our statistical programming teams work closely with data management and biostatistics to ensure that metadata and reviewer documentation reflect the actual data strategy and analysis logic.
This is particularly important for complex studies, legacy conversions, integrated summaries, rescue submissions, and programs with multiple vendors or non-standard data flows.

Strong Documentation Strengthens Every Submission

Define-XML, ADRG, and SDRG are not administrative attachments to a submission package. They are part of the review experience.
Define-XML provides the structured metadata. The SDRG explains the tabulation data package. The ADRG explains the analysis data package. Together, they help reviewers understand the submitted data, trace key decisions, and navigate complexity.
For sponsors, strong documentation can reduce ambiguity, support regulatory confidence, and make submission review more efficient.

Need Support with Submission Documentation?

Preparing Define-XML, ADRG, SDRG, or a full submission data package? Bioforum’s statistical programming experts support standards-compliant datasets, reviewer documentation, validation review, and independent quality control.