TECHNICAL WHITE PAPER

A governed, standards-driven workbench for reproducible clinical test data and auditable AI-generated SDTM transformation programs

ABSTRACT

A reproducible path from study intent to test-ready evidence

Synthetic Data Generator Pro is a Clinical Hub workbench for producing clinical test data and standards-oriented transformation evidence without using real patient records. It combines an eCRF specification and a Unified Study Definitions Model (USDM) study design in a revisioned Study Blueprint; uses that blueprint to generate schedule-aware raw datasets deterministically; and then supports an AI-authored Raw-to-SDTM programming path in SAS, R, or both. The distinguishing design choice is not the presence of generative AI alone. It is the separation of bounded AI assistance from deterministic parsing, generation, validation, and packaging—with explicit human confirmation gates and durable provenance.

The workbench addresses a practical gap in clinical systems engineering: teams need representative data to test metadata pipelines, transformations, validations, interfaces, and handoffs, but access to suitable clinical data is constrained and manual preparation is expensive. The 2026 CDISC AI Innovation Challenge frames the same problem and calls for synthetic SDTM and/or ADaM generation with traceable linkage to source inputs and metadata.[1] Synthetic Data Generator Pro implements that traceability as a first-class artifact.

Executive summary

Clinical test-data generation is often split across disconnected spreadsheets, scripts, mock data, and manual review. That fragmentation makes it difficult to answer basic questions: Which study-design revision produced this record? Which rule controlled the visit date? Which raw variable supports an SDTM target? What prompt and model generated the transformation program? Which validation findings were known when the package was handed off? Pro makes those questions answerable by design.

• Standards-first intake. eCRF workbook metadata and USDM JSON are reconciled into a single versioned Study Blueprint with source checksums and entity-level provenance.
• Deterministic raw generation. Subject count, seed, anchor date, study arms, encounters, schedule cells, collection patterns, and approved scenario constraints drive repeatable records.
• Governed AI. AI may suggest ambiguous mappings, draft scenario constraints, review SDTM mappings, and author SAS/R transformation programs; suggestions remain tagged and require human review.
• SDTM design grounded in real metadata. The workbench supports SDTMIG 3.4, 3.3, and a visibly identified curated 3.2 fallback, with variable metadata retained for review.
• Layered validation. Domain rules, SDTM structural checks, generated-code checks, a browser preflight, and an optional local CDISC CORE bridge create evidence at multiple points.
• Interoperable handoff. CSV, JSON, audit packages, SAS/R scaffolds, GitHub publication, execution-target links, and a read-only MCP endpoint support downstream use without embedding customer execution credentials.

The tool is appropriate for automation testing, standards training, metadata-pipeline qualification support, integration testing, demonstrations, and controlled experimentation. It is not a source of real-world evidence, a substitute for sponsor validation, or an autonomous regulatory-submission system.

Contents

1. The clinical test-data problem

2. Product design and architecture

3. The end-to-end workflow

4. AI responsibility boundary and human oversight

5. Validation, traceability, and auditability

6. Security, privacy, and interoperability

7. Intended value and evaluation framework

8. Limitations and responsible use

9. Adoption approach and conclusion

Appendices and references

1 INDUSTRY CONTEXT

The clinical test-data problem

Clinical data workflows must be tested before they touch production data or support regulated decisions. Teams need to exercise eCRF-to-raw mappings, visit logic, conditional collections, SDTM transformations, validation services, export packages, and receiving-system interfaces. Yet realistic clinical data is difficult to obtain, carries privacy and governance obligations, and may be poorly suited to deliberate edge cases. Manually curated fixtures solve only part of the problem: they are expensive to scale and frequently lose their connection to protocol intent and metadata.

The challenge is therefore not simply to create plausible values. A useful synthetic-data system must preserve structural and temporal relationships, expose the rules behind generation, support deliberate scenarios, and produce evidence that reviewers can inspect. It must also distinguish semantic plausibility from standards conformance. A blood-pressure value can look plausible while the dataset that carries it still violates a required-variable rule, key constraint, or study-day convention.

Why study design should drive generation

USDM provides a structured representation of study design and is intended to support conformant technologies and exchange across upstream and downstream clinical systems.[2] Its value for test-data generation is direct: arms, epochs, encounters, activities, timelines, interventions, and biomedical concepts can become executable design inputs rather than narrative context. Pro combines this design layer with eCRF field intent, allowing the schedule to determine when collections occur while the eCRF determines what is collected.

Why SDTM needs a governed transformation path

SDTM defines a standard structure for study-data tabulations and supports consistent review and reuse.[3] Transforming study-specific raw data into SDTM still requires interpretation: source variables must be matched to targets, derivations must be stated, required variables must be populated, and keys and controlled values must be checked. Generative AI can accelerate program authoring, but unbounded generation creates a new failure mode—confident code that invents sources, omits required targets, or hides assumptions. Pro responds by grounding code generation in bounded artifacts and validating the returned program and mapping manifest before it can be treated as review-ready.

2 PRODUCT DESIGN

A standards-driven, evidence-producing architecture

Synthetic Data Generator Pro is organized around a canonical, revisioned StudyBlueprint.v1. Imports do not overwrite the workbench with opaque state: source identities, timestamps, optional versions, and checksums are retained; mappings carry confidence and review status; and generation runs point back to the blueprint revision that produced them. This makes design change visible and allows a run to be interpreted in context.

Figure 1. Pro separates deterministic controls from bounded AI assistance while preserving a single revisioned lineage.

Four architectural layers

Study Blueprint as the system of record

The blueprint records the study identity and version; sources; arms and epochs; encounters with relative days and windows; activities and timelines; biomedical concepts and properties; interventions; forms and variables; arm-scoped schedule cells; scenario constraints; mapping issues; and an overall review state. Each form is assigned a collection pattern—subject-level, eligibility, disposition, scheduled finding, occurrence event, treatment administration, interval, or repeating log. That pattern determines how record contexts are created.

Determinism as a review feature

A deterministic generator is not merely easier to debug; it is easier to govern. Given the same blueprint revision, seed, requested subject count, and anchor date, Pro produces the same subject assignments and record contexts. Subject dispositions, visit reachability, event frequency, dates, controlled values, and numeric values are derived from stable seeded functions. Approved constraints are compiled into this same seeded process. Reviewers can therefore reproduce an issue without freezing a hidden random state.

3 OPERATING WORKFLOW

Twelve stages from source intake to audit package

The workbench exposes the lifecycle as twelve explicit stages. Each stage produces or reviews an artifact; the workflow can be revisited without losing the relationship between earlier design decisions and later runs.

Stage 01 — source intake

The eCRF importer reads workbook metadata, including an optional Schedule of Assessments sheet. The USDM importer extracts study identity, arms, epochs, encounters, timings, activities, interventions, biomedical concepts, and timelines. Imports are incremental: replacing one source is designed to preserve design data originating in the other. Baseline reconciliation uses deterministic similarity and classification logic; the tool does not require AI to interpret every column.

Stages 02–04 — reconciliation, schedule, and raw design

Forms are mapped to activities and biomedical concepts with confidence and review status. Ambiguous cases can be sent to an administrator-enabled AI reconciliation service using metadata-only payloads. Returned mappings are suggestions, never confirmations. The schedule view then makes encounters, relative days, arm scope, and activity cells visible. The Raw Designer lets reviewers confirm each form's collection pattern and variables before generation.

Stages 05–07 — generation, raw review, and scenarios

Generation occurs server-side and persists both the configuration and result. Subject count is not fixed by a template. Arms are assigned consistently, dispositions exercise multiple paths, visits stop according to disposition, and scheduled records are created only where the form's activity is present for the encounter and arm. Event and interval patterns create their own record contexts. Raw Review checks referential integrity, disposition logic, ISO dates, required fields, and domain-specific invariants before export.

Scenario constraints add controlled variability without making generation opaque. A reviewer can define categorical distributions, numeric ranges, and conditional values. AI may draft constraints from metadata, but only enabled, approved constraints enter the deterministic compiler. Constraint provenance remains in the blueprint revision.

Stages 08–10 — SDTM design, code generation, and conformance

The SDTM Designer creates a versioned SyntheticSdtmMappingPlan.v1 tied to one raw run and blueprint revision. For SDTMIG 3.3 and 3.4, the tool's catalogs are generated from bundled CDISC Library CSV exports and retain variable order, class, label, type and length, role, core, codelist, value-domain, value-list, and note metadata. The current implementation exposes 58 domains and 1,713 variables for 3.3, and 62 domains and 1,907 variables for 3.4. SDTMIG 3.2 is explicitly identified as a curated fallback.

The AI program-generation route receives a bounded manifest of the blueprint, synthetic raw inputs, selected IG metadata, mapping plan, and clinical golden rules. It returns SAS, R, or both, together with a machine-readable mapping manifest, assumptions, unresolved questions, and model self-assessment. The server records provider, model, key mode, template version, input and response usage, source manifest, and cryptographic hashes. Static checks reject or flag invented source variables, unknown targets, missing required variables, destructive filesystem or shell behavior, network calls, embedded credentials, and incomplete domain coverage.

A deterministic SDTM compiler remains available as a baseline and fallback. Its output is checked for required variables, DOMAIN consistency, ISO-formatted dates, and key uniqueness. The CORE Validation stage can run an instant browser preflight or send files only to a user-controlled local Python CORE service at 127.0.0.1 for the fuller executable rule set. It also accepts external XPT, CSV, Dataset-JSON, XLSX, and Define-XML packages.

Stages 11–12 — handoff and audit

Handoff supports per-domain CSV, complete JSON, deterministic SAS import and R-to-XPT scaffolds, company SAS or Posit launch targets, GitHub publication, and a read-only Streamable HTTP MCP endpoint. Execution-target records store adapter type and launch URL—not customer execution credentials. The final package gathers the blueprint, run configuration, validation, mapping plan, AI provenance, code hashes, run summaries, and reviewer notes into a single JSON evidence package.

4 RESPONSIBLE AI

A narrow AI responsibility boundary

Pro uses AI where expert acceleration is valuable and keeps deterministic logic where reproducibility and structural control are essential. This division avoids two weak extremes: a fully templated generator that cannot adapt to ambiguous study metadata, and an end-to-end generative agent whose decisions are difficult to reproduce or validate.

Human-in-the-loop is an artifact, not a slogan

Review status is stored in the model. Forms can be unreviewed, suggested, confirmed, or conflicting; scenario constraints can be draft, suggested, or approved; mapping plans and code generations carry their own statuses. This allows downstream controls to ask whether a decision was approved rather than inferring approval from the presence of generated content.

Two confidence signals are kept separate

Model self-assessment is advisory. Pro separately computes deterministic code-confidence and validation scores. Keeping these signals distinct avoids presenting a model's confidence as evidence that a program is correct. A high self-assessment with invented variables should still fail deterministic checks; a low self-assessment may still point reviewers to a program that passes syntax and coverage checks but contains unresolved semantic choices.

Bring-your-own-key without key persistence

The implementation supports platform routing and transient user-supplied keys for supported providers. BYOK values are not persisted in generation records. Persisted audit data records the provider, model, and key mode without storing the secret. Provider errors are sanitized before they reach the user interface, and failed attempts can be retained as audit evidence without retaining a supplied key.

5 EVIDENCE AND QUALITY

Validation, traceability, and auditability

CDISC describes conformance rules as a key part of standards implementation and is developing machine-executable rules and the open-source CORE reference engine.[4] Pro reflects that direction by treating validation as a layered activity rather than a single pass/fail badge. Each layer answers a different question.

Hash-linked provenance

Each transformation-code generation can retain a prompt-template version, prompt hash, response hash, bounded input hash, and per-file code hashes. These do not prove semantic correctness, but they establish identity: the program reviewed today can be compared with the program packaged tomorrow. The source manifest also records the blueprint revision, raw run, mapping plan, selected standard, and bounded inputs that grounded the request.

Audit package as a handoff contract

The package is intentionally transparent JSON. It reports which artifacts exist, whether validation passed, the selected IG version, run and plan IDs, model/provider provenance, usage, validation scores, assumptions, unresolved questions, timestamps, and reviewer notes. This supports machine processing while remaining inspectable by standards, programming, QA, and platform teams.

6 TRUST ARCHITECTURE

Security, privacy, and interoperability

Synthetic by purpose, not automatically safe by context

The generator creates artificial subject identifiers and values; it does not require real patient records. That reduces privacy exposure for its intended use, but it does not make every deployment or input harmless. An eCRF specification, USDM payload, reviewer note, repository name, or custom source file can still contain confidential study information. Organizations should classify inputs, control project access, configure secrets appropriately, and review exports before external sharing.

Access-controlled projects and immutable evidence

Projects are authenticated and access-controlled. Blueprint revisions and generation runs are persisted so that later work does not silently replace earlier evidence. The MCP endpoint accepts an administrative browser session or a configured service-account bearer token, checks allowed origins, and exposes read-only tools for projects, blueprints, run summaries, mapping plans, code-generation audits, and execution targets.

Minimal credential footprint

Customer SAS and R execution credentials stay in the customer execution environment. Registered execution targets store only descriptive connection metadata such as a launch URL and adapter type. GitHub publication uses a token for the request; if a user elects to remember it and server secret storage is configured, the token is encrypted at rest. AI BYOK values are transient. These boundaries reduce the number of secrets represented inside the blueprint and run records.

Interoperability surfaces

• Data: per-domain raw and SDTM CSV, complete result JSON, audit JSON, and external validation inputs including XPT and Dataset-JSON.
• Code: AI-authored SAS/R transformation programs plus deterministic SAS import and R-to-XPT scaffolds.
• Repositories: optional publication of programs, datasets, blueprint, mapping plan, validation, and AI audit records to GitHub.
• Execution: launch-target registry for SAS Viya, SAS Studio, Posit Workbench, Posit Connect, and custom HTTPS environments.
• Machine access: read-only Streamable HTTP MCP tools designed for authenticated inspection and orchestration without direct database access.

This orientation is consistent with the broader Digital Data Flow objective of structured, reusable study definitions and standard APIs that improve interoperability across clinical systems.[2]

7 OPERATIONAL VALUE

Intended use and a measurable evaluation framework

The product's value should be measured in the work it makes more repeatable and reviewable—not in a generic claim that AI is faster. A controlled evaluation can compare Pro with an organization's existing fixture and mapping workflow across the measures below.

Primary intended uses

• Automation and regression testing for clinical metadata, transformation, validation, and export pipelines.
• Standards training that lets learners inspect the path from study design through raw collections to SDTM.
• User acceptance testing and integration testing where realistic structure is needed without real patient data.
• AI-code-generation research with explicit source manifests, review gates, and deterministic comparison baselines.
• Vendor demonstrations and challenge submissions that require visible standards integration and end-to-end traceability.
• Early test-data design for new studies, provided outputs are kept separate from production and submission data.

Stakeholder value

Standards teams gain a reviewable mapping and metadata workspace; programmers gain bounded generation inputs and editable SAS/R proposals; QA teams gain repeatable runs and evidence packages; platform teams gain defined APIs and handoff seams; and clinical data managers gain a visible link between forms, activities, visits, and generated records. The shared artifact chain reduces the translation burden between disciplines.

8 RESPONSIBLE USE

Limitations and boundaries

A credible synthetic-data white paper must state what the system does not establish. The following boundaries apply to the implementation reviewed for this paper.

Recommended control set for organizational use

1. Classify and approve source metadata before import; exclude real patient data and unnecessary confidential text.
2. Define which blueprint states and reviewer roles are required before raw generation, mapping approval, code execution, export, or repository publication.
3. Pin the blueprint revision, raw run, mapping plan, model/provider, template version, and code hashes used in each test cycle.
4. Execute generated programs only in an isolated, controlled SAS or R environment with restricted network and filesystem access.
5. Compare generated outputs with deterministic baselines and expected test cases; resolve assumptions and unresolved questions explicitly.
6. Run the applicable organization-approved validation stack, retain findings, and document deviations before handoff.
7. Review the final package for completeness, repository visibility, credential handling, and information classification.

9 ADOPTION

A practical adoption path

Adoption is best approached as a test-workflow improvement, not as a wholesale replacement for validated production programming. Start with one representative study and one bounded target—such as repeatable raw-data fixtures for a metadata pipeline or an AI-assisted SAS program for a small SDTM domain set.

1. Pilot. Import an approved eCRF and USDM example, reconcile the design, generate a fixed-seed raw package, and compare it with existing test fixtures.
2. Control. Define review roles, source-classification rules, approved AI providers, validation expectations, and export restrictions.
3. Benchmark. Measure effort, reproducibility, traceability coverage, defect discovery, and review cycle time against the current process.
4. Integrate. Add downstream SAS/R, validation, GitHub, or MCP consumers one at a time, retaining the audit package as the interface contract.
5. Scale. Add reusable study archetypes and scenario libraries only after their provenance and review ownership are clear.

Conclusion

Synthetic Data Generator Pro demonstrates a pragmatic pattern for responsible clinical AI: let standards and revisioned metadata define the problem; use deterministic engines for repeatable data and baseline results; use AI for bounded interpretive and authoring tasks; require explicit human confirmation; and package the complete evidence chain for review and reuse.

Its most important output is therefore not a CSV or a code file in isolation. It is a traceable test-data system in which source intent, generation logic, transformation decisions, validation evidence, and handoff metadata remain connected. That design directly addresses the 2026 CDISC AI Innovation Challenge emphasis on technical feasibility, standards integration, traceability, and ecosystem impact.[1]

APPENDIX A

Canonical artifact set

APPENDIX B

Implementation snapshot and methodology

This paper was prepared from the Synthetic Data Generator Pro implementation available in the Clinical Hub repository on 29 July 2026. The review covered the Pro library README, canonical types, importers, generator, SDTM mapping and generation logic, transformation-code controls, validation utilities, project API routes, read-only MCP endpoint, and the twelve-stage user interface. Product behavior may change after this snapshot.

External context was checked against current official CDISC pages for the 2026 AI Innovation Challenge, Digital Data Flow and USDM, SDTM, CORE, and terminology. Product-specific claims in this paper are implementation claims, not claims of endorsement, certification, regulatory qualification, or conformance by CDISC.

References

[1] CDISC. “AI Innovation Challenge.” 2026. https://www.cdisc.org/events/ai-innovation-challenge

[2] CDISC. “Digital Data Flow” (USDM and implementation guidance). https://www.cdisc.org/ja/node/8100

[3] CDISC. “Study Data Tabulation Model (SDTM) v1.6.” https://www.cdisc.org/standards/foundational/sdtm/sdtm-v1-6

[4] CDISC. “CORE — CDISC Open Rules.” Updated 15 May 2026. https://www.cdisc.org/core

[5] CDISC. “Terminology.” https://www.cdisc.org/standards/terminology

[6] Synthetic Data Generator Pro source repository. https://github.com/vdebbeti/synthetic-data-generator-PRO

Trademark and standards notice

CDISC, SDTM, SDTMIG, USDM, and CORE are referenced for descriptive and interoperability purposes. All trademarks and standards content remain the property of their respective owners. This document describes an independent implementation and does not imply CDISC endorsement.