 Hi, I'm Mo Duffy and I'm a senior principal UX designer with Red Hat and I'm going to talk to you today about UX and free software and how they depend on each other. And I'm going to use the Chris project as an example. So you may not be familiar with the Chris project. So just as a quick run through, it's an open source project and it's developed at Boston Children's Hospital in partnership with other organizations. Red Hat, my employer, Boston University, the Massachusetts Open Cloud and other universities and organizations. The goal of the Chris project is to make all of the amazing free software in the medical space more accessible and usable to practice practitioners in the medical field. And let me just give you a quick peek under the hood because a lot of times people will say platform and it's a bit of a nebulous term so I just want you to know exactly what I'm talking about. When I say Chris is a platform. So Chris has a back end. Okay. And it's attached to the back end. We have different UIs and we'll talk about them in a bit, but the back end connects and I know it's hard to read in the diagram, but this is open stack. And this is open shift here. Okay. And this is a container based system. So the back end pulls data from medical institution. And showing there, right, pushes the data into a series of containers that are chained together. So this one is sort of the in it container and then each can each of the containers in the chain here might have a different piece of free software in it. And what Chris does is it manages taking that medical data and pushing it in between the containers taking the output of one pushing it to the next. We'll talk about this in detail, but each container the important part is a free software medical tool and it performs some kind of analysis uses that input output model. So you push data in and the container runs through the data provides output you take that output and you provide it to the next container, which is probably another free software plugin or it could just be out to the end user and your process is complete. Anyway, there's just a quick overview of what we'll be using as a case study this Chris project and what exactly I mean when I say it is a platform. Okay, so now that you've gotten a quick overview of what Chris is, who am I and what do I know anyway, I'm a UX practitioner and I've been working at Red Hat for over 15 years now. I specialize working with upstream free software communities, typically embedded in those communities. And I'm also a long term free software user myself. I've been using free software since I discovered Linux as a high school student. I fell in love with it. I loved how customizable it was and how it really provides an opportunity just the whole free software model of letting you co create your own computing environment. So from that experience, I've come up with two basic principles of UX and software freedom. The first one is that software freedom is critical to a good UX. And the second one is that good UX is critical to software freedom. So today we're going to be focusing on the second one. But if you're interested in the first one and want to dive a little bit more into it, I have another talk that I do on it. And this is just a quick overview. The main idea is that the principles inherent to free software give free software a much better potential to have a fantastic UX than proprietary software could ever have. For example, if you're using proprietary software and it uses a proprietary format, your data is more susceptible to bit rot that reduces the longevity of your data and your ability to access it over time. I actually, in college, when I was a freshman, I used a tool called Macromedia Director, if you've ever heard of it. By the time I was a senior in college, like less than four years later, I could not open the files I made as a freshman because that file format had completely bit rotted and you could not access the software to open it anymore. So that's a bad user experience, right? This is not something that generally happens with free software because it adheres to open standards and you don't have to reverse engineer formats to access data. It's open source. Anyway, you can watch that talk where I give this and many other examples of, you know, why this principle is, and I actually gave it at a previous DevConf in Boston. So the link is there on the slide. The slides will be available after the talk. Okay, so our focus is today, today is that good UX is critical to software freedom. So I have three questions for us to kind of start off to kind of get you in the thinking space here, all right. So you've probably heard this one before. If a tree falls in the forest and no one is around to hear it, does it make a sound? Okay. So if your software has features and nobody can use those features, does it really have those features? And the third question here, if your software is free software, but only a few people can use it, are you really providing software freedom? So, you know, these are just some opening questions, just this is where I'm coming from with this principle. Here 2021 we have a wealth of free and open source technology. In seconds, you can get a containerized app running on any system. In a few minutes, you can deploy a Kubernetes cluster on your laptop. And then in a few more minutes, you can deploy a deep learning model on Kubernetes on that cluster. This is amazing. In free software in the past 10 years, maybe even longer, I mean, we've made so much progress. You can work in almost any domain and start up a new software project and all of the underlining infrastructure and plumbing that you need is already available off the shelf free software licensed for you to use. You can focus mostly, most of the time on the actual bits that you really care about on that innovation piece, making something new because you don't have to reinvent the wheel for all the foundational stuff. So, there's a problem. This is the cloud native landscape and this is put out by the cloud native computing foundation. Now I don't want to pick on cloud at all, but this is just a fantastic example that shows it's all a little complicated. There are so many tools. And technologists themselves have a hard time keeping up with all of this. So when we're talking about free software aimed at the medical domain like the free software tools that we deploy on the Chris platform. How do we expect medical experts and clinicians to be able to keep up with an eye chart like that. They're not software developers and even software developers have a difficult time keeping up. But the thing is, is there's so much potential here. There really are so many free software tools in this medical space. Some of them have been around for years. By default, they tend to be developed and released as free software tools because they're created by researchers or academic labs organizations that really want to collaborate and share the same way that they do with any research where it's the academic model you come out with a finding. You share it you invite others to reproduce it. And, you know, you try to come to an understanding you build on each other's work. So they would like to use that same model with software, which is the free software model. But, you know, as a medical practitioner, there's all these tools. How do you actually use them? They're often built by researchers who don't have a software development background. They're usually built for use in a very specific study or under a specific lab environment and they don't have wider deployment in mind. There tends to be a lack of standardization in these tools and a lack of integration between them because the researchers developing them are very focused on one thing. They're not thinking more broadly about integrating things and making for generic usage. And depending on the computation involved, they may require a more sophisticated operating environment than most clinical practitioners have access to. And just overall, there's a high barrier to entry. Even though these tools are free software and they're publicly available, these aren't tools that your typical medical practitioner could just pick up and start using in their practice. We have to remember those. These are very smart people in the medical field. They're neuroscientists and brain surgeons, for example, but they can't hack the Gibson. Good UX does not require your users to be hackers. Unfortunately, traditionally and historically, free software has kind of required users to be hackers in order to make the best possible use of it. So how do we bridge that gap between all of this amazing free software and clinical practice so that the free software can make a positive difference in the world so it can feasibly impact medical outcomes in a positive way? It is good UX that is what will bridge that gap. And that is why good UX is so critical to software freedom. So again, if your software is free software, but only a few people can use it, are you really providing software freedom? I'm telling you, no, not really. You need a good UX to be able to do that, to be able to allow more than a few people to be able to use it and to be able to provide that software freedom to them. So what are all of these amazing free software tools in the medical space? This is a very quick map that I made. It was honestly based on a 5 to 10 minute survey I did of research papers and conference proceedings in various technology related medical groups. These are all free software tools, and it barely scratches the surface of what's available. I want to talk about two of these in particular. COVID net and free surfer. These are both tools that are now available for use on the Chris platform. Free surfer is an open source suite of tools and it focuses on processing brain MRI images. It's been around for a long time, but it's not really in clinical use right now. This is a 3D animation that was created in free surfer and it was running on top of the Chris platform. The workflow here involved taking 2D images from an MRI and MRI basically takes images in slices across the brain. And they're 2D so free surfer constructed a 3D volume out of those flat 2D images, and then it segmented the brain into all of its different structures so you can see all the different colors there. Free surfer color coded them so out of glance you can see the different structures of the brain right on this 3D model. So, you know, how is this useful in medical practice, you might have a clinician who's not really sure what's wrong with a patient. So instead of reviewing the 2D slices from the MRI, they'll be able to pan around this color coded 3D structure and they might notice for example, one of the structures, let's say it's larger than is typical. That might give them a clue as to what the diagnosis is and then once they have a diagnosis, it'll get the patient to a quicker treatment. So just being able to do this, it could make a practitioner. Much more able to diagnose a condition and so you can see the potential here right with tool like free surfer. Okay, so here's another project COVID net. This is a free software project and it's developed by a company called Darwin AI in partnership with the University of Waterloo. It uses a neural network to analyze CT and X-ray chest scans and it provides a probability where it will tell you if the patient is more likely to have healthy lungs. This is an open source tool. It's available to the general public and the potential here is to provide an alternative way to triage patients when let's say there's a COVID surge in cases. You have a lot of people coming into the hospital, you're running out of beds and maybe your test results are backed up. If you can get the patient to a CT scanner or an X-ray, then you could use this as an alternative way to triage the patient, diagnose what kind of ailment that they have. So these are just examples of two projects that we've worked with in the CRISP project. Okay, so how do we get amazing tools like these? They're free software. They have a lot of potential. How do we get them in the front lines in medical institutions? Dr. Ellen Grant, who is the director of the Fetal Neonatal Neural Imaging and Developmental Science Center at Boston Children's Hospital, who is one of the founders of the CRISP project, she came up with a list of three basic requirements for these tools to have in their user experience so that clinicians can actually use them. So the first is that these tools have to be reproducible. The second is that they have to be rapid, and the third is that they just have to be easy. So let's first talk about reproducibility. In the medical space, you're interacting with scientists and medical researchers, and they're trying to find evidence to support new technology or techniques or methods of analyzing data to come up with an idea. So if a new method comes out, and let's say it's a new machine learning model, let's say it's the COVID net model, okay, and you're reading a study that supports the technique and it shows evidence for its effectiveness. If you want the best possible shot of reproducing those results, you want to put your data into that system and you want the system to be as close as possible as to the actual system that was studied. So you want to eliminate any variables like the operating environment, the type of container, the OS, the configuration that might skew the output. To be able to reproduce exactly what somebody had done with one of these tools previously, you would have to take it and install it in exactly the same way, the same configuration, rebuild it with the same flags, exactly the way it was built in as close an environment as possible. This is what that would look like, for example, if you're installing free surfer as a screenshot of that process. This is not something that we can expect medical practitioners to go through. So how do we make tools like these more reproducible for clinicians? I'll use COVID net as an example. We took it and we packaged it in what we call a Chris plug-in container. The Chris plug-in container is just, it basically means it's containerized, and we put like a small wrapper on top that has some metadata and miscellaneous tools that allow it to work on the Chris platform. Once a plug-in has been containerized as a Chris plug-in, it can run on Chris, which gives you a number of UX benefits, including reproducibility. A clinician can just pick the tool from a list of tools from within the Chris UI, push their data to it, and get the results, and Chris manages all of the rest. We have a broader vision for reproducibility via Chris here. This is a screenshot of a Chris plug-in store prototype. We envision making all of these amazing free software medical tools as easy to install and run on top of Chris as it is to install and run apps on a phone from an app store. So this is an example of a tool containerized for Chris. It's called PLSivot. You could take a look at the tool, deploy it to your Chris server, and use it in your analysis, and it's pretty much like shopping in an app store. All of these amazing tools, they're hard to install, they're hard to run, and they're hard to reproduce in the same exact way that was in the same way that a study was done that showed some effectiveness. So instead of requiring medical researchers and practitioners to use the Linux terminal to compile code and to set up environments with exact specifications, we envision them being able to browse through these tools, like in an app store, and to be able to easily run them on their own Chris server. That would mean they would get much more reproducibility out of the tools, and they can know exactly what, they can know that they are running the exact same version in their container. Okay, so the second requirement from Dr. Grant is rapidness. These tools need to be quick. For example, we're still in a pandemic right now. As COVID cases surge, hospitals run out of capacity and they need to turn over beds quickly. Computations that take hours or days to run will just not be used by clinicians. They don't have time. So the tools have to be fast. Or let's take a non-pandemic case, you know, take a little break from that for once. You might have a patient who needs to travel far for specialized care. Maybe they have a rare condition and the closest, you know, medical center that can help them is far away from home. If results could come back in minutes, it could save that sick patient from having to stay in a hotel away from home waiting for results in the next steps. So some of these computations take a long time. So let's throw more computing power at them and get results back quicker that way. Chris lays the foundation that will enable you to do that. Chris can run or orchestrate workloads on a single system, HBC or cloud, or cross those combined in different deployments. You can get really rapid results and Chris gives you all of the basic infrastructure to do it. So individual organizations don't have to figure out how to set this up on their own from scratch. For example, this is a screenshot of the Chris UI and it shows how you build these pipelines or analyses in Chris. If you see here, each one of these little nodes on the graph is a container and each one of these containers is running a free software tool and that tool was containerized for Chris. So you can see here, this is the free surfer container running right there. And this one up here is it's input container. So that takes the data that is going to be pushed through the analysis and loads it into the next container. You could see free surfer splitting out here. So basically what's happening here is it's taking the same containers like the same software and containers and making copies of them and splitting up the data so that they can run in parallel. So you could get all of this kind of orchestration and computing power just based on the infrastructure that you get from Chris out of the box. Where did my mouse go. So this is just another diagram to show a different view of this. So you have the Chris store here. And like this PA thing. This is the plug in. So the plug in gets loaded to the Chris back ends. And then Chris also organizes how to get to the hospital data store which is typically what you call a packs server. It'll get the data from that store, pull it in and then it'll push that data into a container that it sets up in one of several computing environments like you could see this one is an open shift open stack computing environment. And cloud computing environment, but there's other computing. I'm sorry for interrupting you, but sure it's left. Oh my really. Okay. All right. I'm going to move quickly then. So anyway, yes. So you could see Chris can orchestrate workloads and push them out to different work or computing environments and then pull back the data. All right. And then one of those compute environments that Chris uses is the Massachusetts open cloud and this is Dr. Orrin Krieger. He's the principal investigator for the MOC at Boston University. This is a publicly owned non commercial cloud that collaborate with the Chris project. And actually we have a test deployment with COVID net right now running on the MOC. And this is just another way that we're looking to make massive power that's in cloud computing environments, accessible to medical institutions using a public cloud rather than a proprietary one that might, you know, have weird data sharing agreements. Okay, so the final requirement here from Dr. Grant is easy. Okay, so we've kind of assembled all the infrastructure and plumbing to provide a rapid compute and we've made a kind of a structure that is reproducible. So what we really need is the tools then to be easily deployable are easily used by medical practitioners. And then I'm just going to move a little quickly here since I'm running out of time. This is an example of the core Chris UI. This is the feed list, and this is aimed not at clinicians, but medical researchers who are building pipelines so they have some knowledge of what these analysis tools can do and how you could potentially chain them together to get an output. So they're using this interface to sort of develop and refine these pipelines of containers running together without having to know how to run containers or compile code or anything. And this is just an example of how they, they add nodes to the pipeline, and this shows sort of the output, right? So this is an example of a UI that is more focused towards a clinician. This is the COVID net UI, and it's a very single purpose UI. Rather than having the clinician have to pick out a pipeline like this, this UI is keyed exactly one to one with one of those analysis and this one is the COVID net analysis pipeline. And it just allows them to pick the patient images, push it through that pipeline, get the results back. So all of that complicated pipeline building stuff is working under the covers for the clinician. They don't even have to know or worry about it. And here you can see you just type in the patient MRN. Oh, that didn't work. That's all right. You type in the patient MRN. It gives you the images. You pick the images you want to analyze. And then in a couple minutes you get results just like this. So here you can see it's like a 75% or so rate of prediction that is normal lungs. And there's a 25% probability that the patient has COVID. If the clinician wants to kind of open up the image and look with their own eyes to kind of double check what the model found, then we've built in a radiology viewer into the tool as well. So you can see with this model where we're, we're for clinicians, we've provided all of the plumbing and everything you need to build a very custom streamlined UI for a very specific purpose aligned to a very specific pipeline. That is to make it easier for them to access all of the amazing technology underneath. So you can see how we have tried to meet all of these three requirements reproducible rapid and easy to make this free software accessible on the medical front lines. And honestly, in other words, you know, to get that in the front lines, we have to provide a great user experience. And for free software to matter, generally, we have to provide a great user experience. So just a quick review of my two principles here, software freedom is critical to good UX and good UX is critical to software freedom. Thank you. Maybe there's a minute or two for questions, maybe not.