Grasping the Impact of Artificial Intelligence and Machine Learning on Medical Devices

It seems like every time you turn on the TV, there’s commercials, movies, and shows that highlight the use of artificial intelligence (AI) and/or machine learning (ML). The current trend of using AI and ML is even finding its way into medical devices. Recently, the FDA issued a press release about the potential of AI and ML to fundamentally transform the delivery of health care.

This episode’s guest is Mike Drues of Vascular Sciences, who joins Jon Speer to discuss nuances, regulations, and implications to know when incorporating AI and/or ML into medical devices and software.

LISTEN NOW:

Like this episode? Subscribe today on iTunes or Spotify.

Some of the highlights of the show include:

• Is FDA’s statement about AI and ML simply marketing hype? Other medical devices have the same opportunity, even if AI and ML are not used.
• Most medical devices are 510(k)s and may already have such potential, if substantially equivalent to a device that currently exists.
• The FDA is basically proposing the use of AI and ML to make companies be more proactive with product improvements that help patients.
• The difference between AI, ML, and other technologies is that AI and ML have ability to learn, adapt, and evolve; but may create quality and regulatory issues.
• The regulatory logic of AI is nothing new or different, but it hasn’t caught up. How to do change management to learn and adapt needs to be offered
• AI software should give manufacturers recommended changes, how they should be handled, and when to identify change creep.
• Digital Health Software Pre-cert Program: Focuses on team, not device. Does this mean the FDA is moving away from 21 CFR Part 820 in favor of ISO 13485?
• Software as a medical device (SaMD) companies considering AI and ML should follow FDA’s proposed regulatory framework for AI- and ML-driven software.

Links:

Statement from FDA Commissioner Scott Gottlieb, M.D. on steps toward a new, tailored review framework for artificial intelligence-based medical devices

Artificial Intelligence and Machine Learning in Software as a Medical Device

FDA Proposes Regulatory Framework for AI- and Machine Learning-Driven SaMD

FDA Eyes Tailored Approach to Regulating AI-Based Medical Devices

FDA wants public input on AI-enabled device regulation

FDA Premarket Notification 510(k)

Digital Health Software Precertification (Pre-Cert) Program

ISO 13485:2016

Yes it’s true – the US FDA is shifting toward ISO 13485. But how much and how soon?

21 CFR Part 820 - Quality System Regulation (QSR)

Mike Drues

Greenlight Guru

Memorable quotes from this episode:

“I’d like to believe a lot of medical devices have the opportunity to fundamentally transform the delivery of health care. Maybe AI products will, too.” Jon Speer

“This is almost being touted or proposed that AI and ML has an opportunity to help companies be more proactive with product improvements and, ultimately, helping patients.” Jon Speer

“The thing that distinguishes these kinds of technologies from everything else is the ability to learn and adapt and evolve.” Mike Drues

“From a quality perspective, what does consistency mean? Consistency is sort of the antithesis of learning. Consistency means that we keep doing something the same way.” Mike Drues

Transcription:

Announcer: Welcome to the Global Medical Device podcast, where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Jon Speer: I find this topic of artificial intelligence and machine learning, I find it very, very fascinating. It's very common, just about... It seems like every time you turn on the tv, movies or commercials for all sorts of things, and it's starting to find its way quite a bit into medical devices, too. In fact, FDA has recently put out a press release about artificial intelligence and machine learning, and it has the potential to fundamentally transform the delivery of healthcare. That's a bold statement, folks. But there are some nuances to this. There are some things that you should be aware of, if you have software that incorporates any sort of AI or machine learning. And there are some regulatory implications and the good news is, we got you covered. On this episode of the Global Medical Device podcast, I have my good friend and common guest on the Global Medical Device podcast, Mike Drues from Vascular Sciences joining us to talk about AI and machine learning. Please enjoy this episode.

Jon Speer: Hello and welcome to the Global Medical Device podcast. This is your host, founder, and VP of Quality and Regulatory at Greenlight Guru, Jon Speer. And if... I would say in the past, I don't know, a year or so, maybe a little bit longer, there seems to be this trend and it's not just a trend that's hitting the medical device industry, but I think it's sort of this hot topic that seems to be happening all over the place right now. And the trend that I'm speaking about is this idea of artificial intelligence or AI and machine learning and all that sort of thing. And I think it's starting to really come more to fruition in the medical device industry. In fact, there were some recent statements and articles, as recent as early April of 2019, on this topic. And there's some confusion, there's some trickiness and a few other things that we have to figure out from a regulatory perspective how to navigate. None other than Mike Drues will be joining me on this episode of the Global Medical Device podcast. As you know, Mike is with Vascular Sciences and he's an expert for these gray area regulatory topics. Mike, welcome to the podcast.

Mike Drues: Thank you Jon.

Jon Speer: Alright, you and I have shared a few emails, we've had a brief conversation about this topic. Pretty high level, but there was a press release or a statement that came out from FDA just a few days ago and it's about artificial intelligence based medical devices. I know you've read this but I guess, before we dive too deep today, what was your thoughts or maybe you can give the audience a little bit of context on what this topic is and maybe what it means from a med device perspective and then as we chat today, we'll dive into some of the nuances and some of the details.

Mike Drues: Thanks Jon, always a pleasure to speak with you and your audience. And I agree with you, I think this is a very timely and also very important topic. The press release coming out of FDA from outgoing FDA commissioner, Scott Gottlieb, that you alluded to a moment ago, said, among other things, that these kinds of technologies have the potential to fundamentally transform the delivery of healthcare. And that, to me, Jon, is a pretty powerful statement. "Fundamentally transform the delivery of healthcare." I think that's really, quite frankly, marketing hype. I agree in principle that it does have the possibility to make changes, both in terms of technology, also regulatory challenges that we'll get into, but fundamentally transform, I'm not sure. One thing to... What do you think of that statement, Jon?

Jon Speer: It is the opening line of that particular press release. Let's just say, for me, it was a good hook, because I read further. I read on, and some of the things we'll dive into and talk a little bit more about today, but I'd like to believe a lot of medical devices have the opportunity to fundamentally transform the delivery of healthcare. Maybe AI products will, too but I think there are other devices that have that opportunity as well.

Mike Drues: I would like to believe that as well, but I'm not sure reality is always the case, Jon. Not to be cynical, but aren't the majority of medical devices 510(k)?

Jon Speer: That's true.

Mike Drues: And does the 510(k) have the potential to fundamentally transform healthcare if it's already substantially equivalent or basically the same as something that already exists? I think that is a rhetorical question.

Jon Speer: [chuckle] Okay, it sounds good. But I think on this particular topic, I think it is hot as far as, and like I said, not just med device but just in general today, it seems like every time I get on the internet or read a story or see a commercial or this or that, there's AI this and AI that and AI this and AI that, so it is timely. And so I guess from an FDA perspective, good on them to kinda jump on this and realize that this is coming to a med device, chances are near you, real soon. And so I know FDA has had a lot of initiatives recently, and we'll talk more about that here in a moment, but the one thing that I think is interesting is that this is almost being touted or proposed that AI and machine learning has an opportunity to help companies to be more proactive with product improvements and I suppose, ultimately, helping patients. Do you agree with that notion?

Mike Drues: Well, I do, Jon. But let's take just a half a step backwards for the benefit of our audience, and let's just talk a tiny bit about what we mean when we refer to artificial intelligence or machine learning. There's several other phrases that are used synonymously. To me, as a professional biomedical engineer, the thing that distinguishes these kinds of technologies from everything else, is the ability to learn and adapt and evolve, just like almost in a Darwinian evolution sense, where the device is somehow monitoring itself, and making actual improvements in itself, such that it does things better in the future. And that, to me, Jon, presents not just some regulatory challenges, but also some quality challenges, as well, when we talk about consistency and validation and so on and so on. First and foremost, I'm trying to keep the technical detail here as simple as possible. But I think by AI, in our context, we're talking about the device to self monitor and change itself, evolve with as it learns more information from real world use. Would you agree with that, Jon?

Jon Speer: Yeah, I would agree with that. And a slightly different way or maybe just to add on to what you stated just a little bit, this implies that code, if you will, that software code is constantly evolving as it "learns" and gets more intelligence about a particular situation or event or occurrences and that sort of thing. It's constantly shifting its code base, somewhat autonomously. And so I think there's some things to your point, that implies that... And I guess for me anyway, looking at it, it raises some flags, some things that I would certainly want to address as a quality professional, not the least of which would be making sure that... How I prove that those algorithms, that those things that are changing, how do I know that those things are changing in the right direction, so to speak?

Mike Drues: Well, that's a great question, Jon, and I would love to dig into that on the quality side, but first, let's talk about the regulatory side, if that's okay?

Jon Speer: Oh yeah, absolutely.

Mike Drues: Because this brings us to, in my opinion, the first and perhaps, the biggest challenge of how do we regulate these technologies. It goes back to something that you and I have talked about many times before, Jon. And that is, a lot of people like to talk about what FDA regulates. What I like to talk about is what FDA does not regulate. And what FDA does not regulate is the practice of medicine. And when we're talking about learning, we're talking essentially, about the practice of medicine. In other words, when a surgeon does a procedure and he or she, either purposely or accidentally comes up with an improvement and uses that for the future, for future patients. Obviously FDA has nothing to do with that, because that's the practice of medicine. FDA doesn't regulate the practice of medicine. That's what all the regulatory textbooks say, that's what all the regulatory consultants say, but that's not completely true. FDA doesn't regulate the practice of medicine when it's practiced by a person. When the practice of medicine is practiced by a device, and this is now where we bring in the AI, now FDA is all over it. When we're talking about devices with this sort of innate intelligence, if you will, it's the ability to learn and to evolve. FDA will definitely regulate that, but that's a drastically different kind of a paradigm than what we've been working on in the past. Does that make sense, Jon?

Jon Speer: It totally makes sense. And as you were sharing that, I was reminded of past conversations that you and I have had, both on this podcast, and in webinars and just one on one conversations that we've had about changes to a clear device. And what you need to do when your device changes from a, not just from a regulatory perspective, but also from a product testing standpoint, from a quality standpoint, all the things that are required or expected and frankly, just prudent engineering and best business practices, whenever you make a change to something. In a mechanical world, if I change a component of my device, whether that be the color, the material, whatever the case may be, I have to evaluate the impact of that change. And I have, maybe in some cases, I might have to do some additional product testing to ensure that the product still performs as expected and meets the quality criteria and patient safety and all those sorts of things. And it might also mean that I have to do an additional regulatory submission. This is... I don't know if you have the answer, but now, we're talking about something that's changing almost without my knowledge on the fly, without my ability to assess and evaluate that change before the change is made. It just seems like this is like a regulatory quality product, quality... I don't know. It just seems like some sort of Pandora's box of some sort. [chuckle]

Mike Drues: Well, let's dig into that Pandora's box a little bit, Jon, because if we think about it properly, it's not a Pandora's box. As a matter of fact, I see very little here that's new. Coincidentally, I was asked to participate in a conference just a few weeks ago and one of the topics was AI and how do we regulate it. And some of the folks were saying how this is so new and different. And I said with all due respect, I see very very little here that's new or different, because what you're now starting to get into is the whole concept of change management and how do we do that. First of all, Jon, let me just point out for you and your audience that we're not talking about devices that are hypothetical, that we might have in five or 10 or 25 years. FDA has already cleared or approved a few devices using AI already, in the area of detecting retinopathy in the eye, for example, or analyzing CT images. But here's what happened. They specifically dumbed down the AI technology, they disabled the AI technology by creating what my software friends call lock algorithms, that do not allow the device to continuously learn and adapt. Do you wanna guess as to why they did that, Jon?

Jon Speer: Well, I have a couple of guesses. One might be that if they did not lock the algorithms, that that would probably have changed how FDA would have classified their product and would have made their regulatory pathway maybe a little bit more onerous than they had hoped, that would be my first response to that.

Mike Drues: Well, that's certainly part of it, Jon, both regulatory, as well as quality, because you and I have talked about before in the area of change management, how much can you change an existing device before you create a new device? When can you change a device and justify doing a letter to file versus if you change it too much and you then have to notify the FDA, for example, with the special 510(k)? These are challenges that have faced this industry now for decades, and we're still not all that great at dealing with them. But now, we have the potential to take the manufacturer out of that loop completely and allow the device to do it itself. Well, suffice it to say that that technology is there, but the regulatory paradigm to control it is not. This is unfortunately, Jon, one of many examples where we have literally dumbed down the technology, because our regulatory thinking has not caught up. And this is one of the reasons why it is still important for us in this industry to have these conversations as to how to regulate it.

Mike Drues: Here's my suggestion on how to handle AI devices for right now, given the current regulatory paradigm that we have, because I think you and some in your audience know me well enough, Jon, that I refuse to be the repertory police, I refuse to tell companies what they cannot do. And so instead, we have to focus on what we can do. I do not wanna dumb down the technology, I do not wanna disable the AI by creating these locked algorithms. That's just going in the wrong direction. Here's my suggestion: We enable the AI, we allow the device to learn, but we don't allow the device, at least, not right now, to implement the changes themselves. Instead, what the device does, is it learns, it collects that information, it comes up with those suggestions and instead of implementing those suggestions right away, if they send them to the manufacturer, we, as the company, we evaluate those changes, we implement those changes if they make sense, we validate those changes, we then decide using the same principles that you and I have talked about in the past, whether we're gonna make this change as a letter to file or as a special 510(k).

Mike Drues: In other words, there's nothing that's all new here, Jon. All we're doing is we're applying the same thinking that we've done before, the regulatory logic, if you will, not the regulation itself, but the regulatory logic to things that we've done in the past. Eventually, as we build up more experience, as we build up more trust, if you will, with the AI, we can talk about ways to allow the AI enabled device to implement those changes themselves. But we're not quite there yet, Jon. When I was thinking about this, it reminded me of this whole debate over self-driving cars. Right, self-driving cars are clearly gonna be the future, but we're not quite there yet. There's a lot of people, I suspect you might be one of them, who might be a little hesitant about getting into a self driving car and letting the car drive you, just without any input whatsoever. I think there's a lot of paramounts here. That's my recommendation for the short term, Jon. Have the software give us the recommendations and then we decide to implement them or not, we validate them and then we either notify FDA or we don't. What do you think of that suggestion, Jon, at least in the short term?

Jon Speer: Well, I think in the short term, that is a pathway that makes a lot of sense, and here's why I think that makes sense. If we do not basically, allow this opportunity to really, for these devices that are incorporating AI and machine learning, to actually collect that information and identify opportunities to evolve and change, if we don't create a vehicle for that to happen, then we'll never be able to leverage the benefits that AI can provide to medical technologies. That statement from FDA, "Have the potential to fundamentally transform the delivery of healthcare," if we don't enable the AI and the machine learning technology to be able to do that, then we'll never be able to come close to achieving anything near transforming the delivery of healthcare. I think this is a new thing, I think historically speaking, software has been from a regulatory perspective, very confusing, very challenging.

Jon Speer: I know FDA has done a lot of work, even in a traditional 510(k), there are certain expected criteria and behaviors that one needs to address if their product contains software or firmware or anything like that that needs to be captured as part of that 510(k) submission. But a lot of the guidances that have been provided from regulatory bodies, whether that be IMDRF or FDA, on the whole topic of software, are not necessarily state of the art. They're far from current accepted best practices by software developers. And so, I think this is a way to try to catch up, and I know FDA has done a lot of work on their Pre-Cert Pilot Program to try to catch up, if you will. And I guess I'm curious, Mike, have you worked with the Pre-Cert Program, or any companies that have gone through that, by chance?

Mike Drues: I have, Jon, and I wanna share a few thoughts on the Pre-Cert Program in just a moment, but just coming back for a second on what you just said. You're right, software does present different challenges, when you look at the regulation from a literal perspective, when you take a literal interpretation of the regulations, but as I hinted at earlier Jon, I don't do that. When I focus on the intent of the regulation, what I call the "regulatory logic", there really is absolutely nothing new here when it comes to AI or anything else, with the exception of that topic at the beginning, the ability to self learn and I already gave a solution to that problem.

Mike Drues: Here's my second suggestion for my AI friends, is let's push AI even a little bit further. Let's have the AI software give the manufacturer a recommendation as to what the change should be, how it should be handled. In other words, a letter to file versus a special 510(k), to have the software tell us if this is gonna be an example of change creep. You and I have talked about before, Jon, this idea of change creep and how problematic it is, how many times can you change an existing medical device before you do need to let FDA know? Again, when you understand, or try to understand, the intent of the regulation, the regulatory logic, I don't think it's that new.

Mike Drues: Okay. Let's come back to your question about the pre-certification program. I love this idea in principle, and I've recommended already to FDA that we take it many steps further. For those in the audience that are not familiar with it, this is a program that was created about two years ago, in 2017, and it's still a pilot program. There's only, as far as I know, about nine companies that are in it right now, a few of them are actually customers of mine. And the biggest difference here, Jon, is that the certification goes on the team, not on the device. In other words, as you and all of our audience know, when you bring a new medical device onto the market, you need to get a 510(k), or a De Novo, or PMA, or something; that's on the device. But the Pre-Cert Program, which was originally created for software because of the quick iterative nature of the software, it doesn't make sense to have to apply for a new 510(k) every single week because you're iterating the software so many times. The idea is instead of certifying the device, you certify the team developing the device.

Mike Drues: Think about it this way, Jon. When you get your driver's license, that's a certification on you. And once you get that license, you don't need a special approval from the DMV or anybody to drive from your house to the grocery store because they've already certified you. When a person goes to medical school and graduates, that's the certification for them to allow them to do surgery. They don't need to get permission from a medical board or a hospital in advance every time they want to do a surgery. That's the metaphor here. The reason why I love this program, Jon, is because it treats people as professionals. I'm a professional biomedical engineer; I know what the heck I'm doing. When I'm developing a medical device, whether it's a piece of software, whether it's hardware, whether it's an in-vitro diagnostic, whether it's something that's gonna go inside somebody's body, I know what the heck I'm dong and I don't need to be micro-managed by anybody to tell me how to do it. I would love to be able to have that kind of a certification, not just for software, but here's a whack-a-doodle idea for you, Jon, for all medical devices, what do you think about the idea of certifying the team or the company as opposed to certifying the device?

Jon Speer: Well, I think it's an interesting concept, and I know that the companies... The Pre-Cert Program, to me, is one of those... It's a great example, and I love to hear that you've had experience with that and that you've made some recommendations that this be more pervasive, or actually continue to expand in its application within the agency. But it is an example, I think, of an FDA program that's a little bit more forward thinking, and I do like the idea of extending it just beyond just software as a med device. Why not extend this to other companies, other teams, other opportunities, other product spaces beyond just software as a med device? And I guess I wonder, Mike, is this a speculatory question, but there's been some discussion, and I expect we'll see more about this in the coming weeks, but FDA moving away from a 20... 21 CFR Part 820, in favor of 13485, it may be this Pre-Cert Program could be a means or a vehicle for FDA to get some assurance, so to speak, that a company is doing the right things and is a properly accredited or certified to be able to do these sorts of things. But yeah, I love the notion of being able to broaden this beyond just SAMD.

Mike Drues: Well, I do agree with you, Jon, in the sense that the Pre-Cert Program is one of the very few, what I would consider to be new and novel ideas floating around in the regulatory world. Let's be honest, Jon, so much of... Not just what we're talking about today, but what we've talked about in the past, it's just a reincarnation of what we've done before. Even in the AI example, the discussion document that FDA just put out, a 20-page proposal on regulating AI. To me, that reads almost exactly identical to the special 510(k) guidance that FDA originally put out in 1998, so 21 years ago, and then was just updated last year. The Pre-Cert Program is something very new and different; certifying the team as opposed to certifying the device. As I said, I would love to see it taken further. And we should be responsible for our actions.

Mike Drues: For those of you coming from engineering backgrounds, again, this is not a new idea. This is the concept of getting your Professional Engineer license, your PE. There's a tremendous amount of precedent, in terms of is it going to grow in the future, which is I think, the gist of your last question, Jon. Well, I don't know. I hope that it will, but obviously, we need to have more confidence, just like the self-driving car. It's still relatively new and we need more experience to get a higher level of confidence. But I'll tell you this, Jon, and I've said this before, there's no better way to ensure that we have more regulation in the future than if companies and the people working in them continue to do stupid things. And I would say the same thing for the Pre-Cert Program. These nine companies that are part of the Pre-Cert Program now, they have a huge responsibility to make sure that they don't do stupid things, because if they do, then I can just about guarantee that this Pre-Cert Program will never continue in the future.

Jon Speer: And folks, we'll provide a link to more information about the Pre-Cert Program, but I'm looking at that list, Mike, and I see some names of some companies that we wouldn't normally think of as med device companies on that list, either. Companies like Apple, Fitbit, Samsung, Verily. I think it's kinda interesting to see that this has been embraced by traditionally non-med device companies to basically, transition some of the technology that they're working on, that might be used in consumer goods or just non-medical device purposes and using this as a potential vehicle to bring some technologies into a medical device indication, kinda interesting.

Mike Drues: I think you're right, Jon. And I as I said before, I don't think it's really appropriate for me to single out specific companies, but I did mention that several on the list, including a couple that you just mentioned are customers of mine. And it amazes me how much here is not new. For example, people for a long time have been asking in the software world, whether a particular software app should be regulated by FDA as a medical device or not. Well, to me, this is no different than any other question. And that is, what is a medical device? Does it fit the CFR definition of a medical device, whether it's made of physical stuff or lines of code or chemicals or whatever it is? It makes no difference to me. It's form independence. What matters more is the function. What does it do and how does it work?

Jon Speer: Absolutely. So folks, I wanna remind you all, I've been talking with Mike Drues from Vascular Sciences and we've been talking about this topic of regulatory framework around artificial intelligence and machine learning and how this applies to software as a med device. Certainly, Mike's an expert in this space and an expert with regulatory strategies. So definitely encourage you to reach out to him, especially if you're interested in AI and how it can apply to your particular product and ways to navigate these waters in a way that allow you to get that product to market but do so in a way that's proactive, that's innovative, that's creative. He's certainly one of, if not the best, when things like this. But Mike, just thinking, as we wrap up today's conversation, we've talked a little bit esoterically, about some things and what this topic is and why it could be important. But I thought, maybe we can wrap up today, if I am a company, an SaMD company, softwares med device or maybe some other type of technology where I'm incorporating, or considering incorporating things like AI and machine learning, do you have any tangible, practical, pragmatic tips for those listeners on how to embrace and incorporate AI into their products?

Mike Drues: I do, Jon. Thanks for the opportunity to share some final thoughts as we wrap this up. First of all, as I've said now a few times in today's conversation, I don't think there's an awful lot that's really new here, when it comes to AI from a regulatory perspective, even though many people seem to think that there is. The one most interesting question to me is this whole concept of self-learning devices, evolving devices, devices that can actually change themselves, and how do we regulate that? And I already gave the short term solution. And this is what I've told a couple of the AI companies that I work with right now, and that is temporarily disable, sorry, not disable, but allow your AI software to make the recommendations to you as the manufacturer, but do not allow, at least not yet, the AI software to implement those changes itself. Instead, you evaluate those changes, you validate those changes, then you decide letter to file versus notifying the FDA. And then once you do all of that, then you provide some sort of a software update to update the devices that are already in the field. That's a very tangible recommendation right now.

Mike Drues: My second recommendation, and this just came up a week or two ago with one of the AI companies that I'm working with, is, are AI devices going to learn at their own pace? In other words, if you have a bunch of the same devices out there, they're all learning at their own pace. Some devices might learn faster than others or instead, will they learn collectively, kinda like a herd of animals. And if they're going to learn individually, how are they gonna communicate what they've learned with the other devices that are in the herd or are they even going to communicate with the herd? In this particular company, what we've decided to do is that the manufacturer is going to monitor the herd learning. In other words, the manufacturer is gonna monitor each individual horse in the herd or the cow or whatever you want, and get the information from that particular animal. And then put it all together and go through that validation process and then update the entire herd in a collective way. Right now, what we're having to do, Jon, is micromanage the herd in order to mitigate the regulatory burden, but eventually, we'll want the herd to be able to learn and implement those changes itself, but we're not quite there yet. Just like we are with the self-driving car.

Mike Drues: And the last thing that I wanted to mention, Jon, and I would love to hear your thoughts on this as we up wrap this up, is from the quality perspective. What does consistency mean? In other words, to me, Jon, consistency is the antithesis of learning. Consistency means that we keep doing something the same way, whereas continuously improving something is based on that learning. Just at this conference that I was at recently, there was somebody there that said consistency does not mean that you do something the same way over and over, rather, it means that it's continuous improvement. You're changing things. But how do we reconcile that from a quality perspective? And how do we know that those changes aren't going to be problematic in the future? I don't know if this is something that you want to get into now, Jon, but as the quality guy, I would love to hear your thoughts on that.

Jon Speer: [chuckle] I feel like I'm stepping into a loaded topic, but I'll do so. I'll jump into it willingly. It is, especially, if you consider some of the standards, state-of-the-art, with respect to traditional software. There's still a lot of code review that's happening that's maybe peer-to-peer review. There are maybe a unit testing that's done, either in line with development or again, maybe by a QA or a software testing group. And there's the integrations testing. There's constant... A lot of Agile software methodology best practices, or at least, profess to incorporate quality as sort of the development cycle in and of itself.

Jon Speer: But at the same time, a lot of companies are embracing the automated testing for different parts and pieces, and that sort of thing. It is kinda interesting to think about, I guess, the classic, "This is a very dated approach." But a lot of people think, "In order for me to ensure quality, I have to 'inspect it'." And a lot of times, that involves manual intervention, or a human looking at something, so to speak. And conventional wisdom and folks, more times than not, conventional wisdom is wrong. But conventional wisdom is, "I can improve quality by adding additional inspection steps." But that is... There's plenty to corroborate that that is a fool's errand to think that adding more inspections will improve your quality, [laughter] but we won't get into that.

Mike Drues: Perhaps, Jon, since we focus so much on the regulatory challenges of AI, maybe we'll have a future podcast discussion on some of the quality challenges of AI because I think it does pose some interesting quality questions.

Jon Speer: It does.

Mike Drues: The last piece of pragmatic advice that you asked me for that I wanted to share is right out of FDA's announcement in the last couple of weeks. And to me, this is such a no-brainer. This is such a statement of the obvious. This is another example of how there's nothing new here. One of FDA's recommendations to manufacturers, and it's a good recommendation. It's my recommendation, too, and that is, take it to the FDA early on. I mean, geez. Do we really need FDA telling people now in AI, "Come and talk to us in advance of your submission?" To me, that's just common sense. But bottom line, I would wrap up my part of the conversation, Jon, and you can offer any final thoughts if you would like.

Mike Drues: When it comes to new technologies, whether it's AI, or 3D printing, or tissue engineering, or nano technology, new technologies require new ways of thinking. And one of my frustrations with our industry, as well as with the FDA, is we're constantly using these old, regulatory paradigms, paradigms that were intended to be used for old kinds of technologies and we're trying to change them. We're trying to morph them to fit these new technologies, like AI. In some cases, that works. In many cases, it doesn't. We really need new ways of thinking in the regulatory world to go along with new ways of thinking in our technology. To me, Jon, that's where the real exciting stuff happens. And we, as companies working in these phases, we can take the lead. We don't have to wait for FDA to tell us what to do. You take it from there, Jon.

Jon Speer: No, absolutely. That's spot on, and I love that statement. And folks, certainly, as you are... Especially if you're a software-as-a-med-device company or a software company that's considering venturing into the med device space, this is probably going to be a bit of a new world for you because... On the surface, it's gonna seem like the opposite of what you're trying to do as an Agile progressive best practice software company. And trust me and hopefully, Mike, trust him, as well. But realize that regulations, especially when you're talking about development of a device, I would say they are a framework. They're not dictating how you do things. They're not dictating your methodology. They're not dictating this specific type of product development approach they take. I know sometimes people hear, "Oh, my gosh. If I'm a medical device, I have to follow a 'Waterfall' or a phase-based approach." Simply not true. There is important parts of your... Any development, whether it's software, mechanical, electromechanical, there are things that are important.

Jon Speer: You should be capturing the requirements of your product. You should be assessing, from the verification standpoint, does your device meet those requirements? You should also be assessing whether or not your product meets the needs of the end user. Did you design the product correctly? Did you design the right product? Folks, that is Design Controls 101. And good news, we have you covered at Greenlight Guru. This is what we do all day, every day, with the Greenlight Guru software platform. If you're new to med device or even if you have been in med device for a long, long time, I would encourage you to go check out what we're doing at www.greenlight.guru. You can learn more about our software platform, and actually how it's going to help you embrace what's expected and what's important from a design control, from a risk, and eventually, from a quality management system. And that's why we're here.

Jon Speer: I wanna thank my guest, Mike Drues of Vascular Sciences. As always, I love talking to him about these exciting topics and regulatory, especially those topics that are a little bit gray, and maybe a little bit ambiguous for folks. He has clarity. He can provide clarity. And the good news is, it's not a one-size-fits-all answer. He figures out the right path for your product, the right path for your technology. Reach out to him. Learn more about how he might be able to help you. Folks, as always, if you have suggestions, comments, ideas, things that you want to hear us talk about on the podcast, or cover it in a webinar, always reach out to us. Our lines of communication are always open. Please reach out to us. We'd love to hear from you. And I'm gonna wrap up this episode of the Global Medical Device podcast. This is your host, founder, and VP of Quality and Regulatory at Greenlight Guru, Jon Speer. And you have been listening to the Global Medical Device podcast.

ABOUT THE GLOBAL MEDICAL DEVICE PODCAST:

The Global Medical Device Podcast powered by Greenlight Guru is where today's brightest minds in the medical device industry go to get their most useful and actionable insider knowledge, direct from some of the world's leading medical device experts and companies.

Like this episode? Subscribe today on iTunes or Spotify.