ONC-2024-001 — Interactive Oncology CDISC Package

What is this, and what problem does it solve?

This is a complete, end-to-end clinical-trial statistical-programming deliverable for an oncology study — the entire chain from raw collected data to the datasets and outputs a regulator reviews. It exists to demonstrate one thing clearly: the ability to independently own a full submission package, not just write isolated programs.

In a real trial, dozens of programmers and a CRO produce this over months. Here it's authored as one coherent package — every SDTM domain, every ADaM derivation, every table and figure, the define.xml, and the reviewer guides — so you can inspect the whole workflow and even run the analyses yourself.

The study

The CDISC pipeline — what each stage is

1 · Raw data

CRF-like data as it comes off the EDC and IxRS systems — unstandardized, study-specific. The starting point.

2 · SDTM (Study Data Tabulation Model) — 7 domains

The FDA-required standardized format for collected data. Each domain is one type of data:

• DM — Demographics (one row per subject)
• AE — Adverse Events
• EX — Exposure (drug administration)
• DS — Disposition (how each subject left the study)
• TU / TR / RS — the oncology trio: Tumor Identification, Tumor Results (measurements), and Response (RECIST assessments). These are what make this an oncology package specifically.

3 · ADaM (Analysis Data Model) — 4 datasets

Analysis-ready data, derived from SDTM with the statistical logic baked in:

• ADSL — Subject-Level: one row per subject with population flags (SAFFL, ITTFL) and grouping variables. Every other analysis joins back to this.
• ADAE — Analysis AEs, with treatment-emergent flags and severity.
• ADTTE — Time-to-Event: the OS and PFS times plus censoring flags — the hard derivation, with rules for when an event is "censored" vs counted.
• ADRS — Response: best-overall-response logic per RECIST 1.1 (the algorithm that turns a sequence of tumor assessments into one CR/PR/SD/PD result).

4 · TLFs (Tables, Listings, Figures) — 7 outputs

The actual analysis outputs: the ORR table, AE summary, two Kaplan-Meier survival curves, a waterfall plot, a swimmer plot, and a subject listing.

5 · Submission package

define.xml 2.1 (machine-readable metadata describing every dataset and variable) plus the ADRG and SDRG reviewer guides — the documents an FDA reviewer opens first.

What the interactive tab is computing

ORR (Objective Response Rate)

The proportion of subjects whose best response was CR or PR, with an exact binomial (Clopper-Pearson) confidence interval — the standard for a single-arm response rate. Change which categories count as responders or which population is analyzed; the CI is recomputed in R each time.

Median survival (Kaplan-Meier)

The Kaplan-Meier estimator handles censoring — subjects still alive (or progression-free) at last contact contribute partial information. The median is the time at which the survival curve crosses 50%. Computed live with R's survival package, the same engine used in regulatory submissions.

ADSL derivation

Shows the foundational SDTM→ADaM step: SAFFL is set to "Y" for any subject with exposure records in EX; AGEGR1 buckets age at <65 / ≥65. Real joins across DM, EX, and DS — the kind of derivation logic that, if wrong, invalidates every downstream number.

Why dual SAS + R?

ICH E6(R3) and FDA practice expect independent double-programming for key outputs — two programmers implement the same spec separately and the results must match. Here R is the executed reference/validator and SAS is the submission deliverable. Producing both from one analysis spec proves command of the language the industry runs on (SAS) and the open-source stack it's moving toward (R/pharmaverse).

Compliance & data

100% synthetic data generated with seeded randomization — no real patients, no proprietary study content, no real drug. Standards followed: SDTMIG, ADaMIG 1.3, define.xml 2.1, RECIST 1.1, ICH E6(R3). GDPR/HIPAA-safe by design.