Understanding Software as a Medical Device
Vivek Thakkar has over a dozen years of experience in regulatory affairs for Class II and III medical devices, while at Roche, JUUL, Cardinal Health, and Abbott Vascular. He is also a frequent speaker on software, artificial intelligence, and machine learning. Vivek is now focused on start-ups and consults with medical device companies to identify and refine their regulatory strategies in the software as a medical device space.
In this episodeVivek shares the definition of software as a medical device, the regulatory requirements during product development, how hardware and software programs are similar and different, working with teams that do not have a medical device background, how changes are made to software products, AI and machine learning and what is being done today vs. what will be coming, and the challenges specific to software products that the industry and regulatory bodies are attempting to overcome.
Links from this episode:
Mastering Medical Device:
Episode Transcript
This transcript was generated using an automated transcription service and is minimally edited. Please forgive the mistakes contained within it.
Patrick Kothe 00:31
Welcome! As our industry continues to evolve, software as a medical device has emerged as an important advancement. But when we hear software as a medical device, what exactly are we talking about? And how does it differ from hardware devices when it comes to development and management. Our guest today is Vivek Thakkar, who has over a dozen years of experience and Regulatory Affairs for class two and class three medical devices. While at Roche Juul, Cardinal Health, and Abbott Vascular. He's also a frequent speaker on software, artificial intelligence and machine learning. Vivek is now in the startup world and consults with medical device companies to identify and refine their regulatory strategies in the software as a medical device space. In this episode, we discussed the definition of software as a medical device, including some examples, the regulatory requirements during product development, how hardware and software programs are similar, yet different. Working with teams that do not have a medical device background, how changes are made the software products, AI and machine learning and what's being done today versus what's going to be coming. And the challenges specific to hardware products that the industry and regulatory bodies are attempting to overcome. Here's our conversation. Vivek, welcome. So happy to have you joining us here today.
Vivek Thakkar 02:12
A pat, thank you. Thank you for having me as a guest, I'm very happy to be here.
Patrick Kothe 02:18
Well, we've got a lot of great information to go over with in terms of software as a medical device. But I really want to start off because there's some confusion about what software as a medical device really is. So can you help us in defining what it is?
Vivek Thakkar 02:35
Sure, that's, that's a pretty common question, too, that I get from a lot of teams that I'm working with that what what is a software as medical device, and so I think in order to understand that, what I would suggest is just take a step back, you know, first, first try and understand what a medical devices. And you know, that way, you know, if, if your software is doing any of that thing that medical device does, then you have a software as medical device. So if you are a manufacturer of a device, and if you are claiming your device, to do something to do to do some kind of activity, or to have some kind of medical purpose, then you have a medical device. So it's a very plain and simple language that if you have an item that is doing a medical purpose, and it is not a drug, then you have a medical device, and a very layman language. But now once you once you say yes to that, and once you think that you have a medical purpose, you start going down a little bit deeper, and you start asking yourself questions that, you know, is are you diagnosing or treating something? Are you curing something? And, you know, those answers are gonna are going to define what kind of medical device do you have? So So I would say that's, that's in a nutshell that have you define your medical device. And now let's talk about software. So let's say if you have a software that is doing a medical purpose, or does have a medical purpose, then you have a software as a medical device. And again, that's a very, very plain and simple language. But then once you once you have a yes to that answer, then you start going into deeper and say that, what kind of function you're doing and that way you classify your device, classify your software as medical device. But that's, that's pretty much what you'd have to do.
Patrick Kothe 04:33
So let's talk through a few things that are software that is used within the medical space. So if you have a ultrasound device, and within that ultrasound device, there's software that helps to run that device. Is that software as a medical device?
Vivek Thakkar 04:55
No, that is not so that's a good question and one of To the components of software, as medical device or one of the definition is, if your software is standalone, and it is, it is not a part of a hardware, or not helping a hardware to achieve a medical purpose, then it's a software its medical device. So, you know, there is a difference between software as medical device and then software in a medical device. So what you asked for a software that will be defined as software in a medical device, because that software is controlling a piece of hardware, which is going to achieve a medical purpose. So so that's that's the distinction between software as and in a medical device.
Patrick Kothe 05:44
I think one of the other other interesting things that you'd use discussed is if it's working in conjunction with a medical device. So let's say you're selling a go back to ultrasound device, and you've got, you've got the ultra ultrasound device, and it's connected in some way to a computer, and it could be a Bluetooth connection, or it could be a wired connection, and you've got a software suite on there that's using that information that's coming out of that machine is that software as a medical device. So
Vivek Thakkar 06:20
now I think we are entering a big gray zone, if the data that you're getting from the software, if that data is used to make any kind of treatment or diagnostic decision, then it is a software as a medical device. So if if your if your suite in your if ultrasound is connected to a software, and if that software is getting information from ultrasound, and then it is connected to a cloud computer, or just connected to a cloud, and it's identifying some patterns in the ultrasound and, and providing information to a radiologist regarding a treatment or diagnostic decision, then it is software as medical device. So, and again, you have to consider a lot of things. Like there are some combination devices where you use the software and hardware as a combination product. So So yeah, there are there are multiple, multiple ways you can consider what what makes a software its medical device.
Patrick Kothe 07:29
So let's talk about electronic medical records. So you've got an EMR system that's that's in a hospital EPIC system, or some some other system for electronic medical records is that defined as software as a medical device.
Vivek Thakkar 07:47
So medical records, as long as you are you are not using so let's say if you are just keeping a log of, of something, and if you're if you're just keeping a log of your heart rate, you know, that's that's like, that's an equivalent to a digital diary. So, you know, in that sense, you are not doing anything with that information, then it's not a software, it's medical device. But if you use that information and send it to your doctor, and the doctor decides that hey, you know, it seems that, you know, it seems that you need a particular treatment or you know, it seems that there is a diagnosis of a disease. In that case, the risk of the information that is obtained from the device, it just increases from the software, it increases. And it has a medical purpose now, so so that, that makes it a software as medical device. So again, I went whenever you whenever anybody asked me a question, I give them a very famous regulatory answer. And that's it depends. Because I cannot I cannot answer you based on a single question whether you have a software medical device or not, because I'll have to ask you so many follow up questions, and then come up with a conclusion whether you are or you are not device. And that's
Patrick Kothe 09:07
the reason why we have regulatory specialists is is really to fine tune these things, because a lot of it it has to do with what claims are you making about what's the use case scenario? And what claims are you making with the two when I when I think about you know electronic medical records, and I see the physician that is entering in for information in as they're interviewing that patient. And then I think about treatment algorithms and is the treatment algorithm in that EMR? Or where does that treatment algorithm sit? And is that treatment algorithm? As if it's embedded within within a software system? Is that now does that become a software as a medical device?
Vivek Thakkar 09:51
Yes, yes, that is correct. So typically, I think these companies who are building these algorithm they have multiple As a to deploy them in a clinical workflow. Sometimes it is embedded in the, in the systems within the clinic, sometimes it is a cloud based system. Sometimes they have a Software as a Service. So there are many ways to, to deploy this. But, again, you know, I would just keep taking you back to the purpose or what problem you're trying to solve. And, you know, what's your claim? And what, what gap you are filling in the clinical workflow that will define whether you know, you have a medical device or not?
Patrick Kothe 10:39
Yeah, it as you said, it's a it's it's not a black and white issue. It really depends on the use case scenario that you've got who's who's looking at the information, whether they're taking action, often information or they're just displaying information? And are they monitoring? Are they diagnosing? Are they treating based on that information? It comes back to, as you said, defining what a medical device is, and then defining it as a piece of software. Does it fulfill that the that definition of a medical device? So I guess we'll put it we'll put a stop on this this section of our discussion and say, I think we've got some real good direction about what software as a medical device is, but each individual application is going to need some significant oversight from a professional to say, Does this or does this not fit as a medical device?
Vivek Thakkar 11:38
That's, that's correct.
Patrick Kothe 11:39
So let's talk a little bit about developing software as a medical device, because most of our most of our listeners are used to dealing with hardware products and not software products. So when you go through the development of a hardware product, it's pretty well defined all the different steps that you go through as a device manufacturer, but software is different. Can you explain a little bit about the differences between developing a hardware product and developing a software product?
Vivek Thakkar 12:14
Correct? So that's, that's, again, again, a big question that is very common. With a lot of companies. Yes, software and hardware development are different. But from a regulatory standpoint, if you see there are a lot of common factors, and there are a lot of leverage points that you can use from the hardware regulatory framework that will apply on the software as medical device. So for example, so let's let's say, you're starting with defining your medical device and you have your intended use and you know, that you have a medical device. The next step, whether it is a hardware or a software, you need to classify your device, because having a device is one thing and depending on what you have, the risk of your device can vary a lot, you can have a simple device like a tongue depressor which is least risk and you can have a pacemaker which is highest risk and same goes for software. So, the classification of the device or classification of your software is the next step in the development process and every health agency around the world, they have their own classification matrix, but there are certain harmonized standards or there are certain harmonized definitions, which you can use to classify your device based on based on your intended use. If you want to market your device in the US, then you follow the US FDA classification, which is from the increasing risk increasing order of risk from class one two and three. In Europe, there is another there is a similar classification matrix, but they have class one, two, a two B and three and so on and so forth. There are other other categories to classify your device as well. So, so, now you have your intended use, you have your classification. So, combining these two, you have a regulatory identity for your software, when you started initially, you just had a software where you did not know if it's a medical device. Now, if you know it has a medical purpose, now, you know that it has a classification and a certain kind of risk associated with it. So, with that information, you can define a pathway for your product from there to go to market. So, these two are the critical piece that I would say for any team or for any company to first finalize these two things and put a lot of resources time and energy in order to do that, because once you have these in place, the rest of your development will just fall off from these two things and it becomes very easier for for the development henceforth.
Patrick Kothe 15:00
vague, I've seen quite a few companies who have started software development software as a medical device. And what they've done is they brought in software developer developers who don't have a background and medical device, they've got a background in in consumer products or some other non FDA or non medically read a regulated product. And there's often a, an education, we'll just put it that way, there's often an education about what it means to develop within a regulated environment. Can you explain a little bit about what you've seen when you've got people that are coming in into the industry and what the differences are between developing software for a non regulated space and something within the medical device space?
Vivek Thakkar 15:55
Sure. So it's not it's not it's not a binary division where there are unregulated industry or they're regulated, each industry has some sort of regulation. So even if a software developer is developing a software for a consumer product, they do have some kind of regulation, but when it comes to medical devices, that the bar or the scrutiny, it just increases exponentially. So now, suddenly, you are if you if your software has a medical purpose, and if you are helping or assisting or treating, diagnosing, then you suddenly enter into a space where every point of your of your development is, is requires a lot of documentation requires a lot of risk analysis, risk mitigation, and a lot of design control that, you know, you it sometimes becomes very difficult for the software engineers who are used to working in an industry where, you know, they can make changes real quick, they can develop real quick, and now they're in medical devices. And now suddenly, you know, there is a design input phase is a design transfer, and you have to document you have to have a design history file, you cannot just make a change to existing software, you need to go through an impact assessment on how it will impact the safety and efficacy of your device. So, so it's a little bit tricky. And I guess that's that's where your regulatory and quality folks can come in, and, and educate the team and educate the developers that, you know, it's not about, it's not about just having a lot of documentation, it's about making sure that the change that you are making now, someday it will impact a patient and you know, there is there is a person down the line and you know, that that kind of mentality needs to be developed within the team. So that, you know, we can we can comply to the design control requirements and put out the devices in market or software in market which are safe and effective.
Patrick Kothe 18:05
Within the medical device space, as you said, there's design controls from the start, you're looking at putting design inputs in and then you know, documenting at each of the development steps, all of those changes and what's going on? Am I understanding correctly that if you if you're not within the medical device space, what you're really doing is you're testing at the end? Or are they not concerned with the development process?
Vivek Thakkar 18:37
So it's not that the other industries are not concerned or not concerned with the development process? But
Patrick Kothe 18:45
let me rephrase, they're not documenting the development process as rigorously as we do and
Vivek Thakkar 18:50
that is that is correct, yeah. So, the requirements are not as rigorous as medical devices. And you know, these there are certain there are certain standards that you need to comply with, if you want to market your medical device right and these standards are internationally accepted or their international standard which are accepted by FDA and in many European notified bodies and a lot of different countries. So, these standards forces you to implement design control in your development process. And you know, you have to check for the safety and efficacy of your device at every point. You have to make sure that you have a history of how you have designed the product. So if something goes wrong, you can go back and check you need and now with the software in in the equation. You also need to make sure your your software has some kind of cybersecurity because now you are dealing with a lot of data, a lot of patient data and those are all sensitive information. So you need to make sure that your software is no not vulnerable to any kind of a cyber attacks, with all the leak in leaking all that information, there is a whole amount of scrutiny that comes along with developing a medical device.
Patrick Kothe 20:14
So let's start at the beginning of the development process and say that somebody has an idea for a new piece of software that has medical application. It's the same flow that you'd have you'd you'd identify from the customers, what the needs are of that product, correct?
Vivek Thakkar 20:34
That's correct. Yeah. So so that's it goes back to your development lifecycle? Yeah, if you have a product if, if you have, if you're trying to solve a particular problem, then you start from what identifying what that problem is. So going, going to your users and asking them, you know, what, kind of how can you make their life easier using a software? Or how can you how can you make your clinical workflow efficient using a software and it all starts from, from the customer needs, which will guide the development of your intended use, which will help you to classify your device, so it's all kind of you know, it's all linked. And, and that's, that's the design process that the medical device industry has been following.
Patrick Kothe 21:19
So at that point, you've got your inputs, and you have to know it, it's it needs to work within following operating systems needs to have X amount of processing power to do this, it needs to people can't be the colors that are used, you can't be colorblind, in order to use them. If you've got any, any alerts in there, you're all of these different things that you need to put up. And then so once once you've got your needs needs done, then you start on on development, how different is that development in terms of the documentation than a medical piece of hardware? Is there any difference? Or is it exactly the same,
Vivek Thakkar 21:59
the fundamentals are the same. But the way of executing those fundamentals are different when it comes to software versus hardware. So we are you, as you accurately mentioned, you have your user need, that that converts into your design input, where you know, you have you start setting up your specifications, you convert the user need into specification, and then you design a product and you test your product with respect to those specification. So that that fundamental is always going to be the same no matter if you no matter if it is hardware or software. But now in software, you know, there are some inherent differences where you know, certain things from hardware cannot apply. So for example, the you know, there are manufacturing standards that are manufacturing specification that applies to hardware devices. And you cannot apply that for software. But once you write the code, you can just replicate it any any number of times you want. There are multiple differences between hardware and software. But this again, as I said that the fundamental remains the same. You know, you need to have a design history file you need to have, you need to have your supplier management because sometimes, you know, you buy a software as a platform, and you know, you need to maintain those suppliers. So there are a lot of quality system requirements, which apply to software as a medical device.
Patrick Kothe 23:27
So, I think we covered kind of some of the front end stuff and then as you're, as you're also developing, you're doing things like risk analysis, let's talk about the difference in software and hardware products in terms of risk analysis. So, once
Vivek Thakkar 23:41
once you are developing your devices have once you're developing your software, there, you will come across certain risk which which your software will have. So, even in case of hardware, you know, the risk analysis is exercise that you do with with your team to to foresee how these how this device can be used in future. And you know, what are the risks that this device will have? If it is not used as per the intended use of that device. And in order to mitigate each risk you have a certain standards to meet with so there are certain risk management standard for medical devices, there is ISO 14 949 71, which which you can you can use that standard and if you comply with that standard. You know that's that's how you ensure that your software risk management is is well considered and you have risk mitigation for all the foreseeable risks that you see with your device.
Patrick Kothe 24:45
Can we go back a little bit to the privacy and security issue because it's it's obviously an extremely important issue with with software. What exactly is being done to help mitigate the issues regarding privacy and security,
Vivek Thakkar 25:05
FDA has been very engaged with the industry in developing these guidance document for cybersecurity. And, you know, there are there are other international medical device the International Medical Device regulatory forum called IMD, RF, they also have the principles and practices for medical device cybersecurity. And, you know, there are a lot of security features that the standards explain you the standards, you know, recommend you to have in your software as you are developing it. And, you know, how do you how do you test those security features? And, you know, what are your what are the considerations for information sharing, and, you know, there are a lot of other considerations in terms of cybersecurity, that, that each company has to take in order to in order to comply with the standards,
Patrick Kothe 25:58
we do human factors testing, with hardware products, I'm assuming human factors testing are is equally as important with software products.
Vivek Thakkar 26:11
That is correct, because your software is going to be used by someone, if a physician or if a patient cannot use your software or it's too complicated, or it's not not helping the diagnostic or treatment of any any kind, even though you have designed a really good software as medical device if it is not usable, if it is not. If it's not intuitive, then it might lead to wrong decisions. And that's exactly why there are human factors studies, so so that we can ensure that your device is not making the user dumber. So. So that's that's the purpose of making sure that your use your device is designed and simple enough to use that it doesn't disrupt the clinical workflow at all.
Patrick Kothe 27:02
Vague let's talk about verification and validation. vnv is obviously a really important step in in our product development, how does it differ in the software's medical device space as compared to a hardware product?
Vivek Thakkar 27:20
Sure. So again, I would say the same thing that the fundamentals remain the same, whether it is software or hardware, the way you the way you do it, the way you perform your verification and validation might have slight differences when it comes to software or hardware. So in case of software, if you verification and validation is something that you have to do, in order to build the evidence package that you submit to FDA or other agencies to demonstrate that your device is working as you claim it, as you claim it to be. So when you in case of software, when you verify your software, what you are, what you essentially are doing is making sure that the way you have built your software, it is performing in exactly the same way, like the output that you are getting is the range of output that you are getting is equal to the range of input that you designed your software to be. And it is it is in accordance with that design specification. So that's what you are verifying, that's what you are verifying. And when it comes to validation, what you are doing, you're making sure that the output of your software is fulfilling the intended use of that software validation is something that you make sure that your claims the whatever you are claiming is happening with your device. And verification is like a technical, technical verification that your software is working properly. So all I say to all the teams that I'm working with, is that verification means that did you build your device, right? And validation is did you make the right device? So that's that's like a clear distinction between these two. And you know, that's that's how a company making a software as medical device should approach it.
Patrick Kothe 29:26
Now that we've got a product that has gone through the full development phase, done all the testing, you've submitted it and you have clearance for your device or end and it's on the marketplace. As as it's out in the marketplace, there may be some changes that you want to make within the general software space, the non medical device, people can make running changes, but typically what they'll do you know, they may make a running change and say I want to change something very minor, but Typically what they'll do is they'll batch things together and then have an update. That fixes a number of different different things. Let's talk about how you do that within a medical device. And whether that's a new 510 K, whether that is a letter to file, so to speak, how are changes made? And how are those determinations of what pathway they need to take in order to make a change when it's a software product,
Vivek Thakkar 30:31
whether it is hardware or software, once you have your device in market, and you need to make changes to it, you have to go through a process of evaluating that your change is not impacting the safety and efficacy of your device. And it is not impacting the intended use of your device. It's not just changing the intended use of your device. And there are several guidances, that FDA has an interest certain international agencies who have also released similar guidance documents, in order to understand which what kind of change will require an additional approval from the agency, or what are the changes that you can implement right away. And again, these are risk based risk based divisions where it all depends on the change that you're making, and what kind of risk that change is introducing to the product and, or just, you know, adding an additional risk to your already risk management profile. In case of software, also, this this same fundamental applies. But what happens is in case of software, these changes are so fast that, you know, some companies, they update their software every two weeks, and they have a new version coming out every two weeks. And it's not a timeframe that, you know, a hardware industry can take to make that change, it typically takes 90 to 120 days to make a change to the existing product. So FDA has to adjust to this. And that's where a lot of framework development processes going on right now with FDA where, you know, they have introduced something called predetermined change control plan for devices which, which are software like software as medical devices, where when you do the initial application, you work with the agency to establish that what kind of changes you foresee in your software happening in the near future. And you work with your team internally and the regulatory person in your team can help putting this predetermined change control plan together, the predetermined change control plan is not just what changes you're going to make. But how those changes are not impacting your device safety and efficacy and how it is not changing the intended use also needs to be included in that change control plan. And then once you have put together this document, you know, you can submit it to FDA. And along with your initial application, this predetermined change control plan also will be reviewed and will be cleared by FDA. So it's not just the software that you are you are submitting. But depending on how you have developed your change control plan you will get you will get a clearance for those changes also that you're trying to implement. And then when you come to a point where you want to implement that change, you know, if it is within the documented plan, then you can go ahead and make it right away, rather than going through the process of submitting another application and waiting for that application to be cleared before you implement the change. So so that's that's the difference between between software and hardware when it comes to changes.
Patrick Kothe 33:58
One of the other things I find interesting is that typically when you think about if it's a diagnosis piece of software, and you think about it as a medical device, you say, okay, the algorithm or the process that I'm running to say I'm diagnosing something in here, it's you're diagnosing pieces of information, that is the critical piece, and the skin of the software. The user interface is not as important. It's not it isn't. But it very well can be talked about a minute ago about changing a color. If someone's colorblind, they can't see that color or you move a button and it's in the wrong location or can be confused with where the button was previously. Now those pieces are those little changes that you think are deaths just a user interface change that affects the product itself. So this whole risk process is very interesting to go through. And when you think about, you know, all of the functions of what the software does, the user interface is pretty, pretty important as well.
Vivek Thakkar 35:09
Yep, yep, yep, the user interface, it can make or break things in your software intended use can change completely if you have not designed your intent if you're if you haven't designed your user interface in the right way.
Patrick Kothe 35:23
So a lot has been talked about recently with artificial intelligence, machine learning. Let's, let's talk a little bit about that, because AI hat, as I said, has gotten quite a bit of, of press. But how that's implemented within a medical device is quite complex.
Vivek Thakkar 35:47
That's true AI and AI, and machine learning based software as medical devices are getting a lot of lot of popularity these days. And it's something where a lot of companies are also putting in a lot of resources to develop such software, especially these, especially the companies with a really developed software infrastructure, you know, they, they are investing a lot of money in developing this AI machine learning based software's. But at the same time, there are a lot of challenges also, when it comes to these devices, in terms of in terms of adoption of these technologies, in terms of regulating these technologies, like FDA, and we talked about a lot of standards and guidance that FDA is introducing. But again, there needs to be a lot of changes in the existing regulatory framework to be able to evaluate this AI based software in a much better way. And FDA is working on that a lot of other industries are working on that with the developers with, with the payers and with the agencies there are there are so many teams, there are so many moving parts to it, that the entire ecosystem needs to work together to make this possible, make sure that all works complementing to each other. For for these AI products to be introduced, and help the patients improve their life.
Patrick Kothe 37:18
Let's just kind of define a little bit the differences between AI and machine learning and how it's implemented today,
Vivek Thakkar 37:26
AI as the name says, artificial intelligence is just, you know, trying to replicate the human brain. And machine learning is a subset of the wider, wider artificial intelligence. So the devices that we have now, they are more based on machine learning where you you teach an algorithm with a certain data set, and the algorithm will learn from that data set and, you know, will be able to provide you that information based on based on that learning. So, so these machine learning right now, they are not at a point where they can independently make a diagnostic decision or a treatment decision, majority of the devices that are in market right now, they are, they are assisting the healthcare professional or assisting the user or the patient with some sort of daily little daily activity. And, you know, making sure that they are the AI device will make the process more efficient. So sometimes, you know, I keep hearing with all this hype with AI is that, you know, AI is going to take away all the jobs of the doctors and in the healthcare professional and that's why there's a lot of hesitation sometimes in adopting this. But from what I see happening is that we are very far away from the possibility of AI taking over a job of, of a brain surgeon or like, like a doctor. But what I strongly feel and what I have heard AI is not going to replace the physicians, but the physicians who are not using AI, have will be replaced by the ones who are using AI. So I think it's the it's the team of human and AI that is that is more important than just one one component by itself. So that's that's what my My take is that AI is here to stay. But, you know, the more efficiently we can use it and the more easier we can make our life with AI, especially in the clinical workflow, you know that that's gonna that's gonna make a tremendous change,
Patrick Kothe 39:40
artificial intelligence, if you put a product out there that has AI in it, and by definition, it continues to learn. So if you put that product out there and it is continuing to learn in may give you a different answer today. Then, a year from Now, because it has learned, but it's the same product that you put out into the marketplace. Right now, I believe that machine learning is used in the background, and you've got version one that comes out today and version two that comes out the next time that you want to update it, because you've used machine learning to, to learn new things. And now you can track that version one did this one way, version two did this the other way? Do I have it correct? In what AI is, is capable of doing? And can that give a different answer today from from a year from now,
Vivek Thakkar 40:40
you are correct in terms of defining AI. But in order to address this exact same problem, or exact same scenario, where if you introduce an AI tool in market one year from now, as you said, it's going to it's going to work in a different way because it will adapt and it will start learning. So and that doesn't work well, when it comes to medical devices, because medical devices when they are in market, these are the current devices or static devices, right, they cannot change. And in order to make the change, you have to go through a process. So what FDA recommends is the AI machine learning based software has medical devices which are in market, they are called locked devices, where the learning capabilities of those devices are locked in a way that they will not update themselves live or they will not update, they will not start learning when they are in field, they are controlled in a way that they have a version one. And based on the real world data that the sponsor will collect that the manufacturer collects, they can decide that they need to improve the algorithm and they want to retrain the algorithm with the new data. So they will train the algorithm again, they will test the algorithm again, they will validate it again and release a second version of it. So that's the process right now. But it is completely opposite of AI, right AI means you need to learn artificially without anyone teaching you over and over again. But I guess we are not at a point from our regulatory framework point of view where, you know, our current regulation can evaluate such devices. So when we reach a level, where we have frameworks, we have international standards, we have all the international agencies working together to develop these standards, until then we would just operate in this locked device framework.
Patrick Kothe 42:41
So let's look a little bit towards the future then. So you've just just identified an area where FDA is working and industry is working to get to is that really kind of the main area from a software standpoint that you see as being a real area of development, or what are some other areas within software as a medical device that are going to be changing emerging, transitioning
Vivek Thakkar 43:08
the regulatory piece is a big piece in, in my opinion, in the industry, that innovation is not going to stop. You know, if you see 10 years back in software as medical devices, there was not a lot of things happening. And there were few devices that were cleared or approved by FDA. And now if you see the amount has exponentially increased in last decade, and especially with the COVID, you know, it has even increased more because now the need or the value of remote patient monitoring, for example, has has just been resurfaced with with the COVID and the lockdown in place. So a lot of money is being invested in these digital health technologies to ramp up and to make sure that you know, in a situation like this, it can it can help us to solve such problems. So the industry is moving at a very fast pace, the innovation is moving at a very fast pace. But the regulations right now, you know they are playing catch up. And I believe that with with the kind of progress which is going right now. And now we for example, we have a new division within CDRH that was established called Digital Health Center of Excellence, that Center of Excellence will will deal with all the software as medical devices and all the other digital health technologies. So we see a lot of things happening. But again, I think once once we have a regulatory framework to handle these innovation handle these new technologies, that's that's where a real change in healthcare will happen.
Patrick Kothe 44:48
So Vivek, obviously, finding a good consultant is very, very important, especially someone who has significant experience on Android Stan, that that's also one of the things that you do. Tell me a little bit about what, what you can do as a consultant? What are the types of things that are gonna be instrumental in getting a software project really kicked off correctly? Sure. So
Vivek Thakkar 45:14
thank you. And yeah, I have I have been in the medical device industry for last 12 years. And more recently, I have been consulting, and I have, I have started my own consulting firm called Rackspace. And you can look me up on LinkedIn connect with me. And if you are developing, or if you know, someone who is developing a software as medical devices and, and need some quality and regulatory planning, or regulatory or quality solutions, then, you know, I'll be happy to help you can look me up and get connected, and we can start talking.
Patrick Kothe 45:52
Vivek, thank you so much for leading us on this discussion today. Last question I've got is is regarding people who are developing software solutions right now software as medical device solutions. What advice what general pieces of advice would you give to people that are embarking on new projects,
Vivek Thakkar 46:15
if you are, if you're a company developing or trying to develop a software as medical device, and you have never done it before, I would put a lot of value in defining your purpose, like defining defining what you want to do, defining what problem you're solving. And you know that that should be your step number one, that's what will define what your testing will be, what your validation is going to be, what your what your regulatory pathway is going to be not only in the US, but around the world. So I would say focus on your intended use, put a lot of time and energy to develop an intended use statement, and then classify, and then when you begin your development process, that will make your life much more easier. And if you don't know how to do all these, you know, just hire a regulatory person or hire a regulatory consultant. And you know that that way you ensure that you are following the right regulatory steps.
Patrick Kothe 47:10
Software can provide significant medical benefits, and like all medical products, needs regulation to assure safety. As software as a medical devices evolved and continues to evolve, we really must stay on top of the issues because as we look at the mission of our companies, we may find that a software solution may fit in our offering just as seamlessly as a new hardware product. A few of my takeaways. First, a medical device has a specific definition, whether it's hardware or software. But there are nuances for each individual application and each individual product. So as you're contemplating these products, make sure that you either have the internal resources or obtain them externally. So you can best understand the nuances of these devices. And what that'll do is it'll set you on a clear path and ultimately reduce your timeline. Secondly, your team needs to recognize that they work in the medical device industry. And again, if they're coming from outside of medical device, there's some specific things that are that are required within medical device. And design controls are not optional. And also pushing back or complaining is just a waste of everyone's time and is really should not be tolerated in any company. It's just leading you down down a wrong wrong pathway. Finally, industry and the regulatory bodies are working together to address the unique nature of software as a medical device. And your heard vague talk about the predetermined change control plan, anticipating changes and the process that you're going to use to implement that. It's one great example of of looking at this as a specific thing to software. And then we discussed the AI side of things, and some specific challenges to implement AI within a medical device. So just keep your ears ears open. This is an evolving process. And it's really good to see that both industry and the regulatory bodies are working together to come up with come up with the answers. Thank you for listening. Make sure you get episodes downloaded to your device automatically by liking or subscribing to the mastering medical device podcast wherever you get your podcasts. Also, please spread the word and tell a friend or two to listen to the mastering medical device podcast as interviews like today's can help you become a more effective medical device leader. Work hard To be kind
