Clinical systems / Study data
One fictional study, defined once in USDM, taken through collected data, SDTM, conformance checks, ADaM, Define-XML and the tables and figures of a study report. Select any number to see the records it came from and the protocol activity that scheduled them. To run a study of your own, design it in CRF Studio and press Run Pipeline.
Synthetic data for demonstration. Not from any real study. DEMO-301 and its sponsor are fictional, and every subject is generated from a seed.
Run / 01
The engine runs in your browser, in a Web Worker, so nothing is sent to a server. The same seed and subject count always give the same datasets, tables and figures.
Running the pipeline…
The datasets archive holds every SDTM and ADaM dataset as Dataset-JSON, CSV and XPT, a define.xml per layer, a README and a manifest of SHA-256 hashes. The outputs archive holds the tables as HTML and RTF, the figure as SVG and HTML, and the ARS reporting event as JSON.
Stages / 02
One study definition flows through seven stages. Counts are for the current run.
33
scheduled activities
7 visits · 8 activities · 3 arms
Best practice shown hereThe protocol is defined once, as data. Its visits, windows and schedule of activities drive every later stage.
—
waiting for the run
Best practice shown hereSeeded, keyed draws: the same seed and subject count give the same records, and adding subjects leaves existing ones unchanged.
—
waiting for the run
Best practice shown hereTabulation keeps collected values apart from derivations, and each record keeps the ids of its source records outside its submission columns.
—
waiting for the run
Best practice shown hereEach finding names the published rule it models and cites its source. A demonstration subset, not a validator of record.
—
waiting for the run
Best practice shown hereAnalysis rows point back to SDTM through SRCDOM, SRCVAR and SRCSEQ, and analysis values never flow back into SDTM.
—
waiting for the run
Best practice shown hereGenerated from the same variable metadata as the datasets, so the metadata and the data cannot drift apart.
—
waiting for the run
Best practice shown hereEvery displayed number is an analysis result that names the ADaM rows it was computed from.
Outputs / 03
Lineage / 04
Select a table cell, a dataset value, a finding or a scheduled activity. The explorer walks back to the protocol activity that scheduled the source and forward to every number it feeds. Direct records hold the traced value; supporting records contribute to it, such as the first-dose date a study day counts from.
Standards / 05
| Standard | Version |
|---|---|
| USDMUnified Study Definitions Model | 4.0.0 |
| SDTMStudy Data Tabulation Model | 2.0 |
| SDTMIGSDTM Implementation Guide | 3.4 |
| ADaMAnalysis Data Model | 2.1 |
| ADaMIGADaM Implementation Guide | 1.3 |
| OCCDSADaM Occurrence Data Structure | 1.0 |
| ADaM-CRADaM Conformance Rules | 5.0 |
| Define-XMLDataset metadata | 2.1 |
| Dataset-JSONDataset exchange format | 1.1 |
| ARSAnalysis Results Standard | 1.0 |
| NCI-EVS-CTNCI EVS controlled terminology, package date | 2026-09-25 |
| RulesThe pipeline's own conformance rule set | 1.7.0 |
Versions are pinned. Changing one is a controlled upgrade with an impact report across datasets, metadata and outputs, and every run declares them in its trial summary, its Define-XML and its manifest.
The controlled terminology is a hand-curated subset of the NCI EVS CDISC package of the date shown. Every codelist and term it uses is checked against that release in the test suite.
The conformance stage models a subset of published SDTM and ADaM rules, each cited by id. It is a demonstration, not a validator of record; the complete published rules run in CDISC CORE.
No implementation guide text is copied: variables, codelist terms and rules are encoded in the pipeline's own words and cited by id. The design is recorded in ADR 0065.
Synthetic data for demonstration. Not from any real study.