What this tool does

SDTM Mapper turns a raw clinical dataset into a submission-style SDTM deliverable in five steps. You select or upload raw data; it profiles the columns and identifies the most likely CDISC domain; it drafts a full variable-by-variable mapping specification; it writes the matching SAS, R, and Python programs from that single specification; and it runs the code to produce the actual SDTM dataset, exported as CSV and SAS Transport (XPT).

The problem it solves

Writing SDTM mapping specifications by hand and then programming each domain is slow, repetitive, and inconsistent across programmers and studies. A first-draft spec plus paired SAS, R, and Python programs and a runnable dataset normally takes hours to days per domain. This tool produces that first draft in minutes, so the programmer spends time reviewing and refining rather than starting from a blank page.

Why it is different

• One spec, three languages. The SAS, R (pharmaverse conventions), and Python programs are generated from the same mapping specification, so they stay aligned — useful for independent double programming and validation.
• Grounded in the standard. Classification and mapping are anchored to SDTMIG v3.4 domain metadata (variables, roles, core status, controlled terminology), not free-form guessing.
• It scores itself. Every run shows a classification confidence and a Required/Expected coverage percentage, so reviewers see how much of the domain was mapped.
• It produces a real dataset. The pipeline runs the code and returns an actual SDTM dataset plus an XPT transport file — not just a specification document.

Packages & standards used

The tool is built on established clinical-programming open standards and libraries:

How a mapping row is built

Each target SDTM variable gets a method, the source it draws from, plain-English derivation logic, and any controlled-terminology note.

Accuracy & honest limitations

• The classifier reports a confidence score; the specification reports Required/Expected coverage as the share of must-have variables that were mapped.
• Only variable names and labels present in your source can be mapped. Where no source exists, the row is marked Not Submitted.
• The AI suggestion can be overridden — choose a different target domain and re-run, then refine the spec.
• Currently supported domains: loading…

Toward regulatory acceptance

AI-generated output is not automatically submission-ready. Regulatory acceptance is a process property, not a model property. This build already includes the foundations, with the remaining items on a clear roadmap.

Already in place

• Deterministic generation — every model call runs at temperature 0, so the same input yields the same output (reproducibility).
• Audit trail — each run records a UTC timestamp, the input file SHA-256 hash, the target domain, the model and version, the temperature, the coverage score, and the number of self-repairs. Append-only.
• Self-repair loop — generated code that fails at runtime is automatically regenerated from its own error, so the dataset is built reliably rather than crashing.
• Standard-grounded — mapping anchors to SDTMIG v3.4 domain metadata, and a paired SAS + R + Python set supports independent double programming.
• Human in the loop — the AI classification can be overridden and the spec reviewed before any code runs.

On the roadmap

• CDISC conformance validation — a Pinnacle 21-style rules check on the produced dataset, with a pass/fail conformance report.
• define.xml 2.1 — machine-readable dataset + variable metadata generated from the spec.
• Controlled Terminology versioning — pin and display the CDISC CT package version used.
• cSDRG — an auto-drafted Study Data Reviewer's Guide.
• 21 CFR Part 11 / CSV — access control, electronic signatures on sign-off, and IQ/OQ/PQ computer-system-validation documentation.
• Traceability matrix — explicit source-to-target lineage export.