Prevention Is Better Than Cure: Applying Medical Principles to MedTech Cybersecurity

Cybersecurity is evidence of quality software. So from a cybersecurity perspective, if a device is compromised or hacked into an IVD, and somebody has sepsis but it says they don't have sepsis, that patient could die. So you cannot have quality software, quality processes without having cybersecurity inherently tied into it, since that's pretty much a good product, especially in the medical space. There is either intentionally or unintentionally a lack of consideration of A, the clinician and B, the user environment. Having your ISO 13485 certificate or CE certificate, that's not a guarantee of a good product. Prevention is better than cure. Christian: Hey, welcome back to another episode of the Med Device Cyber podcast. Today we have a guest, uh Steven Smith. Steven uh comes to us from... Where you coming from today, Steven? The UK? Stephen: Cambridge in the UK. Christian: Cambridge. I I did my first punting in Cambridge a long time ago. Punting, if those of you don't know, is where you're on a boat and there's a guy with a stick that pushes the stick down to the bottom and kind of pushes the boats along. It's called punting. Is isn't that right? Stephen: That's right. Christian: I don't know why they call it punting. I think punting is you're kicking a football or something, but in the UK they they kind of change everything up so to keep us confused as Americans, I think. Cool. And uh we got Trevor here as well. Trevor, you're coming from NorCal, I believe, right? Trevor: NorCal. here for the next hour and a half then got to catch a flight. Christian: I'm coming from Austin at a hotel. Um, I'll see Trevor later on this evening. He's going to be joining us in Austin. I was just here doing a this weekend a Formula 4 advanced course, but it was 20 degrees out one morning so we had to put the uh wet tires or the treaded tires on the car because there was frost on the track which which makes it a little challenging to drive, but I I survived. Cool. So Stephen, you want to like give us a little bit of background about yourself and your organization and uh what you do in the medtech space? Stephen: Sure. Well, my name is Stephen, as as we've said. Uh, I started working in medtech way back last century, actually in 1999. Christian: 1999. The last century. The last century. I guess that was the last century. Last century. Stephen: Last century, yeah. So this is my 27th year, my god, that's depressing, in medtech. So I started as a as a Q, quality assurance auditor for a for an IVD company here in the UK. And being an auditor, I got talking to a lot of people, interacted with a lot of people, but more importantly that was I guess listening to a lot of people because auditor, being an auditor you got to talk and you got to listen as well, it's a two-way thing. That's something I think a lot of auditors have actually got to understand. So obviously I had to audit to to to regulation and listen to their answers, but I also had to in some cases question their answers. So, while the the products of this company were were pretty good, they were really good actually and some of them from 20 odd years ago are still still in use today. People's perceptions on what quality regulatory was all about was I guess a bit poor. They knew they had to be regulation and they knew they made medical devices, but they had no idea what type of medical devices they made, what they did clinically, which surprised me. So I went about doing a bit of research, finding out what these devices do myself because I was relatively new, and I thought, okay, these things are actually quite important. So I I made a product awareness course, and that and I got group group of people together, mainly on the production line, "Guys, this is what these devices do." And it was a revelation to people. "Oh, the these actually could cause risk to to people. These could misdiagnose. We could be on the receiving end." And that changed their perspective. I guess it changed my perspective as well seeing how they reacted. And that's I guess sparked my course of my career in QA and RA in medtech, making sure that what I did conforming to regulation actually had an impact, not regulate for regulation's sake, but making sure that regulation and what I did was effective. That's probably a long answer to a short question. Christian: No, I think it's the same challenge with cybersecurity. A lot of people think it's just a something you have to do. But like you said, if a IVD causes a misdiagnosis or a delayed diagnosis, they can drastically affect a patient. So from a cybersecurity perspective, if a device is compromised or hacked into an IVD, and somebody has sepsis, but it says, they don't have sepsis, that patient could die. So it's about patient safety. Like you said, I want to ask a couple questions here based on what you said. So QA and RA are two different things, and somebody once described RA as offense and QA as defense. Do you agree with that? Stephen: To a point. QC's more defense. Quality assurance is more future tense. It's assuring quality, not necessarily defending it. It's assuring it, so you don't have to defend it, if that makes sense. Christian: So if I do QC, I got the quality control. Somebody comes in and says, "Hey, I want to check your QMS." That would be the the QA would be to make sure it's set up right. But the QC would be we actually have these things implemented according to the QA. Stephen: Yes. Quality control is past tense. You're checking something which has already been done. Quality assurance is putting the systems in place to make sure it is done properly. Christian: Makes sense. From a cybersecurity perspective, how does cybersecurity fit into RA and QA from your perspective? Stephen: It comes down to risk. Cybersecurity, the procedures for cybersecurity have got to be inherent in your design process for a device. And those procedures obviously got to be in the quality system as well. As you touched on before, there is a whole array of risks associated with cybersecurity, and you've got to understand what those risks are. Anyone who's worked with me will know I go on about risk all the time because that's what it's all about. So you've got to have cybersecurity as a design input. Know where those risks are. And those risks will change over time, particularly with cybersecurity. Trevor: I think one thing that I heard once that was a really interesting way to look at cybersecurity is that cybersecurity is evidence and an artifact of quality code. So you cannot have quality software, quality processes, without having cybersecurity inherently tied into it, since that's pretty much a good product if it's secure or if it's safe, especially in the medical space. So, you're saying that if we have quality systems, if we have quality practices that we're adhering to, we should inherently have cybersecurity within our devices. Stephen: Absolutely. And you've got to know where your devices are going to be used because I I guess some of you guys know more about cybersecurity than I do. Practices and threats will change between geographic areas, countries, etc. So you've got to know what risks this will pose to your device, what security risks, what the impacts of those risks will be, how to mitigate those risks. Christian: So that's a good point. I was, I just did an interview this morning and one of the things I mentioned from a cybersecurity perspectives, perspective is clinical workflow. Like you said, I think there's a lot of assumptions made about how a device may be used and we often overlook what is the disruption or impact to the workflow in the healthcare delivery organization if this device has a quality issue, has a cybersecurity issue because it's not you know, just the device, it's the whole workflow and the whole ecosystem around the device that's impacted. Stephen: Totally agree. One thing I have noticed particularly with startups, and I spent most of my career in startups, is that, again, going back to risk, there is either intentionally or unintentionally a lack of consideration of A the clinician and B the user environment. They don't necessarily know what the clinicians want or what goes on in that user environment on a day-to-day basis, unless they have been in that user environment or get representation from that user environment, how are they going to know? I mean I've been in risk assessments where I've actually said stop and one example I can give is for a device that was used in an intensive care unit. They were thinking of 10 or 12 of us in that room. Nobody had ever been in an intensive care unit. So how could they know what the risks are in that unit and how to mitigate them? So you're you're absolutely right. You've got to have experience and knowledge of how your devices will be used and misused on a day-to-day basis within the clinical environment. Trevor: Even outside of a risk perspective, I feel like this is a problem with just understanding market fit. People are looking for a problem. They're looking for a workflow that is just fine the way it is or is going to be severely uprooted if they implement this brand new solution. And I think people forget that doctors don't want to change what they're doing. They don't want to add a new password, they don't want to add a new process, they don't want to add another layer. I don't want to add another layer. I get where they're coming from. And a lot of med-tech innovators are creating these really complicated, difficult-to-integrate solutions and trying to fit a square peg into a round hole within the ICU. And it's causing a bunch of friction with their users who are the doctors, and they probably could have had a much easier path forward if they had started by talking to doctors. So even outside of risk, product-market fit gets really impacted by this problem. Christian: Isn't this where the KOL comes into play? The KOL, the the newest acronym out of the list of ever-growing acronyms. Yeah, well in that case, the doctor would be the KOL. You go talk to that KOL, get his opinion about it. Say, "Hey, what do you think about this?" He'll say, "This seems clunky and annoying to use. I don't think this would be effective for me." You go, "Great, back to the drawing board." Christian: What are the startups we have been working with, they they have the company, but they have a KOL, the key opinion leader, that's a surgeon that knows exactly how this device, which helps with blood clots and coagulation and a few other things, would work in the field. So I think like you said, if you if you're trying to develop it in a vacuum, it's a little bit well, it's very challenging and it may not ever have a market fit, but you can have somebody augment your team that would be the user of this device to help you make sure you're designing it in a manner that it would be adopted. Stephen: Agreed. Another thing we've got to consider, or what companies don't consider, is that doctors, surgeons, or whatever, they have different skill sets. I mean, I've I've worked for a company that made devices to be used by surgeons, right? I said, "Well, what type of surgeons?" That's a very broad user spectrum. And even within, let's say an obstetrician-gynecologist, I'll use that an example because my wife is an obstetrician-gynecologist. They have different skill sets. Some surgeons, consultants, like to use the latest technology. Techno-geeks, call them that. You've got the other side who are not techno-geeks. They like the manual instruments, devices. They're still coming to terms with the steam locomotive. They don't like high tech. Again, those who have very both surgeons, obstetricians, gynecologists, but they have different risk profiles, different usability risks. Certainly in my experience, what I have learned through work and through being married to a doctor is that nobody can break things like a doctor can. Nobody. It's incredible. My car is testament to that as well. Trevor: And I think that's a great point. And if you're not careful and not trying to balance the line, you're going to ostracize one of those groups. You're going to make something that's way too high-tech and way too frustrating for someone who likes doing things a little bit more old-school, or you're going to make something that's way too simple and basic and not innovative enough for someone who's really into these new cutting-edge technologies. And I think finding a way to balance seamless usability and breakthrough technology is a really, really hard challenge to solve. But it's a silver bullet if you can figure it out. Something that doctors love to use and has a new way of covering medicine, that's fantastic. Stephen: Yep. You've got to talk to them. You got to get a broad consensus as to what they want and what the broad risks are so you can mitigate those risks accordingly. Christian: Do you think, Stephen, over the years, from your experience, you know, you said you've been in medtech since the last century, have things changed from a cybersecurity perspective? I hope so, but I feel like things are super slow from a cybersecurity perspective to change. Like people still don't understand why they need cybersecurity or what cybersecurity is really about. What's your perspective? Stephen: I agree it's changing, but not at the rate it needs to change. It wasn't really a thing 10 years ago, I could probably even say five years ago. Now it is a consideration. And I think the FDA and to to an extent the MDR as well, you know, in Europe, are forcing that. But it's still slow. It's still an afterthought, as it were, as opposed to being at the forefront, as opposed to being a design input into devices. Christian: Why do you think it's still an afterthought? Given, you know, from my perspective, we've had lots of product recalls, we've had the Department of Justice in the United States get involved with a company that falsified cybersecurity information, we have mandates, we have lots of people getting rejection letters from the FDA and MDR. So I'm wondering like why it still is not a forethought, it's still an afterthought like you said. Stephen: I guess there's two answers to that. One is it's going to add extra work. Particularly for startups, they've got... cyber security involves again, risk. Those risks are going to have to be mitigated. Mitigation takes time, it takes money, it adds to project timelines. For startups especially, they've got they've probably promised shareholders, investors that they're going to have a regulatory submission by end of June, for example. If we add cybersecurity risks, that's going to push that out. And I've seen this in other areas as well. I've I've worked in places where there has been no clinical import and I've said to one I said to one design director once, 'Look, I can get a clinician in here to tell you how these devices are used. I'm married to one, you know, I could bring her in. It won't cost you anything.' The answer was, 'Well, she'll tell us something we don't want to hear.' Well, yeah, that's the idea, guys. 'cause you either hear it now or you hear it in the field. You choose. So I think, and I to your question Christian, that that's part of it. The other part is no one wants to hear their baby's ugly. They're not going to want to hear that it's not going to work in this area. There are going to be cybersecurity risks which might throw the project timeline right back. And I guess a third point is, they probably just don't think of it. They don't think of it, they don't understand it, and to get that necessary expertise in, again, is going to cost money. Trevor: I think that's a common theme even outside of just trying to understand market-fit or risk is people don't want to hear what they don't want to hear. And I can think of times where we're trying to we're talking to a prospect or we're talking to a client about the problems they're facing and they'll they'll load these questions. They'll say, "Do you think we should do this strategy? Do you think we should put this control on the device?" I go, "Absolutely not, you shouldn't do that." They go, "Well, this is going to be easy and cheap for us to do." I go, "Yeah, it's going to be easy and cheap for a reason. It's not the correct thing for you to do right now. This is the correct thing to do. It's expensive, it's difficult, and it's going to take a lot of time. This is what you have to do to get towards where you need to be." You can't just take the shortcut and try to look for validation. And sometimes we'll even see, you know, I I can think of times where seven different consultants are brought in to face the problem, and whoever comes up with the easiest solution is the winning consultant out of the group, even if it ends up going back to the other six and going, hey, that didn't work, let's try again. Stephen: They've got a consultant to tell them the answer they want to hear. Christian: Yep. And like you said, it's ultimately about risk. I think life is ultimately about risk and managing risk. So, if you don't know the risk and you pretend they don't they're not there, it's how do you manage it? And especially with bringing a product to market, there's a lot of risk. And it's about, how we mitigate these risks? There's risk our reimbursement strategy might work. There's risk it may not be able to sell to a specific health care delivery organization. You know, there's a lot of factors or biocompatibility study might may fail. There's a lot of things to consider. And the approach like we don't want to know about it because it may cost more money is like, like I said at a talk a couple weeks ago at JPMorgan, it's better to spend $5,000 now than $500,000 later. It's difficult to convince people still to spend the 5,000 now, so they end up spending the 500,000 later and I don't want to say I told you so, but it's like maybe it's just human nature. Stephen: It is. It's it's Christian: And I don't wanna go to the doctor, we don't wanna get blood work done because they may tell us something is wrong. But if we wait until it's actually wrong, we may not be able to do anything about it. And it may end up affecting our lives much more than if we could have said, 'Oh, my cholesterol is going up, I need to change some habits here' versus waiting until it's a big problem later on. Stephen: Prevention is better than cure. Christian: I'm guilty of that too. I don't wanna, I haven't been to the dentist in like seven years. Trevor always gives me crap about not going to the dentist 'cause I had a traumatic experience the last time, and I'm just like what are they going to say? I have a cavity and drill a hole in my tooth and fill it with something? Like, I don't know. I'm probably not that's what they do at the dentist, yeah. ...But why? Like what what is a cavity that goes unhandled? What does it matter? Is it gonna like make my tooth fall out? Trevor: Yes. That is exactly what it does. Christian: Okay. alright. well maybe i should go to the dentist. But i brush my teeth, I don't eat a lot of sugar, so they should be okay. I floss, I do all that stuff. And I heard when you when you get older, you don't get cavities that much anyway. Trevor: That is actually true. Christian: Okay. Cool. So we're coming up here on time. What are some last minute words of advice? I'll start with you, Trevor. Yeah, what's some last minute words of advice to our audience here listening to this discussion, which we've covered a lot of things. We've covered responsibility, approved versus cleared, regulatory RA versus QA. So a lot of factors we covered. So what's what's some advice to tie this together? Trevor: I'm going to borrow from myself earlier and say cybersecurity is evidence of quality software. If you are adhering to a quality process, these quality processes are generally an invisible component of your product. They're important, but they're not something you can directly see and attribute. That's why the traceability, the verification that you're following all these is so important. But I think that cybersecurity and quality are intrinsically tied together and that cybersecurity is evidence of quality software. Christian: Alright, Stephen, what do you, what do you have to say? The parting words here? Stephen: I think know your risks, know where those risks come from. Think outside the box. Know your users, what goes on on the day-to-day basis. Know their user environment. What systems is your device going to be plugged into? What countries? That's going to present different risks. Are there different practices in the countries that your device is going to be used? because it might not be the same. So just know your risks, make sure those risks are understood as early as possible. As we said before, prevention is better than cure. You don't want a recall. Christian: I agree with that. I just did my advanced Formula 4 car training this weekend and I tend to not want to let anybody ever pass me. So I was making mistakes. So then the second session, I decided I don't care if people pass me, I'm going to work on my entry speed, my exit speed, hitting the apex, all the fundamentals. So I slowed down. And then the last session, I went much faster. So in some cases, I think it's important to slow down, like you said, understand the risk, work on mitigating those risks, and then you can actually go faster. Because for me I had a lot of risk, like I didn't know my threshold breaking, I didn't wasn't hitting the apex's right. So if I were just try to brute force it, I would have crashed the car and there it would have been the cure versus the prevention, right? So it's the same same concept. I didn't crash the car. So I'm here. I made it. There you go. Good. It is good. It was super cold and slick, but all good. Awesome. Well, thanks everyone for tuning in to the Med Device Cyber podcast. I hope you found value in this episode, and we'll see you in the next one.