How Pharma is Pioneering WebAssembly with webR for FDA Clinical Trial Submissions

Striving to improve clinical trial regulatory submissions.

In the not-so-distant past, submitting clinical trial data to the FDA for new medical treatments was a physical affair involving boxes of paper documents meticulously reviewed by hand. Today, the submission process has evolved, albeit with new challenges. The prevalent use of .pdf files, while a step up from paper, often results in unwieldy documents with tables sprawling across numerous pages. When regulators request revisions, the response can involve creating and resubmitting hundreds of new tables and figures.

And the reliance on proprietary software tools for these submissions has traditionally obscured statistical methodologies behind closed-source codebases and priced out many researchers. In response, there is an industry shift toward open-source tools, employing languages such as R, Python and JavaScript, and sharing analytics through interactive web applications like Shiny. These platforms enable visualization and interaction with substantial data sets, allowing stakeholders to explore and pose new questions directly with the data.

FDA leadership has long been vocal about the need for innovation in the submission process, advocating for methods that enhance efficiency and robustness. Janet Woodcock, Principal Deputy Commissioner of the FDA, has notably criticized the reliance on ‘Digitized Paper’, those pages of .pdf files, citing its detrimental effect on the pace of drug development.¹ However, FDA reviewers carry the weighty responsibility of making decisions that can be a matter of life or death. While adopting new practices may seem appealing, it’s not without its hurdles. For instance, using open-source software raises questions about the reliability of specific packages. Interactive tools can complicate reproducibility and may lead users to produce confusing or unreliable results.

The Submissions Working Group has pioneered the use of an R package and a Shiny application in their pilot submissions. These submissions, along with code, all data, and sponsor-reviewer correspondence, are shared on a public repository for others to learn from. ²

Nonetheless, the transition has not been seamless; the Shiny pilot, for example, required five pages of technical instructions, adding to the already complex task of FDA reviewers who must ensure that submissions comply with study-specific requirements. Whether you’re working with a regulator or just another colleague less familiar with your particular development stack, these complexities would ideally be abstracted away so they can focus on the data and analysis.

The Submissions Working Group has therefore looked at webR to help reduce the time and effort required to access these submission packages.

Image: Instructions to FDA reviewers to launch the pilot Shiny application in the Analysis Data Reviewer’s Guide

Pilot 4: An FDA clinical trial submission made with R, Shiny and webR.

WebR is a version of the open-source R interpreter compiled for WebAssembly. A Shiny application built with webR needs only a modern web browser to function. Users need not install software or configure their local machine, and it doesn’t even require access to an external server.

And other WebAssembly applications are used by millions across the internet. Alphabet’s Google Earth, the online versions of Adobe Photoshop and the video editing app CapCut are all written in WebAssembly. Figma, a popular website and app design tool, is also written with WebAssembly. ³

To this end, the Submissions Working Group is piloting the use of webR with the FDA, aiming to reduce the time and effort needed to engage with these analytical tools.

Like previous pilots, this submission is made transparently with publicly available data, facilitating an open dialogue with reviewers who may seek additional information or clarification. This open exchange is shared on a new public repo, including all correspondence between the submission team and the reviewers. All this is available for anyone to review at Pilot Four’s website, where you can learn from their example.

When is webR right for me?

Sharing reproducible scientific research with colleagues – whether at the FDA, just down the hallway or across the globe – poses a set of challenges.

A long list of dependencies may need to be installed, which in turn may depend on the operating system being used. End users may be unable or unwilling to install new software or reconfigure their local machines.

Researchers often share their analytics via web applications like those made with Shiny. These are traditionally hosted on servers that users access remotely. For each application researchers want to share, they must provision and continuously maintain a server. This can be quite costly & burdensome as the number of applications grows and dependencies age and are deprecated. And imagine if these researchers want their analysis accessible for as long as possible. And what if your end-user does not have consistent access to your external server?

Easier to get up and running. WebAssembly empowers users to engage with applications and their associated data and analyses without the burden of software installation. By simply accessing a webpage (or possibly just loading a file into the browser), reviewers can immerse themselves in the analytical process, bypassing the barriers of traditional software setup and configuration.

Cross platform. WebR runs seamlessly in web browsers, making it agnostic to the user’s operating system. Whether you’re working from a Windows PC, a Mac, or a Linux machine, the only prerequisite is a modern browser. Wasm also helps ensure that your applications produce computations in the exactly same way over time.

Security. And webR executes code within a sandboxed environment, minimizing security risks and offering users peace of mind that their local systems remain unharmed.

Finding the right balance between local and remote computation. WebAssembly applications provide developers with greater flexibility to offload compute tasks to client machines. Consider Adobe’s Photoshop online application; with so many users, handling even basic operations solely on Adobe’s servers would be expensive and may create a bad, laggy experience. Allowing client machines to handle most work reduces server load and provides a snappier experience by minimizing lag due to one’s network connection. Additionally, computationally complex tasks, like generative AI, can still be handled more efficiently on company servers. WebAssembly applications give developers greater freedom to finding the right balance between client and server-side computation.

George Stagg, senior software engineer at Posit, PBC, and maintainer of webR says, “The promise of WebAssembly with webR is that researchers can produce analytics with R & Shiny, place that onto a static repository like GitHub, and be as confident as is possible that any user will be able to get it up and running quickly on their browser. And it will be run in a decades’ time exactly the same way as it is today. That researcher doesn’t have to continuously maintain servers or worry about dependencies over that period.”

George Stagg, webR Maintainer

Posit’s George Stagg supports webR and the Submissions working group pilot in several ways.

He provides the web infrastructure for the default webR binary package repository. When one runs “library(ggplot2)” in webR, it downloads pre-compiled Wasm binaries from this CRAN-like repo. There are nearly 20,000 R packages on CRAN which have been compiled into Wasm, but many require diligent care to ensure they may be successfully executed.⁴ This work includes maintaining the webR content delivery network that allows webR to be embedded dynamically into web pages.

Stagg is also the lead developer on the webR core system. Besides maintaining webR, writing documentation, and examples; this involves deep exploratory infrastructure work not immediately visible. For example, check out his personal blog documenting his work helping ensure R packages that include Fortran are successfully compiled into Wasm, Fortran on WebAssembly

“There will always be use cases for traditional server-hosted Shiny, but for certain applications WebAssembly has its advantages. For self-contained apps where everything can be public, or delivering a Shiny app as part of research output, where reviewers or other users might struggle to get the environment set up. In those cases, producing a reproducible WebAssembly app that can be run locally or freely shared using static web services, without needing to maintain Shiny server infrastructure, is where webR and Shinylive really shines.”

George Stagg, webR maintainer and engineer at Posit PBC.

The promise of webR for clinical trial submissions is to offer FDA reviewers minimal friction. However, it’s important not to understate the challenges involved.

Converting a Shiny app into webR can be hard. Compiling packages to WebAssembly, unfortunately, isn’t always straightforward. While George Stagg and others have compiled most R packages on CRAN to Wasm, many have yet to be tested, and some will cause errors when used. Many packages have numerous dependencies, and diagnosing errors often requires walking back the dependency tree to find the specific package that isn’t working, and then either working around or resolving that issue.⁵

WebAssembly’s execution model places strong restrictions on how an application can use a user’s machine. It’s given access to compute power, but it’s a virtual environment and restricted when doing much else, especially for any kind of input/output. Therefore R packages to access the internet, like curl and httr2 are not currently compatible with webR.

WebR Shiny apps can feel slow to boot. The webR Shiny app used in Pilot 4 has loading times ranging from 1-3 minutes, with variation depending on the machine used and the speed of one’s internet connection. Stagg and others are working on speeding this up, and load times have significantly decreased in the past year, but there may not be much to be done in terms of app load times for webR. Stagg says, “R has a wonderful and expansive package ecosystem, but there’s no getting away from the fact that when you have many dependencies, you do need to download the binaries at some point if you’re running locally in Wasm.”

Although with the FDA submissions use case, webR may offer a significant improvement over the lengthy installation of R and its dependencies, it falls short of the instantaneity expected by users today from standard web applications.

WebR Shiny applications are unlikely to ever replace traditional server hosted Shiny app. Stagg says “There will always be use cases for traditional server-hosted Shiny, but for certain applications WebAssembly has its advantages. For self-contained apps where everything can be public, or delivering a Shiny app as part of research output, where reviewers or other users might struggle to get the environment set up. In those cases, producing a reproducible WebAssembly app that can be run locally or freely shared using static web services, without needing to maintain Shiny server infrastructure, is where webR and Shinylive really shines.”

How can I get started with webR & Shiny? How can I contribute to these projects?

Reach out to Posit’s Pharma Team. At Posit, we have a dedicated Pharma team to help organizations utilize open-source software for drug development. To learn more about our support for life sciences, please see our dedicated Pharma page where you can book a call with our team.

Get Involved with the Submissions Working Group. If you are keen to learn from the R Submissions Working Group’s example, we encourage you to review their pilot repositories and follow their activity at the R Consortium. If you would like to participate in this effort, reach out to the group via their website. And you can follow the progress of the webR submission pilot here.

R/Pharma. The Submissions Working Group and many other initiatives emerged out of R/Pharma, the annual conference that brings together statistical computing practitioners and leadership across industry, academia, and public policy to discuss open source software in pharmacology research.

Help George Stagg with WebR. Stagg says, “In an ideal world, I want people to be able to take something like an R-based analysis in Quarto or an R Shiny app, and convert it directly to run in WebAssembly without any changes to their R code. We’d handle the implementation details, the user would just get a binary reproducible blob of data that can run in any modern web browser. This is a hard goal. But I do think, for most applications, we can get there one day.”

R package developers interested in helping out can try building their package with WebAssembly, either using Jeroen Ooms’ R-Universe infrastructure, or via GitHub Actions for working with R and WebAssembly.

For R users and Shiny app developers, there are over 19,000 packages built for WebAssembly in the official webR binary package repository. The team at Posit can build them, but we can’t test them all. Try things out in Shinylive and in thewebR demo application. Let the team know what works well, and what’s broken (particularly packages) at webR’s GitHub issues.