How do dFMEA and ISO 14971 work together? This topic is controversial but essential, and today’s guest is more than capable of tackling it. Risk management is one of the top 3 reasons the FDA issues 483s, so it’s important to understand.
In today’s episode, Wade Schroeder, a medical device guru with a master's degree from the University of Dayton, shares his insights on risk management in medical device design. Wade discusses the importance of a top-down approach, the collaboration between dFMEA and ISO 14971, and how Greenlight Guru software aligns with ISO 14971. The conversation covers the value of considering the patient perspective, the complexities of regulatory, ethical, and business obligations, and the benefits of tools like dFMEA and fault tree analysis.
Listen now:
Like this episode? Subscribe today on iTunes or Spotify.
Some of the highlights of this episode include:
- Understanding risk management in medical device design
- Importance of collaboration between dFMEA and ISO 14971
- Exploring ISO 14971 and FDA consensus standards
- A top-down approach to risk management in medical device design
- Considering the patient perspective in the risk management process
- The complexity of regulatory, ethical, and business obligations
- ISO14971 as a regulatory burden ensuring patient safety
- How Greenlight Guru is designed to align with ISO 14971
- Benefits of tools like dFMEA and fault tree analysis
- Mapping dFMEA and ISO 14971 for FDA review
Links:
Memorable quotes from Wade Schroeder:
“Put simply, it's all about telling the story of what could go wrong with your device and what harms could that lead to." -- Wade Schroeder
"Before you even start your design, you need to identify the serious harms we need to avoid." -- Wade Schroeder
Transcript
Etienne Nichols
00:00:00.640 - 00:01:34.370
Hey everyone. Welcome back to the podcast. My name is Etienne Nichols, and I am the host of today's episode.
Today I got to speak with Wade Schroeder, and I spoke on the topic of risk management, specifically how DFMEA and ISO 14971 can work together. This is such a controversial topic, and I'm sure we won't turn that around in one episode.
But this is also an important topic since risk management, or maybe I should say risk mismanagement, is one of the top three reasons the FDA issues companies…483.
Wade has a master's degree in electrical engineering from the University of Dayton and is a medical device guru at Greenlight Guru, where he has worked with dozens, if not hundreds.
And that's not an exaggeration of medical device companies to overcome their challenges and to start building out their quality management system, their design controls, matrices, and their risk management files.
Wade is also one of the most fun people you'll ever work with, as he is completely dedicated to his work, but also genuinely cares about the people he's interacting with. So, I hope you enjoyed this episode with Wade Trader on risk management and the role of DFMEA within ISO 14971. Hey everyone. Welcome back to the podcast. This is Etienne Nichols. Today with me is Wade Schroeder.
For those of you watching the video, I'm just gonna say we did not plan to wear the exact same shirt today. But before we get into that, how are you doing, Wade?
Wade Schroeder
00:01:34.610 - 00:01:40.250
I'm doing good, doing good, and I don't know, you may have sneakily planned it without me knowing.
Etienne Nichols
00:01:40.250 - 00:01:50.690
So, we were in a virtual all hands meeting earlier today, and I did know that he was wearing the same shirt as I, so I could have changed before we started recording this, but I'll leave it at that.
Wade Schroeder
00:01:50.690 - 00:01:53.170
So, yeah, it's a comfy sweatshirt. I don't blame you.
Etienne Nichols
00:01:53.440 - 00:02:38.700
I'm excited to get to talk to you today.
For those of you listening, Wade was my mentor when I first started at Greenlight Guru, and I still look up to him both physically and from a career standpoint as well. He's a lot taller than I am in both ways, so it's good to have you on the podcast today.
I'm excited about our topic too, which is risk management, the approach to risk management. Okay, I Originally wanted to do a title that was a little bit provocative, like DFMEA are dead.
If you're on LinkedIn and you've seen that post and if you disagreed with it, feel free to reach out to me. There has been another post as well that I posted about ISO 14971 versus DFMEA, which got a lot of heat as well.
So, there's obviously a lot of controversy. Wade, do you have any thoughts on why that even might be before we get into the technical breakdown here?
Wade Schroeder
00:02:38.940 - 00:02:52.700
Yeah, I think it's just a matter of people are used to what they're doing, they've seen it work, and that's coming from both sides. So, both of them have their effectiveness, have their reasons, and when people see a be successful, they want to argue for it.
Etienne Nichols
00:02:53.030 - 00:03:26.240
Yeah, it's hard to let go of the some of the things that we've always believed in. You know, I just kind of go down a slight rabbit hole there.
Maintaining a beginner's mindset with the heart of a teacher is something I've always tried to do. But it's hard because at the same time, while you want to have that beginner's mindset, you don't want to let go of things you've always used.
So anyway, that's kind of a side discussion. But 14971 versus DFMEA, it's not an accurate way to put it, so I shouldn't even position it that way. But let's talk about both tools.
Maybe we could start with, I don't know, which one would you prefer to start with? Any preference?
Wade Schroeder
00:03:26.640 - 00:03:37.600
Oh, I mean, I would love to talk about ISO 14971. That's been my day to day more recently when I used to use DFMEA in the past. So, we can start with ISO 14971.
Etienne Nichols
00:03:37.760 - 00:03:45.520
Let's do it. Let's talk about ISO 14971. How do you look at for ISO 14971 and then maybe we can talk about what it is actually composed of.
Wade Schroeder
00:03:45.760 - 00:04:45.490
Yeah, well, I look at it first as it's a standard, it's a consensus standard for the FDA. That's first and foremost. But. But I view it as very helpful in breaking down your risk.
One of the things, when I first came to Greenlight, I had used FMEA in the past, as most people do when they're engineers going through any type of development. And when I came to Greenlight, the software tool is set up to align with ISO 14971. Since it's the risk management standard for medical devices.
And I was chatting with one of our other gurus, Jessica, at the time, and I was like, can you help me understand, like, what the difference is here? And the way she explained it. And once I started using it, I realized that 14:9, 7:1 was really easy to use.
And if you read the standard, it reads really well, too.
So, I think that's the biggest takeaway for me is that it really is an easy standard to follow, and it makes risk management a lot less complex, a lot less scary.
Etienne Nichols
00:04:45.730 - 00:04:54.270
Let's just go ahead and go one layer deeper. What is that process of risk management that ISO 14971 puts in place, or how would we follow that process?
Wade Schroeder
00:04:54.830 - 00:06:03.150
Yeah, well, there's a whole lot of clauses to it with a lot of additional detail. But I think, put simply, it's all about telling the story of what could go wrong with your device and what harms could that lead to?
It's all about that patient injury, the harms. How can you mitigate those?
So, it's, you know, identify that foreseeable sequence of events of things that could go wrong, whether that's design issues, manufacturing issues, use errors. What are those foreseeable sequences of events that could go wrong? What situation is that gonna put the patient in then?
And what harm could come from that? What injury? And I think that's the biggest thing with 14971 is it's a story of, here's what could go wrong, this is the harms it could lead to.
And then how am I mitigating that? How am I making the chance of that happen a lot less?
And that's what it's really all about, is you wanna get that down to a level where you can accept the risk then and say, hey, you know, it's impossible. Everyone knows you can't get rid of all risk. There's always going to be risk. But we have mitigated this down to a level where it's acceptable now.
And the benefits of our device highly outweigh these minuscule risks that we have mitigated as far as we possibly could.
Etienne Nichols
00:06:03.790 - 00:06:31.920
Yeah, that's a great way to put it. And that's something that I think when we get into the technical discussion, sometimes I tend to think we forget about the real purpose.
And that's the end goal. One engineer told me, he said, I'm not satisfied with the safety of my device until I could comfortably say, I'm going to use this on my son.
And I think that's a powerful way to look at it.
You know, when you're looking at this risk management, whatever tools you use, at the end of the day you need to be confident that it could be used on one of your family members, for example.
Wade Schroeder
00:06:32.000 - 00:06:36.480
So that's a serious way of looking at it. Yeah, definitely take it seriously when you're doing that.
Etienne Nichols
00:06:36.960 - 00:07:06.770
You mentioned the mitigation. I know ISO 14971 has a priority for approaching those mitigations.
Correct me if I'm wrong, I'm going to take a stab at my memory here because it's been a while since I've read the standard but starts with inherent safety by design. That's the first mitigation they want you to have. You want to design a device that just the risk can't take place. So ideally you design it in.
The second one is safety measures. So, I don't remember the exact wording that they put for that. Maybe you fill in the gaps here.
Wade Schroeder
00:07:06.930 - 00:07:09.450
That's as much as I remember on the exact wording too.
Etienne Nichols
00:07:09.450 - 00:07:35.790
So, okay, safety measures. So, like putting a guard over a blade, for example, or putting a sheath across a, you know, a scalpel.
And then the third one is training or IFU instructions for use. And do you ever see problems or justification?
I know we're getting a little bit into the application side, and we need to get back to the standard itself. But when it comes to those mitigations, why do they put it in that priority?
And are there any issues you've seen companies getting into by getting that priority out of order?
Wade Schroeder
00:07:36.110 - 00:09:27.490
Yeah, actually I think you explained it really well of why they put it in that priority. Because you know, if you have inherent safety by design, it's inherently impossible for that risk to occur for that patient to be harmed from that.
So obviously that's the best way. And that I think gets into one of the benefits of taking that top-down approach of 14971 is you're looking at the harms early on in your design.
So, before you even start your design, you've identified, okay, here's the serious harms we need to avoid. Other people have developed devices very similar to this, and these are the critical harms.
So very early on, and I'm sure every engineer out there would appreciate very early on knowing here's the things I need to design against. Very early on you have those. So, if you can build those in with inherent safety by design, awesome.
Obviously, there's going to be things you can't avoid. Like you mentioned the scalpel or the Blade, you know, you need it for the device to function properly, so you can't avoid those.
But if you can put in safety measures to avoid accidental risk, there definitely want to do those.
And then of course, last is, you know, IFU, I can guarantee everyone has gotten some technology in the mail recently, some toy they're playing with, and they did not read the user manual. No one reads the user manual. So, it's still good. And I shouldn't say no one reads the user manual.
Everyone should read the user manual, especially for a medical device. I know for myself, I'm not the best at that, but we should, because it does have important information. But I think it's just inherent human nature.
You can't rely on that. So that's why it's the lowest version of it. And you'll get called out for that. Whether it's an audit or going for your 510(k).
If you have the capability and they see the capability of you being able to put in safety measures, but all you did was an IFU, they'll second guess that. They'll ask you about that. So, it is important to take that hierarchical view of those.
Etienne Nichols
00:09:27.490 - 00:11:37.510
That makes total sense. So, you are talking about the inherent safety or. No, the IFU issue. I actually heard a story once about the nest.
I don't know if you heard the nest thermostat. I think it was Tony Fadell who started that company before Google bought it. During that time, they developed something, I think it was a baby monitor.
And he came from Apple. That was his background. He did all the iPod and the first few generations of the iPhone.
And so, he was very much into the user experience and everything being sleek design, all about usability. And they said, because this is going into a kid's bedroom, we have to have the warning label on the cord. And they had to tape that on there.
And so, his solution was, okay, we have this warning label here and this is it.
I don't know if this completely applies, but I'm just going to go down this rabbit hole anyway because they had to have that electric shock warning, whatever he said, okay, we'll put it where it will always be obvious so the user will tear it off. And that's what they did. They put it right up there where you would always see it, like just right beside the thing.
And it's so annoying, you rip it off. And they made it easy to rip off and so forth so that, you know, it would be a clean design once, once it's actually installed.
I say that to Say it's just an example of how we as humans, we don't want to see that warning label, you know, perpetually, even though maybe we should. And it makes it make sense. We circle back to what you were saying. I guess I'll get myself back on track. There were two things you mentioned.
One was the top-down approach. And I don't know if you mentioned the second one. It's just popping into my brain, the top-down approach, which is how I see ISO 14971.
But the second aspect of 14971 is I see it as user focused, and I want to see if you agree with me and we can talk about the other tools and how their approaches are. But the, the reason I say its user focused, I know there are other things that certain tools may not inherently cover.
For example, ISO 14971 expects you to cover foreseeable misuse, which may or may not be covered in something like a DFMEA or double fault failures, which I've seen teams argue about double fault, triple fault failures or maybe residual risk and so forth. So, all of those ISO 14970 requires to be considered. So, I see it as user focused.
Are there any thoughts that you have on that aspect of the standard being that top down, user focused approach?
Wade Schroeder
00:11:37.910 - 00:12:57.190
Yeah, yeah, actually with user focus. And actually, this is probably more even so top down than user focus.
But one of the things I always like to consider is what happens if the device is working as expected? Can there still be harms in that situation and how can we mitigate those? Then that leads to better, safer device design.
I think the best example I have of that is I'm a type 1 diabetic and I have an insulin pump. And an insulin pump can be really dangerous.
If you give yourself way too much insulin, obviously like that can lead to some very serious issues, even death. And if I type into my controller for my pump that I want to give myself a hundred units of insulin, you know, that could kill me.
But the device didn't do anything wrong, the device didn't act wrong. So, you wouldn't capture that in a failure mode, because there was no failure mode. I just typed in that I wanted 100 units of insulin.
But taking the 14971 top-down approach, you're looking at what are the most serious things that could happen from this device. The top one is going to be giving too much insulin. And so, at that point you're looking at how can we mitigate a user getting too much insulin.
And that's built into my controller actually too. I'm not allowed to give myself more than 10 units at a time.
Etienne Nichols
00:12:57.510 - 00:12:58.710
We need you alive. Good.
Wade Schroeder
00:12:58.710 - 00:13:19.270
Yeah, yeah, exactly. Which makes sense. But. But would that have been caught with FMEA?
Maybe someone might have thought about it, but by taking that top-down approach, you're focusing on the patient, on the end user, and you're thinking about how can we mitigate these harms. So, it's really important to look at that from that top-down approach there.
Etienne Nichols
00:13:19.510 - 00:13:45.620
Okay, so I love that example. That makes a lot of sense when I think about ISO 14971.
As you already mentioned, it's a systemic or systematic process to identify, evaluate, control, and monitor those risks. What do you think or what comes to mind when you hear people say, well, ISO 14971 really isn't comprehensive enough?
Do you have any thoughts or feelings on that? Love to hear your thoughts there.
Wade Schroeder
00:13:45.700 - 00:14:55.940
Yeah. Usually when people say that and people say that, I mean, it's inherent. I think everyone has that in the back of their mind.
When they first start with 14971, I typically ask them, you know, what is it about 14971 that isn't fully comprehensive? A lot of times they feel like it doesn't go deep enough into the design or the process.
If you think of, like PFMEAs, it's all about how you use it though, in the tools that you leverage. I think that kind of merges us into talking about FMEAS a little bit. But also, there's a lot of other tools too.
Like one of our favorites at my previous place, before coming to Greenlight that we use was a fishbone diagram.
We would just basically build out our components in this fishbone diagram and then we would talk about the major issues that could happen with those components. And that was a really great way to gain more of that comprehensiveness.
So, 14971 in itself is a format and it's a standard set of rules you should follow when you're thinking about these things, what you should be considering. But it also recommends, here's some tools you can use to help with that to make it more comprehensive.
Etienne Nichols
00:14:56.500 - 00:16:13.680
Awesome. Yeah, I love that you use that as an example.
So, I was actually talking to Mike Dreus recently on another podcast episode about the common issues that companies face or let me see if I can get the title right. The common issues found in an FDA inspection that result in a Form 483. And if you look at the last 10 years, they're all the same.
It's CAPA design controls and complaints.
And within that design controls umbrella, which is like the second, it's almost tied with CAPA for first, but, but within that, a large majority, I think it's the majority, a large percentage anyway, is tied to risk analysis. An inadequate risk analysis methodology. So, and I'm going to come back and I'm going to tie this together. You were talking about a fishbone diagram.
Now typically you'd think Ishikawa is a root cause analysis tool, right?
But when you use root cause analysis thinking and you apply it to your risk management, you're going to go a lot deeper, you're going to get a lot more out of that.
And I think one of the reasons we see that as an issue with FDA inspection is a lot of us engineers, we're not trained on divergent thinking, at least I wasn't. I was. I want to converge on a solution, right? We want to optimize for the solution rather than diverge and cover all of the potential problems.
So, I love that you use that as a potential risk analysis tool. I've not heard many people talk about that. So that's really cool.
Wade Schroeder
00:16:13.760 - 00:17:53.460
Yeah, we enjoyed it a lot. We got a lot of good use out of it.
And actually, I don't know, I don't want to change the topic if, if you had a certain direction you wanted to go with this. But I have an interesting, a customer I work with, they were working pretty closely with the FDA. They got a breakthrough device designation.
So, they get to meet with them more often and get good feedback.
And one of the things that they were hearing from the FDA about risk management, and I was helping them with risk management, it was going really good. They had a very well built out risk management.
We did a lot of those, you know, use a lot of those different tools to really dive into, you know, what could go wrong with the device and everything. In addition to taking the top-down approach. And we built it all in a 14971 format. It was great.
And the FDA came back, and they said, well, have you considered when a patient is in this medical state? And so, they are looking at it as we were kind of talking about before from the patient perspective.
So, we just looked at when we were doing risk and I should say they, I helped out a little bit. They did the majority of it.
But when they were looking at the risk, they took just a patient in this normal state that they expected the patient to be in. The FDA said, that's not good enough. We want to know what happens when the patient is in this state. They were working on a very high-risk device.
So are patients in different critical states.
And so, it was very important for them to analyze if the patient's brain was in this state, how does that impact what the device could do to the patient? And they had to really make some changes to their device. They had to take other risk into account.
And so just kind of circling back to the point from earlier of taking that patient approach, that's how the FDA is going to look at it too.
Etienne Nichols
00:17:53.620 - 00:18:14.330
Yeah. Okay, that makes sense.
So, when you think about the patient and the patient state, maybe use related risks, what do you think about how the 14971 approach allows you to cover design, use, process, or do some of those fall outside the scope of 14971? What are your thoughts? There's.
Wade Schroeder
00:18:14.720 - 00:19:19.890
Yeah, no, that's a great question. We could dive in deep here. They're definitely all encompassed in what you can do with ISO 14971.
As we were mentioned before, you can certainly use tools to allow yourself to dive in deeper, allow, you know, yourself to think about it a little bit differently, a little bit deeper. But 14971 will be all encompassing of those because you're talking about that foreseeable sequence of events.
So those foreseeable sequence of events could be, this goes wrong in this one step of our manufacturing process, which leads to this, which leads to the patient seeing this, which, you know, leads to this hazardous situation. There could be sequence of events that come from processes. There could be sequence of events that come from user misuse.
There could be foreseeable sequence of events that come from design as well. So, it is all encompassing. There are tools that can help you dive in deeper.
I know people really like PFMEAs, for example, because you're really detailing out every single step of the process as you're going through that. No reason you can't do that in a 14971 with foreseeable sequence of events as well.
Etienne Nichols
00:19:19.970 - 00:20:30.720
Yeah. And I guess the pushback might be that 14971 doesn't make you go deep if you're comprehensive enough to prevent any harm reaching the patient.
So, I want to bring out a point with that statement. 14, 9, 71 has an expectation that you keep the patient safe. I mean, that's the real focus. It's patient safety, your safety.
However, there may be other factors that a company wants to consider. So, when I think about companies and their, I don't know, maybe their obligations, they have multiple obligations.
Obviously, there's a regulatory obligation. And so, I kind of see ISO 14971 as fulfilling some of that regulatory burden.
And that regulatory obligation, it also bleeds into a second obligation that's an ethical obligation. So, they're trying to meet that with patient safety. But there's a third one, and that's a business obligation to make money.
So, you want to streamline your processes.
Perhaps a PFMEA is how you do that and actually get to where, you know, you have a repeatable process, you have a really solid throughput, maybe even a D FMEA so that you have fewer failures that still aren't going to result in any harm, but it could potentially have other issues that arise. So, I think about those three kinds of spheres. I don't know if you have any thoughts or something you want to add to that.
Wade Schroeder
00:20:30.800 - 00:21:52.130
Yeah, that's a really good point. And that definitely comes up as that business case that you're stating is like, where do you put that in ISO 14971?
Like, if it's not going to lead to any patient harm, like, you still want to have a device, though, that, you know, isn't going to get complaint and stuff like that, or.
But I think with that, if something's going wrong with the device or even just like going wrong with manufacturing and you're having to scrap a bunch of parts and all that stuff, that's when those extra tools are going to be helpful for you because then you're looking at all those different things. And even if it doesn't lead to patient harm, you have that documented using that other tool.
I would keep what's in your regulatory submission, though. I would keep that to the ISO 14971. Those patient harms. I probably wouldn't be putting a bunch of business risks.
So, we're going to lose money if this happens. That's one of the horror stories I heard from one of my customers. This is before they started working with Greenlight.
They were saying that they put in as a mitigation, I shouldn't say as a mitigation, as a reason for not mitigating is that it would be too expensive to mitigate that. And the FDA saw that as, no, this is completely necessary that you mitigate this.
So, yeah, using cost as a reason not to mitigate, but that's a different business side of it. It's still, oh, wow.
Etienne Nichols
00:21:52.130 - 00:22:48.880
Yeah, my brain just went down this path of the FDA reading that.
They probably wouldn't think this necessarily, but do you understand that the FDA is a cost to the American society, and we consider it a worthwhile cost even though it's, I don't know how much we pay for, you know, with our taxes on to even have an FDA. But you know that cost is not really a factor when it comes to patient safety. Yeah, yeah, that's the micro and the macro.
But anyway, so when I think of some of these tools, so DFMEA obviously is one that always comes up in conversation and like I said, you could go to different communities and see the controversy that arises when people start talking about ISO 14971 and pitting it against all these specific tools such as DFMEA. When I think about DFMEA, we talked about engineers and their preference for convergent thinking.
I see DFMEA as a bottom up, product focused approach to risk management and I want to see if you agree and see what your thoughts are or if you want to expound any on that.
Wade Schroeder
00:22:49.230 - 00:23:47.930
Yeah, I completely agree and that's why I say too, it can be a useful tool because any of the tools that you use, whether it's a DFMEA or like we did with the Fishbone there, there's tons of different tools you can use, but a lot of those, they just help you look at all the different components, all the different steps of the device, PFMEA steps of manufacturing, they're very useful tools for sure. I think when it comes down to it, engineers love looking at their product and you can't take it away from them. And that's what I used to do.
I think you said earlier like DFMEAs are what you used to do. I think everyone has experience with DFMEAs, they see the usefulness of them. I think we just have to remind ourselves that it's a tool.
And what we always need to come back to is patient safety and a tool is great to help us get there, but it's not all encompassing. And so, we take that 4971 top-down approach.
Etienne Nichols
00:23:48.090 - 00:24:38.480
Yeah, I agree.
I think one of the things that I always like to stress to customers who are working through this maybe for the first time, or even seasoned professionals who are pushing back on ISO 14979 you mentioned at the beginning, it's a consensus standard. There's an expectation that you're going to fulfill the requirements of ISO 14971.
And that being said, when you look at some of these other tools, as you mentioned, they could be useful Fault tree analysis, DFMEA, the FMEA approach or even Fishbone Ishikawa diagram, all these different things are good tools, any one of them, by themselves. However, I think it's important to think about. They may not fulfill the requirements of ISO 14971 by themselves.
And so that's something that I think we get into a trap. If you're holding onto this one tool and this is the tool you want to use, you just gotta remember that may not take you all the way.
So, yeah, just something to think about.
Wade Schroeder
00:24:38.560 - 00:25:40.680
Yeah, absolutely. And it's the same way, you know, with 14971, with what you were talking about is like, 14971 might not identify some of those business risks.
So, it's probably still helpful to use some other tools. One of my favorite customers I was working with, they had this massive, like. I don't know, it was like a mind map. I don't.
It was basically just all these notes that they put down, but they had. In this one sheet. I wish I remember what tool it was. In this one sheet, though, they had five different tools, all different ways of looking at risk.
And I'm sitting here just trying to understand what they're doing in all these situations. But he had a full grasp on it, had the best understanding of, like, all the risks associated with his device.
And if you look at it from all these different directions, you're definitely going to get the most comprehensive view of it. So, like, yeah, use all the tools that you feel are necessary as long as you're still using 14971 too. Because patient safety is most important. Yeah.
Etienne Nichols
00:25:40.760 - 00:25:58.520
And, you know, maybe another way to look at it is 14971 is the strategy, and these others might be part of your tactical advantage, you know, depending on how you approach it. Very cool. What are we missing? Any other thoughts that you have? We've talked a little bit about this in the past. It's been a while.
You know, we're wearing the same shirt, so we're probably just repeating each other.
Wade Schroeder
00:26:00.110 - 00:28:34.910
Yeah, no, I mean, I think the biggest thing, my takeaway is, as I've worked with, I think I said it earlier, maybe like 50 or so customers that have come into Greenlight with an FMEA fully built out, and they're like, okay, I want to transition this. How do I Transition this into ISO 14971? They actually map so well together. It's amazing how similar these are.
And it's just like what I typically see. And I don't want to, like, I guess, give away exactly how to map it because everyone's FMEAs tend to be a little bit different.
Which is another like benefit I guess of 14971. So, you got one format, really a lot of different FMEAs out there.
But with FMEAs, typically you have the failure mode which is going to be your hazardous situation.
You have your failure mode effects which are going to be your harms and then you're going to have your failure mode causes which are going to be your foreseeable events. And so typically they map together very well. Both of them do a probability and severity rating.
Both of them have mitigations, they map really well together. So, if you're currently using FMEA, I would say don't be intimidated by 14 971. Use what you have in your FMEA. Take that, it's great information.
Map that into 14971 because that's what the FDA is going to want to see. That's how they best review it. Map that into 14971. You probably just need to change some column headers. That's probably about it.
And then take that thought process and look at it from a top down as well. Because you did that FMEA, you looked from the bottom up, you understand your device, all the things that could go wrong.
But then take a look at what are those harms that could come to the patient.
I highly recommend if you hadn't taken the opportunity to go into the FDA's database, type in your product code, go to that product code, product lifecycle report and look at all of the harms and even has hazards in there of the issues that have happened with the devices in that same product code. Take a look at that. It has such valuable information, and you can do that from the very beginning of your design.
Before you even develop the first thing about your product. You just have an idea of what you want it to be. You can go look that up and you can start your design with all of that risk in mind.
But I deviated like six different times when I was talking to that. What I want to get in is if you're doing FMEA right now, don't be intimidated to move to 14971. It's easy to transition.
And then you can just take the rest of it from that top-down approach. Looking at those potentials.
Etienne Nichols
00:28:35.780 - 00:29:00.220
That's fantastic advice. I want to just kind of emphasize one of the things you said because you did say several things and they were all good.
One that I think is a great piece of advice is going to that FDA website, looking up your product code that maybe we're talking about a Class II device, and you have a predicate in mind looking up that predicate, seeing the risks associated with that. That's great piece of advice that I think some people sometimes that's a little bit difficult to unearth for some newer companies and so forth.
Wade Schroeder
00:29:00.220 - 00:29:13.590
But yeah, a lot of people don't know it's out there. FDA doesn't have a very good advertising agency, I guess we can put it that way. So, they're not Greenlight Guru.
You don't get an email from them all the time about the new tools that FDA has available.
Etienne Nichols
00:29:14.230 - 00:29:18.310
Maybe that's okay, maybe we don't want to pay for them to be a marketing agency, but you know.
Wade Schroeder
00:29:18.310 - 00:29:19.990
Exactly. Yeah.
Etienne Nichols
00:29:20.230 - 00:29:49.970
Okay. So, one other thing you mentioned, Greenlight Guru and mapping them to Greenlight Guru’s process.
In the past I didn't plan to go down this route, but I kind of think I might anyway. In my past I've seen Excel be the main tool that people use to house their risk management. But Greenlight Guru is a little bit different.
It puts in guardrails around 14971 to force you into that 14971 way of thinking. What does that look like and what's the output look like? Is it something someone would be familiar with?
Wade Schroeder
00:29:50.210 - 00:30:41.120
Yeah, absolutely. Well, I guess speaking of that output first it's probably going to look very similar as I mentioned, to that FMEA that you're used to doing anyway.
You know, change the column header so you'll be able to map that into 14971 and then take it the rest of the way with the top-down approach. I think the best part about using a tool like Greenlight is that you have your design control traceability matrix connected to the risk.
So, they're really one and the same as you're identifying your risk and how you're going to mitigate those, you're pulling those mitigations from your traceability matrix, and those links are kept there for you. That way you don't have to manage two different Excel sheets and oh, it's a nightmare. I mean I'm sure so many people have had to do that before.
I know that's how we did it in my past life too was two Excel sheets, one for risk and one for design. So.
Etienne Nichols
00:30:41.200 - 00:30:42.480
And everything shall meet.
Wade Schroeder
00:30:42.480 - 00:31:27.830
Yeah, yeah, exactly. And then the two shall meet and it's, it's madness.
And then if you change one, you always forget to change the other one that references this one and.
But anyway, that was my like mind-blowing moment when I, I was actually interviewing for Greenlight and Taylor Brown, one of the other gurus, she showed me Greenlight during the interview and I was like, oh my gosh, like, even if I don't get this job, like, how do I get this tool? Because this would have made my life so much easier doing design and risk with my latest product.
But yeah, that was the part that blew my mind is just how well connected your design and risk are. It just creates a higher quality product. It makes risk management so much easier.
I know no one likes to do risk management, so yeah, that's my two cents on.
Etienne Nichols
00:31:27.980 - 00:31:48.140
And I want to go one layer deeper into what I think is a benefit of using a tool like Greenlight Guru. And that was. We only touched on UFMEA versus PFMEA versus DFMEA and maybe that's a topic of a future discussion perhaps.
But how would that be handled in a tool like Greenlight Guru? I mean, is it, you know, one repository or are you able to see different views? How do you handle that?
Wade Schroeder
00:31:48.300 - 00:32:44.500
Yeah, no, it's a fantastic question. So, you can put it all in that one matrix view. That way it's all still connected to that design control traceability matrix.
But then you can identify those as you're going through that foreseeable sequence of events. Is this a use related error we're talking about? Is this a process use or process error?
Is this design so you can label those in Greenlight, something that's called tags, you can label those and then you can filter that down. So, if you're just building that usability file, we'll say just pull out the ones that have that usability tag, put that into your usability file.
Or if you're wanting to send something to your manufacturing team, you know, part of transfer to manufacturing, something like that, you pull out just the process ones and send it to them. So, you can label all of those that way they're all still in that same risk matrix to get that comprehensive view tied to your design controls.
But then you can label them if you ever need to filter them out.
Etienne Nichols
00:32:44.580 - 00:33:36.060
Or even label them with multiple. Which I think is great. So, absolutely very cool. Well, we can get back off the tool discussion though.
You know, I love seeing new tools and like you said, when I first saw the tool, I was mostly in the design controls, but I also was handling some risk management.
And I thought, wow, you know, this is regardless of whether I work for this company ever, this is going to be my new tool that I preach wherever I go. So, it's fantastic for a product development Engineer, you can't, man. It's life changing.
Well, any other thoughts on if we go back to ISO 14971 and then talking about some of these tools? I think we covered a lot of ground as far as ISO 14971 being a strategy and could be an all-encompassing strategy inclusive of your tactics.
But there are other tactics you can use as well to, you know, maybe go a little bit deeper on the product side and so forth if you like, like anything we missed or anything you want to cover. Any other thoughts?
Wade Schroeder
00:33:36.300 - 00:34:09.410
You know, I do want to give one tip that I give to every one of my customers I work with that use 14971. Definitely take a look at 24971. Yes, it's the application of 14971. That is the most helpful guidance document ever.
It gives you examples even for benefit risk analysis. That's one of my favorite things to share when people ask about Brazil as great examples in there for that.
But yeah, definitely take a look at 24971 as you use 14971.
Etienne Nichols
00:34:09.410 - 00:34:21.610
That is so handy that they made it 24971 as well. Just to throw that out there. Thank you, ISO. I also think they separate out the cybersecurity risks, which I think is cool in 24971.
Wade Schroeder
00:34:21.690 - 00:34:37.900
Yeah, they talk about that as well. Yeah, we don't need to go down that rabbit hole because that's a whole another ball game.
But yeah, they do talk about that as well, which is very helpful when you're mapping it and you're considering your cyber security risk. How does that relate to 14971? So, yeah, another good point about 2497.
Etienne Nichols
00:34:38.060 - 00:35:07.760
We'll link to both standards in the show notes. So, if you're interested in pursuing one or the other, then, you know, easy findability there. Okay, thank you so much, Wade. I really appreciate it.
I know we're almost out of time. Well, if you're ever at Greenlight Guru off to show you Wade's calendar. It is back-to-back to back-to-back.
I don't even think he goes to the bathroom. I'm amazed at this guy. We'll edit that out hopefully. But thank you so much for taking the time to be on the show is what I'm trying to get to.
And yeah, I'm excited to have future conversations on maybe this subject or a different subject. But thank you so much for being on the show.
Wade Schroeder
00:35:07.840 - 00:35:12.160
Awesome. Thank you, Etienne. And yeah, hopefully it was helpful for people out there.
Etienne Nichols
00:35:12.320 - 00:36:39.330
All right, we'll talk to you later. Thank you so much for listening to this episode. We'd love to hear what you thought. Feel free to reach out to us.
Etienne Nichols, Greenlight Guru or look me up on LinkedIn. Feel free to reach out to Wade as well if you're interested in learning about our software specifically.
I don't know if you've heard, but we have just released a new version of our risk management software. On top of that, we have something new called Risk Intelligence, which is an AI platform.
I shouldn't say that it's just a buzzword these days, but it crawls out there to see what risks are associated with your particular product code and maybe the predicate and the predicate of the predicate, all the different harms that are associated with those things and brings those back to you and applies Bayesian statistics to determine a baseline level of where you should be looking at your risks and what the probability or the potential probability of those are. Lots more detail we could go into on that, but our Risk Solutions is what we're calling it.
Both the risk management software and the risk Intelligence gives you a total risk solution. Definitely something worth checking out. If you're interested, head over to www.Greenlight.Guru and you can see more there. Finally, please consider leaving us a review on iTunes. I know this is something that I struggle to do myself, but it's something that helps others find us. It lets us know how we're doing, and we love to hear from you and see what you think. Thanks again and take care of.
About the Global Medical Device Podcast:
.png)
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.
