Designing Secure Medical Device Software with Randy Horton | Ep. 45

In this episode of the Med Device Cyber Podcast, hosts Christian Espinosa and Trevor Slattery are joined by Randy Horton of Orthogonal to discuss the critical intersection of software development and cybersecurity in the medical device industry. The conversation centers on the necessity of integrating security from the ground up, a practice known as DevSecOps, rather than treating it as an afterthought to be 'bolted on' before a product goes to market. Christian introduces this core theme, highlighting that a device with security designed into its architecture is inherently safer and more robust than one where security is addressed reactively. The guest, Randy Horton, brings extensive experience from his company, Orthogonal, a firm that specializes in accelerating the development of Software as a Medical Device (SaMD), connected device systems, and digital therapeutics. Randy shares his journey from discovering the first web browser in 1994 to a career focused on innovation in healthcare technology. He explains Orthogonal's philosophy, which involves fusing the best of modern, agile software engineering practices—many originating from Silicon Valley—with the rigorous quality, safety, and regulatory frameworks required in MedTech. A central argument is that these modern methods don't have to be at odds with compliance; instead, when adapted correctly, they can fundamentally raise the bar for both safety and effectiveness. The discussion explores the cultural and practical differences between the traditional tech industry's 'move fast and break things' mantra and the needs of healthcare. Randy proposes an adjusted credo for MedTech: 'Move faster and break nothing.' The group delves into why this is a significant challenge for the industry, which has historically been based on the principles of physical engineering where change is difficult and costly. Software, by contrast, is infinitely malleable, presenting a different set of risks and opportunities. This flexibility means that a device’s lifecycle never truly ends, especially with the need for ongoing security patches and feature updates. The hosts and guest agree that while the industry is slowly maturing, many companies still struggle with this paradigm shift, often leading to inefficient development and last-minute scrambles to meet cybersecurity requirements.

Host: Hi, welcome back to another episode of the Med Device Cyber podcast. Today we're talking about software development with mobile devices, with cloud, and specifically medical device software development. We have a guest here, uh Randy Horton with Orthogonal. They are do software development specialized in medical devices. And it's important to make sure as Randy was mentioned earlier, that cybersecurity is actually part of your software development. So we do DevSecOps versus just DevOps, sec being the security portion. Uh and it as we know, a medical device is much more secure if cybersecurity is designed into the product rather than bolted on at the end. So I'm also joined here with Trevor, our co-host. Trevor uh, are you still in California, Trevor? You got a different background today. Trevor: Still in California. I've just been banished to the corner of my tiny apartment so that my girlfriend can walk by during podcasts. Host: Oh. You don't have the beads as your door. Trevor: No, no. The beads are gone, but gearing up to head down to San Jose in a couple hours here for Device Talks, which is gonna be fun. Host: Awesome, and you're giving a talk at Device Talks, right? Trevor: Yeah, yeah, tomorrow at I believe eleven or eleven thirty, giving a talk on the common pitfalls and some of the horror stories that we have seen from mismanaging cybersecurity in medical devices, and talking about some of the things that can go wrong. Obviously, being this involved in the industry, we've seen a lot of the mistakes that companies make, come to us for help, and so we're talking about how to avoid those mistakes in the first place. Host: It's always good to be proactive rather than reactive. Trevor: Exactly. So this episode will probably go live after I've done that talk, but if you were there, it was uh good to see you. Host: Awesome. We're talking in the past and the future at the same time. It's kind of weird. All right. Randy, where are you coming from today? Guest: I, well, we're a Chicago-based company. Uh, culturally I'm a Chicagoan, but I'm coming to you, I moved about five years ago down about an hour north of Miami. Host: So what does that mean culturally you're a Chicagoan? What's that mean? Like, what's the difference between Chicago and Miami? Guest: Chicago in my heart, you know, I'm a rust belt kid, what can I say? Host: Uh, maybe you can explain a little bit about your background in med tech, uh, Randy, and a little bit about what Orthogonal does, then we can dive into our discussion here. Guest: Yeah, sure. So I've been a long-time software innovation change person. It kind of started in 1994, in January I was getting ready to graduate from college and I didn't know what I wanted to do. And one night at the computing center, I found the first web browser, Mosaic, and I did an all-nighter. And I swear to you, this, I can't prove this, but I only went home when I ran out of links on the internet to click on in 1994. Host: There was like twelve links, weren't there? Guest: There were about, I don't know, maybe twenty websites. And I left and I said, I don't know what this is, but this is what I want to do with my career. So here we are. I'd say about eighty percent of my career's been in healthcare, and a large amount in the last decade and a half has been in, in medical imaging and our medical device. So, Orthogonal is a, you could think of us as a contract manufacturer for software as a medical device. So medical device manufacturers hire us to help them accelerate the development of software as a medical device, connected device systems like an insulin pump or a glucose monitor, and digital therapeutics. Um, and we got into this business because we saw a massive opportunity to move the outcome in a really big way, on, outcome on patient outcome. You know, we could really move health care with, with modern software and connected software. And the way we do that is we take the best of the modern worlds of software engineering and product management. Really, you know, Trevor from where you're at, more from the Bay Area, you know, these methods that have helped us build great software, um, faster than ever before, and fuse those with MedTech's focus on safety and effectiveness as actuated by laws, regulations, uh, quality, and compliance. And our view is that, anybody who says, oh, you can do Lean and Agile and user-centered for your medical device, but don't worry, you can still be compliant is way under-stalling the power of modern software. We think that modern software, when it's built well, um, can actually fundamentally raise the bar on safety and effectiveness in medical devices, as opposed to being sort of some odd thing that we're trying to graft on, which is a lot of how our industry has unfortunately looked at it in recent years. Trevor: So are you looking at this more of quality software should inherently be safe and secure as opposed to it being this big, arduous task that manufacturers have to undertake? Guest: Yeah. Here's what I would say and this is kind of our lesson learned is that, um, and so we can talk about cybersecurity, but I would include that as just a part of quality. Right? You need a medical device that operates the way it's supposed to and never does anything it's not supposed to, which would include being, doing something wrong because it's been hacked. Right? Um, if you're running a, if you're in MedTech, and you're running a great software organization, and you brought in somebody from a great software shop, you know, Netflix, you know, in the Bay area, out. And they did an assessment of your organization and they said, yeah, you know, respect, you guys are doing well. You're doing Agile, you've got, you know, test-driven design, uh, you know, DevOps, CI/CD. You like, you're, you're running a good organization. If you can get that kind of a blessing that you're running a good quality modern software shop, you're already 80 to 85% of the way to where you need to be for medical device design controls. You just need to then stitch in that last layer, which is essentially another layer of risk-based requirements including cybersecurity, um, that are just dotting our eyes and crossing our Ts. And, and, and that's our argument. And, and, and my proof point for people to say, yeah, but you know, other organizations, human lives don't depend on it. Here's my answer to you. I can give you a choice of being in front of two firing squads for a failure of software. One is to be in front of an FDA regulator, or worst case, US Congress answering for why the device was recalled. The other one is that you can be in front of Jeff Bezos explaining why the Amazon.com shopping cart has gone down. You pick who you want to be across from. So, just because human lives may not be dependent doesn't mean that people take it any less seriously. Host: I, I agree that we should be doing cyber screw, look, looking at cybersecurity requirement. It seems to be the exception rather than the norm though. From our experience, the software was developed with like, without any cybersecurity requirements, without any thought to cybersecurity. And then the manufacturer comes to us about 60 days before submission. The regulatory affairs person's like, what did you do about cybersecurity? They're like, oh, we didn't do anything. We didn't know we had to do it. And now we have to retroactively work with the device software developer to or development team to sort of add on cybersecurity retroactively, which is, as you know, not quality from our perspective. And I appreciate you saying that because we, we think quality software has cyber security built into it as well, because if it can be hacked and harm a patient, then obviously that's a problem. So why, what, why do you think that is, um, or maybe, maybe from your perspective, it's, it's different. Like our perspective is, I don't know, Trevor, what percentage would you put on like the clients that come to us that have actually developed secure software? Trevor: It's a slim percentage. If they're developing it in-house, I would say maybe ten, maybe. Um, contracting the engineering out is going to be a little bit better, but still under half. Guest: That's, uh, I'm not surprised. It is unfortunate to hear. I hope the needle's moving in the right direction. So let me give you my, my philosophical answer for this, a little bit of history. Um, and cut me off if this is too boring or academic. Um, and by the way, I speak to this as a, um, person who spent his, you know, his career in technology. I'm not really a technologist. I was an American history major, you know, which is the second most common major in medical device after biomedical engineering. Not, I met one other American history major in my years in MedTech, um, we're forming a club. So, medical devices were predicated on modern science and engineering, which basically meant that we were taking what we know about the science of biology, chemistry, and physics and using engineering to bend the physical world to meet the needs of the human body, right? Again, it's all engineering disciplines, you know, medical disciplines, it's mechanical engineering, electrical engineering, materials engineering, industrial engineering, because we needed to know that our devices were safe and effective. They did exactly what they were promised to do, had the exact result, or in the range of results that we had promised, and never did anything else, you know, especially anything unintended that was harmful. And I don't mock that because that was, that's the basis of the medical device industry. There are still five iron lungs in use in America last I read. There's one guy who repairs them, but there's five people who still have iron lung machines. These machines are like 45, 50 years old. They're still running. So, you know, I challenge any modern software device to have that kind of record. And, and, and medical devices ran safely long before these kinds of things came onto the, onto the market. That said, modern software comes in, and I think it's been a challenge for us. Here's my, my philosophical answer why. Um, I haven't had anybody argue with me on this so far, but I, I would welcome it. Um, biology, chemistry, physics, science, engineering are all predicated on the fact that it's hard to change the physical world. And all of our design controls and practices around quality are predicated about how do we know that we have successfully bent the physical world in the human body? Software is completely the opposite. It's not about sort of constraints. The problem with software is you can do anything, and you have a really hard time finding what it is you want your software to do, or that it's not doing other things that you didn't think about it doing. That's a completely different set of sort of constraints or, or, or philosophical challenges you have to deal with in engineering. And I think the challenge our industry has had is that we've looked at software and tried to apply these, this whole world of physical constraints as a quality mechanism on top of this world of absolute digital malleability and flexibility. And I think everything else that comes out of it suffers as we learn to build it. It's funny, for a while I thought it was like, yeah, you know, we've got to build up our software muscle and you know, I'm going to the gym. My, my legs are really strong but I want to build up my abs so I'm going to do this. And I've come to see it over time. It's more like CRISPR. We have to splice new DNA in, and there's a lot of good DNA to splice in from the tech world, but we have to splice new DNA in, um, to figure out how to run these worlds together. And that's just hard. Trevor: Yeah, and I think that the shift into regulated software was, especially, a little bit of a unique one. Not even just within the medical industry, but regulated software as a whole. So, the applicability to aircraft, automotive, industrial automation and control systems. I think that it is getting better. You mentioned that, you know, the numbers on how much we see with cybersecurity in mind is disappointing but not surprising. I do think it is getting a little bit better. Um, I think that with regulated industries and regulated software, it's still not really to the mature enough state where it's common practice, it's second nature for engineers to go through the development cycle in a safe and effective way. You mentioned earlier that, you know, Silicon Valley brings all of these engineering practices which help create effective, fast software. And I think it's a little bit of a double-edged sword. There's also this mentality out here, and I see it all over with the cycling billboards and companies coming up and then going down left and right is this move fast and break things. Everyone is just on a rush to get something created, get something out there. And I don't think it's as effective with a medical device. You need to really step back in regulated industries and go, okay, what's, what's all the input into this to get this output and how can we get this input in a controlled, documented, repeatable, safe way instead of, you know, hey ChatGPT, make me an app that does X, Y, and Z, and then just ship it. Guest: Yeah, and I, I agree and I actually think, well I would not advocate that every technology company outside of MedTech put in a 1345, 62304 compliant QMS. There is something to be learned from risk-based approaches to development. You know, when CrowdStrike has this Microsoft problem that goes down globally, it's like, well, maybe some risk-based approaches might have helped in there. You know, I think there's, there's value in that. Trevor: I went to, uh, one event not too long ago that was out in Macau in some of the casinos out there. This was a cybersecurity convention. And it was super interesting. We got to go through a tour of the facilities, a tour of the casinos. And the VP of ops over at MGM was giving us an awesome explanation of the way that security is designed within these products, within the gaming industry. And how low the fault tolerance is. Significantly lower than what it can be for automotive. Significantly lower than what it can be for medical devices. And even then what we see. There is zero room for tolerance in these machines in the casinos. But it's interesting that that seems, those devices are possibly some of the most secure products I have ever seen. Hearing the way that the security is built into it, there are cameras built into the slot machines to recognize if you're, you know, behaving problematically around them, it just won't drop anything for you. There is so much built into these products that is just missing and that feels like that is the only industry I've ever seen where security is truly put first above anything else. Guest: Oh, that's fascinating. I'll have to do some reading. I had, I wasn't aware of that, but it makes a lot of sense as a use case for why it's not just safety critical industries that take these things really seriously. So what are you guys seeing in terms of organizations adjusting the fact that, particularly with cybersecurity, your medical device is never done? Because we've been preaching that mantra for a while that your medical device should never be done because of the opportunities, you know, for your device to get smarter and that you can continue to do software upgrades, you know, it's like AirPods when they first came out were decent. And then with a couple of software updates over a year, your same hardware got a lot better. Your Sony TV didn't used to get better over a course of a year. You know, you're, but, um, but they do. And we've been talking to a lot of companies saying, treat the fact that you have to do ongoing monitoring and patching for cybersecurity as an opportunity to just get good at continually pushing updates to your device, either due to threats or opportunities. Just get good at it as a, as a thing. How are you guys seeing that? Trevor: It's not always viewed that way, unfortunately. Sometimes it's viewed as, oh, we have to have this update mechanism to do X, Y, and Z. If we have this update infrastructure, it's causing all of these problems. And we see a lot of companies actually just strip out any update mechanisms in their device, which is something we really, really push against. Um, as I'm sure you can imagine, if there's anything that goes wrong, then they have to do a full recall, reflash everything, push out these new devices. That is a huge lift as opposed to putting in a module that lets it hook up to Wi-Fi and just dealing with securing that update server. So, there is a little bit of a misunderstanding with how that should work from what we're seeing. And I do think that that's probably one of the biggest pain points that we see for a lot of manufacturers is how do they design and secure a update server or update mechanism? And often times, they just see it as not even worth the effort. Guest: Even today with the latest in cybersecurity guidance, you're still fighting this fight? Trevor: Yep, which is especially concerning since the FDA explicitly calls out and says devices should have the ability to receive updates in the field. It's not an explicit requirement. We've worked with a lot of companies that have gotten devices cleared that can't be updated once they're out in the field, anything short of a recall procedure. But the FDA makes it clear, this is their preferred path forward, since if there is a problem, you can fix it easily instead of having to go through this huge process. Um, but with that in mind, people still, still want to try to lock down their devices as much as possible. And I do get where they're coming from. You would think that a simpler product is inherently more secure. There's a lower attack surface on it. And, while I do think that is partially true, you know, compromising a small organization is always going to be more difficult than a huge enterprise with thousands of websites, hundreds of thousands of employees and users, and just massive complexity going all over the place. So, from a security perspective, it does make sense. But the logic just doesn't hold off from a cost-benefit perspective. Having that update mechanism, it lets you iterate your product, it lets you easily deploy security patches without as much as a second thought about it. At the risk of a little bit more complication in your product, a little bit more complexity in the software, a little bit higher of an AWS bill, but there are so many upsides. I am definitely surprised it's as common as it is. Host: Well, we also deal with a lot of devices that are in home use, like oxygen pumps and things that are not really software as a medical device. It's a device that has firmware on it, which, you know, you can argue, does it really need to be updated when it's shelf life is, you know, a year? Trevor: Yeah, and that is another thing that we see is some disposable software products as well, which are one-time use or, you know, a couple times use. And then they're not meant to be used anymore. You don't need an update for something like that. You just iterate on the next release of the product. Guest: Right. In a worst case scenario, you push out a newer product to somebody sooner at, at a cost. It'll be interesting to see how much change will get driven as we start to see born digital MedTech companies. I mean, they're already out there. We're now seeing sort of MedTech companies that are inherently from day one, either purely software, or they're hardware, but they'll tell you really our differentiator is the software and long-term, you know, we're going to, we're going to make our money and have our impact on the software. Some of those companies will start killing it. We're seeing some signs of a few are, but some of those companies will start killing it. And their ability to move fast and to continually deploy more and more value, I think hopefully will be the competitive nudge that the rest of the industry needs to keep up. That they'll say it's no longer a nice to have, we have to have it. And at that point, hopefully, you know, for cybersecurity, you guys can just go along for the ride. Other pressures, other than regulatory requirements will push them to want to be able to push more stuff out, and at that point, you know, cybersecurity is just part of the story. Trevor: Yeah, I think the, the market edge side of it is actually a much stronger motivator than the regulator saying we recommend X, Y, and Z. And we always say this to our, to our clients is, it's recommended that you do blah, blah, blah, blah, blah. Okay, but do I have to? Do I explicitly have to? Well, okay, then I don't want to do it. That's a fairly common response. And, you know, in regulations, if you're not saying you have to do it, there is not much reason for a lot of people to adhere to it. But all of your competitors blowing you out of the water with a more scalable product is a pretty good reason to work on that a little bit. Guest: Yeah. And I'm, I'm hopeful that, that we're going to see some of these board digital MedTech companies, existing ones or new ones coming online that are really going to start to raise the bar for the whole industry. It could come from the established companies. We work with plenty of established companies. But my gut is the real breakthroughs are going to come from companies that are, are digital from day one, but also MedTech from day one. It's not just a bunch of great digital people who came in and said, let's do some MedTech and, oh yeah, you have to fill out some regulatory quality forms over there. Host: Yeah, I'm curious about, uh, both of your perspectives because we kind of touched upon this a little bit with Trevor being in whatever, Silicon Valley. I guess that's what you call it over there. Uh, where things are designed very quickly. You know, you use Chat GPT, come up with software and a week later, it's on the Play Store or whatever. Whereas medical devices, I think the average cycle for to get a device to market, is like seven years. So it's very long. So in terms of innovation and software development, it seems like it's very on the opposite sides of the spectrum because, you know, the regulations and the regulatory, regulated industry of MedTech. So what are your thoughts on like, how that affects like software development and cybersecurity because we're talking like a super long development cycle. Trevor: I think that that is something, it's a little bit of a necessary situation to have. We've been talking about how low the fault tolerance is for medical devices. They need to do exactly what they're supposed to do and never do what they aren't supposed to do. If you have some new dating app and it behaves weirdly one out of every three swipes, who does that hurt? It's annoying to the end user for sure, but that's not, that isn't going to lead to any tangible harm to anyone or anything. It's just an inconvenient bug in an app. If one in three uses of a medical device failed, that device would never see the light of day. That's an intolerable design failure. So, understanding what these fault points are is so much more important with a medical device. And I think that's what leads to the long development cycle. There's a lot that goes into it. There's a lot that has to come out with it where, in a lot of non-regulated industries, you can sort of just do whatever and it doesn't have to be perfect. You can work on it later. It can be super buggy on release. It's not a big deal. Just work with your customers, iterate the product until you get to something good. So, I do think that timelines is also a little bit skewed for, I guess, the traditional tech sector, since, sure, they release something really fast, but it takes a lot of time to work it up to a very good product. And I think the medical industry just puts in that work up front. Guest: It will always take longer to ship a MedTech product. And it probably should because we have extra due diligence steps. That said, sometimes I've said I feel like orthogonal's motto about modern software should be like, orthogonal, no, it doesn't have to be so painful. Like, it shouldn't be as bad as it is. We can do a lot with automation. We're starting to learn as an industry how to do more with AI, not just AI in the medical device, but AI in assistance to the medical device. We can speed things a lot. We will have extra steps, but the gap doesn't have to be as huge. And you can run, frankly, we, I, part of that for us will also be figuring out how to run, uh, you know, we have this idea of the multi-functional device, right? You know, where some of the pieces of it are medical device functions and some are not regulated device functions. We're going to have multi-functional ecosystems. We already have it. We're going to have multi-functional MedTech organizations where it's a, it's a split between what's a device and what's not a device, or what's a device today, but the next release, you know, might change, or it might be different in a different country. We're just going to have to get used to managing at a much better level. Frankly, of architecture, and aligning the architecture with the business and the regulatory piece so that we can speed up certain things. Um, I, I won't turn around, but like the back of our Orthogonal sweatshirt here, um, has our engineering credo, which is move faster and break nothing. And I think that's, that's really what we're all in pursuit of here. Host: That's like the kind of the opposite of what you always say about the Silicon Valley mindset, Trevor. What do you say over there? Trevor: It should be the opposite. Host: What, what is the mindset over there you say all the time? Trevor: Move fast and break everything. Guest: Yeah. Trevor: Move faster and break nothing. That's the way you should do it. Guest: This is, this is sort of our, our, our direct response because we do want to move faster, but if you break something at our industry, it's a human body. Right? And the really scary part is with connected devices, there's the potential to break human bodies at scale. So, um, that's, that's our responsibility and our challenge, both. Host: Well, Trevor can speak to the UK BEC incident that caused some fatalities that was a medical device, right? Guest: Right. Yeah, that, that's the classic case study. It was a radiation oncologist machine. I think it had its own operating system. And the way the user interface is designed, when you hit enter to like, say, okay, go ahead and zap the person with radiation for their oncology, the cursor didn't move to the last, next line until the radiation dose was done. And so the text assumed that it wasn't happening and they kept hitting it and there was no safeguard to prevent it from people getting zapped over and over and over. That was really, as I understand, the thing that really brought the FDA into software and said, we need to start treating software as an engineering discipline that needs to be, you know, regulated in, in with the sophistication that we do for other spaces. So, you know, who knows, maybe I've seen too many Die Hard movies, but maybe it's going to be somebody not just, not just building a botnet on a hospital, but actually ransoming off a bunch of pacemaker controls. Trevor: It was a ransomware attack against some blood centers in the UK and complete denial of care to anyone within the network. Their entire system was shut down. And was one of the first events where they were able to directly pin death to the result of ransomware. There were patients that needed critical care, they needed infusions, and the system was so backed up and shut down, everything was being done manually since the whole network was ransomware. Nobody could get the treatment that they needed, and it was one of the largest NHS blood centers in the UK. So, it was a lot of people going without treatment and some of those people badly needed it and ended up unfortunately passing as a result of not being able to receive that therapy. So, that was another wake-up call that I think really spurred a bit more cybersecurity interest in the hospitals, healthcare delivery organizations. And that's something that we're working with our clients on a lot is how to get ready after the regulators even. Getting ready for the hospital, getting ready for insurance. They're going to have much different and often more involved questions than the FDA on how you're securing your product, since they're the ones taking liability if they bring in a dangerous product. Um, obviously it's a little bit of a shared burden there, but if the hospital gets ransomware, it is their job to have due diligence against cybersecurity threats. They need to ensure that the products they're bringing in are not going to be patient zero for that ransomware attack. And if it is, that is the hospital's problem. Guest: Christian, you wrote a book on cybersecurity, right? Host: Well, it's really about emotional intelligence for highly rational intelligent people to fix the problems, uh, that I think exist in cybersecurity because people talk over people's heads and don't communicate or collaborate. Guest: So the short answer is yes, but it wasn't just cybersecurity, it was a more sophisticated look. For book number two, I suggest you write a book where you compile the case studies of all of these fatal or harm-inducing cybersecurity events in, in MedTech as much as possible or healthcare. So people can stop saying, well, I don't know, it's a, it's a vague, unnounced thing and, you know, to your point, just say, no, no, no, five people died in the UK from this. You know, and we need to compile the really concrete examples from this. Host: We're almost done with a book so we can, we've added some case studies, we can add a few more. Trevor and I are working on a book. Trevor: Book number three for Christian. Guest: Number three. Okay. Host: Well, I think something else that's unfortunate that this happened but it is helping, uh, is the Illumina case, uh, where they basically falsified information and got their device cleared through the FDA and then later a whistleblower came out and said, hey, the device actually has all these cybersecurity risks. So they got in trouble with by the Department of Justice and a few other things and we've had several clients come to us that previously were like, yeah, we don't, I don't know if we really need to do this from the cybersecurity perspective. Now they're like, we need to do everything. We don't want to have a loss on our case, or, or go to, go to prison. Guest: Yeah, look, I think unfortunately, you know, threats to the, to the freedom of, of boards of directors, um, has some value. There needs to be a backstop. You're going to take the salary for being on a board, you better make sure the company is operating right. Host: That's right. It's part of the responsibility. I would imagine. Guest: No, you know what, it's, it's, those things are unfortunate, but hopefully we can shine a lot of light on them. Not to the extent of like, you know, I was just listening to a show where they were talking about when did America stop letting American kids roam around? And apparently we took away American kids' freedom, which has bred all these other problems of anxiety and stuff when we started putting the missing kid faces on the milk cartons. And all of a sudden everybody thought that like every other kid in America was missing and it was this huge danger as opposed to this rare thing. So hopefully we won't freak people out that much, but we do need to, to, uh, have more awareness and have it taken more seriously. Host: The missing kid face on the milk cartons is like the catalyst for some of our, our issues. Guest: That's what this, it was an author talking about why Americans helicopter parent and don't let kids wander their own and track them whereas, you know, for, at least for Christian, I think you and I in our childhoods, we were free range kids. We said, your parents could buy, I'm going out, you have no cell phone. They said, you got to be home by ten, right? You go out on your bike. And now, you know, I'm guilty of this too. Parents want a lot more control and knowledge of where their kids are. And our kids as a result have learned to be less independent, um, which is causing all kinds of other problems. Host: I've never thought about the milk carton and the kid on the milk carton is a, but I can see it now. If you're a parent, you always see missing kids on milk cartons, you're probably thinking, I'm going to make sure my kid doesn't go missing. So I'm going to be overly controlling and have a monitor or tracker on my kid at all times. Guest: Yeah, because you had this missing kid looking at you every time you opened the fridge. So, um, I think it's, it's, it's, it's a, it's a, it's a responsibility of ours to make people aware and to scare them a bit, but to not scare them unreasonably so and, and keep it in proportion, because these are manageable things, right? These are things that can be addressed and dealt with. And most of it's sort of common sense we've learned that we just need to spread. Host: Yeah, but I mean the American way is typically we have a problem, we overreact and the pendulum swings way the other way, other side, and then then we overreact and it swings back and we rarely like meet in the middle. It kind of passes through the middle very quickly. Trevor: We get like a couple weeks of everything being in a good level state and then it goes right back to whatever side. Guest: Well, that's, that's, that's our responsibility as professionals in this industry. So. Host: For sure. Well, we're coming up on time here. I like to ask for last minute words of wisdom or departing words, uh, for our listeners. So I'll start with you, Trevor, uh, so Randy has some time to collect his thoughts and I, you got to say something original this time, Trevor. You always say the same three things. Trevor: I've been mixing it up recently. Host: You have. You, I'll give you credit. You have. Trevor: All right. Well, what I'm going to say this time is that cybersecurity is simply evidence of quality in your product. Essentially, if I had to boil this whole episode down into one sentence, it would be that. It, cybersecurity should not be thought of as this extra thing that you need to do. It's not setting a, setting a chunk of time. You don't go through a cybersecurity study the same way you go through like biocompatibility or whatever. Cybersecurity is something that good developers, good engineering practices are just innately going to build this into the product as opposed to needing separate cycles for it. If you're designing your device correctly, cybersecurity honestly shouldn't be that much of a problem for you. It shouldn't be some defined step, it should just happen naturally. Host: What do you think, Randy? Guest: I will buy that. So I think the one of the things that we've been preaching, um, and this goes through our work on medical, medical devices on the cloud, medical device apps on smartphones, and medical devices that are internet-enabled, you know, can talk to network is, historically medical devices, we made sure they worked and were safe and effective by building them, testing the heck out of them to a certain point, putting a stamp on it, and then locking them down and never touching them. We're past that world. We are now in this much more open world where we are not in direct control of everything on the device. We don't directly control, you know, a computer in AWS, and you go to AWS because they're secure. Why are they secure? Because they never change things. No, they're secure because they change things hundreds of times a day, without checking with you. So we need to be able to admit that we have much less direct, much more indirect control and much less direct control than we used to have over devices, and be okay with that and just get really good at managing risk around that. But kind of embracing uncertainty as opposed to hoping we can make it go away because it ain't. Host: I like that. I'm a big fan of embracing uncertainty. I agree with you, Trevor, on this one that cybersecurity is quality. Uh, I think I don't think we've actually used that phrase before. But it's ironic because the guidance from the FDA that was finalized in June, uh, 2023, uh, is called Cybersecurity in Medical Devices, Quality System Considerations. So, obviously, they're thinking along the same ways. It's like a quality device should have cybersecurity in it. It shouldn't be an afterthought. It should be built in to the, uh, and designed into the product. All right, awesome. Well, thanks everyone for tuning in. I hope you got some value out of this episode. And we hope to see you on the next episode of the Med Device Cyber podcast.