Solutions
About Us
Insights
Careers
Contact us
Contact Us
Customer Support
Customer Support

risk.assessr: R Package Validation for Regulatory Submission in Pharmaceutical Development

In pharmaceutical development, the reliability of statistical software is not a luxury; it is a regulatory requirement. For organizations leveraging R in regulated environments, this mandate means a rigorous approach to validation is needed. Tools like risk.assessr allow users to create a practical, data-driven process to meet regulatory requirements.

 

Validation in R

In pharmaceutical development, validation typically refers to systems validation. The system validation should incorporate all of the following elements:

  • Accuracy
  • Reproducibility
  • Traceability

When assessing the accuracy of R packages, the R Validation Hub differentiates R packages by the following types:

  • Base and recommended (core) packages: developed by the R Foundation and shipped with the basic installation and represent the highest tier of reliability.
  • Contributed open-source packages: developed by anyone in the community and may vary significantly in their accuracy and robustness.

 

Validation using risk.assessr

Recognizing the need for a structured, risk-based approach to R package validation, we developed the open-source tool, risk.assessr. The risk.assessr package takes a risk-based approach to evaluate the potential risks linked to each R package.

The assessment considers:

  • A package’s complexity and structure
  • Unit test coverage
  • Traceability
  • Documentation quality
  • License
  • Popularity
  • Package activity and maintenance

 

By extracting these risk-based metrics, risk.assessr allows users to make informed decisions about whether a package is suitable for use in regulated environments or in exploratory analysis.

 

Key metrics for package validation

Validation metrics are gathered by risk.assessr through specific functions that retrieve desired data. Table 1 lays out some of the key metrics and risk.assessr functions:

 

Table 1: Key Metrics

 

Risk analysis using risk.assessr

The power of risk.assessr lies in its risk analysis capabilities, which employ rule-based criteria. These risk criteria can be used to enforce stricter standards, accommodate internal tooling priorities, or meet compliance requirements. Users define threshold values for high, medium, and low risk across the metrics mentioned above or for metrics that they define themselves. These thresholds are stored in inst/config/risk-definition.json, allowing for centralized, version-controlled governance of validation standards.

The get_risk_analysis() function applies these rules to calculate risk ratings, transforming raw metrics into actionable, easy-to-understand intelligence. This approach recognizes that validation requirements vary by organization and use case — what constitutes acceptable risk for an exploratory analysis differs from risk tolerance for a regulatory submission.

 

Risk analysis: Reporting

risk.assessr generates two complementary reports that serve different audiences and purposes.

The generate_html_report() function produces a detailed report for developers and validation teams that translates the three level threshold risk values into a three-level visualization: red for high risk, yellow for medium risk, and green for low risk. This visual approach makes risk assessment immediately apparent and facilitates technical discussions about package suitability.

For validation team sign-off of R packages, write_summary_report() generates a concise one-page summary that produces three actionable recommendations: Approved, Rejected, or Remediation Needed. This report, typically generated by a Validation GitHub Action, provides a structured framework for validation teams to apply critical thinking and make final decisions about package inclusion in submission or other environments.

 

Final takeaways

risk.assessr can be a critical component of an easy-to-use, reliable, and detailed validation workflow. These workflows allow organizations to confidently create validated R environments for submission purposes and/or exploratory purposes. They also help maintain audit trails and compliance documentation.

Embedding R into GxP-Compliant Statistical Computing Environments

Biotech and mid-sized pharmaceutical companies are increasingly modernizing their statistical computing environments (SCEs) to keep pace with growing data complexity, advanced analytics, and evolving regulatory expectations. Open-source languages such as R offer clear advantages in flexibility and innovation. However, in GxP-compliant settings, adoption introduces challenges that go far beyond technology itself.

Much of the discussion around R focuses on its capabilities. In practice, the real challenge lies in operationalizing it within a compliant ecosystem — where validation, governance, and reproducibility become critical.

This article explores these challenges from a practical perspective and outlines how organizations are addressing them.

 

The real barrier: GxP complexity

Adopting R is not the primary hurdle; embedding it into a GxP-compliant environment is. This requires:

  • Validation of open-source packages
  • Governance and auditability
  • Reproducibility and traceability
  • Ongoing lifecycle management

For organizations without established frameworks, these requirements can introduce significant overhead, often slowing innovation rather than accelerating it.

 

Why mid-sized organizations are disproportionately impacted

Mid-sized biotech and pharmaceutical companies face a structural challenge. While regulatory expectations are the same as for large pharma, available resources are not.

Smaller teams must manage validation, infrastructure, and delivery simultaneously, often without dedicated support functions. As a result, system complexity scales faster than internal capacity, directly impacting timelines and limiting the ability to innovate.

 

Different starting points, different challenges

In practice, organizations face different realities depending on their level of SCE maturity:

  • Some lack the infrastructure to support GxP-compliant open-source environments
  • Others have established systems but face integration challenges with external partners
  • A third group is transitioning toward R and multi-language workflows but lacks maturity in governance and tooling

These scenarios require flexible approaches tailored to each organization’s context.

 

Moving toward integrated, multi-language environments

To address fragmentation, many organizations are adopting polyglot SCEs, where SAS and R coexist within unified workflows.

This approach enables greater flexibility while maintaining compliance, ensuring traceability, reproducibility, and smoother collaboration across internal teams and external partners.

 

A practical path forward

Rather than building and maintaining complex infrastructure internally, many organizations are exploring CRO-based service models.

By leveraging GxP-validated environments, sponsors can access production-ready R ecosystems without the burden of developing validation frameworks or managing platform engineering. This approach supports both full outsourcing and hybrid collaboration models, while ensuring alignment with client-specific systems.

 

Final takeaways

The challenge is not adopting R — it is managing the complexity of making it compliant.

Organizations that successfully unlock its value do so by:

  • Addressing GxP requirements early and systematically
  • Adapting approaches to their level of SCE maturity
  • Leveraging integrated, multi-language workflows
  • Exploring service-based models to accelerate adoption

With the right strategy, R becomes not a source of complexity, but a powerful enabler of innovation in clinical development.

 

Interested in learning more?

Join our upcoming webinar, “Navigating GxP Complexity: Unlocking the Value of R,” where we will share practical experience from Cytel’s polyglot SCE, including validation approaches, governance models, and operational best practices.

Register now to learn how to modernize your statistical computing environment — without adding unnecessary complexity.

Building External Control Arms in Rare Disease Clinical Trials: A Programmer’s Perspective

External Control Arms (ECAs) are gaining a lot of attention in clinical research, particularly in rare diseases, where traditional randomized trials are often difficult to execute. Much of the discussion focuses on the statistical methodology and study design required to identify appropriate populations and data sources. But in practice, one of the biggest challenges lies in the programming effort, which is equally critical, but often more complex than anticipated.

Given that ECAs are still an evolving area, formal regulatory and industry guidance remains relatively limited. However, available publications are beginning to address key considerations. For example, the FDA’s Data Standards for Drug and Biological Product Submissions Containing Real-World Data (2024) provides recommendations on preparing and submitting RWD-derived datasets, while highlighting challenges in standardization and traceability. In parallel, industry initiatives such as the PHUSE white paper on Data Standards for Non-Interventional Studies outline common data standardisation challenges and practical approaches to address them. In addition, dedicated working groups within PHUSE are actively contributing to the development of best practices for ECAs.

This article focuses on the practical challenges from a programming perspective, drawing on recent case study experience.

 

Working with real-world and heterogeneous data

From a programming perspective, ECAs differ significantly from traditional clinical trials. Instead of working with well-structured datasets collected under controlled protocols, programmers are required to integrate data from multiple sources, including Real-World Data (RWD), historical trials, observational studies, and natural history cohorts. Each source brings its own structure, conventions, and limitations, often with poor documentation.

In one case study, external control data was derived from two independent natural history cohorts across different regions. While both sources represented similar patient populations, differences in baseline definitions, visit schedules, and outcome assessments required careful reconciliation.

The programming team aligned key covariates, including baseline age, genetic subtype, and functional scores to support comparability with the treated trial population. This went far beyond standard data mapping and required informed decisions to standardize variables that were not originally designed for cross-study integration.

 

Harmonization and data standardization

Once data sources are understood, harmonization becomes a critical step. The validity of an ECA depends on ensuring consistent definitions across baseline variables, endpoints, covariates, and visit timing.

In practice, this involves standardizing baseline windows, assessment schedules, coding dictionaries (such as MedDRA, across multiple versions, and laboratory standard units), endpoint derivations, and covariates used for matching. Across the case studies, this proved to be one of the most time-intensive phase.

Even small differences required careful reconciliation. For example, the same functional score was recorded on different scales across studies, requiring re-derivation into a common format.

If not addressed early, these inconsistencies can significantly impact downstream analyses, including propensity score modelling and bias estimation. Early and systematic harmonization is therefore essential to ensure consistency and minimize rework.

 

CDISC alignment, missing data, and analytical complexity

For studies intended for regulatory submission, alignment with CDISC standards (SDTM and ADaM) is essential. However, external datasets are rarely structured with these standards in mind, requiring substantial programming effort during transformation.

In another case study, SDTM datasets pooled from multiple studies, were used as the source. However, inconsistencies in specifications and differences in SDTM Implementation Guide versions across studies created challenges in standardization and traceability during ADaM specifications development. Key variables including demographics and baseline characteristics such as age, sex, education, genotype, and clinical scores had to be consistently derived and validated across studies. Maintaining traceability was critical, with define.xml playing a key role in documenting transformations and assumptions.

At the same time, missing and inconsistent data remain inherent challenges. In the natural history cohort example, gaps in timepoints and patient coverage, limited direct comparability with the treated trial arm. Programmers addressed this by defining analysis windows and deriving aligned time variables, enabling more meaningful longitudinal comparisons. However, such adjustments introduce assumptions that must be clearly justified and documented in specifications and Reviewers guide.

ECA analyses also rely heavily on advanced statistical techniques, including propensity score matching, weighting, and longitudinal modelling. These methods can be computationally intensive, particularly when working with multiple heterogeneous datasets. In one case study, certain models required several hours to run for a single output, directly impacting timelines for quality control and iterative revisions.

As a result, programmers must optimize code for long-running processes, manage runtime constraints, and ensure reproducibility across environments. For example, when generating figures based on many simulations (e.g., 500,000 iterations), a single output could require several hours of execution time. To improve efficiency, figure generation was separated into independent programs rather than being combined within a single workflow, which significantly reduced total runtime. Similarly, validation procedures for computationally intensive simulations were performed in a staged manner, starting with smaller sample sizes and progressively increasing to the full scale, allowing for earlier detection of discrepancies, while minimizing unnecessary computational cost. In addition, parallel execution strategies were employed, with multiple programmers running processes concurrently, further reducing overall turnaround time.

Furthermore, the inherent uncertainty in external data typically necessitates multiple sensitivity analyses, requiring flexible and efficient programming workflows.

 

Operational constraints and regulatory expectations

Beyond technical challenges, ECAs introduce operational complexities. External datasets are often subject to strict privacy and governance requirements, with analyses conducted in secure or third-party environments. These constraints can limit direct data access, slow iteration cycles, and introduce additional layers of review and approval.

Programmers must therefore adapt to restricted computing environments, limited data visibility, and evolving access rules, all of which require careful planning to maintain timelines.

At the same time, regulatory expectations remain high. While agencies are increasingly open to ECAs, they require strong evidence of data quality, bias mitigation, and endpoint consistency. From a programming perspective, this places significant emphasis on transparency and documentation.

All transformations and analytical decisions must be fully traceable and clearly justified, including mapping approaches, imputation methods, endpoint derivations, harmonization decisions, and sensitivity analyses. Well-structured documentation is therefore as critical as the datasets themselves in supporting reproducibility and regulatory review.

 

Final takeaways

The development of ECAs extends far beyond data integration. It requires a structured and methodical programming approach to ensure consistency, traceability, and regulatory readiness.

The case studies highlight that successful ECA implementation depends not only on methodological rigor but also on the quality of data preparation and standardization. Early harmonization, robust documentation, and flexible programming frameworks are essential to delivering reliable and submission-ready results.

As ECAs continue to gain traction, programming plays a central role in bridging diverse data sources and generating credible evidence for regulatory decision-making. Despite the availability of industry white papers and broader guidance on observational data standardization, dedicated standards and detailed guidance specific to ECAs remain limited, highlighting the need for continued collaboration and development in this area.

 

Interested in learning more?

Join Gautham Selvaraj, Ralf Koelbach, and Steven Ting for their upcoming webinar, “Implementing External Control Arms in a Rare Disease Case Study” on April 30 at 10 am ET, where they will offer practical insights and experience-based strategies for implementing ECAs with real-world data:

Rethinking Evidence in Rare Disease Research: A Case Study Using Propensity Score Methods

Rare diseases pose unique challenges for researchers and clinicians. Due to small patient populations, conducting randomized controlled trials (RCTs) is often impractical or ethically difficult. As a result, observational data becomes a key source of evidence.

In the landscape of rare disease, data is both our most precious resource and our greatest challenge. For conditions like Infantile-Onset Pompe Disease (IOPD), the journey from the first life-saving Enzyme Replacement Therapy (ERT) to the next generation of optimized treatments is rarely a path free of challenges. It is a path marked by small patient populations, high clinical variability, and the heavy weight of every data point.

The difficulty in rare disease research often lies in the “how”: How do we prove a new therapy is truly superior when baseline functional levels vary so wildly? How do we ensure that a single data entry error doesn’t mask a breakthrough or suggest a false decline?

In this blog, we explore how propensity score methods can be used to estimate treatment effectiveness in a rare disease setting through a real world–inspired case study.

In this case study, we pull back the curtain on the analytical rigor required to compare motor function trajectories in IOPD. From Propensity Score Matching to “red-flag” data auditing, we explore how sophisticated analysis turns fragmented data into a clear roadmap for the future of neuromuscular treatment.

 

Case study: Advancing motor function outcomes in IOPD

The evolution from first-generation drug to next-generation drug

Infantile-Onset Pompe Disease (IOPD) is a rare, progressive neuromuscular disorder. While the first generation of ERT revolutionized survival, the quest for superior motor function remains the “North Star” for researchers. This study compares longitudinal motor outcomes between the First-Generation Drug and Next-Generation Drug cohorts using the Gross Motor Function Measure (GMFM-88).

 

The challenge: Comparing across clinical trials

Comparing results from different studies requires more than just looking at averages; it requires accounting for the inherent variability in how patients present at baseline. To test the hypothesis that the Next-Generation Drug offers a superior motor trajectory, we implemented a rigorous three-tier analytical approach.

 

A three-tier analytical approach

1. The power of precise matching

To ensure an “apples-to-apples” comparison, we restricted the analysis to patient pairs matched by both age and baseline functional level.

  • The criteria: Matches were strictly filtered to those within a +/- 13-point window of the GMFM-88 raw score (rather than a percentage).
  • The goal: By tightening these parameters, we eliminated “baseline noise,” allowing the true pharmacological impact of the treatment to surface in the longitudinal graphs.

 

2. Data integrity: Investigating the “jumps and drops”

In rare disease registries, a single data point can skew an entire trajectory. Our team conducted a “deep dive” into five specific patient profiles that exhibited extreme volatility — marked by sharp drops or vertical jumps in scores.

Expert insight: A drop to zero isn’t always a clinical decline; often, it’s a data entry artifact where a missing value was defaulted to ‘0.’ By identifying and correcting these anomalies, we ensure the motor trajectory reflects biology, not a spreadsheet error.

 

3. Sophisticated balancing: Propensity Score Matching (PSM)

Propensity score methods help simulate a randomized experiment by balancing observed characteristics between treated and untreated groups.

To further validate our findings, we moved beyond simple matching to Propensity Score Matching. This statistical technique allows us to predict a patient’s likelihood of being in a specific treatment group based on their baseline characteristics, effectively “balancing” the two groups.

 

Key covariates included:

  • Baseline status: Age and GMFM-88 total raw score.
  • Clinical history: Age at diagnosis and age at start of ERT.
  • Biological markers: CRIM status (Cross-Reactive Immunologic Material) and LVMI (Left Ventricular Mass Index) z-scores.
  • Treatment variables: Specific enzyme dosage levels.

 

Why this matters for the rare disease community

This case study demonstrates that in the world of rare diseases, how we analyze data is as important as the data itself. By correcting for entry errors and using high-fidelity matching, we can more clearly see if the next-generation drug truly provides the “superior trajectory” hypothesized.

 

Precision analytics as a catalyst for care

By applying high-fidelity matching and propensity score modelling, we move beyond “average” results to understand the true potential of new interventions. Furthermore, our dedication to data integrity — manually investigating anomalies and “red-arrow” outliers — ensures that our conclusions are built on a foundation of clinical reality rather than administrative error.

Ultimately, this study reinforces that in the fight against rare diseases, data is our most powerful ally. When we refine our lens through rigorous matching and clean data, the path toward better motor function and brighter futures for IOPD patients becomes clearer than ever.

A Preview of Cytel’s Contributions at PHUSE EU 2025

I can’t believe it has already been a year since we wrapped up PHUSE EU Connect 2024, and in two weeks we will be gathering another exciting PHUSE EU Connect conference, only a few kilometers from Heidelberg, where everything started twenty years ago with the very first PHUSE event. I was one of the couple hundred lucky attendees and now, twenty years later, I have the great honor of supporting Jennie McGuirk and Jinesh Patel as Conference Co-chair for this year’s edition.

With a promising agenda featuring about 190 presentations, 34 posters, 9 hands-on workshops, 2 panel discussions, and 3 inspiring keynote speakers, this year we are going to the city of Hamburg for the 21st PHUSE EU Connect. The agenda is full of topics looking toward the future, with about 40 talks and posters referring to AI in their titles, and once again open source will be the confirmed leitmotif.

Cytel will make a significant contribution this year, perhaps more than ever, with six presentations, one poster, active participation in both panel discussions, and co-chairing the “Scripts, Macros and Automation” and “People Leadership & Management” streams.

 

Monday topics: Agile code writing, extracting metadata from R OOP functions, and leadership

The week kicks off on Monday with Kamil Foltynski, who will present “Overcoming Challenges in Collaborative Spreadsheet Editing with Shiny, SpreadJS and JSON-Patch” in the Application Development stream at 11:30 am. Kamil will provide a technical deep dive into enabling real-time spreadsheet editing within Shiny applications, using tools such as SpreadJS, sharing key lessons learned so far. Following Kamil’s presentation, Eswara Satyanarayana Gunisetti, will present “Micro-Decisions, Macro Impact: The Role of Agile Thinking in Every Line of Code” in theCoding Tips & Tricks” stream at 12 pm. See his recent blog on the topic. Eswara will share how an agile “mindset” can positively influence the way we write code.

In the same stream, a few hours later at 2 pm, another colleague Edward Gillian, in collaboration with Sanofi, will present “Risk.assessr: Extracting OOP Function Details,” discussing strategies for extracting metadata from R Object-Oriented Programming functions. Prior to Eswara and Edward’s sessions, at 1:30 pm, Kath Wright, will moderate the Interactive People Leadership & Management session “Invisible Glue: Trust, Influence and The Architecture of Teamwork.” With this live workshop, attendees will engage in practical exercises to learn how to identify barriers to trust, evaluate influence dynamics, and apply evidence-based strategies to strengthen collaboration in both physical and virtual environments.

 

Tuesday topics: Industry trends, extracting macro usage and dependency information from SAS programs, and integrating ECA data into CDISC-compliant datasets

Tuesday also brings two presentations and one poster. Right after lunch at 1:30 pm, Cedric Marchand will join other industry leaders in the panel discussion “Reimagining Statistical Programming: AI, Standards & the Talent of Tomorrow.” The panel will explore how current industry trends, such as AI, open source, and the evolution of data standards, will influence the next generation of statistical programmers.

The afternoon continues at 4 pm with my young and talented colleague Marie Poupelin, who will present “From Zero to Programming Hero: How Internships Shape Statistical Programmers in a CRO” in the “Professional Development” stream. Marie is a great example of the success of our internship program, and she will share her journey from having “zero” statistical programming experience to becoming an industry-ready programmer. Thirty minutes later, at 4:30 pm, Guido Wendland will present “Which Macros Are Used in the Study?” in the “Scripts, Macros and Automation” stream, a stream co-led this year for the first time by my colleague Sebastià Barceló. Guido will discuss techniques to extract macro usage and dependency information from SAS programs; this is particularly useful for identifying potential issues or estimating the impact of macro updates.

Later, in the traditional Tuesday evening poster session, you can join my colleague Cyril Sombrin in discussing “Our Journey in Integrating External Control Arms (ECAs) and RWD for Rare Disease Trials.” There you can discuss real-world case studies on integrating ECA data into CDISC-compliant datasets, exploring the unique challenges and solutions when aligning real-world data with CDISC standards.

 

Wednesday topics: Real-time spreadsheet editing within Shiny applications and real-time validation and streamlined submissions

On Wednesday at 12 pm, Hugo Signol, another young talented Cytel statistical programmer and a product of our internship program, will present his talk “From XPT to Dataset-JSON: Enabling Real-Time Validation and Streamlined Submissions.” Building on Cytel’s experience from CDISC Dataset-JSON-Viewer Hackathon, Hugo will demonstrate a Shiny application that supports interactive exploration and real-time validation through API-based checks.

 

Meet us there!

Cytel will be at Booth 9 at the conference, where you can engage in discussions with our team or meet any of us throughout the week.

I hope I didn’t miss anyone, or anything! We look forward again to reuniting with colleagues and friends from around the world and meeting new acquaintances.

See you all in Hamburg!

Micro-Decisions, Macro Impact: Cultivating an Agile Mindset in Every Line of Statistical Code

Statistical programming is a cornerstone of clinical research, converting raw data into the standard datasets, tables, listings, and figures (TLFs) that support decision-making, regulatory submissions, and publications.

Traditional workflows often limit collaboration, adaptability, and early input from programmers. As timelines shrink and expectations grow, it’s clear that a new way of thinking is needed, one that goes beyond efficiency, and into adaptability, collaboration, and value creation.

In clinical statistical programming, agility isn’t only about sprints or ceremonies, it starts with the smallest choices we make at the keyboard.

 

Every day, statistical programmers make hundreds of tiny decisions such as

  • How to name a variable
  • Design a macro
  • Structure a dataset

Most of these choices happen quietly, almost on autopilot. Yet together, they define

  • How flexible our studies are
  • How easily we can adapt to change
  • How smoothly teams can collaborate.

 

These small choices (micro-decisions), multiplied across teams and studies, drive what I call a macro impact.

 

Agility at the code level

Agile thinking refers to building programs with change in mind, favoring adaptability over perfection, and prioritizing clarity and consistency over clever shortcuts. These ideas might sound subtle, but together, they create the difference between rigid code and resilient code.

Programmers can apply agile thinking directly at the code level, through clarity, simplicity, adaptability, and value orientation.

Habits like intentional naming, smart commenting, modular macros, and built-in quality checks make code more resilient and teams more responsive to change.

 

Agility at the code level shows up in many subtle but powerful ways:

  • Intentional naming makes programs self-explanatory and audit ready.
  • Smart commenting tells the why, not just the how.
  • Scalable macros turn adaptability into a default setting.
  • Readable structures make collaboration effortless.
  • Built-in quality checks turn QC from a final gate into a shared rhythm.

 

When practiced consistently, these habits turn teams into systems that learn, adapt, and deliver faster with accuracy and compliance.

 

Thinking differently

This isn’t about doing more; it’s about thinking differently while doing what we already do.

Proven models like Kaizen and Toyota Lean philosophies manifest that, through continuous improvement with a culture of cooperation and eliminating waste, we can deliver maximum value to the customers by sticking to the existing process and not letting go of what we have already learned. Through the lens of these philosophies, we see how small enhancements in daily programming can scale major gains in collaboration, reuse, and efficiency.

 

Final takeaways

Code is communication. Every variable, macro, and comment is a message to a collaborator, a regulator, or your future self.

Let every line you write carry clarity. Let every structure you build invite change. Let every decision reflect agility. That’s the path from micro-decisions to macro impact.

 

Interested in learning more?

Eswara Gunisetti will be at PHUSE EU Connect 2025 to present “Micro-Decisions, Macro Impact: The Role of Agile Thinking in Every Line of Code.” Discover how every line of code can contribute to a more adaptive, transparent, and rewarding way of working, where agility lives not just in our processes, but in our programming decisions themselves.

Register below to book a meeting or visit Booth 9 to connect with our experts:

Streamlining Data Management and Improving Statistical Accuracy in Clinical Trials with AI

As clinical trials grow increasingly complex, the need for smarter, faster, and more efficient data processes and analysis is in demand. Artificial intelligence (AI) emerges as a powerful tool, especially in programming and data management. For clinical trial professionals, AI offers the promise of streamlining workflows, improving data quality, and reducing time to database lock.

 

The evolving role of AI in clinical data programming

AI is not replacing clinical programmers; it’s augmenting them. AI should be considered a tool to use within clinical trials, just as EDC and SAS are commonly used tools. Automation tools driven by machine learning can now handle routine, rules-based programming tasks such as edit check generation, derivation logic, and data transformation. This allows programmers to focus on more strategic activities like validating statistical code or optimizing data pipelines. AI needs the expertise of our clinical trial professionals.

Natural Language Processing (NLP) is also making great progress. For instance, NLP can interpret free-text protocol documents to auto-generate specifications, electronic case report form (eCRF) templates, or even suggest initial SDTM mappings, significantly reducing manual effort.

 

AI in data cleaning and quality oversight

Traditionally, data cleaning has been labor-intensive, with data managers manually reviewing queries, data listings, and edit checks across multiple data sources and systems. AI tools can now proactively flag anomalies or data trends that human review might miss, such as unexpected patterns in lab values, inconsistencies across visits, or possible fraudulent data across participants and sites.

Predictive models can help identify study participants at high risk of dropout or noncompliance, enabling earlier intervention. This not only improves data completeness but also enhances trial efficiency and participant retention. The effort and cost of replacing clinical trial participants is significant and felt across all stakeholders. Improving the patient’s experience would be a significant way to save time, money, and accelerating progress.

 

AI in statistical programming: From code automation to advanced insights

Statistical programming is central to clinical trial analysis from producing tables, listings, and figures (TLFs) to preparing submission-ready datasets. Traditionally reliant on manual coding in SAS or R, this work is now gaining speed, consistency, and quality through AI augmentation.

 

Where AI adds value in statistical programming

  • Automated code generation: AI models trained on historical programming logic can produce initial SAS macros or R scripts for common TLFs and dataset derivations. These drafts accelerate development by up to 40–60%, freeing programmers and biostatisticians to focus on complex analyses and interpretation.
  • Code review and validation: AI-assisted tools can scan code for logic errors, inefficiencies, redundant steps, and deviations from programming standards. Acting as a “second reviewer,” they flag potential issues early and suggest optimizations.
  • Dynamic statistical modeling: AI algorithms can rapidly explore large trial datasets to detect subgroup effects, anomalies, or emerging trends. When guided by statistical oversight, these insights can refine analysis plans and support adaptive trial decisions.

The aim is not to replace human judgment, but to boost productivity, reproducibility, and the speed of insight generation, without compromising scientific rigor.

 

AI in biostatistics: Powering smarter, more adaptive clinical trials

 Biostatistics remains the foundation of evidence generation in clinical trials, providing the methodological rigor to transform raw data into reliable conclusions. In the context of AI, biostatisticians play a dual role: safeguarding scientific validity while leveraging new computational tools to enhance insight generation. This requires a careful balance between deep domain knowledge and technical proficiency in emerging AI-driven methodologies. From applying knowledge graphs (KGs) to map complex biomedical relationships, to developing predictive models that anticipate trial outcomes, biostatistics is evolving into a more dynamic and interconnected discipline.

 

Where AI adds value in biostatistics

  • Balanced expertise: Integrating statistical theory with AI/ML techniques to ensure robust, interpretable results.
  • Knowledge graph applications: Using KGs to uncover hidden relationships between biomarkers, treatments, and outcomes, supporting hypothesis generation and trial design.
  • Early prediction tools: Building predictive models for recruitment success, dropout risk, and endpoint achievement.
  • Segmentation and personalization: Identifying patient subgroups most likely to benefit from a therapy, improving trial efficiency and precision medicine strategies.
  • Support for registrational trials: Leveraging AI to optimize trial design, stratify patient populations, and run simulations that ensure the study is powered and structured for regulatory success.

 

Regulatory readiness and caution

Despite its promise, AI must be implemented thoughtfully. Regulatory agencies like the FDA are increasingly open to the use of advanced technologies but expect transparency, traceability, and validation. AI-based tools must be auditable and explainable, especially when used in clinical data workflows that feed into regulatory submissions.

 

What’s next?

As AI becomes more embedded in clinical trial ecosystems, we can expect increased integration with EDC systems, CDISC standards, and statistical programming tools. The goal isn’t to eliminate human oversight but to enhance it, allowing clinical data professionals to make faster, better-informed decisions.

 

Final takeaways

AI is reshaping programming and data management in clinical trials. For clinical trial professionals, now is the time to become familiar with these tools, understand their capabilities and limitations, and engage with cross-functional teams to ensure responsible and impactful implementation. Ultimately our goal is to shorten drug development timelines and improve patient outcomes. With AI, we can be part of the solution to provide improved treatments for patients.

 

Interested in learning more?

Join Steven Thacker, Sheree King, Kunal Sanghavi, and Juan Pablo Garcia Martinez for their upcoming webinar, “How AI Enhances Biometrics Services: Streamlining Data Management and Improving Statistical Accuracy in Clinical Trials” on Thursday, August 28 at 10 am ET:

Moving to Agile: A New Approach to Statistical Programming

Prior to recent advances, traditional software development processes have been characterized by rigid methods that required teams to follow pre-defined processes. However, the advent of Agile programming revolutionized traditional development processes by shifting the focus to flexibility, collaboration, and continuous improvement. Unlike traditional methods, Agile embraces change and enables teams to respond quickly to new requirements.

Now, the Agile approach has moved from software development into statistical programming, allowing teams to work in small increments rather than following a linear, pre-planned process. Instead of extensive upfront planning, Agile encourages adaptability and frequent reassessment of project goals.

Here, I discuss Agile methodologies, the benefits and challenges, and invite readers to learn more with our new case study on implementing Agile and Scrum for SAS programming in clinical development.

 

What is Agile programming?

Agile is an iterative project management and development approach that prioritizes flexibility, collaboration, and responsiveness to change. Though originally developed for software engineering, Agile has since gained widespread adoption across various industries, including healthcare and clinical research.

At the heart of Agile is the concept of breaking down complex projects into smaller, manageable units of work, called “sprints,” typically lasting one to four weeks. At the end of each sprint, the team delivers a functional product increment, ensuring continuous feedback and the ability to adjust course as needed.

Key tenets of Agile in statistical programming include:

  • Prioritizing individuals and interactions over processes and tools to foster teamwork and effective communication.
  • Prioritizing customer collaboration over contract negotiation to involve stakeholders throughout the process.
  • Prioritizing responding to change over following a plan to support remaining flexible to evolving needs.

These tenets support incremental delivery of outputs, frequent feedback loops to all programmers, and overall team collaboration.

 

Benefits of Agile programming

Agile methodologies offer numerous additional advantages, making them a preferred choice for modern development teams:

 

Faster delivery times

Agile focuses on small, manageable iterations (sprints), allowing teams to release interim deliverables frequently rather than waiting for the entire product to be complete.

 

Higher customer satisfaction

Continuous delivery and ongoing stakeholder involvement ensure products align with user needs, leading to better adoption and positive feedback.

 

Reduced risk of project failure

By regularly assessing project goals, teams can detect potential issues early and make adjustments before they become costly problems.

 

Agile methodologies

Agile methodologies come in different flavors, each tailored to unique team dynamics and project needs.

 

Scrum

Scrum is one of the most widely used Agile frameworks. It divides development into short cycles called sprints (typically 2 weeks), during which teams work on prioritized tasks. Scrum incorporates daily stand-up meetings and reviews to track progress and remove obstacles.

 

Kanban

Kanban is a visual workflow management system that emphasizes continuous delivery. Teams use a Kanban board to track tasks in various stages (To-Do, In Progress, Completed), ensuring transparency and limiting work in progress to prevent bottlenecks.

 

XP

XP focuses on high-quality development practices like test-driven development (TDD) and continuous integration (CI). It encourages pair programming and frequent code reviews to enhance software quality.

 

Challenges to adopting Agile

While Agile offers many benefits, teams may face challenges when adopting Agile practices. Rapid development cycles can lead to frequent scope changes, making it hard to maintain focus. This can be avoided by clearly defining priorities and using backlog refinement sessions to keep scope manageable.

Additionally, Agile relies heavily on collaboration, but without proper communication, misunderstandings can arise. Strategies for preventing this include encouraging daily stand-ups, using standard project management tools, and fostering a culture in which open commentary is encouraged.

Finally, transitioning to Agile can be difficult, especially in organizations accustomed to traditional methods. But a gradual approach to this new methodology is warranted: provide Agile training, start with pilot projects, and celebrate early wins to build confidence.

 

Final takeaways

Agile programming is more than just a methodology — it’s a mindset that promotes adaptability, efficiency, and collaboration. By embracing Agile, teams can deliver high-quality software faster while continuously improving their processes. Whether you’re a startup or an enterprise, adopting Agile can lead to better productivity and customer satisfaction.

 

Interested in learning more?

Download our new white paper that provides a detailed case study on implementing Agile and Scrum for SAS programming in clinical development.

Expediting the Regulatory Submission Process with Automated Tools

In the biopharmaceutical industry, expediting regulatory submissions is crucial for timely access to life-saving medications. As a statistical programming team, our role involves accelerating the drug approval process by meticulously preparing Electronic Common Technical Document (eCTD) packages, including the statistical review and programming process of mapping SDTM, deriving ADaM, and TLF generation.

Here we discuss the process and benefits of the metadata-driven approach. From mapping to report, this approach enhances the efficiency in attaining results and generating submission packages promptly by reducing manual interventions.

 

What are eCTD packages and how are they prepared?

The eCTD is the “standard format for submitting applications, amendments, supplements, and reports to FDA’s Center for Drug Evaluation and Research (CDER) and Center for Biologics Evaluation and Research (CBER).”1 It facilitates the electronic submission of dossiers for market approval requests, such as for a new drug (NDA).

Among files stored in the eCTD, there are some key components related to Biometrics deliverables:

  • SDTM Dataset: The Study Data Tabulation Model (SDTM) is one of the most important CDISC data standards. It’s a framework used for organizing source data collected in human clinical trials.
  • ADaM Datasets: Analysis datasets are created to enable statistical and scientific analysis of the study results. CDISC Analysis Data Model (ADaM) specifies the fundamental principles and standards to ensure that there is clear lineage from data collection to analysis.
  • TLF: Analytical outputs, in the form of tables or figures, are used to summarize the analysis required for the submission to the regulatory agencies. These outputs are supported by listings that display the actual data at all the data points.

 

The need for automation

When working on any project / analysis, certain elements remain unchanged regardless of the study design. Therefore, standardizing and automating their production could lead to efficiency, ensuring consistency, and reduce the overall time required for submission. Also, by automating these items, we could reduce manual intervention, thereby minimizing the chances of human error.

This approach has several benefits, including:

  • Efficiency: Since the team can focus more on the non-standard parts of the outputs, the overall efficiency of the team is increased.
  • Consistency: Since automated tools generate standard code based on a set of rules, the resulting code remains highly consistent across various projects. This makes it easier to understand and debug (in case of any updates).
  • Quality: Since the tools have been rigorously tested, they produce extremely high-quality and reliable outputs.
  • Reduced manual intervention: Since manual intervention is limited, the possibility of human error is minimized. As long as the specifications are correctly drafted, the output generated by the standard code should be error-free.

A metadata-driven approach

Many companies, including Cytel, have adopted a metadata-driven approach to accelerate tasks such as SDTM, ADaM, and TLF code generation. The goal of this approach is not to automate 100% of the final code but rather to generate as much standardized and structured code as possible. This approach enhances efficiency while simplifying modifications when needed.

While a Metadata Repository (MDR) can maximize automation in the long run, currently available MDR tools remain cumbersome.2 For this reason, while still assessing the benefit of MDR solutions, Cytel has taken a different approach — extracting metadata from existing documents that statistical programmers already use in their daily work. Without adding extra workload, this metadata is stored in a structured format, allowing us to apply automated rules to enrich it. From there, we can generate SDTM, ADaM, and TLF code efficiently.

For example, metadata can be extracted from ODM.xml files or raw datasets to streamline SDTM specification mapping. These specifications can then be leveraged to generate SAS or R code automatically. Similarly, metadata from study mock shells — such as titles, footnotes, table headers, and table body structure and content — can drive the creation of TLFs with minimal manual intervention.

Another key advantage of this metadata-driven approach is its language agnosticism. By structuring metadata independently of the programming language, the same metadata can be used to generate both SAS and R code. This ensures consistency, facilitates the transition for SAS programmers moving to R, and maintains quality without impacting project timelines.

 

Final takeaways

In line with the premise that “one solution does not fit all,” CROs can maximize the value of metadata within clinical trial delivery by leveraging the metadata already embedded inherent in study artifacts. If you are able to define the way of extracting as much metadata as possible from the documents you already use, you can obtain a lot of value if you are able to transform that metadata into real deliverables.

This metadata-driven approach is sensitive to the fact that CROs must accommodate a multitude of sponsor standards and delivery requirements, without sacrificing the benefits of automation in an ecosystem rich in interdependencies between regulatory authorities, industry consortia, sponsors, CROs, and other third-party technology vendors.

 

1 US FDA. (4 October, 2024). Electronic Common Technical Document (eCTD).

2 PHUSE White Paper (2 October, 2024). Best Practices in Data Standards Implementation Governance.

 

Interested in learning more?

Watch Manish Deole and Sebastià Barceló’s on-demand webinar, “Expediting Regulatory Submissions through Automation”:

AI’s Influence on SAS Programming

The advent of Artificial Intelligence (AI) has transformed numerous fields, and the domain of SAS (Statistical Analysis System) programming is no exception. From automating tedious tasks to enhancing decision-making processes, AI has made significant inroads into how SAS programmers work.

However, AI is not a substitute but a companion to programmers. While AI can help us focus our critical thinking, creativity, and problem-solving skills, AI needs our expertise. Domain expertise is still essential.

To understand this transformation better, here we explore key ways AI has impacted SAS programming, particularly by comparing skills of traditional to AI-assisted programming, examining the days before and after AI, and discussing the new responsibilities and skills required in the modern programming landscape.

 

Traditional SAS programming vs. AI-assisted SAS programming

Traditional SAS programming has long been a manual, code-intensive practice requiring a high level of expertise in statistical analysis and programming. In the earlier days, SAS programmers worked with well-defined, often repetitive tasks. The process of developing code required a deep understanding of the data and statistical methodologies, all while meticulously debugging and quality-checking code.

AI-assisted SAS programming introduces a new level of efficiency, allowing programmers to focus more on value-added tasks rather than repetitive work. Traditional SAS programming workflows are now supported by AI-driven automation tools that can generate code, optimize algorithms, and even offer suggestions for complex statistical analyses. For example, where traditional methods would require a programmer to sift through data to find patterns, AI can now analyze large datasets in seconds and offer insights that help in decision-making. This allows the SAS programmers to focus on more strategic and high-level interpretations.

In essence, the role of the SAS programmer is evolving from being a “code generator” to a “code curator” and they maintain control over every step, providing deep customization and understanding of the entire process.

 

AI as a companion, not a substitute

The fear of AI replacing jobs has become a common narrative, but in the case of SAS programming, AI should be viewed as a companion rather than a replacement. While AI can optimize code, automate reporting, or even suggest corrections, it is still far from replacing the creative and analytical skills of programmers. AI systems can generate insights based on patterns within datasets, but understanding the nuances of those patterns and making informed decisions based on them remains a unique programmer’s skill.

SAS programmers have a deep understanding of the data they work with, including the context, limitations, and real-world implications of their findings. While AI can handle the heavy lifting in terms of data processing and analytics, the role of the programmer is to interpret these findings, cross-check their accuracy, and ensure the outputs are aligned with business goals or research questions.

Additionally, AI’s suggestions aren’t always perfect, especially when dealing with edge cases or complex datasets with nuanced relationships. In such scenarios, a programmer’s oversight is crucial to prevent AI-driven errors from propagating throughout the analysis.

 

Before and after AI

The landscape of SAS programming before the integration of AI was characterized by manual coding, exhaustive debugging processes, and labor-intensive quality control procedures. Let’s break down the key changes AI has brought to these areas:

 

Code development

Before AI, coding was manual and depended heavily on a programmer’s syntax knowledge and experience to ensure that the code adhered to best practices for efficiency and performance. This could be a time-consuming process, especially when dealing with large, complex datasets.

In the post-AI era, code development is becoming more efficient through AI-assisted coding tools. These tools can automatically suggest code snippets based on previous coding patterns or even generate entire blocks of code tailored to the dataset. AI-driven auto-complete features and advanced libraries that recommend the best statistical models or data manipulation techniques have significantly sped up the development process.

 

Debugging

Debugging used to be a meticulous and painstaking part of the SAS programmer’s job. Identifying errors in code or incorrect outputs is often required by going through large blocks of code line by line, manually reviewing logic and syntax.

AI has revolutionized debugging by identifying errors in real time, suggesting fixes, and even automatically correcting syntax errors. AI tools can also track changes in code and predict where potential issues might arise based on past errors, significantly reducing debugging time and enhancing code accuracy.

 

Quality control (QC)

Before AI, the QC process was often manual or semi-automated, prone to missed errors, and involved peer reviews, statistical validations, and rigorous testing to ensure that the code met the necessary standards. This was particularly important in industries such as healthcare or finance, where data accuracy is critical.

Today, AI-driven QC tools can automatically verify the integrity of datasets, flag inconsistencies, and ensure that statistical models meet predefined accuracy thresholds. These tools can run tests much faster than human reviewers, allowing for quicker validation cycles and better compliance with industry standards.

AI doubles productivity, without replacing the need for programmer’s intuition and expertise, so we can opt for other developmental activities like enhancing the client outcomes, learning new skills, and mentoring to strengthen the overall team.

 

New responsibilities and skills for SAS programmers in the AI age

New responsibilities and skills required for AI platforms

  • To understand how to work along with AI tools
  • To adopt AI-driven workflows for faster development cycles
  • To learn to guide and review AI-generated code
  • Additional skills like data literacy, critical thinking, and ethical AI considerations are also required

 

Industry AI tools

  • Tabnine: AI-powered code predictions
  • Snyk: AI-driven security checks
  • DeepCode: Real-time AI code review
  • SAS Viya: Integrate existing code with AI tools

 

Final takeaways

AI tools are transforming the role of SAS programmers, making them faster and more effective, but human expertise remains crucial in directing AI and ensuring high-quality outcomes. The future of programming likely lies in a hybrid approach that leverages both human expertise and AI-driven efficiencies.

 

Interested in learning more about AI in clinical development? Watch our recent webinar: