SDTM Engine

What it does

Building the CDISC SDTM datasets from a raw EDC export is the clinical deliverable most sponsors outsource. This engine does it from one declarative YAML spec per domain. The spec drives both the data build and the rendered mapping spec, so the data and its documentation cannot drift, and conformance is judged against bundled SDTMIG + CDISC controlled terminology rather than a vendor package. Distinct from the CDISC Submission Pipeline: this is the spec-driven mapping engine, traceable to the raw field, not double-programming reconciliation.

How it works

• Spec-driven build: a small op vocabulary (const, copy, ct for controlled terminology, dtc for ISO-8601 dates, derive for identifiers and ages, seq for --SEQ) plus reshaping builders for the hard cases. The demo runs a minimal interpreter of that vocabulary live in the browser over a synthetic raw EDC, including a wide-to-long builder that turns one wide vitals form per visit into one SDTM record per measurement.
• Click-traceability: on the Build & trace tab, click any SDTM cell and it lights up the YAML spec op that produced it and the raw EDC field it came from, with the derivation printed. That is the engine's core principle made visible: every value traces to a real collected source.
• Never fabricate: a required variable with no collected source is emitted as an honest pending blank, and a not-collected reading produces no row, rather than an invented value. A partial (year-only) birth date yields a blank age, not an estimate.
• Standards-judged conformance: SDTMIG + CDISC CT checks run live on the built data (CT codelists, date formats, uniqueness, required-variable presence), with an opt-in path to external CDISC CORE for an independent validation pedigree.
• Source-trace report: every variable tagged auto (matched / derived / constant), review (verify the pattern), or todo (no source). Roughly 90% auto on this synthetic build.
• Automated vs manual: the science-vs-scaffolding scorecard. The engine column is computed from the build; it nails the analysis-critical science (identifiers, dates, controlled terminology, reshaping, no fabrication) where a manual build commonly slips, and is explicit about the mechanical gaps that remain (supportive variables, dictionary coding, breadth).

Why SDTM and ADaM are not the same problem

SDTM is standardization. Raw data mapped into a published structure with fixed domains, variables, and controlled terminology. There is a correct answer the standard defines, which is why this layer can be built to a button: given the data and the spec, the output is deterministic, reproducible, and conformance-checkable.

ADaM is analysis. There is no published "correct" ADaM, because ADaM is constructed to serve a specific statistical analysis plan. What counts as baseline, how treatment-emergence is defined, which population, which windows, how missing visits are handled, these are judgment calls that come from the protocol and the SAP and differ for every study. That layer cannot be a button, and anyone who tells you it can has not built one.

So the two layers are built differently, and the showcase keeps them as separate demos. SDTM is push-button: this engine aims for clean, traceable, conformance-checkable output. ADaM is the job of the Statistical Programming Pipeline demo, which does the mechanical work but surfaces the judgment calls and traces every derivation, so a statistician makes and owns the decisions instead of a black box making them silently. The goal is not to remove the statistician. It is to make the work faster and the decisions auditable.

A from-scratch demo built from a spec-driven SDTM engine. Synthetic seeded study and raw EDC; every value is computed in the browser with an in-page self-test that reconciles the build, file://-safe with no network calls. Takes ?tab= (overview, build, conformance, trace, compare) and ?still=1. No real subjects, no sponsor data.