Last updated: Sept 3, 2026
Transcript:
Welcome to nPhase.ai: where automated clinical programming runs through a single, governed pipeline.
A phase three trial now generates about six MILLION datapoints. That's almost "SIX-AND-A-HALF TIMES" what it was a decade ago.
Almost EVERYTHING about how we "collect that data" has changed; but almost NOTHING has changed about how we turn that data into a submission.
While the industry has made progress to improve the process, getting from "locked study data" to SUBMISSION has never been fully addressed... until NOW.
Consider the process of SDTM Mapping; Adam file generation; TLF production; ... and the clinical study report itself.
In most organizations, that work is still hand-built "from scratch" on every study, programmed in environments that don't interact, and then reconstructed after-the-fact because an inspector asked how you got there.
That's the "last mile", and it's where submission time actually accumulates.
To be clear, this is NOT a tooling gap, because statistical programmers have good tools.
It's a "governance gap", because automation introduces a harder question: "can you DEFEND the output?"
This is SCE — the Statistical Computing Environment from nPhase.ai...which is anchored to the CDISC Analysis Results Standard.
It takes "locked clinical data" through a "SINGLE governed pipeline" to produce SDTM; Adam; and TLFs; all within a "single system".
It brings SAS; R; and Python together into a SINGLE environment. It runs an automated production chain anchored to the CDISC Analysis Results Standard.
And it enforces a "governance model" through actual platform guardrails.
AI "proposes" these data transformations... humans "approve" them... and deterministic engines "execute" them.
A governed, human-controlled pipeline for AI-assisted SDTM, ADaM, TLF, and CSR generation. What matters is whether you can DEFEND the output.
Everything starts in the Project Portfolio — "four" active studies, all pulling from "one shared Library", each pinning its "exact approved version".
Inside the project, raw data flows through SDTM AutoMapper, then ADaM AutoMapper, and finally TLF generation, packaging, and CSR drafting.
AI "assists"... humans "approve"... and deterministic engines "execute".
Now for SDTM mapping — The AI proposes a recommended Adverse Events mapping. For AE severity, it proposes a 94% mapping accuracy, and the reviewer accepts it. The variable representing "Relationship to Non-Study Treatment" is treated differently. Although it is surfaced here, it is not executed without further qualification. The AI makes a recommendation...but a human makes the final decision.
Accepted mappings become real, "editable code"; but nothing is run quite yet. It's important to distinguish that deterministic compute produces the final artifacts, "not" the AI. In other words, execution evidence is captured at the moment it runs, "not" reconstructed afterward.
What comes out is an approved SDTM package, including all necessary files in a "frozen state". ADaM consumes this "exact package".
In ADaM, the AI proposes derivation logic for the treatment-emergent flag at 95% confidence. The reviewer accepts it, then the spec becomes locked once it is approved.
That locked spec becomes a real ADAE program, producing a traceable dataset. This is governance enforced by the "platform", not asserted in a policy. The spec is always approved and locked before any code runs.
ADAE and ADSL are released as the frozen upstream source. The approved SDTM flows into the approved Adam, which flows into the TLF contract.
The TLF AI configuration locks six versioned assets — AI capability, system prompt, validation ruleset, examples, Article 50 marker template, and reviewer acknowledgement. These version-controlled assets are stored in the Library, not bolted on afterward.
Everything is locked into one frozen execution context. The SAP is parsed into five candidate Analysis Results — three approved, and two pending. That's the Analysis Results Standard doing its job: connecting objectives and methods downstream.
The AI proposes a full contract for the "Treatment-Emergent Adverse Events" object — grounded in the Safety Population, ADAE and ADSL, and a specific filter. The application iterates through programming tasks, validations, packaging, and final CSR drafting. All of these steps are traced back to approved evidence which is both predictable and reproducible.
Production programming turns the TLF contract into real SAS code, but nothing is run quite yet.
QC Programming is a genuinely "different program" — independent code, same frozen contract, "no shared code with production".
Each programming step is then brought together for comparison. In this case, the result flags a mismatch in the subject's de-duplication key. While the AI can "explain the problem", only a human can "resolve it".
Every output runs through "five validation checks". Here we have four passed items, and one warning which was already acknowledged. That AI-governance check isn't paperwork, but rather a "gate" inside the validation workflow. If it fails, the output does not ship.
The "Package and Attestation" step reconciles subject counts from 812 down to the final passing population. "Two separate reviewers sign off" before the package and CSR manifest are locked.
CSR drafting is the last step. Only 6 sections are eligible in this case. A draft narrative is recommended by the AI for each eligible TLF source and section, all of which are still subject to review. Items that have not cleared validation are simply not available to draft from.
So that's SCE, start to finish. The Library "defines", the Study Setup "pins", Execution Context "freezes", and AutoMappers "execute", with all audit records retained for evidence. Now "this" is an output we can truly "defend".
The same governed pipeline unlocks ADDITIONAL capabilities that improve other aspects of trial operations.
Take legacy SAS migration, for example. Teams carrying decades of SAS programs can migrate them to R or Python inside the SAME environment, applying the same spec-lock and independent-QC discipline to the migration itself.
With SCE, you're VALIDATING the transformation rather than simply TRUSTING it...and hoping for the best.
Take CSR generation as another example. Because the statistical analysis plan is already parsed into the Analysis Results Standard chain, clinical study reports can be generated directly from the chain rather than manually assembled at the end.
And what about older studies not designed against CDISC standards? SCE can be used to bring older, non-standardized datasets up to current SDTM and Adam standards.
SCE already integrates with the systems you already run, so there's no need to replace what is already being used. This is by design, because we understand that the most realistic path into a large biometrics organization is coexistence rather than replacement.
Underneath all of this sits a built-in data science workbench, elastic scale, enterprise access management, and support for federated data sharing. The environment grows WITH the portfolio instead of constraining it.
SCE is anchored to the CDISC Analysis Results Standard, with COMMITTED alignment to DDF and USDM, and metadata repositories for canonical governance.
The point is NOT that AI touched the work. It's that EVERYWHERE AI touched it, there's a locked specification. An independent check; a named approver; and traceable evidence captured in the moment.
That discipline is what collapses the last mile — fewer query cycles; less manual reconciliation between production and QC; and a shorter run from lock to submission.
Speed is only "commoditized" when the output is one that you can "truly DEFEND".
Learn how to apply SCE to YOUR data pipeline at nPhase.ai.
