In this episode, "FDA Regulations Guide for Medical Device Developers," listeners are taken on a comprehensive journey into the intricate world of FDA regulations governing medical device development. Through insightful discussions with industry experts, including Elaine Duncan from Paladin Medical, the podcast explores key concepts such as defining medical devices, understanding indications for use, and classifying devices according to FDA guidelines. The episode delves into the importance of early collaboration and thorough documentation, emphasizing the critical role of human factors engineering and risk assessment in the development process. By shedding light on the complexities of FDA compliance, the podcast equips listeners with essential insights and practical tips for navigating regulatory hurdles and successfully bringing medical devices to market.
In this episode, "FDA Regulations Guide for Medical Device Developers," listeners are taken on a comprehensive journey into the intricate world of FDA regulations governing medical device development. Through insightful discussions with industry experts, including Elaine Duncan from Paladin Medical, the podcast explores key concepts such as defining medical devices, understanding indications for use, and classifying devices according to FDA guidelines. The episode delves into the importance of early collaboration and thorough documentation, emphasizing the critical role of human factors engineering and risk assessment in the development process. By shedding light on the complexities of FDA compliance, the podcast equips listeners with essential insights and practical tips for navigating regulatory hurdles and successfully bringing medical devices to market.
Speaker 1 0:12
Welcome to the product development playbook a series where we explore the world of medical devices and development. This show is your go to source for news and best practices in the rapidly changing medical device industry. We'll discuss the latest trends and innovations as well as how to stay ahead of the curve and stay competitive in the medical device space. Our guests are experts in their field and they'll provide invaluable insights on the topics that matter to you. So get ready to get informed, stay nimble and join the conversation. Today's episode delves into the regulatory aspects of medical device development. This is the first episode in a series that we are going to record on this topic. I'm your host, Sarah, and today we have special guest, Elaine joining us, Elaine, can you please briefly introduce yourself?
Speaker 2 1:10
I'm Elaine Duncan, and I'm the president of Paladin medical. We do medical device regulatory consulting, and primarily work with new projects and startup companies that want to put their products into the US market. We cover the entire development arc, from the general idea to an FDA application and all the things in between. I have a master's degree in mechanical biomedical engineering. And I've worked for him with both large and small companies my entire career, both in development, quality and regulatory.
Speaker 1 1:53
Awesome, thank you so much, Elaine, we're excited to get some knowledge and input from you today. We also have James and Jonathan joining us today. James, can you please say hello to everyone and give a brief intro?
Speaker 3 2:07
Yes. Hello, everybody. Thanks for joining us today. I'm James. I'm the Industrial Design Manager here at nectar. And yeah, excited to be here.
Speaker 1 2:19
All right, and Jonathan, could you please introduce yourself?
Speaker 4 2:24
Hello, everyone. My name is Jonathan. I am the quality engineer here at nectar recently started my role back in May. Some of you who may be listening to podcasts may remember me on our very first episode, I was just an intern back then. But now I've scaled my way up. But yeah, my background is in human factors. And I have just been trying to learn as much as I can within the quality engineering role as much as possible. So I'm glad to have it lane here with us. Awesome.
Speaker 1 2:52
Thank you, everyone. We got a good group here today. And Elaine, would you mind starting us off?
Speaker 2 3:02
Well, one of the first things that people want to need to know is how would they be regulated by FDA? And what does it take to get into the marketplace? As a first step, I like to make sure that we're really dealing with a medical device. Believe it or not, sometimes a device isn't a medical device. Sometimes what you think shouldn't be a medical device is sometimes we have a combination product. Sometimes it's a biologic or drug. But most of the time to get started, it's a good idea to review FDA definition of what is a medical device. And one of the main things you'll notice is that a medical device would be breeding, trying to cure, prevent, mitigate, or diagnose the disease. Now that can be interpreted broadly. But those are some key words to go back to, if you ever have a question about it. One of the areas where a lot of questions come up is is my software a medical device. So a software that functions with an active patient, monitoring or analyzing their specific medical condition may well be a medical device, but other software such as those that are just used for, say a diary by a patient, keeping track of their steps and the like that wouldn't necessarily be a medical device, but it's always good to compare yourself to other products and help you know if you have a medical device. So now we've established we have a medical device. I usually start by asking with the client, what they what competition they may have in the marketplace. We start looking to see if their competitor might be regulated and how FDA might regulate it. But the key issue To start with and to know for yourself, is the indication for use for your medical device. That is usually coupled with intended use. But that's different. Think about an indication for use as being the medical condition. And the intended use, or the intended user would be who and where the device may actually be used. Usually, then we can go through the product classification database, and figure out from there, plus using competitive products as a benchmark to determine how FDA might view this product and try to determine a pro code. Sometimes this is trial and error, because we'll select one of these classification codes, nicknamed pro code, to try to determine if some other competitive products may already either have a 510 K, or at least be registered with the FDA. The we can use that promo code as a very good tool to help us find alternative devices that might be like your own, and determine how they are regulated. And based on the definitions and the regulatory information surrounding those promo codes, we can usually come to a pretty good understanding of how FDA might regulate the device. So
Speaker 3 6:29
I have a question for you. So when you're when you're doing this analysis and the very early stages of a product, and people are giving you information about what their goals are, what their intended use is that sort of thing. How much of this is, is totally ironed out and completely resolved by your team members? Or how often is it more of a discussion and they want, they want to get your input on this sort of thing.
Speaker 2 6:58
And I usually get involved at both levels. One of the things we really need to do when we're looking at a competitive product is make sure that we we have an introduce new technologies. So that's why it's often wise to make sure you're talking to the full range of the team members, because one team member they know are very different technology is being brought into the new product. Okay, interesting. I can give you an example, we had a client with a very new device, it's fun at off from her university work. And because it was being used with a radiation beam that is used for therapeutic purposes, we were obviously concerned about how FDA might regulate such a device. But this device was intended to help the technicians be sure that the beam was being focused properly. The technique that was previously used was just to take literally a picture using a chromatic film, and determine if the beam was coming onto that film in the proper location. But my client had come up with software, and had realized that digital camera such as what exists on this cell phone was perfectly capable of taking an accurate picture. And with her software, which was really just a mathematical equation, he could determine much more accurately, if the beam was in the location that needed to be in before they use the product on a patient. We were concerned we'd have a 510 K. But we did a 513 b instead. Now that's a way to go to FDA and ask them to agree with your understanding of the regulation for the product. This worked out very well and FDA agreed that her device was class one exempt even though it was bringing in new technology.
Speaker 3 9:14
Can you talk a little bit about the process of interacting with the FDA could kind of talk us through how that goes and what your experiences are and what kind of wait times you've encountered that sort of thing.
Speaker 2 9:26
It certainly varies by the product and the type of interaction we're having. 513 G as I gave a bad example, I was quite surprised how interactive and casual that whole process was. The reviewers were asking the inventor and myself a whole host of questions we hadn't even thought about even though we had made a proposal in writing as to why we thought of the classification when we're doing a class to file I've been k, then of course, we have more structure, we first file the 510 K, and for those that may not be aware of 510 K is referring to the premarket notification. And that is a, currently an electronic submission, the FDA just introduced that all 510 K submissions go through their portal in a format that they have prescribed, then they have roughly two weeks to make sure that they believe the 510 K application is complete. Once they accept it, they then can have approximately 60 days to do a thorough review of the application. And at that point, they will typically send you a letter to let you know if there are any deficiencies that need to be corrected. Oftentimes, it's just they want changes to labeling, or they feel like an additional test may be necessary. Of course, if additional testing is necessary, that could drag on. And we could be looking at up to 100 180 days for us to get our 510 K cleared through that 510 K process. Most of it is done electronically. But occasionally, we do have an opportunity to do a submission review and verbally meet with FDA on over the internet. Determine what the issues may be, and how we can try to resolve them before the 180 days is out. There are other less formal meetings, such as a pre shop in the beginning before you even file. And again, it's good to have a firm outline of what you think your product would need for clearance so that you're getting more of a yes and no questions and answer.
Speaker 3 12:07
Like to back you up for just one second, because we might have some listeners here that aren't as familiar with med devices or even the product development process at all. So I'd like to define some terms here. You've talked about pre sub, you've talked about 510 K. We haven't talked about PMA yet, I believe there's de novo, can you maybe talk from a very high level about what some of these different terms mean, and why this matters to us as product developers?
Speaker 2 12:35
Yes, certainly, de novo is a very good topic, because as I mentioned, sometimes in new devices, we have a new technology, we may be introducing a new risk that was not apparent and predicate product. And by the way, a predicate is that term is used to describe the device to which you are claiming substantially equivalent of the 510 K is about establishing your equivalence to an existing product that's already on the market. When you are equivalent, maybe due to new technology, or even a new indication for use, FDA establishes whether or not that new indication for use or new technology would be allowed under the process of de novo. Of course, that means of the new. Now the contrast is a class three product would require a pre market approval process. And that is much more involved. Most typically require some sort of clinical data. And often the new product could be in those cases life threatening or life sustain it. But a de novo product is somewhere in between a me to 5k device and a class three Iris device.
Speaker 3 14:09
Okay, yeah, thanks for bringing that up. And then I think what might be helpful is if we put this in a little bit of context. So for example, let me put this in the point of view of the entrepreneur. So if someone has an idea for a medical device that they want to create, they'll come to a company like nectar product development with their idea. And sometimes they have absolutely no idea how this device would be classified or what that regulatory path might look like or what the challenges are or any of that. Sometimes people have done their homework and they know a lot about the industry and they know what the challenges are and they know how long it takes. But what's more interesting, I think is when someone has something that is new, maybe There is no predicate device, or maybe it becomes our job to determine if there is in fact, a real relevant predicate device out there. And that kind of becomes a starting point. So I'm curious to know how you would even start going about this. You talked about the databases, do you have just this bank of knowledge in your, in your brain from doing this for 20 years or something? Or, like, where do you start?
Speaker 2 15:29
Well, believe it or not, oftentimes, the inventor, even though they may not be aware of it, has started promoting their products, through literature, articles, publications, that sort of thing. So they have in mind, what they want to do with the device. And from that discussion, I can usually pick out the key words that are most significant to their product. Now, I'll give you an example, someone approached me to help them determine a classification. And they had already been been using the term biofeedback in their own website descriptions of their development project. So obviously, I was able to go to the FDA website, and the word biofeedback and I knew there, there was a classification for that. And I came up with biofeedback as a classification. And it was clashed to but exempt from a 510 k. Now, the technology was new. But the exemption for the classification allowed that if it was a battery device and used to train muscles that met the exemption, so then the need to find an exact predicate was somewhat diminished. Although I always try to confirm the best description, by continuing to go out and look for comparative products, and then document why we believe that the new device, even though it doesn't need a 5k is exempt from 5k. Under the regulations, that gives the company some defense, if FDA were to, in the future challenge, why they didn't get a 510 K. But it also gives them a baseline. And I think that baseline is critically important, because as they continue to develop the product, they might add features and claims that the original inventor might not have thought of. and a very good example is software. Everyone wants to put a cell phone attached to a product. And so sometimes we have to make sure that adding features like software, do not trigger a, an exception to the exemption. So it's really an iterative process, we look at all of the terminology, and the indication for use, what is the medical condition that we are going after, and what kind of risk is associated with the device, that usually helps us see ro N on how its regulated?
Speaker 3 18:36
To interesting discussion, we're having this reminding me of a project I did one time, it was a pretty novel idea. It was a wearable device that had sensors and things. And they wanted to roll out the device relatively quickly. And there was a big debate about how we were going to classify it, how it was going to be regulated, that sort of thing. And the client really wanted to launch the product as soon as possible, basically, the shortest regulatory path that we could. And basically, they wanted to launch it as a, I think we're going to do a class Class One exams, we're going to try to claim but our regulatory team at the time had a big issue with that. Because there were certain features that we were going to include on the hardware. There was some sensors and things on the board that we said, hey, we're just we're not going to include those in the gen one product. That's something we can turn on develop later. But the feedback that we were getting from the regulatory team was they were saying like, hey, like, do you know that you're putting these in there with the intent to use them someday? Which puts us at risk? Have you ever heard of anything like that? Oh, I can
Speaker 2 19:51
understand where the anxiety would be. But that's where the designers should be able to literally They turn off the feature. Now sometimes that's difficult to do if the feature is present right on the screen, for example, and I also would take you back to the labeling, one of the benefits of good labeling is to illustrate in the labeling what you intend the user to do and what the device is supposed to do. If you were to be able to have a gen one, and gen two, even if generation two, we're going to trigger a 510 K, the basic ergonomics of a device is a class one device, some of the usability aspects of the class, one device could still be a very good regulatory pathway, as long as you've done the risk assessment, to assure that it can't be misused, though, it's very rare that FDA would step in and say, We know you secretly want to use this device in a different way. And if they did, if you had mechanisms for turning off those features, just because you developed it that way to start doesn't mean that your intended use. So we look at indication for use and intended use, and going along with intended use is the intended user. I hope that helps a little
Speaker 3 21:29
Yeah, no, it does. And I mean, this was all about data collection. And there was, yeah. So they were basically worried that we were going to be collecting certain data about patients, that would have been relatively easy to activate. I don't know if an end user could have accidentally activated or intentionally activated it. I'm not sure. I don't remember. But if that data was collected, and essentially shared, even if it was inadvertently, that could have been that data could have been used to make decisions, which was ultimately what they wanted to do with their end product. And maybe the issue is that going back to the labeling thing, I think they were kind of already pitching that idea to their investors. And you know, I think they were kind of saying like, Hey, this is the future. And this is what this product is going to be. So to all of a sudden say like, oh, but yeah, actually, we're, we yeah, we designed it that way. But we're not going to use that yet. I think that was a problem. And maybe that that point of anxiety, like you're talking about?
Speaker 2 22:32
Well, frankly, that's not a bad opportunity to go to FDA. And lay it out option one and option two, and make sure that you know what would need to be done to go to your more advanced option. And see if they're in agreement to a staircase type development, that's not unreasonable. And remember, if it's for diagnosing a disease, sometimes there's a even a level of diagnosis, where you can consider the risk relative, for example, to a misdiagnosis. So you have a higher risk for your device, if you're Miss diagnosing a fatal disease. But if you're Miss diagnosing a head cold, perhaps it's not too bad. So one of the things we really try to make sure we do is understand those risks. And as an early project, start to work up the user requirements. And the input requirements. Now, they're a little different from the point of view, that the user requirements are typically, if you will, the voice of the customer. And the input requirements are usually more elaborate and include things like the standards and more detail about the environment of use batteries versus shore power, that sort of thing. So as early as you can to lay out these requirements, will help the team to look at what kind of risk mitigation needs to take place.
Speaker 3 24:22
So this is where Jonathan really comes in. So Jonathan is our Quality Manager, like you said before, he's very helpful at our company, for a bunch of reasons. He has background in human factors engineering, master's degree, and really kind of understands both sides of the equation, in my opinion, and Jonathan, you can talk more about it. But basically, Jonathan makes sure that we are controlling all of our documentation for the projects and he's having everybody to make sure that we're tracking what needs to be tracked. And we're documenting the way that we need to. But he also understands the user needs from a high level workflow and usability perspective, because of his his background in human factors engineering. So he's active on projects, but he's also doing the documentation. So Jonathan wants to talk a little bit about your role and how it kind of feeds into what what you do here at nectar.
Speaker 4 25:24
Yeah, definitely. So essentially, with my human factors background, I do help the design team a lot with the usability, but the usability, the workflows, creating the personas, and just figuring out how we want our product to be used. And it is great that you have already mentioned Elaine about indication interviews and intended use, that is something that we have been looking at more and more just so we could figure out how to roadmap how the product is going to be used. Who, what, when, where, why. But just like James was saying, as I have stepped more into the quality engineering role here at nectar, I have been more on the documentation side. And I have been seeing the difference between the voice of the customer and the standards. So it is funny seeing the list that our customers gives us, you know, casual language, very broad language, and then having to then communicate with the design team, the mechanical team, the software team like this is what we need to follow. This is the regulations, we need to follow here. Here's the IECs. Here's the ISOs. Here are all the standards that we need to look up and look more into. Because they may just say comfortable, but there are many specific numbers and data that needs to be followed for these requirements. So I've been delving myself more into that process here at nectar, just making sure that the language between the customer and the language with our design team is is portrayed correctly.
Speaker 2 26:55
Yes, let me circle back for a second James. So with donathan concerned about the usability of the device, and in the case of your fictitious client, who had more than one feature capability in a device at the same time, it is actually coming to play that we can make very sophisticated devices, and the user may not be able to use them well. Though, sometimes we even have to turn off some of the features in order to make the device more usable for a certain subset of the users. And folks take for granted using a cell phone. So if you have a device that uses a cell phone, but your mom, or your granny still has it figured out cell phones and gets intimidated by the cell phone, they might not use the device. And so it's not unusual for inventors, to innovate very far and literally skipped over the capabilities of their users. This is one of the reasons why we tried to make sure we validate the device for the intended use, and not just verifies all of the standards. throw you in a little bit more word salad there. But that's the Ark we have. We're trying to get a product on the market.
Speaker 3 28:28
Yeah, that's, that's interesting. I think a lot of this intended use, the kind of the early stages of the project is really the interesting part for for me, because this is one, this is the part when we really all have to be working together very closely. Later on in the project, when we kind of know what it is. And everyone kind of has their role, the software guys are going to write the code and do the testing. And the mechanical guy is going to figure out the enclosure and the industrial designers are going to figure out the branding and the the aesthetics, the look and feel the the key features and functions, like everyone's got their role. But on the beginning stages of the project is really when we all have to come together and say okay, like what the heck is this thing? How are we going to classify it? What features can we actually include? There's a lot of give and take. And it's a everyone kind of has to be able to be willing to compromise to some extent, because the client is going to have a wish list of 1000 things they want, but that's never going to make it to market. Yeah, I personally like the early stages in the project, because when we are talking through these things, and we're figuring out what the product is, how does it get marketed? What are we going to claim? What's the intended use that that sort of thing.
Speaker 2 29:48
And some of these early studies that we do to go out to the marketplace and essentially take a litmus test of where is that sweet spot where the buyer is? Is the buyer, the person who's really gonna buy into the device, maybe a home user, maybe even somebody in the hospital, because they're the ones who have to be satisfied, even though the purchaser might be the physician. And so we have to really recognize that sweet spot in the fire feedback sample, the product had lights. And so as the person recovering from an injury would use the device, they could see different colored lights telling them they were doing the right action. But also, they had put a cell phone attached to the device that could record the action, and even sent the information to the physician. Now, if they turned off the lights, and we're only recording what was happening with their product as the user was using it, it's no longer biofeedback. Because the patient wouldn't be seeing their own actions and reacting to it in real time. But the physician could still use the product and monitor or even as a result of the therapy say, well, I need to change my protocols in the future, and have them use the device differently. So there were literally three variations on the very same device. And a lot depended on do you take the cell phone away? Do you turn the lights off? How do you actually implement this product in the field?
Speaker 3 31:34
Yeah, that's really interesting. I have a question for you did something that made me think of this, you were talking about engaging with FDA. And when you're developing the app for phone to get it onto the Apple Store can be quite a challenging task. And I've heard stories about developers getting feedback from Apple, basically critiquing the design of their app. Have you ever heard of anything like that in talking with FDA, where they go in and discuss the functionality of it and the usability and give you advice or anything like that?
Speaker 2 32:14
Well, there's a couple of things out, I'll bring up FDA right now is obviously very concerned with cybersecurity. So regardless of the kind of device, you may be working, for example, some people don't use a cell phone, but instead use a dedicated tablet. But the tablet might still use Bluetooth. and So FDA, right off the bat wants to know how your data is secured through transmission, but also through store. And I had one client who thought they would reduce their risk with FDA, and took off the data collection mode. But FDA said, I'm sorry, you still have to go in and update software from time to time. So we still want you to have a security plan for how you're going to manage the cyber security in a very general way, how are you going to prevent pollution of the device with dangerous to the device by way of software, and downloading. And again, diverse security of the data that's being transmitted by whatever means. So this is very important with any device. And certainly you want to use components that are FCC registered components, you need to have an understanding of the risks of the software design. And if there could be any abuse by the user. One project I was just working on, the folks were hoping that they could put their app on the person's own cell phone. And I strongly recommended against that. Well, this was in a clinical trial, because the clinical trial was going to be in various countries. So I told them, if they hope to merge all the data from these various countries, they should be providing the mobile phone as well as the app for each phone and not have the users put the app on their own personal phone is sort of risk mitigation on the fly. But I was recommending that because I was really concerned. They could wind up with a hodgepodge. And even downloading the data from different countries off of different cell phones might be a control mechanism too far. I just was wasn't sure this client had the ability to be sure they couldn't be bringing in some sort of the virus by way of the cell phones that are controlled by the individual users and not by the clinical trial.
Speaker 3 35:08
Interesting. Yeah, the topic of cybersecurity is a really interesting one. That's something that comes up on pretty much every project we do. Now, nowadays, anything that has electronics or software, I mean, everything collects data. So that's always
Speaker 2 35:27
everything but a tongue depressor. They haven't figured out how to put chip on a tongue depressor yet, but wait till next week.
Speaker 3 35:36
Well, there was an interesting product that just got launched at the CES show a couple weeks ago. In Las Vegas, it's these binoculars that can detect what type of bird you're looking at. It's like for people who are into bird watching. So,
Unknown Speaker 35:53
we have a cell phone app that'll do the
Speaker 3 35:57
really well, yeah, this has been really interesting. Jonathan, do you have any questions for Elaine? We're coming up at at a time, at least first installment of this series. Jonathan, did you have any questions for Elaine, before we wrap up for the day?
Speaker 4 36:17
This kind of goes way back in the very beginning. Hopefully, it can be a short question. One thing that we've talked about here and there about is the difference between indication of use and intended use. Obviously, both are very important. Which do you believe out of the two deserves more of the focus from the design team or from the product developers side? Which which is the better thing to focus about the condition or the who and where of the product?
Speaker 2 36:46
Well, from from my chair, you can't separate them, you certainly have to know what medical indication you're looking to apply your device for. Remember, it's a treat, or cure, prevent, mitigate or diagnose? And so to try to, say, intended use is more important than indication for use, I would have to say no, but and like, Okay, what FDA has evolved through many years is that, for example, if a device is being used currently by a physician, but now we're going to take it home, we're going to sell it at the drugstore, we really have to know more about the intended use and the intended user. Because if the intended use, for example, is to diagnose cancer, you don't want to make a mistake. Okay. But if you give a device at the drugstore, that helps a person tech their skin, and that, of course, might not be a device but something that would mitigate sunburn, or otherwise prevent cancer, by some mechanism, you would want to know exactly what is the indication for using this product. So we can't really separate the two and the regulatory system really tries to recognize the difference. When FDA first started allowing a pulse oximeter or blood pressure cuff to be sold to the lay user, there was a lot of anxiety, can the user use it properly? What happens if they get a number and don't know how to interpret that? So the intended use goes hand in hand with the indication for use. One thing I'd like to point out with respect to that is to really understand the risks associated with that environment. And this is why when you go and change intended use or intended user, you may be introducing new risks that have to be mitigated differently. And so I want to put in a plug for understanding about the ISO 14971 standard. And how important that is to designers and developers. As they're looking at their input requirements. They go hand in hand, the earlier you can start to appreciate some of these risks, the better you might be in mitigating, including usability studies. So it all ties together. It all moves the the product forward. And this is why again, we go back to a comparative analysis to help to understand what the regulatory game may be for any new product. Thank you.
Speaker 1 39:57
And that wraps up today's episode of The Product Development playbook, we explored the challenges of medical device development from navigating FDA regulations to obtaining crucial ISO certification. Remember staying informed, collaborating with experts and embracing human centered design principles are essential for success in this industry. keep innovating, and we'll be back with more insightful discussions in future episodes. Thank you for tuning in.
Speaker 3 40:30
Yeah, thank you so much, Elaine. And looking forward to having you on the podcast again to talk more about risk and another things related to regulatory
Unknown Speaker 40:41
risk five guys. Bye, everybody. Bye bye.
Transcribed by https://otter.ai