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 Sunil Kumar Pusarla to share his journey and insights from over 20 years in statistical programming. Sunil discusses the skills and traits essential for success as a statistical programmer, addressing the challenges and pressures that professionals face today. He emphasizes the importance of maintaining high-quality standards, even under tight deadlines, and compares the distinct cultures and expectations of big pharma versus smaller biotech companies. Sunil also explores how technological advancements are reshaping the role of statistical programmers and offers his vision for how the field will evolve over the next decade, including the new skills that will become crucial in the future.
Guest: Sunil Kumar Pusarla, senior director of statistical programming at Omeros, a Seattle-based biotech company. Background in homeopathic medicine and a public health master's with dual majors in epidemiology and biostatistics.
Host: Tomás Sabat Stöfsel, CEO & Co-Founder, Verisian
Topics: Sunil's path from medicine into biostatistics and SAS, learning by studying SAS conference papers and community forums, SAS's continued relevance alongside R and Python, the pressures of leading a regulatory submission, big pharma versus small biotech career exposure, lab data standardization as an underrated technical challenge, predictions for SDTM automation over the next decade, perspective on AI and LLM hype, career advice and continuous self-assessment.
The full episode can be found on YouTube, Apple Podcasts or Spotify.
Sunil's route into statistical programming began with a Bachelor of Homeopathic Medicine and Surgery, followed by a public health master's combining epidemiology and biostatistics. Comparing tools like SPSS and Minitab against SAS during his coursework, he found SAS's depth and flexibility a better match for his interests and pursued both base and advanced SAS certifications before starting as a junior programmer. He describes an explicitly mimetic early learning strategy: identifying strong SAS programmers and their published conference papers, then treating each new technique he encountered as something to personally master and apply.
Sunil credits specific SAS conference papers and community contributors directly with shaping his skill set: Mike Zdeb's work on CAT functions (introduced alongside SAS 9.2), Paul Dorfman's hash-object techniques, and papers from Art Carpenter and Cynthia Zender, alongside years of following the SAS-L listserv community, where the same question would draw multiple different solution approaches depending on an answerer's industry background. He treated each new SAS capability, statistical graphics (SG) procedures, FCMP user-defined functions, as something to implement in his own work as soon as he encountered it, describing this continuous technique-by-technique absorption as the core mechanism of his career growth.
Asked where SAS sits today relative to R, Python, and rising open-source adoption, Sunil is direct: in his career, he's never encountered a problem SAS couldn't solve, and while he acknowledges the field's growing exposure to R and Python (particularly among newer graduates with less SAS training) and industry momentum behind projects like Pharmaverse, he pushes back on the assumption that SAS licensing costs are prohibitive for smaller companies specifically, arguing the fee is comparatively minor next to other operating costs. He frames the real opportunity as interoperability rather than replacement, noting SAS's own support for R (via SAS/IML) and Python (via SASPy) as evidence that having more tools available, and knowing when to reach for each, matters more than picking a single winner.
Asked how he manages the intense pressure of leading a regulatory submission, Sunil describes a deliberately checklist-driven approach built from lessons learned in prior filings: cataloguing what made a previous submission stressful, then converting each pain point into a concrete item for the next project's checklist. He notes that keeping pace with continuously evolving implementation guide versions (ADaM 1.1 to 1.2, SDTM 3.1.2 to 3.1.3) and shifting regulatory guidance (FDA technical conformance updates, EMA requirements) is itself a moving target that has to be tracked deliberately rather than assumed stable between projects. He's also candid that a single lead programmer can't personally own every component of a large, multi-study submission and has to build trust in delegating pieces of the work to others.
Drawing on his primarily small-biotech experience (including his current role at Omeros), Sunil contrasts it with what he's heard from peers at larger pharma companies: bigger organizations often silo programmers into a single specialization (SDTM only, or ADaM only, or exploratory analysis only) for extended periods, while smaller companies, out of resourcing necessity, expose a single programmer to the full pipeline, raw data ingestion, SDTM creation and compliance checking, ADaM programming, TLF production, plus ad hoc analysis requests from medical monitors, CMOs, or conference submissions, and post-filing FDA/EMA correspondence. He frames this as a genuine advantage for building complete, end-to-end programmer expertise, while acknowledging the pattern varies by company.
Asked about his toughest professional experience, Sunil points specifically to reconciling lab data collected from many local, non-central labs across different countries and sites, each potentially using different units and testing conventions for the same parameter. Unlike centralized lab data (a single unit per parameter), standardizing this kind of fragmented data and finding accurate unit-conversion factors can take anywhere from half a day to a full day per conversion, a genuinely painful bottleneck when compressed against filing deadlines. He adds that experience alone doesn't eliminate this kind of friction, since data varies meaningfully by molecule and study, and even seasoned programmers regularly encounter new problem types that demand fresh, unbudgeted time investment.
Looking a decade ahead, Sunil predicts 60-80% of SDTM programming could realistically be automated, but stresses this depends on standardization starting far upstream, at CRF design and within EDC systems themselves, since some EDC platforms still lack the functionality needed to support that level of downstream automation. He's more skeptical about fully automating exploratory analysis, expecting better tooling (R Shiny, dashboards, platforms like JMP Clinical or Spotfire, SAS Visual Analytics) to make exploration easier rather than eliminate the need for a human programmer, arguing machines fundamentally can't replicate human judgment and that experienced programmers with strong domain knowledge will remain essential regardless of automation gains.
Asked directly why he hadn't mentioned AI once in the conversation, Sunil is candid that he's not particularly engaged with current AI/LLM terminology, coming from a medicine and public health background rather than computer science, and draws a direct parallel between what's now branded as "AI" or "machine learning" and concepts he already has working vocabulary for, like macros. He's clear this isn't dismissiveness so much as a conscious choice to lean into his actual strength: deep, hands-on domain knowledge built through direct experience across the full data and submission pipeline, rather than chasing newer terminology he hasn't yet had reason to apply.
Sunil's advice for programmers hoping to reach his level of experience starts with honest self-assessment: identifying whether you're stronger in programming or domain knowledge, then deliberately building up whichever is weaker, one step at a time rather than trying to absorb SDTM, Define-XML, reviewer's guides, FDA guidance, and a new language simultaneously. He recommends prioritizing whatever skill is most relevant to your current role first, then expanding outward, and treats ongoing conference attendance, community forums (SAS Communities, Stack Overflow, LinkedIn groups), and papers as essential, noting that hearing a paper presented live can land very differently than reading it cold. His closing framing for avoiding complacency is a self-directed thought exercise: would you hire yourself again today, and if not, why not?
"Data is dynamic. It's different for different molecules and different studies. You feel like, 'Yeah, last time no problems. I was able to finish all these things with ease.' But this filing definitely different than the last filings." — Sunil Kumar Pusarla
"When you have a checklist, it will make it easier." — Sunil Kumar Pusarla
"Since data is dynamic, it's different for different molecules and different studies... certain problems are comparatively newer, so when you face it, then only, oh, this is a problem I need to invest more time in it." — Sunil Kumar Pusarla
"The machines cannot think like humans, right? For a machine, it's like plus or minus, zero or one. But there's more to it, so there is a need for experienced programmers with domain knowledge, especially." — Sunil Kumar Pusarla
"Don't let your pride stop learning new things. So keep on learning... even when you're enhancing one month life to a patient, or when you're reducing the suffering of a patient, you're doing a lot of, you're helping humanity." — Sunil Kumar Pusarla
Why does Sunil consider lab data standardization one of the hardest parts of a submission?
Because local labs across different countries and sites often use different units and testing conventions for the same parameter, unlike centralized lab data. Finding accurate conversion factors can take half a day to a full day per unit, which becomes especially painful under compressed filing timelines.
Does Sunil think SAS is being replaced by R and Python?
No. He says he's never encountered a problem SAS couldn't solve and pushes back on the assumption that SAS's licensing cost is prohibitive for smaller companies. He frames the future as interoperability (SAS's own support for R and Python) rather than one language replacing another.
What's the biggest difference between working at a small biotech versus a large pharma company, according to Sunil?
Breadth of exposure. He says large pharma often silos programmers into one specialization for extended periods, while small biotech companies, out of necessity, expose programmers to the full pipeline: SDTM, ADaM, TLFs, ad hoc requests, and post-filing regulatory correspondence.
How much of SDTM programming does Sunil think will be automated in the next decade?
He estimates 60-80%, but stresses this depends on standardization starting upstream at CRF design and within EDC systems, since some EDC platforms currently lack the functionality to support that level of downstream automation.
What is Sunil's view on AI and large language models in clinical programming?
He's candid about not being deeply engaged with current AI/LLM terminology, drawing a parallel to concepts he already has vocabulary for (like macros), and instead attributes his effectiveness to deep, hands-on domain knowledge built through direct experience rather than new technology adoption.
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.
