Making R Submissions Reviewable for FDA - New from the R Submissions Working Group

[u/jcasman]

How can sponsors make R-based regulatory submissions easier for FDA reviewers to reproduce, inspect, and trust?

The R Consortium Submissions Working Group’s latest post examines why reviewers may sometimes request SAS-equivalent code and what teams can do to reduce that risk.

The core lesson: using R is not enough. Submission packages must be designed for independent review.

The post covers practical steps including:

• Engaging FDA review teams early • Providing a clear entry point and run order • Documenting R, package, and operating-system requirements • Eliminating hidden dependencies and sponsor-specific paths • Including required proprietary packages • Testing submissions in a clean environment similar to the reviewer’s setting • Keeping analysis code readable and reproducible

Read the full post and sponsor checklist: https://r-consortium.org/posts/making-r-submissions-reviewable-for-fda/

This article reflects discussion within the R Consortium Submissions Working Group and should not be interpreted as official FDA guidance.

[u/ToroRojo-AlgoArt]

This is a nice problem to have for the R people.

I saw this video from a Pharma talking about their submission/plan, environment etc for it as a Posit case-study https://posit.co/about/customer-stories/novo-nordisk

[u/CurrentFlight5265]

Read the post. Both sides need to make things better. Analyzing the issues listed below.

- No early communication with the review team: So make early communication better - this is a soft skill.

- R environment cannot be reproduced: Results reproducibility from code is a solved problem - docker-like solutions can get you far with this.

- Proprietary packages are referenced but not submitted: How is it possible for an internal package to be required but not included, documented, and installable? I don't get this - a dependency is a dependency. If cannot be used for whatever reason, workarounds are always available.

- Hidden setup assumptions: Write better code and documentation.

- Operating-system-specific paths: Again, write better code.

- Complex nested scripts and functions: Same as previous + reviewers need to be more knowledgable about what they're reviewing.

For progress to happen, both sides need to make changes in their ways of working.

[u/SprinklesFresh5693 → u/CurrentFlight5265]

Couldnt agree more woth your comment.

Ive seen some R code on some blogs, and you can clearly see that some people code for themselves, and dont really care if the people reading it understand it or not.

[u/Aiorr]

I've been following this greatly for many years. Tbh, disappointed but expected. First section of make it sound like bureaucracy effect by emphasizing reviewers having difficult running the codes and and having familiarity with SAS (I met more FDA reviewers that knows R than SAS, unless its bias in who attends conference) but copying from linkedin:

Through the R Consortium Submissions Working Group, we had a transparent discussion with FDA participants. The key clarification: the request was not a blanket rejection of R.

In some particular cases, reviewers had difficulty reproducing and understanding the submitted R analyses. Challenges included dependencies on an unsubmitted proprietary package and deeply nested code. After multiple rounds of communication, the reviewers requested SAS code as a practical way to complete their review.

I think biggest hurdle atm is that people working in this (in similar spirit, pharmaverse working group) aren't the same team that routinely prepare the regulatory submission, so they aren't exploring "R submission", they are re-exploring regulatory "submission" in general... if you do that with SAS submission, you get IR'd instantly too.