Submit when the Science is Done
Learn how to make agentic AI trustworthy in clinical trials, with your experts in control, always.
In this episode of the Verisian Community Podcast, we welcome Shadab from Merck and Rahul from Johnson & Johnson. Our conversation begins with a discussion on the feasibility and desirability of achieving end-to-end automation in clinical programming. We then delve into the world of generative AI, exploring its potential to revolutionize existing workflows. To wrap up, we discuss the evolving skill set and qualifications necessary to excel as a statistical programmer in today's industry.
Guests: Shadab Ahmed, statistical programmer at Merck, computer science engineering graduate; Rahul Ahmed, statistical programmer at Johnson and Johnson, background in pharmacy with prior roles in document control, CRF design, and database development before moving into statistical programming.
Host: Tomás Sabat Stöfsel, CEO & Co-Founder, Verisian
Topics: Guest career origin stories and what drew them to statistical programming, automation successes and failures (including a discontinued end-to-end SDTM automation project), where low-hanging automation fruit lies across SDTM/ADaM/TFL, evolving regulatory acceptance of open-source languages and interactive submissions, generative AI's realistic near-term applications (response-criteria algorithms, documentation, federated learning), skills needed to succeed in statistical programming today and in the future
The full episode can be found on YouTube, Apple Podcasts or Spotify.
Shadab describes working on a fully automated pipeline built as an ETL-style tool that took raw CDASH-standard data and produced SDTM output in a single click, using metadata-driven techniques to eliminate manual SDTM programming almost entirely. In theory, this automated the SDTM programmer's job outright. In practice, the team found that even with both input and output data harmonized to strict standards, every study generated unforeseeable change requests, and supporting those changes ended up costing nearly as much effort as manual programming would have. The tool was ultimately discontinued. Shadab draws the broader lesson that the industry's heavy reliance on macros — modular, flexible snippets of automation a programmer can call selectively — exists precisely because rigid, end-to-end automated systems struggle to keep pace with constantly shifting therapeutic-area requirements, evolving implementation guide versions, and new analysis methods (his example: competing-risk analysis emerging alongside older PROC LIFETEST-based survival analysis).
Both guests converge on realistic, partial automation as the better target than end-to-end solutions. Rahul estimates automation ceilings around 80-90% even for standardized processes, since some proportion of any study will always include collection quirks or complexities the standard didn't anticipate. He argues the clearest starting point is industry-wide agreement on standard outputs, and by extension standard ADaM and SDTM variables that feed them, since every company currently applies its own interpretation of the standards. Shadab agrees SDTM is the easiest automation target, since many companies have already automated large portions of it once raw data is standardized, but identifies ADaM as the hardest: because ADaM variables map closely to final TFL outputs, current ADaM structures are too rigid to automate without also making them structurally more flexible. TFL automation is viewed as more feasible than ADaM, especially with emerging interactive-output tools (e.g., Shiny apps), though shell design still varies heavily by therapeutic area and study design.
Asked whether regulators might eventually accept fully interactive submission formats, Rahul notes his own view has shifted substantially in the past five years: the FDA has published material indicating openness to receiving submissions built in R and other languages, and he expects that trend toward language-agnostic, results-focused review (rather than favoring one specific language) to continue, potentially extending to interactive applications built in tools like Shiny or Python, provided regulators can trust and independently verify the results being shown.
Rahul's clearest AI use case draws on his oncology background: response-criteria algorithms (for hematologic or solid tumor assessment) are already validated three separate times in current practice (investigator-collected, programmatically derived, then adjudicated), making them a well-scoped, already-quality-controlled candidate for training a model to reproduce the same result with the same rigor. Both guests separately identify documentation and internal knowledge search as a second strong near-term use case: an AI system that can search across a company's prior studies and show a programmer the various ways a given variable has been derived historically, surfacing five approaches and letting the programmer choose. Shadab is more skeptical about AI generating full programs directly, arguing no single organization holds enough proprietary code to train a dedicated coding LLM, and that data-sharing constraints make pooling that code across companies unlikely without approaches like federated learning (training locally, sharing only model weights) or cross-company technical communities such as Pharmaverse, which he sees as already moving in that direction.
Both guests frame success as requiring genuine competence across programming, statistics, and pharma/biology, not just technical skill, revising an earlier "jack of all trades, master of none" framing to "master of one, jack of the rest." Rahul emphasizes that statistical programming has evolved faster than almost any adjacent field, citing his own first open-source programming conference poster in 2012 as a marker of how long R and Python took to move from talk to real implementation. Shadab stresses that learning programming concepts (data structures, object-oriented thinking) matters more long-term than fluency in any one language, since languages themselves will keep changing, while foundational statistical literacy (what a p-value or confidence interval actually means in practice, not just in a textbook) and real engagement with the underlying disease biology and mechanism of action are what ultimately improve a programmer's judgment and code quality over time. Both note the growing trend of hiring fresh graduates directly into the field (particularly in India) makes structured onboarding and training programs a genuine organizational responsibility, not just an individual learning curve.
"There was one study where there were 34 subjects in late phase cancer, and all of them died. I couldn't sleep that night... these are not just rows and there is a patient behind every row." — Shadab Ahmed
"There is no point of automation... if it's automated the process but the support of that tool also takes much effort, then... it was discontinued later." — Shadab Ahmed, on the discontinued end-to-end SDTM automation project
"Nothing can be done 100%. It has to be around 80% to 90%." — Rahul Aryal, on realistic automation ceilings
"There is a difference between learning programming and learning a language... once these languages will change, the only thing that can help you is the programming, the concepts of programming." — Shadab Ahmed
"Be true to your work, be true to what you do, and success will follow." — Rahul Arya
Why was a fully automated, end-to-end SDTM generation tool discontinued?
Because even with standardized CDASH input and SDTM output, per-study change requests turned out to be unforeseeable and costly to support, ultimately costing nearly as much effort as manual programming and undermining the automation's purpose, according to Shadab's account of the project.
Which parts of the clinical programming pipeline are easiest and hardest to automate?
SDTM is generally considered the easiest target since it's closest to standardized raw data, with many companies already automating large portions of it. ADaM is considered the hardest, since it maps directly to final TFL variables and current ADaM structures are too rigid to automate without first becoming more flexible.
Are regulators becoming more open to submissions in languages other than SAS?
Yes, according to Rahul, who cites FDA public statements indicating openness to R and other open-source language submissions over the past five years, with a longer-term possibility that regulators could accept interactive output formats (like Shiny apps) as long as results are transparent and verifiable.
Where can generative AI realistically help in clinical statistical programming today?
The strongest near-term use cases discussed are training models on well-defined, already-validated algorithms like oncology response criteria (which are already triple-checked in current practice), and improving documentation and internal knowledge search across a company's prior studies, rather than generating full analysis programs directly.
Why is it hard to train an AI model to generate clinical programming code directly?
According to Shadab, no single organization has enough proprietary code to train a dedicated coding LLM, and data-security constraints make pooling code across companies difficult, though approaches like federated learning or cross-company communities such as Pharmaverse could help address this over time.
The Verisian Community Podcast brings together experts in clinical trials to exchange innovative ideas and best practices central to clinical reporting, submission and review. Aligned with Verisian's mission to accelerate the evaluation and market launch of new medical treatments, each episode features expert insights, with guests ranging from statistical programmers to medical writers, to discuss the challenges and opportunities of the latest software and technology.
You can listen to us on YouTube, Apple Podcasts or Spotify.
See Verisian in action. Share a few details and we’ll be in touch to schedule your demo.
Your request has been received. A member of the Verisian team will contact you shortly to arrange a demo.
