Balancing Innovation and Regulation in MedTech Development with Karandeep Singh Badwal | Ep. 35

In this episode of The Med Device Cyber Podcast, hosts Christian Espinosa and Trevor Slattery are joined by Karandeep Anand, a UK-based quality and regulatory consultant and founder of QRA Medical. The discussion centers on the complex landscape of regulatory affairs and quality management systems (QMS) for medical devices, with a particular focus on the unique challenges presented by Software as a Medical Device (SaMD) and artificial intelligence (AI). Karandeep shares his background, which began in pharmaceutical science before pivoting to the medical device industry. Over the last several years, his work has concentrated on the burgeoning field of software, AI, and machine learning, where he observes a significant disconnect between rapid innovation and the rigorous demands of regulatory compliance. He also hosts the MedTech Podcast, aiming to demystify these often-confusing topics for a wider audience. The core of the conversation revolves around the common pitfalls that MedTech startups and innovators encounter. Karandeep draws a helpful analogy, describing regulatory affairs as the "offense" (getting the product to market) and quality management as the "defense" (ensuring the product and processes are safe and effective through proactive, preventative measures). He argues that quality is not just a department but a fundamental company culture. A major issue he frequently encounters is companies developing their software products well into advanced versions before considering a QMS or proper design controls. This creates a massive, often insurmountable, challenge of retrospectively building a design history file and validating the product's development, a process that should have been integrated from the very beginning. Similarly, cybersecurity is often treated as an afterthought, with companies conducting penetration tests on early versions that become irrelevant as the software rapidly evolves, leaving the final product with unassessed vulnerabilities. Karandeep and the hosts also explore the broader reasons for the high failure rate among MedTech startups. Beyond technical hurdles, many ventures fail due to a lack of early planning around market fit, reimbursement strategies, and the specific regulatory pathways for their target markets. A crucial piece of advice is for companies to shift their mindset: they are not software companies that happen to make a medical device, but medical device companies that use software. This perspective change prioritizes the highly regulated nature of the industry from day one. He stresses that integrating regulatory, quality, and cybersecurity frameworks at the project's inception is far more cost-effective and efficient than trying to patch them in later. The conversation underscores that while standards like IEC 62304 provide a baseline, the dynamic nature of AI and software demands a more continuous and integrated approach to ensure patient safety and successful market entry.

Host: Hi, welcome back to the Med Device Cyber podcast. Today we have a guest, uh, Karandeep. We're going to be talking about regulatory affairs, quality management systems, and some of the differences that have come out recently, uh, across the global regulatory affairs, um, perspective. Host: Uh, Karandeep comes to us from the UK. I'm your co-host, Christian Espinosa, and I've got the co-host here today, Trevor Slattery. I think one of the podcasts we did before, I wasn't here, Trevor handled it up by himself, but he did a good job. Host: So, how's it going, Karandeep, today? I think you're coming from the UK today, right? Guest: That's correct. Thank you for having me on. Host: Awesome. You want to give a little bit of uh background of what you do in your organization does? I know you're also a podcast host. Maybe a little bit about uh, you know, your podcast and what how many years you've been working on that and just a little background on you. Guest: Sure. So I'm Karandeep and I'm founder of QRA Medical, a quality and regulatory consultancy working within the medical devices space. Um, in terms of my background, I actually still come from a pharmaceutical background, which was what my education was based in. So I did a bachelor's in pharmaceutical science and a master's in pharmaceutical quality by design. But it just so happened that when I left university, the first job that I had was actually working within medical devices and I just kind of kept it going from there. Guest: I started working in traditional devices with things like pacemakers, defibrillators at St. Jude Medical, which eventually became Abbott. And over the past sort of four to five years, I've been doing a lot more in the software, AI, and machine learning space where, that's where it seems that the medical device industry is moving forward as well, you know, not just in other industries as well. Guest: Also outside of that, as you mentioned, Christian, I am host of The MedTech Podcast, which I started back in 2021, which I interview different MedTech leaders, founders, CEOs, experts, etc. in the field and give them a platform to share their story. Guest: I also I a content creator on LinkedIn as well for anybody who does follow me on LinkedIn. A lot of people find quality and regulatory often very confusing and there's a lot of guidance out there, you know, if you was to go out and read the regulations, you probably walk out more confused than when you started. So the my point of the content that I make is just trying to make things a little bit more easier to understand, effectively. Host: Awesome. Well, I find quality, quality and regulatory a little bit confusing as well. I we had someone on the podcast before that described regulatory as offense and quality as defense. Would you agree with that statement? Guest: Yeah, there is some element of truth with that because with quality is often to what, taking a proactive approach, you know. For example, the biggest tool that we use often in quality is is often the CAPA corrective action preventive action. A lot of companies out there take a corrective action, they wait for something to go wrong and then they try to fix it. Guest: But what quality often uh tries to encourage is taking a preventive approach. You know, look for something that may potentially go wrong and put something in place to make sure that thing doesn't go wrong in the future. So yeah, I would somewhat agree with that. Guest: Whereas a regulatory, that's more about, you know, getting that market approval, getting the product out there and fulfilling that. Whereas quality, yourself is on the company as a whole. And quality really is not a department, it's more of a culture. Host: What, um, I know you mentioned you're doing a lot of work with AI and software as a medical device, which we see as well, the industry shifting that way. What are some of the biggest uh challenges you've noticed uh working with your clients from a consulting perspective when they have software and some sort of AI model? Guest: The issue that I've often found with companies, so let's for example, I bring them on as a client and they're on version 15. And when I try to go back in time and say, okay, what did version one look like? There were never any proper design controls in place. So realistically, they don't really know the changes that got them from V1 to V15. Guest: Or in some cases there were not the high level of it, you know, but how did that affect the code? Can it give false positives? Can it give false negatives? Uh what are the risks that come with it? So often just trying to do things like that retrospectively can be difficult. Guest: And the second one, Christian, again, timely to the podcast is of course cybersecurity. You know, they all realize that there needs to be some cybersecurity to it but then how far do you go to what extent do you take it? How much cybersecurity is needed? Or in some cases where companies have done cybersecurity, they've done things like penetration testing, but it's probably been done like a version that's two to three years old and now the software has changed so much when they now need to do that level of testing again and then the company's thinking, okay, great, does this require a full test? Does it require a partial test? So companies often out there don't really know because even if you was to go out and read the guidance documents from the FDA, etc., it would tell you that you need cybersecurity but to what extent? To what sort of testing and, you know, how often does this testing need to happen? And these are the questions that I often get from clients. Host: Yeah, that's uh an area that uh we navigate quite often and a lot of questions come up cause cause the requirement is like typically people say once a year is when you need a penetration test. But as you said, if you've gone from version 1 to 15 and there's significant changes, you probably needed 15 tests if that if those changes went in on one year. Um, what is your perspective, Trevor with what Karandeep is saying and our clients coming to us about cybersecurity like in in the versions and do they actually have evidence of the changes between the versions from your experience? Cause you're more on the delivery side than I am obviously. Trevor: I think it's uh, perfect timing for this question to come up. Right before we started recording this, I was actually helping a client with this exact question and that's where do we draw the line between what is a cybersecurity related change and what is not? And there's a little bit of ambiguity. I know the FDA actually just about a week ago published some new updated guidance that provides some clarity on what they're looking at as far as changes that may impact cybersecurity, but it's not an exhaustive list. Trevor: The examples that they provide are things that will affect the authentication mechanisms, things that will affect encryption or how data is transferred or processed. Uh, in general, those are really good examples to go by or any significant alteration of the device functionality. That's likely going to need to have some more penetration testing around it. Trevor: I think where we can see companies getting away without doing additional penetration testing is minor changes, things like cosmetic tweaks or small changes to an algorithm if they have this, you know, AI enabled cloud platform. If it's not affecting the way that a user can interact with the device, which would be how an attacker interacts with the device, the cybersecurity risk and the cybersecurity modifications are likely going to be a little reduced. Host: Agree. And one one of the areas that I I think is challenging is with AI, it technically is not cybersecurity, but I feel like we end up talking to a lot of uh clients and prospects about this is like how they train the model with AI. From your experience uh Karandeep, is this something that you feel like the industry has a good handle on? Like the data they get to train the model or is this still in its infancy? Guest: In my experience, I'll very much say it's in its infancy because, you know, how do you validate whether that data is good or not? You know, that's the issue with AI. You can have two of exactly the same products. One has a good data source and one has a bad data source. But on paper, they will look exactly the same. The difference is the one with the good data source would have a lot less bias, will give a lot less false positives, false negatives and probably give better results in comparison to the one with the bad data. Guest: But again, when it comes to training, that's one thing that I find especially from a regulatory perspective, is not really looked into, you know, what is the validity of the data that they're using to train that particular model? Host: Do you feel like the regulatory authorities have a decent handle on making sure the model has a proper training or are they really, I guess, putting that responsibility on the uh manufacturer? Guest: I think it's very much on the manufacturer. I mean if you was to look at regulatory bodies, you know, FDA, etc., how many people out there actually understand AI, machine learning, software. The chances it's going to be very, very few. So what they often do when it comes to regulatory is often it's a documentation check. They're not really playing around with the device or testing the data or seeing really how it works. They're just relying on the documents that being given to them and they're using that for a regulatory approval. So again, if it looks great on paper, then that may well be the case, but it may not be that it works well in reality. Host: And from a cybersecurity perspective, Trevor, what what are some of the things that have changed that we have to look at when there's software as a medical device with AI, for instance? Trevor: AI is still such a new technology and some of the cybersecurity threats that are being discovered in it are coming out at a pretty astonishing rate. At the same way that any new technology, a lot of risk is going to be discovered. So trying to stay on top of a rapidly evolving technology where the attackers are trying to understand it just as quickly as the defenders, and each one of them sort of becomes a cat and mouse game to try to figure out who's able to push the security research forward the fastest. Trevor: So I think that's a little bit of a unique challenge that comes up every once in a while. I know a recent example of that was around 2008, 2009 when smartphones were becoming far more prevalent. Every medical device had a companion app attached to it for largely for marketing purposes to say we have a medical app. And then the FDA started to clamp down, started to regulate these as medical applications. And so now all the regulations were enforced as far as how you're handling security in this application. Trevor: But the threat landscape was running wild at that point since it was just such a new concept and people weren't really sure what could go wrong there. So I think we're seeing a similar case with AI. Host: And with quality, I know, I know uh Karandeep, you do regulatory and quality and QMS is part of what you do in ISO 13485. Where do you see like, kind of what you mentioned earlier, like version one to 15, you know, there should be the design history file in the QMS. Like, where, why is there such a gap? Is it an awareness problem? Is it, you know, a funding problem? Like we have the same thing with cybersecurity. There's like a big gap. People don't really think about it till later. From your lens, what do you think the reason is for that that gap? Guest: So my view is when they start the software development phase, the last thing they think about is quality or regulatory. And they start thinking about the quality management system when it comes to the time of thinking, okay, great, we're a medical device and we want to get regulatory approval in a year or two from now. But by then, they're already on version seven, eight, or nine, etc. and they've built that without a quality management system. So there never was really a design control process in place at the time in terms of how to do it. Guest: Or if there was a design control process in place, it wasn't really to the standard of which is required under 13485. So I think that's really where the gap comes into it. But then my view here is why I always say to companies is in your early stages Just have a partial quality management system. You're going to want document controls, you're going to want record controls, you're going to want design change history files, etc. But these things ain't just limited to medical devices, you know, you want document controls, you want to have records, you want to record changes, you want to see how changes are made. Guest: So my recommendation for the listeners out there if you're in your early stages, just adopt a partial QMS. It doesn't have to be a big fancy system. It could be paper-based, but just have some sort of change and then ideally try to follow 13485 principles. So when you are ready to have a full quality management system, it's more of a seamless transition into it. Host: When do people typically engage with you? Probably like two, too late to hear your advice you just gave right? Guest: I mean, ideally, I should be there at the start. But then what do companies do is they think, hey, great, this is it. We've got this product, it works, it's fantastic. We've been to conferences, everybody likes it. Let's get regulated. And it's just not as simple as that. Like, and then like, and particularly with companies, what do they try to do? And you guys have probably seen it as well. Our product has 50 different claims. It can detect 50 different types of cancer. And I'm like, guys, yeah, it doesn't really work like that. You can maybe have two or three different indications. And it's also dependent on your clinical data as well. Guest: So often they come to me at the very late stages, but ideally they should be coming right at the start. And then what I often say to companies, if you build quality and regulatory at the beginning, it's actually cheaper in the long run. You know, trying to fix something and do things in retrospective, the example I was mentioning like design history files, etc., it's somewhat impossible or like very difficult to do and there's always going to be gaps. And then sometimes trying to patch something is a lot more time costly than it is to just do it properly from the start. So the answer to the question is ideally yes, they should be there at the start, but they often come at the very late stages and expect me to work some sort of magic and somehow get it through. Host: What do you think, Trevor? Is that a similar situation for us? Trevor: Yeah, I was going to say that sounds about exactly like the way we answer that same question. So, Host: Well, I think from an innovator perspective, I try to look at the world through other people's lens. If I'm trying to come up with a product that I don't know if anyone wants it, you know, it's an MVP, the minimum viable product, why would I care about regulatory or cybersecurity when I don't even know if this thing is a a good fit for the market, right? I mean that's probably the dilemma they're facing. So, you know, if you're talking to an innovator, how would you address that perspective? I'll start with you Trevor then I'll go over to you Karandeep. Trevor: I think it comes down to having your technology, having your product, if it's something that you're creating because you see a market fit, you want to prove that market fit. And if you're able to do that, if you're able to prove you have a market fit, if you've covered all of your bases and you do actually have a good product, then you want to ensure you have your quality all the way going back. Trevor: Uh, similar to quality from the actual quality perspective, I think cybersecurity, it should typically be thought of as quality in software or quality in a product. Safe products are good products. They're high quality products. So, assuming that your product does have this market fit that you see and you will be able to convey that to potential investors, to potential customers, then you want to make sure that you have the best version of that product that you can put forward and the best version of that is going to be a secure, high quality, safe product. Host: What do you think about that, Karandeep, that cybersecurity is part of the quality? Guest: It should be, really. It should be part of your quality management system. It should be part of your procedures. You know, every time there's a design change, for example under 13485, there has to be some sort of impact on the quality management system. There should also be an assessment, you know, on risk as well. Cybersecurity is also part of your risk management. So yes, cybersecurity really needs to be in-woven within your procedures and people need to realize and particularly software developers, have you guys ever tried to tell a software developer what to do? They probably don't like that, is it, right? Guest: So yeah, you've definitely experienced that. They're fantastic at what they do. They're very, very great at their job. But you know, trying to tell them to work in an agile fashion or a design change, they're used to, you know, I want to add this feature, change a couple of buttons in the code and press enter. In medical device world, we can't do that. We need design inputs, we need design outputs, we need design reviews, we have to record everything. And then sometimes if I develop something, hey, this is just a small change. I just put it through. And then somebody like me in regulatory comes to goes, hold on a minute, why is there a change in the algorithm? It's like, oh, Karandeep, we just made it slightly easier to do. And I'm like, you've just introduced new risks. And this is sometimes there's a communication, and what needs to be done. Guest: So realistically is companies need to change their mindset because what happens in software medical device companies, they act as a software medical device company, sorry, they act as a software company that just happens to be a medical device. They need to flip the mindset into they're a medical device that just happens to be a software. With that approach, a lot of these things make sense. Host: What do you think about IEC 62304? Uh if I'm a software development company, I supposedly comply with IEC 62304, that means I develop secure software with the documentation uh in terms of medical device, uh for a medical device. Do you think that standard is actually helping or people actually following that standard? I'll start with you Trevor, then I'll go over to Karandeep on that one. Trevor: I do think that it's helpful. I know it's getting a little bit dated at this point. And so I think that, and I know that there are, Host: What's, what's dated about it? What's dated about it? Trevor: The last change to it was, gosh, it's it's an older standard. I think the finalized version was published in 2006. So it's development has changed a lot since then as the technology is, the same way that I was talking about how cybersecurity risk has evolved so quickly with these evolving technologies. Development practices and software documentation, software testing, software verification, validation are changing in the same way as all these new technologies are getting introduced into a product. Trevor: So I think that it's not the same landscape for developing a medical device anymore. Developers aren't using the same tools, they aren't using the same procedures, they aren't using the same frameworks and I think that some of the guidance documents need to change a little bit to accommodate for the recency of some of these later technologies. Trevor: But having said that, I still think it's a great starting point. It talks about some of the secure steps in a secure software development life cycle. So that's covering that total product life cycle the FDA wants to see and make sure that developers aren't just going in and making changes because they don't think it's going to be a significant impact. They're able to follow a clear, reproducible step and have all the documentation to support it. Host: Cool. And what's your perspective, Karandeep? Guest: So how often is the word validation used in the IEC 62304 standard? The answer is never. It's not used once. So yes, it's a great standard, but it talks about software verification, but it doesn't talk about validation. And that's I think where 62304 falls short. And just as Trevor was saying, it's back from 2006. This idea of standalone software and AI machine learning was something that you saw in sci-fi movies or Hollywood films, etc. You know, you never thought of this idea of it being a standalone software medical device. So I think it's a great framework and a starting point, but if you're just compliant to 62304, that's just like the bare bones. You know, there's a lot more that you need to do on top of that. Host: That's interesting point uh, that it doesn't talk about validation. So let's let's just kind of unpack that for a second uh so everyone understands the difference between verification and validation. Um, do you want to explain the difference, Karandeep? Guest: Sure. So in simple terms is, let's just say you go to the electronic store and you buy a television. Verification is, you open the box, there's a television there, there's a remote that comes with it and there's a power cable. That's verification. Guest: Validation is, does it work for you? Does it have Netflix? Does it have Amazon Prime? Does it have all the different things you want to do? You know, if you want to play games at 144 hertz, does it allow you to do that? So that's what validation is. It's, is it fit for purpose? Is it fit for what you want to do? Guest: And another analogy that I can give is you go to a suit shop and you get a suit jacket. Verification is does it have a pocket? You know, does it have two holes for your arms, etc? Validation is can you wear it to work? Is it comfortable? Can you move around in it? Is it fit for purpose? So that's the best way to probably describe the difference between verification and validation. Host: So in in your experience, Trevor, um, and and and I guess as a whole for both of you, if I'm developing a minimum viable product and my software developers are following IEC 62304, technically they could develop what is designed, but it may not be actually valid in the market. Which seems contrary to agile software development. Um, what is your perspective on that Trevor? Trevor: The concept of agile software development is trying to move fast, trying to make changes and having, you still have a flow, you still have a V&V process, you have an actual software development documentation and software documentation steps. But I don't think that the traditional, sort of like Karandeep was saying, the traditional mindset of, we're building software that happens to be a medical device, doesn't really apply well. Trevor: A lot of software companies and a lot of tech companies have the Silicon Valley mindset. They want to go as fast as they can. They want to just put something out, see if there's a fit for it. If not, move on to the next iteration until they find that fit. Moving quickly like that works in non-regulated industries, but it doesn't work very well in the medical space. So something like 62304 is trying to slow that process down and have a set of steps that manufacturers and developers should take to ensure they aren't introducing risk into their device. Trevor: Again, it's still just sort of that baseline for security that engineers should implement into the product. But in general, I think just having good, reproducible steps and not trying to do things as this rapidly evolving cycle is a good way for medical device engineers and manufacturers to go about the development process so that they don't have just a runaway train of these versions that they can't keep track of. Their design history file is five versions back. They don't have documentation supporting the current version of the product and it's all just in the engineer's heads. Uh, so I think that these are good standards to try to push away from that, but they might need a little bit more refinement as far as how they're doing it. Host: I think what Karandeep said and you backed it up Trevor is, we're developing a medical device that happens to have software versus the Silicon Valley mindset. And I think, I never really think of, I didn't think about it from that lens before, but I think that's one of the biggest challenges is that Silicon Valley mindset whereas this is a highly regulated industry. Host: I'd used to do cybersecurity for aircraft, commercial aircraft and it's the same concept. It's highly regulated. You can't just build a prototype plane very cheaply and and and test it because you know, it may crash and kill people. So I I it's not quite like that, but it is sort of like that. And I think it's finding that right balance because there's innovation, there's a lot of, and there's investors, there's uh, you know, time to market, there's a lot of factors in and with a regulated industry, it's like how do you balance those factors to bring something to market cheaply, um, quickly and that is actually valid. I think that's one of the challenges we have in the industry. Host: So I know Karandeep, I I heard, I don't know if this is true that you like uh fast cars from a somebody like what does that mean? You you race cars every now and then or are you just, do you have fast cars? Guest: Yeah, I've owned quite a few fast cars. So I was quite fortunate is that when I was quite young, my father had a garage so I always grew up around cars and my dad also buys and sells cars. So I was always being dropped off to school in, you know, anything like crazy American cars which we don't really get in the UK, going to school in like Dodge Rams, you know, one time my dad even had a Dodge Viper, a few BMW M's, etc. He was always sort of trading cars so I kind of grew up around them. Guest: For me, it's kind of, I always like a diversity of cars. So my favorite car is not fast at all. It's a 1973 Morris Marina and it has a 1.3 liter engine and the reason it's my favorite car is I can get the back end out at 10 miles an hour in second gear without causing any trouble. It tops half-way about 55 miles an hour but it's one of very few cars that I can drive that car to the absolute extreme without being dangerous. So for me it's about the fun of driving and that's really what it comes down to. Guest: But in terms of racing cars, I'm potentially looking at getting a racing license and taking it to the track. One of my dream journeys again, being that you know I'm not too far from Germany as well is eventually visiting the Nürburgring one of the days which for the listeners today may not realize is one of the world's most famous tracks where a lot of people can go there and you know test out their cars and see what they can do. Guest: But for me and the benefit that I have of course is I live in the English countryside, we have some of the most beautiful roads as narrow as they may be you know we have very beautiful roads and if the weather is nice, which again is a rarity in the UK, it's nice to just get the roof down and just go out for a nice drive in the English countryside. Host: Is that the Dodge Viper that car you think is the fastest one, Trevor? Trevor: The fastest Americ- well I think it was just dethroned but for many many years it was the fastest American car that was commercially produced. And it has the fastest time on that the Nürburg track or course or whatever. Trevor: Yeah it was. And I think it's now a Corvette beat it. But for a long time was the fastest American car on the Nurnburg track. Corvettes are a midlife crisis car in my opinion. They look like a Ferrari. Host: We'll have to get, we'll have to get on a track someday. I'm I'm working to get my uh SCCA license uh Karandeep so I can race cars and uh a couple of weeks I'm taking an F4 class. Um, so maybe we'll we'll see each other on the track. Cool. Well, um any last minute words of wisdom to any innovators, uh or any regulatory affairs people? Anyone listening in on the podcast about, um quality and regulatory. I'll throw it over to you Karandeep then I'll throw it over to you Trevor for cybersecurity. Guest: Sure, so quality and regulatory doesn't really stifle innovation. It just creates a framework so we can do it quite safely in a regulated space because the last thing you want is a product going out and killing people. So don't think that quality and regulatory stifles innovation, it just allows it to happen in a controlled and safe manner. So always take it very seriously and don't see it as a burden. Trevor: Yeah, and I think from the security lens, goes back to starting with the end in mind. Understand how you are going to, what your end goal is, where you want to get your product and what you want your product to do, and understand how to do that in a secure way. The frameworks are out there, the standards are there to provide guidance. And then it's just a matter of simply applying them and going through a clear, safe process. Host: Yeah, what I'll say, something I I picked up on this uh episode is we're designing a medical device, it just happens to have software. Quality doesn't stifle innovation and neither does cybersecurity. They're things you have to consider in a highly regulated industry where patient lives are at stake. Awesome. Well thanks so much everyone for tuning in and we hope to see you on the next episode.