FDA Proposes Allowing Medical Device Makers to Summarize Malfunctions: What does that Mean for You?

The FDA announced a new proposal regarding the bundling of device malfunctions when Medical Device Reporting (MDR).

On today’s episode, we have Mike Drues, president of Vascular Sciences, to help us dive into the impact of this proposal and the safety of medical devices.

The FDA proposal’s benefits probably outweigh the risks and should be implemented on a small scale.

LISTEN NOW:

Like this episode? Subscribe today on iTunes or Spotify.

Some highlights of this episode include:

• Depending on the severity of the malfunction, you are given a specified amount of time to report it.
• What companies should do to make patients and providers aware of issues.
• Should you react immediately or investigate the root cause? A malfunction is a serious matter and time is critical.
• The importance of having decision trees and processes in place before an issue arises.
• A company’s obligations for severe, life-threatening events and reporting timeframes.
• Rather than reporting individual malfunctions, companies will report malfunction summaries every quarter.
• Companies should be proactive and keep an eye on competitors’ similar products that have problems.

Links:

FDA Proposal

FDA Proposes Allowing Medical Device Makers to Summarize Malfunctions

FDA Medical Device Reporting

Quotes by Jon Speer and Mike Drues:

“If you’re getting a complaint, you need to make that decision or assessment as to whether or not additional reporting is required.” - Jon Speer

“Any action a company takes or doesn’t take is as important, if not more important, than the reporting requirements.” - Mike Drues

“Investigate it first, understand the root cause first before you just do a knee-jerk reaction.” - Jon Speer

transcription:

Recorded Intro: 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:                  Oh, my goodness. Have you seen this, folks? There's a new proposal from FDA regarding malfunctions of devices. And this proposal is related to MDRs and adverse events. And right now, if you have an MDR type of event for your device with FDA, then you need to report that each time that happens. And this proposal is suggesting that you can bundle these basically, that maybe once a quarter you could summarize what's happening about these malfunctions and send one report once a quarter. Very interesting program. It's still a little bit up in the air as far as what happens next. But anyway, Mike Drews and I, from Vascular Sciences, we dive into this topic a little bit on this episode of the Global Medical Device Podcast.

Jon:                  Hello, and welcome to the Global Medical Device Podcast. This is your host and Founder and VP of Quality and Regulatory at Greenlight Guru, Jon Speer. And today we are gonna talk about some recent news frankly, that it's really, at this point in time, as we recording this, it's really unknown what the overall impact is gonna be, but it is very interesting. And this topic is about this discussion's about device malfunctions and what this means to safety and medical devices.

Jon:                  So joining me today, my good friend Mike Drews, the President of Vascular Sciences. Mike, welcome to the Global Medical Device Podcast.

Mike:               Thanks, Jon. I'm looking forward to our discussion, as always.

Jon:                  All right. So, you shared this article with me. And I'll be sure to provide a link to the folks so they can read it, as well. But the title, or the headline of this article, "FDA Proposes Allowing Medical Device Makers to Summarize Malfunctions." And kind of, the subtitle is "Proposal Allowing Firms to Summarize Malfunctions Reignites Safety Debate." And I want to get into that a little bit. But I thought first a good place to start, if you'd do me a huge honor in talking a little bit about the current requirements when it comes to adverse event and medical device reporting. Can you maybe, remind the audience a few moments here about what are the current requirements as we know the regulations today?

Mike:               So, is a great place to start, Jon. And a small request, since both of us have experience in this area, I'd like to do this together. So, let me kind of get the ball rolling here, and then you can feel free to add on whatever I may have forgotten. As probably everybody in our audience knows, any time that there is a problem, a malfunction or otherwise, with a medical device, we have certain obligations to report those incidents to the FDA. And depending on the severity of the problem, that will determine how quickly that we have to report it. In other words, for events that are not necessarily life-threatening, not mission-critical so to speak, we have a little more time, maybe 30 days. On the other hand, if it's something that is truly affecting the safety and life or death kind of a situation, then that information needs to be reported much more quickly, usually in five days or so.

Mike:               And by the way, I would also like to see, although it's not in the current regulation, some frequency of events parameter added in here, as well. In other words, even though we might have a non-life-threatening condition, if we have a whole bunch of events going on at the same time, or within a certain period of time, then maybe we need to report those in a more timely fashion, as well. Right now, at least in my experience, Jon, there is no regulatory or quality requirement to do that. So, that's the beginning of the MDR reporting structure. What would you add? What else do you think is important that companies remember under the current system?

Jon:                  Yeah, that's a good place to start. An MDR is, I guess we could probably think of times when it's not, but generally speaking, if you get a complaint about your product, and that complaint led to some sort of, or could have led to some sort of serious injury or death, and technically speaking that fits within the definition loosely, of what an MDR is. So companies need to be managing their complaints. And virtually for every complaint, at least this is my recommendation to companies, if you're getting a complaint, you need to make that decision or assessment as to whether or not additional reporting is required to FDA, and frankly, other regulatory agencies.

Jon:                  And that's not something that you should delay. It's a decision that you should evaluate almost immediately upon learning this, because to the point you made a moment ago, there is a timetable, or a time scale. The clock is ticking, so to speak. You have a finite period of time. And so, the quicker you can get a handle on this and an understanding of whether or not this is a reportable type of event as it's defined in the regulations today, the quicker you make that decision, frankly, the better your processes are gonna be, the more you can stay on top of things and better address the challenges.

Mike:               I agree, Jon. And actually, I would take it a step further. Thus far, we've been talking simply about the reporting requirements. And reporting is certainly an important part of this, but I think in many ways, any action that the company takes or doesn't take is as important if not more important than the reporting requirements.

Jon:                  Oh, true, true.

Mike:               So, what would you advise companies to do, Jon, in terms of their own investigation as these complaints come in, especially if it's an acute problem, a life or death situation? I mean, should we automatically institute a CAPA? Should we in some cases, send out warnings to our customers, be they surgeons, or physicians, or in some cases individual patients?

Jon:                  Yeah.

Mike:               Should we do failure mode re-creation to try to figure out under what circumstances the problem led to this kind of a malfunction, so that we can determine the root cause? In other words, was it a design issue? Was it a manufacturing issue? A material issue? Was it a user issue? Was it a one-off kind of a thing, just kind of a fluke? Or was it something that affects the entire lot, or in some cases the entire design of the product? So, what do you think the company should be required to do, perhaps as part of their quality system, to not just report this information but to act on it?

Jon:                  Yeah, good questions. And my first advice is, do not knee jerk. Now, don't mishear me. I want you to be deliberate. I want you to apply a systematic, methodical approach to this. I want you to be prudent in your investigation. But just because an event happens, that does not automatically mean that you need to necessarily trigger a CAPA. It does not necessarily mean that you need to recall product that's in the field. You need to do that initial assessment. You need to determine what are the immediate actions that you need to take. You need to understand in some respects, a root cause analysis of this event so that you can better determine, are there other products in the field that may have similar sorts of issues.

Jon:                  But you need to take this very seriously. It is an urgent matter. When you get this sort of complaint from a customer, you need to be thorough on that. And yes, it is possible that once you do an investigation, once you do a little bit of a root cause analysis, some of those actions may actually happen. You may need to do a recall. You may need to notify other customers. You may need to elevate this to a more formal CAPA investigation. But investigate it first. Understand the root cause first before you just do a knee-jerk reaction.

Mike:               Well, I love the way that you put that, Jon. We need to investigate. We should not have a knee-jerk reaction. But as a regulatory consultant, one of my most important jobs here is to play devil's advocate. So let me kind of turn the table a little bit. If we take some period of time to do that investigation that you and I both agree is necessary to come up with the root cause, in the meantime, how many other people are potentially being harmed because we haven't notified our customer base as to what's going on?

Mike:               One of the things that you and I have talked about in the past, Jon, a growing part of my business is acting as an expert witness in a medical device product liability lawsuit. And I can imagine if we had a situation where there was a severe malfunction, the company was taking your advice and my advice of investigating the problem. In the meantime, somebody else, a second patient was harmed. And then maybe a third patient was harmed, and so on. And so, now the attorney is going to be looking to me to say, "Hey, did not the company have a duty to inform, or a duty to notify that there is a problem going on?" "Maybe we don't know yet what the problem is being caused by, but we want to at least let you know that there is a known problem, and something you should be aware of."

Jon:                  That's fair. I mean, you make a lot of valid points. And I still, even with those valid points, I stress that once you learn about something, it's serious. I mean, if somebody got injured, or there was a death, or something of that nature, that's a very serious matter. And I think almost every regulatory professional I know and that I've ever talked to at a medical device company takes this type of situation very, very seriously, and you should.

Jon:                  When you learn of those events, for that person who's responsible for that area, it probably is a "drop what they're doing," this now is the, this is a fire. This is the absolute top priority that they need to deal with. And so, don't waste time. Dive into that investigation immediately. But you should have decision trees. You should have processes, you shouldn't be defining what to do for an adverse event or an MDR type of event when you get one. You should already have worked out what those process steps are. You should lean into what's defined in FDA, CFR on this as well, Part 803. You should probably even look at advisory well, part 803. You should probably even look at advisory notices and recall regulations as well. I think that's an 806, right, Mike? Do you recall?

Mike:               I don't remember the number. I don't remember the number specifically, but anyway, yes, I agree with all the recommendations that you just ticked off, John, but I also know, as a former R&D engineer myself, when I started out in this business a very long time ago, one of the things that I used to spend my time on is failure mode recreation. In other words, you had a problem, you had a complaint, you had a malfunction of a device in the field, and we would try to recreate the circumstances that led to that particular malfunction. I also know, from doing this work myself many, many years ago, that it does take time.

Mike:               Here's an interesting suggestion that may not be very popular with some folks in your audience, but for very severe life threatening events, especially devices that they're used very frequently, where we're under the five day reporting window for example, if this happens on, say, a Friday afternoon, does that mean that you ask your key employees to work over the weekend, to come in on Saturday and Sunday, to be doing this? What exactly does that mean in terms of our obligation?

Jon:                  Yeah. Yes, it probably does, Mike, mean if you learn about something at 5:00 pm on Friday, and it's a five day type of event, yeah, it's one of those exceptions, sorry folks, to lay this on you, but that's one of those times where every day matters. You want, as an engineer, an R&D engineer, who wants to do that, try to, that failure mode, try to reproduce this, I want as much time as I possibly can, especially knowing that the time is ticking, that there's a finite period of time before I have to provide a response.

Jon:                  So yeah, I think this is one of those cases where you have to alert your key personnel and let them know, "Hey, we need to try to understand how and what happened here so that we can determine how big this is." Because that's really what you're trying to do. You're trying to figure out what actions you need to take in order to contain this from being a bigger issue.

Jon:                  Once you understand that, then now you can determine the appropriate course of action. Now that you understand a little bit more about what's happening and how this happens, you may have to generate an advisory notice. You may have to communicate to customers, "Don't do these three things when using this product. If you do, this potentially could happen."

Mike:               I also think, John, and we going to move on to the proposed changes here in a moment, but I, one last thing that I would mention as a suggestion to the audience, this is my, oftentimes, my professional recommendation because I think it's the right thing to do, not necessarily because FDA requires it, but also because it's something that I've learned from my product liability work.

Mike:               I do think there's something to be said for transparency. I do think there's something to be said for what my attorney friends call duty to inform. If you have a problem that's a relatively minor problem, maybe an inconvenience, maybe a nuisance, certainly nothing that is critical to a life or death situation, then this advice would not apply, but if you do have a situation where potentially this could be a life or death issue, potentially it could be affecting a number of devices, because you have a lot of these devices out in the field right now, I think that the right thing to do, and I would be, I would love to hear your thoughts on this, John, is go ahead and notify your customer base anyway.

Mike:               Just basically say, "Hey, we want to let you know that there is a problem, or one problem has been reported. We don't know necessarily all of the details yet. We're in the process of investigating it. We will certainly share more information when we have it." But at least put that information out there. Part of the reason why I make that recommendation, John, is because that will take away the ammunition from a potential product liability attorney from saying, "Hey, you had this information and you were sitting on it. Yeah, you were investigating it, but you were sitting on it for X number of days. In the meantime, my client was harmed because you were sitting on this information."

Jon:                  Alright. That's good advice. Folks, don't take that advice lightly. As Mike has mentioned, he gets called to be an expert witness sometimes, so as a guy that's on the stand as to what companies could or should or did or didn't do, take it directly from him. It's probably good to let people know.

Mike:               I was just going to say, John, maybe this is a good time to move on to the proposed changes ...

Jon:                  Yeah.

Mike:               ... that we wanted to talk about in these reporting requirements. To be crystal clear, the scenarios that you and I just discussed are actually excluded from these proposed changes.

Jon:                  They are. Yeah.

Mike:               In other words, go ahead.

Jon:                  I was going to say, the concern, and I read this article, well, first of all, there's a lot of unknowns here, folks. This is not new regulation as of the time of this podcast. It's unknown at the time of this podcast what happens next. This is a proposal that says, for all intents and purposes, based on what Mike and I know today, this is an idea that's being discussed. I don't know what this is going to translate into.

Jon:                  But the basic premise is that, as I read this, Mike, is that if this proposal were to go to the next step and eventually become a guidance or eventually regulation, all those things we just talked about go out the window. This is talking about doing like a summary report, maybe even as infrequently as every quarter, about product issues, rather than reporting each individual MDR type of event. Do you read something similar, or did I misread that?

Mike:               No. I think, John, my current understanding, and I think the disclaimers that you put, you know, this is very much a work in progress. So neither you or I are privy to all of the details, but I think your assessment is correct. Essentially, the idea here is rather than requiring companies to report malfunction incidents on a individual basis, whether it's within 30 days or five days, depending on the severity, companies instead can report malfunction summaries, perhaps once a quarter, where if we have similar malfunctions, in other words, a series of malfunctions that are all caused by basically the same problem, instead of reporting them individually, we report them in a summary fashion, and instead of reporting them as they come in, so to speak, we report them perhaps on a quarterly basis.

Mike:               To be fair, there are some important caveats that FDA is putting on this program. For example, it's being limited to the least dangerous devices. We're not talking, usually, about life supporting, life sustaining kinds of technologies. In addition to that, there's another interesting caveat that's on this program, John, and that is malfunctions that are already known to the agency. In other words, there are a number of devices that have a history of known malfunctions. My reading of this draft proposal is that as long as the agency, and obviously the company, has seen these malfunctions before, it's really nothing more than providing sort of an update. "Hey we've had a few more of these kind of similar instances."

Mike:               As I understand it, it doesn't look like we're going to be able to use this summary reporting format for reporting of new types of malfunctions or other problems. I think, John, that seems like a reasonable precaution to me in limiting it to malfunctions that we've already seen, we already know about.

Jon:                  Well, yeah. I think that's reasonable. I guess the, as you described that, one of the thoughts that, or memories that jumps into my head was an FDA inspection that I was a part of many years ago. This particular inspection, that was one of the first things that the FDA investigator asked for is a list of all the MDR events. The company had done a good job. They had reported those MDRs to FDA, of course that met the criteria. The interesting thing to me was that the FDA investigator didn't have that information. There wasn't ... There was like a lag in information from when MDRs were reported, it seemed anyway, to the database that this particular investigator was pulling from. I don't know if that's normal or abnormal, or if you've seen similar sort of things.

Mike:               Well, I have seen similar things, and quite frankly, it's not a surprise. It's no secret that FDA does have a difficult time keeping up with complaints and MDRs and so on. To be fair, this is not unique to the device world. It's just as big of a problem, perhaps even a bigger problem, in drugs.

Jon:                  Yeah.

Mike:               One of the challenges that FDA has is when they get all these hundreds or thousands of reports coming in, is how do you triage them? How do you separate the needles from the haystack? How do you figure out the ones that are really worth worrying about, and the other ones that are not?

Mike:               Maybe by allowing companies to summarize these reports, several of them at the same time, instead of one at a time, that might actually allow FDA to better triage these reports to be able to see the forest through the trees. What we really want to be able to do is we want to find the problems that are really worth worrying about, so that we can make sure they're fixed properly, and at the same time, not let those problems be covered up by just the noise, the chatter of all the other things that are being reported that are maybe not as critical.

Mike:               That's a challenge for the FDA. I think ultimately though, and this might sound a bit harsh to some people, I think the ultimate responsibility is on the company.

Jon:                  Of course.

Mike:               Because although the FDA can use the excuse of they're getting all this data and they might not have the resources to sort it out, I'm not sure that the company can make a similar excuse. Obviously it's in their interest to keep track of how their products are being used.

Mike:               By the way, this is a little bit of a tangent, but I also think the company has an obligation not to keep an eye just simply on their products, but on similar medical devices on the market. If a device was brought onto the market under the 510(k), if there's a problem with the predicate device, and if there's a problem with the predicate device, and let's say for the sake of discussion that the problem with the predicate device is based on the predicate device's design, and the design of your device is based on the predicate device, and there's a problem with the predicate device, then it stands to reason that there might be a problem with your device. So, I would actually like to see companies even be more proactive in, not just looking at problems with their own products, but problems with their competitors, especially a similar predicate device, and have that in their quality system to at least trigger an investigation, "Hey, could this problem that our competition is having on our predicate, could that problem happen to us?" What do you think of that suggestion, Jon?

Jon:                  Well, I love it, because I think, you and I have talked on previous podcasts and previous conversations, one-on-one conversations that we've had, that it seems that so often, companies are very myopic in their view on the world, either intentionally, or whatever reason. And part of that narrow view of the world, it seems like the behavior that a lot of companies exhibit is react to situations, wait until something happens, rather than being proactive. And what you just described is a proactive measure. I mean, we shouldn't just look at, or wait until something happens to our product. We should be more proactive about that and staying ahead of it. And part of staying ahead of things going out and soliciting, or looking and observing and seeing what other predicate devices or similar technologies or products, what's happening with those products is important. And when we learn this information, this is really, the whole concept of product lifecycle risk management.

Jon:                  If you're early in development and you have identified a predicate device that's already on the market, and that data, that information on NVR is adverse events, and anything that you can glean, good or bad about that product should all be inputs into your risk management activities so that you can make sure that you've properly designed your device to mitigate or to control those types of issues from being repeated once you launch your product. So, yeah, I like the idea a great deal. And I think the more proactive companies can be, yeah, it's work, folks. Don't mishear me. But the overall objective is to make sure that the product that you're developing is as safe and effective as possible.

Jon:                  And if you know, and you can find it, it's readily available. And if you can find this information about a predicate device that has already had, has known issues, and you didn't do something about it, I mean, shame on you.

Mike:               Well, not only shame on you, Jon, but I would add from my product liability experience, that that actually increases your potential product liability. Because if there is a known problem with the predicate, as I said, if it's for example, a design issue and your design is similar to the predicate, or it's a manufacturing issue and your manufacturing process is similar to the predicate, or if it's a user issue and your device is used similar to the predicate, if there's a problem with the predicate, it stands to reason that that problem might also affect your device. And at the very least, I would like to see the company investigate the possibility. So in other words, you're exactly right, being proactive as opposed to reactive.

Mike:               On a personal note, Jon, I would like to believe that whether, as medical device professionals, whether we are working in our R&D, or in manufacturing, or quality, or regulatory, or what have you, that people would be doing these things anyway because it's common sense, because professionally, it's the right thing to do, and that we would not need to have a regulatory requirement or a quality requirement to tell people to do that. But unfortunately, Jon, I didn't fall off the turnip truck yesterday. So, sometimes, we do need to have rules that tell people what they should know, anyway.

Jon:                  Yeah.

Mike:               So, bottom line, to kind of wrap up the summary, I think that at least from what I've seen so far, there are advantages and disadvantages to everything. But overall, with the caveats, with the limitations that seem to be part of this program, I think probably, my initial take is that the benefits probably outweigh the risks. I would like to see this program implemented on a small scale to start with. And I understand that's the plan, at least initially. It would be available to only medical devices in certain areas and certain product codes, for example. And we try it out for a while, and we see how it works.

Mike:               Because there are some potential concerns here about transparency. And as a matter of fact, the article which we can post on the website mentions a couple of specific medical device companies, I won't mention their names here, that apparently, did some pretty boneheaded things, that did not report certain problems because, believe it or not, according to this article, that information was lost. [crosstalk 00:26:59]

Jon:                  Oh, no.

Mike:               And then they found it again five years later. And listen, Jon, suffice it to say, this was not a little, tiny little medical device company in somebody's garage or basement that nobody ever heard of before.

Jon:                  Right.

Mike:               This particular company is one of the largest medical device companies on earth. I just find that, well, I mean, embarrassing to say the least.

Jon:                  Yeah.

Mike:               So anyway, I'm cautiously optimistic. I think that potentially, this program, as I said, could have benefits for companies, could have benefits for FDA, could hopefully, have benefits for patients, as well, if we implement it properly, if we have the proper safeguards and caveats in place. And as I said, if we roll it out on a small scale first, do sort of a beta test, I think it's reasonable to try it. What are your final thoughts, Jon?

Jon:                  Yeah, I mean, it is interesting. And I know that again, there's a lot that's still unknown at this point. I know this proposal was, I don't know exactly how many weeks it was out for comment. I believe the comment period is closed at this point in time. So, we are in a little bit of a waiting period at this point. But it does seem like there are some potential benefits. To your point, I mean, it's not gonna be applied unilaterally. There are certain areas, or device types that this type of program would suit very well, and there are others where frankly, it just won't. Like those life-sustaining types of devices.

Jon:                  So, I think it's a good idea, it's a good move to try to streamline. And I think, I do believe that applied properly, this type of approach will actually get companies, this is my optimism, maybe, coming out a little bit, Mike. I guess I should qualify that. I'm optimistic that this type of program will encourage companies to be a little bit more proactive about what's happening with their products, as well as other similar products, predicate devices, and so on, as well as doing a better job of tracking and trending what's going on with their products, and having a bigger picture view.

Jon:                  And I think that's the problem, that this type of thing, this type of program has the potential to do, is to give a bigger picture rather than as an individual single event type of reporting mechanism.

Mike:               Well, I agree with you. I think of it does encourage companies to be proactive, that's a good thing. I think if it does allow us to use our resources, both in the FDA, as well as in the company more effectively, I think that's a good thing. But the most important thing that I think our audience should remember about this program is really, what we're talking about simplifying the paperwork, here. We're not really talking about making any substantive changes in the actual reporting events, reporting requirements themselves. I mean, we all should agree that we have an obligation to report malfunctions. We have more importantly, an obligation to act on that information, and to act on it in a timely fashion, whether we're talking about hours, or days, or weeks, or months. That kind of depends on the situation.

Mike:               But I share your optimism. I like to think of the glass being half full, and this is a positive step in the direction that we want to go. But as I said, time will tell. The proof will be in the pudding.

Jon:                  All right, Mike. Thank you so much for diving into this topic with me today. Folks, let me just share with you that one of the things that we have in the Greenlight Guru eQMS Software platform and our postmarket workflows allow you to manage customer feedback and complaints. So, we talk about the ability to track and trend what's happening with your products and processes, especially complaints. You'll be able to do that very easily through a few clicks of a few buttons in the Greenlight Software platform, so that you can get a better picture. And it's certainly gonna help you better report this type of information to FDA and other regulatory agencies around the world.

Jon:                  So, if you'd like to learn more about the Greenlight Guru eQMS Software platform designed by medical device professionals specifically for the medical device industry, go to www.greenlight.guru to learn more. Once again, this is your host, the 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.