By: Steven Nicholas, Director, Analytics Engineering
Clinical analytics is changing. The static tables, listings, and figures that once marked a statistical programmer’s finish line are giving way to interactive applications that let stakeholders explore data in near real time. For directors and VPs deciding whether or not to introduce that capability, and specifically Shiny app development — either in house or through a partner — the hesitation primarily revolves around risk.
Does adopting Shiny mean ditching the governance, traceability, and rigor your team has spent years perfecting? No. The discipline that produces a smooth submission is the same discipline that produces a sustainable application.
The process matters more than the tool
Picture a safety reviewer who spots an emerging trend and needs to pivot from a high-level summary to a patient-level view, filtering on the spot. A static report cannot facilitate the answer. In a traditional workflow, that request starts a new programming cycle and a multiday wait. An interactive application answers it in seconds, with the capability to drill down as needed.
That capability is an extension of statistical programming, not a replacement. The software development life cycle that governs modern analytics development is the same structured discipline that clinical teams have been practicing for decades, just under different names. Recognizing that is what turns a hesitation into a clear next step.
A one-to-one mapping to a familiar workflow
Every stage of building a Shiny application has a direct analog in the workflow your programmers run today:
- User stories and feature requirements do the work of the statistical analysis plan (SAP), defining who needs the information, what they need to do with it, and why, before a single line of code is written
- Wireframes serve as mock shells, a visual contract agreed before development begins, when changing direction still costs hours, not weeks
- Technical specifications and data models carry the role of ADaM specifications and Define.xml, mapping how data moves from source to interface, so every value stays traceable
- Iterative review cycles mirror dry runs and interim analyses, structured checkpoints that catch problems before release instead of after
- Automated testing and code review extend independent QC programming, continuously verifying that new features have not broken validated logic
Where the risk is hiding
The risk in interactive analytics is skipping the discipline, not the technology itself.
In one data quality review application, a team spent three weeks building core functionality before stakeholders communicated their actual requirements, from landing page layout to how data listings should appear on hover. The required changes were more than cosmetic. Each came with downstream consequences for data architecture and navigation logic. A single wireframe session before development began would have identified all of it.
The same lesson transfers across the life cycle. Well-maintained technical specifications and continuous testing are what keep these tools compliant as they evolve. Traceability becomes nonnegotiable the moment an application gains write access and sends data back to an EDC system, because every transformation and decision point becomes part of the audit trail. A regulatory reviewer who expects a clear path from raw data to output will expect that from an interactive application too.
The evidence is public
Through the R Consortium R Submissions Working Group, cross-industry teams have submitted R-based packages, including Shiny applications, to the FDA through the electronic Common Technical Document gateway, with all materials made publicly available as reference examples.1 And the agency’s statement is clear. The FDA Statistical Software Clarifying Statement confirms it does not require any specific software for statistical analyses, as long as the packages that are used are fully documented, including version and build identification.2
Open-source tools like R Shiny are not a roll of the regulatory dice. They are a proven path, and the sponsors already adopting them are pairing Shiny dashboard capability with the validated statistical computing environment their submissions have always required.
Evolution, not reinvention
The convergence of statistical programming and software development is already underway. Roles are evolving, and your team’s experience is needed to make it widely adopted. The foundation that makes interactive analytics trustworthy is the same one that makes your static outputs submission-ready.
View the paper “It’s a Wonderful Lifecycle: Translating Statistical Programming into Modern Analytics Development,” presented at PharmaSUG 2026, by Steven Nicholas.
Atorus™ helps clinical teams build interactive analytics on a foundation of clinical rigor, from Shiny app development and analytics engineering to out-of-the-box validation and statistical computing environment. Talk to Atorus about building interactive analytics.
Frequently asked questions
Does adopting Shiny mean giving up regulatory rigor?
No. The governance, traceability, and validation practices that produce a successful submission map directly onto software development. Wireframes serve as mock shells, technical specifications as ADaM specs, and automated testing extends independent QC. The discipline doesn’t change.
Have Shiny applications been submitted to the FDA?
Yes. The R Consortium R Submissions Working Group has delivered R-based packages to the FDA through the eCTD gateway, with one pilot delivering the same tables and figures using a Shiny app created in R. All materials are publicly available as reference examples.
Should sponsors build interactive analytics in house or with a partner?
Both are viable. A partner with clinical analytics and analytics engineering experience can extend a disciplined software development, while your team maintains oversight.
Is open-source software acceptable for regulatory submissions?
The FDA does not mandate any specific statistical software. It requires that the packages used are fully documented and validated, and open-source tools like R and Shiny have already been used in controlled, GxP-validated environments.
Steven Nicholas
Director, Analytics Engineering
Steven Nicholas is Director, Analytics Engineering at Atorus Research, where he leads global statistical programming FSP teams and the delivery of modern analytics capabilities for clinical development. A statistical programming leader with more than 14 years of experience, he has established and led high-performing teams that support clinical trials from early development through submission. With deep roots in SAS® and a commitment to innovation, he focuses on bringing open-source tools and modern approaches into clinical workflows.
References
1 R Consortium R Submissions Working Group. (2026). R Submissions Working Group: 2026 Plans and 2025 Success. R Consortium. https://r-consortium.org/posts/submissions-wg-2026/
2 U.S. Food and Drug Administration. (2015). Statistical Software Clarifying Statement. As reproduced by the R Validation Hub (pharmaR), Regulations page. https://pharmar.org/regulations/