What if there were an open source web-based computing platform that not only accelerates the time it takes to share and analyze life-saving radiological data, but also allows for collaborative and novel research on this data, all hosted on a public cloud to democratize access? In 2018, Red Hat and Boston Children’s Hospital announced a collaboration to answer this question, deploying the ChRIS Research Integration Service (formerly the Children’s Research Integration System) on the Mass Open Cloud (MOC), making it possible to rapidly apply new and more complex computational tools to image analysis, reducing the burden on radiologists and potentially saving more lives. Leading this effort were Dr. Rudolph Pienaar, Staff Scientist at Boston Children’s Hospital and Assistant Professor in Radiology at Harvard Medical School, and Máirín “Mo” Duffy, Senior Principal User Experience Engineer and Software Engineering Manager at Red Hat.

In 2023, the MOC evolved into the MOC Alliance, with production cloud services operated by Harvard and BU Research IT as the New England Research Cloud (NERC), and shortly thereafter ChRIS deployed on NERC. We asked Boston University Professor Orran Krieger, Co-Director of the BU Red Hat Collaboratory at the Hariri Institute for Computing and PI of the MOC Alliance, to interview Duffy and Dr. Pienaar about the developments with ChRIS. What follows is an animated conversation about the critical roles AI, cloud technology, and open source have to play in both clinical medicine and medical research.

—Shaun Strohmer, Ed.  

Orran Krieger: In 2016, AI pioneer Geoffrey Hinton said that he didn’t know which jobs would be destroyed by AI, but radiologists were like the coyote who’s already run over the cliff and hasn’t looked down yet. He also claimed that, as a result, in five years there wouldn’t be a job for radiologists. 

So, was he right? Has AI solved all the problems? What is your position on the application of AI to radiology and is ChRIS all about AI?

Rudolph Pienaar: What is my position on AI? That’s a very big question. 

Orran Krieger: Specifically, is AI useful for radiologists? And what role do you see AI playing in the future?

Rudolph Pienaar: Of course it’s useful. But before I answer, even that question needs to be taken apart. It’s like saying, “Mathematics can solve these problems.” You have to talk about the specific technique. Usually when people say AI these days, they’re talking about neural network-based technologies. That’s one tiny island in a lake in a continent on this huge planet of the field. 

Neural networks ultimately are good at a limited set of problems. By luck and chance, those problems are pattern recognition, and pattern recognition is a huge factor in many problems we try to solve. So in terms of automating pattern recognition problems in radiology, AI is an extremely useful tool. It is a tool that is useful in a domain, and we have to understand what that domain is. 

Orran Krieger: So AI is one of a set of techniques that can be very helpful as part of the whole workflow assisting the radiologist. And via ChRIS, you provide a tool that makes it possible to apply AI technologies where they’re useful. ChRIS allows people to exploit AI, along with other techniques, to solve problems. 

Mo Duffy: Like Rudolph said, it’s like math. What problem are you solving: are you building a bridge or figuring out how much to pay for groceries? That’s where I’m coming from as a UX engineer. If there is a user story it solves, great—bring it in. But the overall ChRIS platform is geared towards cloud compute, with a specific bent towards radiology, although it can be more generic if needed. That’s the core piece: solving radiology workflows. 

If we can plug in AI to make that better, that’s great. But the problem to solve is that you have a patient who needs to be evaluated, the radiologist has a huge backlog, there are not enough radiologists on staff to do it in time, and you have to prioritize so the most needful patients get looked at first.

Orran Krieger: What is the problem radiologists and researchers developing computational tools for radiology have that ChRIS addresses?

Mo Duffy: I think it’s that all of these open source tools are out there, but radiologists are not going to open up the Linux command line to use them.

Rudolph Pienaar: Yes. The biggest problem is that there’s currently no easy way to inject computing into a clinical cycle. Because there’s no bridge between the compute and the clinician, the connection never happens. 

I’ve seen this many times: you have amazing tools on the computing side, but they don’t magically jump that gulf to help inform a clinical workflow because the infrastructure hasn’t been addressed or put in place. We’ve focused on building infrastructure to link computing in workflows end to end in the way radiologists use computing. The computing has to be in the woodwork: the less a radiologist has to do with computing, the better. 

The computing has to be in the woodwork: the less a radiologist has to do with computing, the better.

Mo Duffy: Even just opening up a new browser window and logging into a new app—you’ve lost them. 

Rudolph Pienaar: You’ve lost them. If you don’t recognize that, you’re never going to solve that problem. We’ve tried to build a system that will take a particular image, do some fancy computing on it, then put the results front and center in the radiologist’s workflow, and they didn’t have to do anything. Linking computing to clinical workflows is the first big way we’re hoping to make a contribution. 

Orran Krieger: What drove each of you to start working on this project?

Rudolph Pienaar: I’d seen so much good software created in my academic career that could make a difference in the real world just go to waste. You create stuff to get a paper published, and when the paper is done, you hope someone will read the paper, be inspired by what you did, and try to either recreate it or build something from it. But you built something yourself, and you threw it away. That was so wasteful to me that it became almost impossible to not think about solving that problem.

Once you start scratching at something, you realize how complicated it is. It is so hard to build an infrastructure. In our case, luckily, we started thinking about infrastructure at the same time technologies were coming online enabling containerization—cloud computing with OpenShift or OpenStack or Kubernetes. These were all bubbling together at the same time, and suddenly they could be connected.

Mo Duffy: For me, since I was in high school, I’ve used Linux. I went to an engineering summer camp and learned this creative development platform and I got very into it. During my undergrad, other people came to me to learn this platform. Then the company making the platform got bought out by another large company, and they shelved the product. So I spent my college years learning a tool, and while the skills still transfer, all these assets I developed over my career were not opening. So I understood the benefit of open source.

“I get this, and I think open source can help.”

Then my father had a stroke. As a user experience designer, I like to know, what is the problem to solve here? In this case, we have to figure out fast what type of stroke it is to know what kind of treatment is needed. How can we help radiologists prioritize patients in the most urgent need, or give radiologists hints if they have a backlog to get them through that backlog in the most efficient way possible? I was very motivated by this personal event, and I thought, “I get this, and I think open source can help.”

Orran Krieger: There are lots of large proprietary companies in the medical industry. Why haven’t they built those workflow tools into, for example, the radiologist’s workbench or the MRI machines? 

Rudolph Pienaar: I think a core reason is that medicine is more about the human making the decision based on the data in front of them, as opposed to some other person or process taking the data and adding value to it. It’s not part of the DNA of a doctor to rely on an external thing to make a decision.

Mo Duffy: When you employ an external thing—say it’s AI—but it’s proprietary, it’s hard to trust it because you don’t know what it’s doing. That’s why open source is important in this space. If we’re going to build tools radiologists can trust, it cannot be a closed black box. With open source, you have some control. You can understand what is going on under the hood. If you need to trust something, you can query it.

Rudolph Pienaar: Even if you don’t do it yourself—I don’t think a doctor’s ever going to look at some code—at least it is out there and can be examined, and if there is something wrong it can be flagged. 

Mo Duffy: Also, a vendor-hospital relationship is a one-way thing. But when the tooling is open source, you can collaborate. You can work together, share what you’ve learned, and put it back into the tool to benefit everyone.

Orran Krieger: How do you see ChRIS enabling collaboration—across hospitals, between hospitals and researchers who want to develop techniques for analyzing images, in open source communities?

Rudolph Pienaar: That’s a good question. We have tried very hard to make the system turnkey simple. It is super easy to get started with ChRIS today for anyone, no matter where they are. You don’t have to be extremely technical; you just need to be able to read some instructions and you are up and running. That’s a huge win.

We also try to lower that barrier of entry for making apps for ChRIS. It’s much simpler to write a ChRIS app than it is to write an iPhone or Android app. You can easily run a ChRIS instance on any infrastructure, and once it’s running, it’s very easy to send and process data. As a user, you have visibility into that in a very straightforward way, and then you can compute. You can write. You can develop a program on your local laptop. And the same program you’ve run on your laptop with your local ChRIS will run on ChRIS in the cloud, so you can process a huge set of data without having to download it.

I’ve jumped over a lot of ground in those statements: there’s security, there’s safety. Assuming those are being addressed, the infrastructure makes it very easy to do these things. 

Mo Duffy: It meets the researchers where they are, rather than bootstrapping them into becoming production software developers. We can say, this is how you write the code. We’ll work with that, we’ll help you containerize it and make it cloud deployable, which is not something they would have the ability to do otherwise. 

Orran Krieger: So one user group is physicians, and they need a pretty user interface or something invisible. 

Then there are developers who want to write things as a scientific program. Then to make this thing deployable, there’s this Red Hat technology of containerization, cloud services, and other stuff to make those things meet in the middle. Is that accurate?

Rudolph Pienaar: Yes, very accurate. ChRIS runs very well on a lot of cloud tech, especially OpenShift. What we’re exploring at the moment is the ChRIS app. There’s no restriction on what that app has to have inside of it. A researcher like me might write a ChRIS app with some kind of AI algorithm. You can develop quickly, and you can then run it on the cloud. 

And, nothing prevents you from scaling much higher. You could take that AI app and retool it, as Mo mentioned, in a more scalable cloud infrastructure— let’s say, OpenShift—so it becomes part of the OpenShift infrastructure. Running the app now becomes very simple. Instead of having all the AI inside of it, it just has a few function calls out to the OpenShift infrastructure. 

What’s a win-win is that from the moment the scientific researcher writes their AI app, they can start running it and get results while they spend three weeks or two months rewriting it at scale for OpenShift or OpenShiftAI. There’s no dead time: you can still be developing your code and testing it, it can be delivering results, and you have a path to run it at a massive scale.

Learn how Chris in a Box expands access

Orran Krieger: You’re at a very rich hospital. What does ChRIS offer to poor hospitals, for example in places in Africa, where you’re originally from, or hospitals in the rural United States? 

Rudolph Pienaar: This is where open source tech and infrastructure make a level playing field. A hospital in a poor area might not be able to pay millions of dollars for the bespoke kind of radiology solution Boston Children’s Hospital has, but it certainly is possible to buy a bunch of PCs and deploy them on premises. Then you can throw OpenShift on them and install ChRIS on that, and you have essentially the same computing infrastructure that a place like Boston Children’s Hospital can have. Or, maybe easier, you can offload all this to a pure public cloud like the MOC and benefit from hosting at scale. And since the MOC offers huge benefits for nonprofits and also runs the same OpenShift as you would on prem, the deployment complexity and experience is the same no matter where you choose.

You could even start for free, running either OKD or the free developer version of OpenShift, then potentially license that further up and get more tools or solutions. You have that scalability path going upwards, but you don’t have to have a huge outlay at the start. 

Orran Krieger: Does ChRIS offer value for collaboration across hospitals? Each hospital has its own infrastructure, which creates silos. 

Rudolph Pienaar: Yes, silos across hospitals, or even within a hospital. They’re just an artifact of how hospitals are run and put together. If I’m running analysis on a piece of data, there’s no discoverable way for anyone else to know I’ve done that. Everyone is sitting on their own laptop, and they aren’t connected at a fundamental level, at the data level.

If there were a hospital-wide ChRIS, then in theory all the data is seen by this one platform. It would be possible to say, “Oh, Orran did this analysis three weeks ago, which is exactly the same analysis I want to do today.” It’s going to give the same results that took 10 hours of computing time. There’s no need to waste those cycles again. Having data grouped together in a unified platform like ChRIS makes that problem extremely solvable. 

If multiple hospitals start to host data on ChRIS on the MOC, we enable the ability to compute at scales hitherto unheard of.

This of course leads ultimately to the MOC, where, if a hospital hosts their radiology IT on the MOC then, using ChRIS, the sharing problem becomes moot. Not only within one hospital, but if multiple hospitals start to host data on ChRIS on the MOC, we enable the ability to compute at scales hitherto unheard of. If the MOC becomes HIPAA compliant, that will really unlock its potential.

Mo Duffy: Just being able to access the PACS (Picture Archiving and Communications System) in a visual way and see, “Oh look, some other people pulled this file. I don’t need to re-pull it to my local PC because somebody already pulled it to ChRIS”—that’s a simple problem but solving it makes a big difference.

For the areas with limited technology, the needs are very simple. Just having something like the open source PACS server is huge. It’s game-changing for some facilities.

Rudolph Pienaar: That’s an extremely good point. Just being able to get to your data in a simple way already changes everything, and we can do that today with ChRIS and with open source solutions running on OpenShift. That opens up whole avenues of potential clinical work.

A hospital might have, say, an MRI scanner, but they can’t afford the licensing or the fees to save its data to a PACS, or they aren’t able to buy a PACS. Instead, someone scans an image and burns it to a flash drive, takes it out of the scanner, walks across campus to their office, plugs it into their PC, then runs whatever janky software might come with a scanner to look at the images. No organization, no databasing—just a bunch of flash drives floating around, and no one knows what was scanned yesterday because it’s too much to keep track of—all for the lack of a free, open source solution they could deploy if it were easy and possible to do so. 

We’re at the point now where it is easy and possible.

Orran Krieger: What’s the relationship between ChRIS and an open source PACS solution?

Rudolph Pienaar: We combine it into the deployment model of ChRIS. These days you can deploy ChRIS with just a few files and a few lines of YAML in a script relying on Helm charts. If you have OpenShift and you have a Helm chart, which we provide, it installs ChRIS, and you get all of the stuff around it in that same deployment. And as part of deploying ChRIS you also get a connected PACS with which ChRIS can immediately communicate.

Mo Duffy: We tried a ChRIS store: an online catalog of ChRIS plugins where people could list plugins themselves. Then we built it into ChRIS as part of the core platform, so when you go onto the ChRIS server you can see the plugins available, or you can look at another organization’s ChRIS server to see what feeds, workflows, or pipelines they use. The output has been made public, so you can see, “Oh, there’s this this plugin, and they ran this this feed with it, and this was the output.” If this looks like the kind of analysis I’d like to do, I will install that plugin. 

Now, say you’re a radiology researcher presenting at a conference and you have some new technique to show off. You want people in the audience to say, “Hey, I’d like to vet that technique and try it on my own data and see if it still pans out.” What if, in your presentation, you had a QR code that goes to your ChRIS server? You’ve made this feed public on your ChRIS server to support your research, and any researcher watching your talk or reading your paper could scan it, visit your ChRIS server, download the same plugin on their own ChRIS server, then attempt to reproduce your research with their own dataset. All the tech stuff that’s challenging for a typical researcher is taken care of by the platform. 

I don’t think we’re there yet, but it’s on the roadmap as one way we could enable cross-institution collaboration 

Rudolph Pienaar: Definitely. We also have our flagship reference public ChRIS running on the MOC-Alliance production cloud (NERC) right now. You can go to that instance and see all of its plugins. It functions as a de facto worldwide ChRIS store.

But to underscore Mo’s point, to make collaboration easier, you need to reduce the work any one person has to do. If you write a ChRIS plugin and I want to run it, the hardest thing I need to do if I have a ChRIS too is type in the URL of your plugin. I am guaranteed it will run on my ChRIS, it will be the exact version you wrote, and if I feed it the same data you published on your site, I will see the exact same results. 

Orran Krieger: That’s very powerful. What are some things integrated into the workflow today that clinicians are using ChRIS for?

Rudolph Pienaar: We have a couple of projects that are already delivering value. One is a project that looks at leg X-rays and measures the lengths of the legs. That doesn’t sound extremely sexy, but it makes a very big difference, because the tools vendors provide don’t do any of that automation. 

A clinician looking at the X-ray of a kid’s legs is trying to figure out if they are the same length, because if they aren’t, they need to figure out what’s going on. With the tools currently available, a clinician has to pull up the image on screen and use on screen tools to manually measure. So if I were doing this, I click on the measurement tools and with my mouse move to the top of the hip joint, eyeball it, click, pull the line down to the knee, eyeball it, click, and it will give me a measurement of what that distance is. I rinse and repeat for both legs, upper leg, lower leg, and I end up with all these numbers on my screen. Then I either look at it in my head and try to figure it out—not a good idea—or I use my phone and add them together, or write on a piece of paper, or whatever. It takes easily 4 or more minutes.

Mo Duffy: It’s very manual, and it’s a very fine-motor task. It takes a lot of effort.

Rudolph Pienaar: It’s a problem that you would think, “hey, this could be done by a computer,” and guess what? It can. A clinician at BCH wrote a prototypical solution (pl-lld_inference) using off-the-shelf AI-python libraries that gives very good results. We cleaned that up and packaged that as a ChRIS plugin. Still, this one plugin just does one thing: tries to find the ends of leg joints. 

To add meaning, you need an ensemble cast. Different actors each do their small part, but taken together they solve a problem. We built all these and can describe what they need to do in a simple YAML workflow that ChRIS can interpret, deploy, and execute. So one plugin queries the hospital PACS and downloads the image. Another converts the hospital imaging format to JPEG because the AI algorithm needs JPEG. The AI plugin loads the JPEG and outputs another JPEG showing where it thinks the landmarks are. Another program picks up that output, looks at the landmarks, then measures the distances between them. Then another program picks it up and draws where those distances are on the image and writes a little summary table of them on the side, and yet another program takes that JPEG and reconverts it back to a medical image based on the original medical image. Another program picks it up and pushes it back into the hospital database.

Each one of those little programs is a ChRIS plugin available in the ChRIS catalog. Technically each is a standalone Linux container, and ChRIS can string them all together. In fact, ChRIS can even run each one on a different cloud, or on prem, or any combination, all as part of the same workflow. From the doctor’s point of view, they just go to their workstation, call up the patient data and then, as if by magic, this ChRIS-processed image is also right there waiting for them amongst all the others for that patient. All they have to do is look at that annotated image and within a second or two, they will know whether it found the right positions. Within 10 seconds, they can decide whether they need to think about a potential medical issue, versus spending five minutes painstakingly doing these manual drawings. That’s a real-world example we’re solving right now.

Orran Krieger: What role does the Mass Open Cloud and its production environment play in this?

The MOC plays a fundamental role, especially when it comes to breaking down those silos and bringing collaboration to the next level.

Rudolph Pienaar: They play a fundamental role, especially when it comes to breaking down those barriers and those silos and bringing collaboration to the next level.

Even if you imagine a world where all these different hospitals have their own ChRIS, are people going to send data easily from one ChRIS to the next? Are they going to trust it? You need a public-facing cloud provider offering a compelling reason to host data and compute there. That is what will bring these pieces together. With more data and more compute, the on-prem IT becomes even more complex, which is why at a certain level having a provider like the MOC becomes not only natural, but more importantly allows for scaling at levels beyond any single hospital. That opens the door for innovation at that next level.

Mo Duffy: When you’re talking about proprietary versus open source solutions and building trust, it’s the same with a cloud platform. If it’s a closed proprietary cloud platform, versus an open, publicly owned platform, there’s a trust difference, and that matters.

Orran Krieger: So if we can create an open public cloud, we reduce the barriers for hospitals to use this technology.

Rudolph Pienaar: Exactly. And you still have ownership of data you put in a public cloud, but it makes it very possible and easy for you to share it.

Orran Krieger: But hospitals do share data when they do collaborations, right?

Rudolph Pienaar: It is extremely cumbersome and idiosyncratic. In fact, it is so bureaucratic and so complex that it’s oftentimes easier to not do it. 

Mo Duffy: That’s where something like ChRIS makes a difference. If each institution has its own ChRIS, and you share the pipelines, the feeds, and how you built it, then each institution can run it on its own data in-house and not have to worry.

Rudolph Pienaar: Exactly. That’s certainly a very attractive feature of a platform like ChRIS.

Here’s a scenario: I want to get medical data from somewhere to develop a new technique, then share the results. Or there’s a GitHub repo of some interesting technique I want to try on this dataset. Without a platform like ChRIS, it’s very hard. You have to find the data. Then you have to do some idiosyncratic database magic to get the data, you have to download it to your local computer. You have to go to the Github repo of the thing you want to run and figure out how to run it. Maybe it’ll work. Maybe it won’t. How much work will it be to get it to run? You don’t know any of these things beforehand. Then you have to construct your own environment in your machine or figure out how to run it on your local cluster. 

With ChRIS, that infrastructural cost dials down significantly. ChRIS already speaks to the arcane image databases you find in hospitals and provides you, the user, with a simple intuitive way to search and collect from this. If the program you want to run is a CHRIS plugin, downloading from the database to your ChRIS and running some cool analysis is literally one URL away, and you know it will work. Sharing the results of that—again, drop dead simple. 

In my experience in the field of scientific computing, things make or break on the infrastructural costs. That’s not just money, but just the amount of work you have to do. If you dial that down, suddenly innovation becomes way easier.

Orran Krieger: What’s exciting to me is that scientists developing new image processing techniques can make a discovery, and this discovery could be available to all the hospitals of the world the next day. With ChRIS on an open public cloud, if there’s a group at a top hospital that develops a technique, they can disseminate and publish it in an executable way to affect real patients in real time—that’s pretty cool. I didn’t think about it that way until this conversation. 

There’s been a large community of people that have played a role in ChRIS. Anyone you want to give credit to?

Rudolph Pienaar: I want to give a huge shout out to my BCH team: Jorge Bernal, Gideon Pinto, Sandip Samal, Jennings Zhang, and Chan-Heng Hsiao. Of course to Ellen Grant, my long-time collaborator without whom ChRIS would have never existed. There are so many other folks, too many to name—eight semesters’ worth of BU and NEU CS graduate students who have contributed, three years’ worth of Outreachy Interns who helped on the project, lots of folks at Red Hat, especially Mo (of course), Hugh Brock, so many other talented folks who have dropped in with their valuable time. It has been and is quite amazing.