 When it's deployed in a medical device that has you know life-safety and other therapeutic functions So today we're going to talk a little bit about what you need to think about When you're using Linux or other open-source software in a medical device And when we talk about the things to consider that go into a medical device we talk about risk So we're going to talk today about reducing the risk of using Linux in a medical device So we'll start a little bit by talking about what does the medical industry consider to be risk management and Software and we'll talk a little bit about a concept called soup, which I'll go into some detail And then we'll talk about well, what does that mean when you're selecting an operating system and Then we'll go into talking about some other considerations about licensing data privacy cyber security and Managing a Linux distribution and hopefully at the end of all this you'll have a little bit better of an understanding as to what it means To want to use open-source software in a medical device and the things that you need to think about So let's talk first about medical risk management, you know, what is it? You know, what is the medical community think about risk? Well, it's a pretty Standard concept across many industries and and and from the beginning it looks very similar in the medical industry You know risk is a combination of the probability of occurrence of a harm and the severity of the harm So if you have something that is Unlikely to occur Then the severity is considered can be considered worse Because it's very unlikely to occur And we'll get into a little bit of that in a minute, you know And then risk management is basically, you know, your policies your procedures your practices to evaluate those risks understanding their severity and then controlling the risks and Monitoring them and the goal of risk management is to identify and control those risks to an acceptable level an acceptable level is an interesting term because it's not really defined and the reason that it's not defined is that The acceptable level only can be considered in context of the device. So if your device is, you know relatively benign in concept, you know, like a Testing device then you really don't want to have, you know, some kind of medical test be likely to cause a patient harm and So acceptable risk would be very very stringent because the harm Would outweigh the benefit Whereas if your medical device is, you know, a surgical robot that, you know, is going to Hopefully improve the likelihood of patient survival over and above where they started Then perhaps your definition of acceptable risk is a little scarier Because once again the benefit is much greater than the potential harm and when we talk about acceptable risk That's really what we're talking about is the benefit greater than the potential harm And risk management is used in many many industries It is part and parcel of the medical device industry. You can't do anything in medical devices without thinking about it So we've all, you know, if you've been involved in risk management You've all sit around a table with a bunch of really bright people And have talked about risks and how to manage them and all of that and it always goes down to some really unlikely thing that happened and and and a lot of time has spent, you know Don't do that. I think this this comic just comes pretty close to home for me because I've been in several of these and Anyway, so what is, you know, we talk about risk management and medical devices. Well, what do we have to do? Well, there's a standard ISO ISO 14971 which is all about risk management and medical devices And I'm not going to go into a lot of detail that ISO 14971 You can you can do that on your own time But it does require a device manufacturer to define a risk management process That looks for the hazards Estimates the risks controls the risks and then monitors the effectiveness of the risk control measures And then a big thing about it is that the risks aren't just things that might come from the intended use of the device but for what they call reasonably foreseeable misuse and So if you can consider in your device Ways that it could be misused that can cause harm Then you need to consider how to minimize those risks in the design and the development of the device And there are many ways to do that, but you can't just say, oh, no, you they're not supposed to do that So it doesn't matter Okay, and then you need to document everything you do and maintain that in something It's called a risk management file, which is actually not a file anymore It ends up being a bunch of documents that are part of the submission that you make to your regulators Before your device can be approved So the key points basically are what we've been talking about all realistic risks must be considered and mitigated to an acceptable level This is not really defined But you need to be able to justify your decisions about risk Because your regulator is going to ask about it Your lawyers are going to ask about it and by God if something goes wrong the courts are going to ask about it And this is not just true for software to follow up by you the person who's making the device But all third-party software that you might use as well So let's talk about that third-party software and in a concept called soup So soup is an acronym called software of unknown providence. It's one of my favorite concepts in safety software Because it basically says, you know, I've got software. It's generally available It wasn't really developed for the purpose of being used in a medical device An adequate documentation of the development standards are not available Now that's actually a very kind of key point there because adequate documentation Basically means was the software designed and developed to a safety standard like IEC 62 304 or IEC 6508 or ISO 26262 there are a bunch of them out there Right so so it doesn't mean that documentation to develop standards development standards does not exist Just that they don't map to a safety standard like 62 304 And soup can either be commercial or open source software And in in my in my role as as safety officer for Siemens embedded, you know I work with both open source and commercial software and and we handle them differently But the idea is the same And then if soup is to be used in a medical device, it must be considered throughout the life cycle of the device So when we talk about soup, right, what are some of the considerations that we have? Um, you know for soup. Well, you know soup has to adhere to the same risk management processes as the rest of the software on the device So if the soup might fail in such a way that can cause harm Then the then then the risk of that software failing that caused the harm needs to be mitigated Right and there are lots of ways to do it But you need to think about those things and and it will depend upon several factors, right? How is it used? You know, how is the soup used? What will happen if it fails? How robust is it? Right, you know, if you have something that's pretty robust that's been deployed in millions and millions and millions of devices Then then that is, you know, that is a key consideration when you're deciding to use soup in your device So something like Linux Might be known to be more robust Then say, you know a two-person graduate student project that was abandoned 10 years ago But it's still out there in github and might be useful Right, um, you know, how are they how are defects managed in the soup and how will it be updated? How will obsolescence be managed all of these things are required to be considered if you're going to use soup in your device And then when you decide to use soup the developer should consider those and other factors And this is true no matter what the soup is So what other things do you need to think about? Well regulators are are looking more and more for a lot of information about any open source software you're using your device And this kind of goes beyond the soup requirements that were mentioned on the last slide You know, some things that they may like may might look for right, you know How do you know that the development process for the open source software is high quality? Right, it's not just oh, it doesn't fail in the field It's got to be something that you can kind of look at and point to and say yes, indeed. This is high quality How active is the community? How do they manage defects? Especially security defects the The FDA in america and and regulators around the world are very focused on security and medical devices You know, what are you going to how are you going to manage updates of those open source modules that you use? Right, what is the maintenance policy of your open source modules? How long will the version that you use be maintained? And if if you want to continue to use a version of open source that is no longer being actively maintained by the community Then how are you going to manage cvs and defects for your modules in the future? So those are all things you need to consider So let's go back a minute and talk about okay. How do I come to the decision of to use an operating system in a medical device? It is in some sense similar to the decision that you make to use an operating system in any embedded device But it's it's a little more Important to consider because of the regulatory approval that must ultimately be made So there are a lot of considerations and I could have listed these considerations in any order possible And i'm not even going to talk about them, but you need to kind of say for my device, right? What's most important? right like if i'm making say a an MRI scanner Right, I probably am going to you know have enough ram and rom and whatever that that it doesn't really matter Right what the what the the ROM size and the ram size of the operating system is going to be Whereas if I have a very small device it may be a huge consideration. So it's all all in context But will my and if and if if my context is small Well, will my design fit because a lot of people when they think of linux think about say a desktop Right where you've got you know a gigabyte of ram or more and you've got All of this room and you've got a hard drive that can host everything You know and and and and really at the end of the day, right? No embedded medical device is going to look like that Because at the end of the day you want those things to be small with a small bomb cost So you need to kind of think about will I be able to fit my design on to My device based on the operating system I'm using and I might want to use an RTOS a real-time operating system It'll always be smaller than linux, but it will not be nearly as functional But you can also optimize embedded linux Smaller than you probably think unless you've got experience optimizing embedded linux, um You know, we've taken one of our linux products down to less than 32 megabytes to have a bootable Usable system doesn't have a lot to it, but it may be enough for what you need Do you have real-time requirements? Right? I mean real time isn't really fast fast is what linux is really really good at Right, but it's more marked by the impact of what happens if a deadline is not met Right, you know a point of sale terminal or something like that. It's not real-time Right doesn't matter if it takes, you know five five milliseconds or 50 milliseconds for something to go through Whereas like an autopilot or A robotic Surgical device right those are real-time right if I delay on acting on a changing input The the result can be catastrophic And so the real question then comes to what kind of real-time am I dealing with if I have no real-time subjective scheduling deadlines kind of depends upon what's going on that I don't need to worry about it I can use linux. I'm happy If I have soft real-time You know if my system can handle A few missed deadlines and a lot of systems a lot of safety critical systems can handle a few missed deadlines then I'm perfectly fine. I can use preempt rt. I'm good to go But if I have hard hard real-time where I can never ever miss a deadline That I need to think real hard about the use of linux or other of linux especially in that system And then here's a little bit just about preempt rt. You probably are already aware of this But preempt rt actually brings linux much much closer To that real-time goal that we were talking about that our tosses are well known for So let's move from there. You know, so let's say you've gone through all of that you go. Yes, indeed I can use linux. It's going to fit on my device. I can Take advantage of all of the rich capabilities that linux and other modules bring on Let's talk a little bit about david data privacy You know and the challenge is really, you know, how can I deliver Devices that support innovative therapies and treatments while protecting user confidential data device security and caregiver networks Right. So basically In the us You deliver to the fda a 510k pre-market submission Uh, that basically then is reviewed by the regulator to determine whether you can Whether you can market your device And you must address security if you have network connectivity Now the fda gives guidance on cyber security For both pre and post market and then most of the rest of the world mandates similar requirements So making device secure requires consideration throughout the life cycle, right? You need to kind of think about it from the beginning When you're designing and developing the system to when it's deployed to when it's decommissioned, right? But many of the considerations come up front, right? How are you going to protect the device against issues that are known before the release? Right if you're using software Uh, especially from the open source But even if you're using commercial software, if you're writing it all yourself Issues will be found while you're developing it. So how are you going to manage those issues? Um that you become aware of before you release How are you going to protect against issues that come up later? Right if you're using especially if you're using um Commercial or open source software issues are found all the time And they aren't all known at the time you really release your product And so you need to kind of consider what you're going to do about it Right and then you also need to think about how you're going to make it difficult to exploit the device after release because the device has a lot of data on it that would be damaging if it was Put out into the public and you would be subject to HIPAA and other violations You know data privacy is a huge deal in the medical world today You know in 2015 kpmg looked at this and said 80 percent of health plans and health care providers acknowledged that patient data had been compromised And even in 2015 there was a lot of cyber related investments that have been made So you would think well between 2015 and today things have gotten so much better Well, the department of health and human services office Showed 686 data care data breaches of 500 more records just in 2021 right just last year And that was almost 45 million health care records were exposed or stolen Which made 2021 the second worst year in terms of breached health care records Well, you know, we didn't have that much to do in 2021. So people got interested in things No, no this data is valuable. It's valuable to the bad guys And and your device needs to protect that data to the greatest extent possible Because HIPAA the health information portability and accountability act requires it As do laws and regulations around the world such as the gdpr and the eu Which if anything is even more stringent than HIPAA So there were a number of considerations that you need to think about right, you know, you have access control Right, you know, if you considered the various role your device supports and have you basically Limited your system resources and capabilities based on those roles using something called the principle of least privilege Basically that every role you define Should have the minimum amount of privilege required to fulfill the role So if the role requires, you know, complete access to the system, that's fine But you need to make sure that that role is very tightly controlled And then passwords right, you know, if your device uses passwords for access control, you know, what are the default usernames or passwords? I mean, you know, I got a Router for my house not that long ago That had a default username and password that was something like user and password If you build that kind of thing into your medical device And you don't somehow require it to be managed before the roles are unlocked Then you're opening yourself up to be exploited by the rest of the world Lack of password management is a significant security hole in many devices You'd be, you know, if you're if you're if you're always thinking about security, you would think that this is crazy But I've seen many examples of people that really don't consider this at all And that leads to a lot of problems You know, and then other considerations, right? Can you can you securely boot your device? Is it protected from tampering? Right, you know, are you are you using the capabilities of your hardware? To protect the device there's a lot of good Hardware security capabilities, but if they're not used then they don't exist And then encryption, you know as your data encrypted Is it secure? Is it secure at rest when it's in storage? Is it secure in use? And is it secure when it's transmitted to another device, right? Or are you just leaving that data out there so that it's easily snooped? And then the thing about security and open source is that because the source is open It's known to the worldwide community And because the worldwide community doesn't include all good guys, but many many good guys and many many good guys are thinking about security Many security vulnerabilities are are found by People with good intent and are publicized to the world through something called common vulnerabilities and exposures or cvs It's a joint effort of mitra corp in the national vulnerability database of the united states And you should verify that no known cvs are in your device before your release Now that doesn't mean that necessarily That no known cvs are in your device that might impact your device before the release And there are tools that can help especially if you're using open source There are the cve check tool. There are many other tools that are available both commercial and open source That can basically correlate cvs with the versions of open source modules that you're using and allow you to the review the results We'll talk a little bit more about cvs But the real problem with cvs is just the sheer number of them. There are hundreds of them identified every month every every week um And and keeping up with them is a bit of a problem, which we'll talk about a bit more And then Basically, how are you going to keep your device secure? You know the time to prepare is during design How are you going to securely update your device? Right? How often? How do you minimize downtime and protect user data while you're updating the device? It's really no longer acceptable to not update a network connected device unless Well, actually there's very few instances where it's acceptable So you need to understand how you're going to do these things Yeah, because your device is probably going to have a lifestyle Lifespan measured in years or decades right for talking about you know an MRI device that costs quite a bit of money You know, it's going to be in use for a long time and downtime is expensive Right, it'll have the effects when you release it that you don't know about today Right, no matter how much testing you do no matter how much analysis you do There's going to be defects and if you're using Third-party software, it'll have vulnerabilities, right? And it's not and they won't be known to the community when you release them So so that is what drives those needs up above Basically, these things are going to happen be ready for them and be prepared to do something about them So let's go back to vulnerability monitoring, you know, I talked about these cvs There's actually about 300 cvs identified every single week Now most of them won't be applicable to your device, right? You know, um, they might be used against older versions of the open source modules that you're using They might be uh, they might only be applicable to certain Targets or certain chips that you might be using You know, but you need to figure out which cvs might apply affect you and then because these introduce risk You need to do impact analyses to determine whether or not they're important, right? You need to look at every one of them and most of them will just be oh, nope I'm using a later version. Oh, nope. That's not my target. Nope. Nope. Whatever whatever whatever But some of them will be applicable And then you need to find the patches for those cvs if you're using linux or other open source now Linux the linux community is very very good about providing these patches Right and they sometimes support previous releases through like the yakto and debian projects Right, but then how do you handle your cv patches if the community no longer supports the version that you're using? Right that basically means you need to do the backport fix and maintenance yourself Right and then you need to constantly monitor right 300 every week So you need to constantly be looking at these things And then as above you need to think about how you're going to do these updates because your customers are not going to be satisfied if you're not going to be Taking care of issues within a reasonable amount of time once they're disclosed So let's talk a little bit about managing linux, right? If let's say i've gone through this whole thing and i'm going yep linux is for me It provides a lot of capabilities. It has You know ai and and graphical and other capabilities and modules that are designed to run with linux that i need Right, so then well what linux should i use? Well, you know, there's the octo project. I can go and download it. It's actively developed. It's got good documentation It's easy to customize You know i can use debian now debian is traditionally an enterprise class os But it has been You know, it basically is moving more and more towards embedded applications because the concept of debian Where there is just a binary out there That basically provides me all of the capability that i need and i don't have to manage How do i get to that binary? Is useful to a lot of people Right, so debian is becoming more and more important in the embedded world And more and more medical devices are at least considering debian offerings As as kind of the building blocks of their device And then there are older things like build route And then there are commercial solutions, you know, we have one our competitors have them You know, there are a lot of commercial linux solutions out there. So there's the octo project I'm not going to go into this. It basically talks about how one goes about you know Using and building the octo project You know debian started out as an enterprise linux os in 1993 If you've ever used deboon 2 you're using debian There are many many many other Considerations and there's a lot of documentation out there about debian And i'm not going to go into that in a lot of detail But the thing that you need to think about is how are you going to manage and support your solution? Right, you know, you have to you know using embedded linux and all of those other modules That's millions and millions of lines of code development tools tool chains everything right How are you going to keep teams from creating too many variants? It's very easy For an organization that is working on four different devices Each of which in a silo ending up with four different linux distributions That have been modified in a way that the source Changes that have been made can't be accepted by the community and have to be maintained by themselves You know, how do you manage the licenses? How are you going to test it? How are you going to support it? Right the community provides support for about two years right for a For a non-long you know long life version of of an operating system or of a module Uh, but like I said a lot of these devices have lifetimes that go way beyond that Right and how do you maintain it for the life of a product? It gets the cost of maintenance gets pretty high pretty fast if you don't think about it up front So what do I do? Right. Well, I need to define processes up front and ensure they're followed Um, you know, it's it's it don't over branch Right. Make sure you have a support plan in place. Right. How are you going to handle those bugs that we talked about? How are you going to monitor the community for violent vulnerabilities? How are you going to update your product? Right train and enable your team to to do the right thing So before I finish, I'll just talk a little just just briefly about what we do at Siemens embedded Right. We have two different Siemens Linux distributions as I meant kind of implied before one based on the octa project one based on Debian You know, we we support graphics enablement. We support broad processor support We support AI and machine learning. We support cve monitoring. We can do it for you um We can we can target um either of those Linux distributions to your device Right. We can help you we can either solve for you Or help you solve a lot of the problems that we talked about during the course of this presentation And like I said, I'm not going to get into it a whole lot But if um, if you're interested, you know, you have my contact information feel free So in summary Risk management is essential when developing medical devices that has nothing really to do with Linux per se Or with open source software per se, but it's just kind of everything that we do And then the use of soup can help reduce risk But it kind of adds things to be considered So you need to consider those things, right Linux is good for a lot of things, right other open source modules are good for a lot of things But there are still valid reasons for using an RTOS or bare metal in some cases and you need to think about those upfront, right Don't make the decision To go in a certain direction before you've thought about, you know, kind of more deeply what your device is going to look like Don't let your open source get out of control Right in managing Linux and tools is not a simple task. And so Think about it up front because if you don't think about it up front, it's going to um hurt you later on You know security never forget about security Follow a standard to find your risks and have a plan in place to address vulnerabilities You know, I talk to a lot of people Who come from the academic world and they have a great idea For an advancement that will help the world You know through the creation of some kind of new medical device And they and they don't think about security And it ends up hurting them at the end because then when they try to go and sell their device Either to a larger medical device manufacturer or on their own. They have no way to get it approved Right, but the key point here is Linux is used in safety certified devices today Right, it's pretty heavily used in those devices today Defying your risks follow certification guidelines Consider going with a commercial vendor. All of those things will make your life easier As you go through your regulatory process So if there are any questions, otherwise, thank you very much. My name is Robert Bates and um, this it. I'll take questions now