Cross Industry Package Development

A Newcomer’s Perspective

Stefan Thoma

2023-07-21

Context

• Shift to open source solutions, particularly R

• End-to-end solution is required

• Pharmaverse

• Cross-industry development

So at the moment there is a shift to R for statistical programming work going on at Roche, but also in the phamaceutical industry at large.

We aim to have an end-to-end clinical reporting pipeline in R - this requires new tools to be developed.

Before, tools used were developed externally and companies created siloed solutions, using R we decided to develop the tools ourselves. But not only do we develop ourselves, but we also open source many of the projects and work on them with developers from other companies who are in a very similar situation.

Together, we created the pharmaverse, an opinionated collection of R packages designed for clinical data analysis.

Today, I would like to talk about why we open source, how we do it, and why it matters for me personally using admiral to exemplify.

Project

library(admiral)

• Part of the clinical reporting solution under Pharmaverse
• admiral covers the creation of ADaM data

admiral is a package designed to create ADaM data, a CDISC standart data format for data analysis and submission to the regulatory authorities.

From the very start, this package has been jointly developed by Roche and GSK

How did that happen?

Strategies

Approach [1]

• Act quickly:
  • Communicate early
  • Open source early
    • Focus on developing for general use
  • Get other companies & community involved

How can you develop effectively?

The first thing is: Get the message out. You are already working on something? Or know that you will soon? Spread the message at conferences, you may get others involved at an early stage. With other companies involved, you will be less likely to create a package filling a company niche and more likely to make a package that is more widely applicable. This, in turn, will more likely result in a broader adoption and in more resources of more companies in the medium turn.

The earlier you start to open source, the less likely other companies have already solved the problem in house. This again increases the likelihood that they may join your project, as there is still room for other companies to have a seat at the table.

I think it is also a very good idea to keep the development team close to the end users. This will ensure that the end product is actually usable at the end. We ensure this by having developers on our team that also work as statistical programmers, plus we try to frequently engage with a broad group of statistical programmers. An example for that was the admiral hackathon last january, where we introduced the admiral workflow to hundreds of statistical programmers.

Approach [2]

• Permissive and jointly owned license
  • Admiral won’t stop if one company exits
  • Monetisation of code not possible
  • Responsibility for maintenance
    • Package is never “done”

Joint license means stability. Stability is needed if we want the industry to trust this and adopt / adapt this solution.

Design

• One core package
  • Plus package for therapeutic area.
  • admiralonco, admiralvaccine, admiralophtha
  • Plus internal company package
  • Plus working groups
• Consistent interface and design across all packages
  • Ensured via developers guide and CICD
  • Overlap of developers between packages
• Modularity + templates for most more complex tasks

Now lets outline some of the thoughts that went into the package:

So first, the admiral package does not stand on its own. It is a core package which includes the most general functionalities. But there are currently x other therapeutic specific packages, namely admiralonco, admiralvaccines, and more. There, another dev team works on therapeutic specific implementations.

There are also company specific extensions, for example, at roche we have admiralroche which includes company specific functions. This can for example override specific default settings of the more general admiral package or implement common challenges in proprietary data-sets that are not generally an issue.

However, we try to keep all these packages consistent with each other. That means that all packages follow a certain design philosophy and nomenclature. We try to “enforce” this by having a public developers guide which lays bare the thoughts that went into the design, and how developers can best follow the practice. Commonalities are further ensured by having core package developers involved in the addon packages as well.

Design

Development workflow [1]

• GitHub repository is the centerpiece
• Every request / fix / improvement starts as an issue
• Weekly stand-up meetings
  • Check-in on progress
  • Discuss priorities for current release
    • Product lead (Roche) & technical lead (GSK)
  • Assign issues from the backlog
  • Strategy discussions
• Quarterly releases

Development workflow [2]

Project board

Impact

For Roche

• 10 Devs for the price of 3
• Seat at the table - shape the product
• No total development control
• Use of R attracts diverse talent

Speaker notes go here.

Workplace [1]

• Broader definition of a statistical programmer

• Shared language between stats and statistical programmers

• Open source development means transparency

  • Work done on admiral – recognition
  • Issues, errors and corrections

Surprised to learn that Roche is investing ito open source projects

Workplace [2]

• Knowledge is more easily transferable to other companies
• Less hierarchies in dev team (different companies)
• Harder to get recognition, no manager present
• Autonomous work - everyone can chose which issues they want to work
• Expanding network across companies
• Leadership opportunities outside of the company

changes DS position to creating reusable software. Changes the ADS position to a more effective and more rewarding work, because there will be less repetition and more focus on writing better and reusable code.

Recognition: That’s why I have to make such a presentation… (joke)

Conclusion

• Open source and cross industry collaboration when done well:
  • Is more efficient
  • Opens horizons
  • Expands the job description of statistical programmers
  • Makes for an attractive workplace (at least for me…)

To do it well you have to be quick, you don’t want 5 other companies doing the work you do at the same time, because all companies are already invested and convinced of their own solution. Get broad support for your project, be it from the inside or the outside. If you know of other projects that try to solve the same problem, be openminded about its qualities. Maybe You should join Them? If you want others to join yours, you need to be transparent about where you are, where you want to be, and how you want to get there. In the end, you need to establish trust. Trust also requires stability, and stability means continuous improvement and adaption. A good R package should not go stale, so proper maintaining should be planned.

Doing now what patients need next