Nicholas Masel - Open-Source Initiatives in Pharma - What's Out There and Why You Should Join

Welcome everyone, thanks for sticking with us here in this Drugs Not Bugs section. So yeah, I recently turned 40. Yeah, this is the age where people with experience say things like, I tweaked my back getting out of the car or, you know, I can't eat that, it has too much cholesterol. So now that I've joined this lovely group, I decided I should set a meeting with my doctor. When I showed up for that meeting, I learned something new about myself. So I have something called white coat syndrome and some of you might be familiar with that. Now what that means for me is, the longer I think about my blood pressure, the higher it goes.

So talking with some friends the next day about this situation with my blood pressure, one insisted, hey, come to the gym with me, I'll pick you up at 5 a.m. Really casual like that, like people wake up at 5 a.m. to work out. So I have to do something, so I agree. 5 a.m. comes quickly and I've never worked out at a gym in my life, lifted weights, so I didn't quite know what to expect and my experience was something like this.

The open-source journey

So believe it or not, when I think back about this now, it actually is a close parallel to my open-source journey. So I found that I needed to make a change. I knew that not making a change could be detrimental, but it was really scary walking into something like this, thinking how I could actually contribute here. So I'd like to take you through that open-source journey and hopefully it helps some of you along the way.

Now when I think about this open-source journey, I dump it into roughly, well, exactly three buckets. Organizations thinking about using open-source, organizations that are currently implementing open-source, and then the last bucket of kind of been there, done that, have the t-shirt, so to speak. You might be saying, okay, well why are we talking about organizations? I'm just a happy bucket that likes to program. But organizations are simply made up of people, they're made up of you all, and I want to challenge everyone here or invite you to think about this from an organization perspective as we talk about this.

How can adopting open-source help your company improve, not just yourself? And I want you all to believe that you have the ability to drive open-source change within your organization.

How can adopting open-source help your company improve, not just yourself? And I want you all to believe that you have the ability to drive open-source change within your organization.

Getting started: showing value

So for you as a driver of change, thinking about how to get your organization to use open-source, you're gonna run into some questions. It might be something like, hey, I love R, I love Python, but how do I gain support so I can use it for my everyday work? You know, should we have an open-source group dedicated to this within our organization? And if so, how do you actually build one? And then where to even start? There's so many ways to go with this, and as corny as it is, it's really just dive in, you know.

So and hopefully my story and our story really will help you to avoid some of those rocks around the edges. So a story of what we did here, right? So we knew we needed to show value. We knew that if we could show value, we could build credibility by showing value. And then we knew we needed more people than what we had to achieve our goals.

And the way we really did this was, to Eric's point, like, interactivity is really powerful here, right? And something new and wild. And if you're able to take that, take quick wins. And for us, a lot of that was taking things, just take something out of Excel, dump it in Shiny. Seems kind of silly, but it's a way to quickly show some value. And don't start from scratch, like steel code. That's the great thing about open source when you join, right? So there's Shiny galleries out there. I believe for the example I'm about to show, it was from BS4Dash. So if David's out there, thank you. You can go to these repositories, grab examples, copy, paste, and start just tweaking and changing things.

So an example. We had an old Excel process where we identified adverse events, and it simply just exceeded some threshold, or maybe you were comparing treatments and you wanted to look at some differential between treatments. So the process would be, open your output, copy all of that, open Excel, dump it in there, and now you could start slicing and dicing your data. We just put that in Shiny. It wasn't really a radical change. It was just now that instead of opening an output in Excel, you open your Shiny app, browse for files, select them, load them up, slice and dice your data.

But what we found was it's easier to use, and it reduced a lot of that copy-paste error, or accidentally modifying some part of the Excel file that you didn't intend to modify, and it really just led to faster, higher-quality results that translated to roughly a quarter million dollars a year. Now, that's more money than I make in a year, so I was thinking, hey, we're doing pretty good here, right, for a couple weeks of work.

So we're able to show quick value and maybe pose that question to your leadership, right? Well, what if you had two people working on this full-time? What if you had three? And really, the point is, you know, what can you achieve here if you invest resources here?

Expanding open-source use: building the house

So you've got a team dedicated on delivering value using open-source tools. When you move into that next bucket, you might start thinking about questions of, how do we expand this more broadly? How could maybe we have a department to begin using open-source tools? And when you move into this bucket, especially when thinking about terms of regulatory deliverables, it changes from not what you're doing, but it's really how you do it, right?

So the questions you really run into in this bucket are, you know, are your results reproducible? Is the software that you're using trusted? And we have to remember also to Eric's point, like, we already have a house. Like, why are we changing? Is this actually getting treatments to patients faster? And it's really easy to lose that when you get in the weeds of this stuff.

So how did we build our house? If you've never built a house before, and I had not, one thing that's great to have is a general contractor, right? So a general contractor understands you need a plumber, you need an electrician, you're going to need some painters. They also understand the order you're going to need those things, and they speak the language of those trades. They can effectively communicate across these roles to get things done as needed. And I'd like to say that the modernization of statistical analytics plays that role of the general contractor. They're not going to come build your house for you, but they are going to help you understand who needs to be there while you're building your house, and also how to communicate effectively to those groups.

So again, general contractors aren't plumbers. They're not electricians. They're not going to build your house. But they do know a lot of plumbers and electricians, and they know which ones are good and which ones aren't. And that's kind of what we think about with selecting software, right? So the R Validation Hub, another working group within the R Consortium, is here to help you along the way. They're really the go-to to help guide you in picking the correct software, and most importantly, documenting that correctly.

So we built the house. Let's move in, right? There's still that last piece of inspection, and this is really where regulatory comes in. And the work Eric's already touched on here with another working group within R Consortium, the Submissions Group, has many examples there to help you safely and correctly document and deliver to regulatory agencies while using open source. And I mean, this isn't everything, but this is essentially how we built our house. We leaned on the open source community. We joined open source initiatives, and we really learned from the industry as we ran into challenges.

Getting treatments to patients faster

And again, let's not forget why we built this house, right? Again, you had a house in the first place. So we need to get treatment to patients faster.

So regardless of open source, standards is always a good way to do this, right? And the Pharmaverse is a group of people working to curate packages specific to our industry. The aim really, in my view, and others, I believe, is standardizing the set of packages that regulatory reviewers are seeing. If each time a reviewer pops open the trial that they're working towards, and they see a new set of packages, maybe proprietary packages, and they have to spend time sorting out, hey, do I trust this? What are they doing? How do they program this? It's the opposite of speeding things up, right? We're going to be slowing things down even further. So we really want to see people using a standard set.

And as a reviewer gets one package for the first time that's new, well, if the next one they get is the same one, they slowly hopefully build that trust, and it will help speed things along.

Now, if we move past packages, and for those that know the Cardinal package already, I made this logo up because they didn't have one, so this isn't the actual logo. You know, if we can think less about how do the results look on a page, the layout of those results, and focus more on is it accurate? This allows things like Cardinal to be built, where this is just a package of table generating functions, right? Plug your data in, boom, you get your results. And if you don't care that this number is here instead of here, we can really begin to move past that, have some sort of industry standards to really begin to speed things up here.

And then, again, interactivity. So there's interactive frameworks like Rhino and Teal out there that provide standard ways for you to give interactivity to your stakeholders. This allows them to answer questions in real time, and more quickly understand and summarize their findings. So I'd say these are the three big items, in my view, of really speeding things up.

Sustaining and growing open source

So you've built your open source team. You've expanded the scope of use to maybe a department. You might be feeling, hey, you know, we've done it. We've been there, done that, have the T-shirt, so to speak. But when I talk to organizations that I feel like fall in this bucket, surprisingly, they don't think they've been there, done that, have the T-shirt. And they know that there's just so much left to do.

And like with what Mark was talking about earlier, people is a big part of that. You can build your house, but if no one's moving into it, it doesn't matter how great it is or what the cool features are. And in the other respect, as far as, again, Eric's talk, there's always new technology. So those roadblocks that we had, new technology we see with WebAssembly comes out, and all of a sudden, hey, we see a whole better, easier way to actually tackle a roadblock that's a major roadblock. So staying up with new technology is something we're always going to need to do.

So if you're using R now as part of this process, you really need to think about, okay, well, how do we keep this sustainable? And one way to just kind of get started is you've got a package pipeline now. Pick a package, right? Pick a package and join in.

And this is the first package I ever contributed to. So when we were building our house, I asked the question, all right, how are we addressing logging in R? Seems kind of like just a side thing you don't really think about. No one really knew. So I began looking, and I ran across the Pharmaverse. There was a group of people working on this. I contacted them, reached out, and joined the group. And ever since then, actually, this is still my favorite package to work on, which is funny. The team is just awesome and just a great experience. So I encourage you to also just pick a package and hop in.

So later today, there is actually a Strengthening the R Ecosystem session that I would encourage you to attend. One of those talks is from Heather Turner. She'll actually be telling you exactly how to contribute to the R project. This one seems scary. I still haven't done this, but I'm going to dip my toes in the water, and I would encourage you to think of the same thing, right? How do we now contribute to core base R things?

And we've heard R Consortium come up quite a bit, right? And there's a reason for that. So basically, the R Consortium is supporting social and infrastructure projects. They're really trying to spread the use of R and provide money through grants to ensure that R remains stable and R remains relevant. So joining this actually helps us as an industry make sure we're setting ourselves up for long-term success.

Sure, we can sustain, right? But also, we would like to grow R. And one way I encourage you to do that is things like this. Share your story. It might not feel unique, but it is, and it will connect with someone. If you'd like something a little more informal, Rachel Dempsey runs a data science hangout every single week, and you can share your story there. And if you say, hey, I just don't want to talk to people, there's blogs and things like that. You can also still share your story.

And as you're building that house, you're probably going to run into things where you see gaps. You don't see really someone in the industry working on it. Maybe it's hard to find. And in that case, I would encourage that you organize and lead. And you can do that through R Consortium as well, starting working groups. There's one I haven't spoken about, which is FUSE, which has been helping the pharma industry for many years now. They also have a working group covering open source. And there's a project request form that you can just put in and say, hey, I found a new gap. I think this is something we need to come together as an industry. And you can request a new working group project.

Closing thoughts

So now for the end of my story around my blood pressure and this crazy gym. So I'm still waking up at 5 a.m. and going to the gym. My blood pressure is way down, and I'm in great health now. And the analogy to me seems stronger than ever, that you really need to change to survive and thrive.

And the analogy to me seems stronger than ever, that you really need to change to survive and thrive.

So I hope you find a reason to make a change, to just dive in, to become a leader in moving your organization to open source. And remembering that there's other people to help you along the way. And I hope you remember to also remain a good steward of open source and help to maintain the stability and success as our industry adopts open source to get treatments to patients in time. Thank you.

Thank you, Nick. As a fellow 40-plus person with hypertension, appreciate the talk. Very interesting. Can you give us some more story on that first contribution you did to the package, to LogRx?

Again, we were building our house, and logging came up, and I wasn't quite sure what we were going to do. So when I found the group, I reached out to just try to understand what they're doing and help them understand where I was coming from. From those conversations, it became really clear we could collaborate, right? They were very welcoming. It was kind of scary because it was the first time. Lovely group of people, extremely welcoming. And any package I've ever worked on ever since then, it's been the exact same experience. So we just talked through, planned some sprints just like you would for anything, worked on things, said, hey, what do you need? Hey, what do I need? Planned it out and just got to work. And I think since then, we probably get together once a year, and we just work through a sprint cycle. So it's been a great experience.

Thank you again, Nick. I really appreciate it.