This episode explores the transition from the Quality System Regulation (QSR) to the Quality Management System Regulation (QMSR) and the foundational elements required for medical device compliance. Host Etienne Nichols and guest Mike Drues discuss the philosophy of building a usable system rather than a "museum of SOPs," emphasizing that the standard list of QMS sections should be viewed as a starting point rather than an exhaustive checklist.
The conversation examines the critical differences between 510(k), De Novo, and PMA pathways regarding manufacturing requirements. While a 510(k) submission may not strictly require detailed manufacturing information at the time of filing, Mike explains why companies must remain audit-ready from the moment they register their establishment with the FDA. The discussion clarifies the timing of registration and the "radar" companies enter once they become commercially active.
Finally, the dialogue focuses on a "triage" approach for resource-constrained startups. By prioritizing Design Controls and Risk Management during early development, teams can remain compliant and ethical without over-investing in post-market systems, such as complaint handling, before they have a product on the market. Mike warns against the dangers of "copy-and-paste" quality systems, urging manufacturers to use professional judgment to tailor their processes to their specific technology.
Love this episode? Leave a review on iTunes!
Have suggestions or topics you’d like to hear about? Email us at podcast@greenlight.guru.
Concept: The Quality Management System (QMS) Think of a QMS like a pilot’s pre-flight checklist. You don't just "wing it" when you get into a cockpit; you have a documented process to ensure the engine is working, the fuel is full, and the wings are clear. For a small plane (a low-risk Class I device), your checklist is shorter and simpler. For a commercial jumbo jet (a high-risk Class III device), the checklist is massive and detailed. However, the goal for both is identical: ensuring the passengers (the patients) arrive safely at their destination through a repeatable, controlled process.
"This is a starting point. This is not a stopping point... Use your own good judgment." — Mike Drues
"The goal is not really to build a museum of SOPs; the goal is a quality management system that teams will actually use." — Etienne Nichols
We want to hear from you! What are the biggest hurdles your team faces when scaling your quality system? Send your feedback, reviews, and topic suggestions to podcast@greenlight.guru. We read every email and pride ourselves on providing personalized responses to our listeners.
This episode is brought to you by Greenlight Guru. The subject of right-sizing your quality system is exactly why Greenlight Guru offers both QMS and EDC solutions. Their Ultralight eQMS is designed specifically for fast-moving, product-led teams who need a flexible, compliant system without the overhead of a "museum of SOPs." Whether you are in early-stage R&D or preparing for a global launch, Greenlight Guru provides the tools to keep your quality and clinical data connected and audit-ready.
Etienne Nichols: Hey everybody. Welcome back to the Global Medical Device Podcast. My name is Etienne Nichols. I'm the host for today's episode and today I want to talk about whether or not you really need a full quality management system or QMS.
What the FDA expects, when and why.
Most of you already know what a QMS is, why it matters, what the sections are. So today we're going to skip the basics. We're going to answer the questions that actually slow teams down.
What's truly required, what can we scale later and what the FDA will expect when they show up. And we'll try to keep it practical because the goal, it's not really to build a museum of SOPs, the goal is a quality management system that teams will actually use, one that keeps releases moving, keeps you audit ready.
That's the goal of Greenlight Guru, especially our ultralight eQMS, which we may allude to later on at the end, but it's a flexible compliant system that we want to build for fast moving product led teams.
And so, with us today to talk about this, what do you need for your QMS is Mike Drews. He's a familiar voice on the podcast. He is the president of Vascular Sciences, and he does quite a few webinars.
He's a well-known voice in the industry of MedTech. So, Mike, how are you doing today?
Mike Drues: I'm very well, thank you for asking, Etienne. And it's a pleasure to be with you again. It's been a little while since we did our last podcast, so looking forward to this discussion.
Etienne Nichols: Yeah, great to be with you as well. And the time that we're recording this, it's January 16th right now, not to give away our secrets necessarily, should be coming out in a few weeks.
I don't know whether it'll come out before or after the February 2 deadline for QMSR. So, I'm sure we'll keep it applicable to all the requirements before and after. But most people already know what a QMS is, whether we're talking about QSR or QMSR.
Why it's important, what the required sections include. So, if we dug a little bit deeper, maybe get into the more philosophical sides. Are all sections of the QMS listed in the QSR, are they all required for all devices?
Mike Drues: Yeah, great question, Etienne. And I know we want to go beyond sort of QMS101. And I'm happy to do that because I've put out several QMS resources through Greenlight and obviously Greenlight has a ton of QMS resources.
But just a quick review to recap what the major sections are. And this is right out of the QSR, the Quality System Regulation.
They include the preamble, or sometimes people refer to it as the quality manual, your complaint handling system, your CAPA system, your change management system, your risk system, your PMS or your post market surveillance system, your document management system, your training system, and finally your supplier quality management system.
So, I'm not going to take the time to talk about those individually. I've done those in other discussions. And as I said, Greenlight has lots of resources.
But my question to you, Etienne, and by the way, obviously Greenlight's products, they include all of those sections.
My question to you, Etienne, is, is that list that I just read off, is that from the QSR, is that a complete list?
In other words, are there other sections that might be applicable?
Etienne Nichols: Good question. So, I should have, it's easier for me if I have the actual list in front of me. I think I don't. Did you mention you mentioned Design controls?
Mike Drues: Design Controls is actually not specifically this list, but we can, it's, it's probably embedded, but, but that's a good one.
Yeah, I guess my, my, the gist of my questions and I apologize because maybe I inadvertently left off Design controls. That's obviously a very good one, a very important one. But the gist of my question is kind of like when a company is doing a 510(k) and they go to the product code description of the predicate.
And as you know, oftentimes in the product code description it will list the recognized consensus standards or what we sometimes call special controls.
And oftentimes companies will ask me, or they will assume that that is a complete and an exhaustive list.
And the short answer to that question is absolutely not, or at least not necessarily.
That's a generalized list that applies to all of the devices that are under that product code. It might very well be that because even though your device is substantially equivalent, it's not exactly the same.
Therefore, there might be some technological differences that would require a different standard or special control that's not on that.
Similarly, companies ask me must I follow or meet all of those controls or all of those standards? Once again, the answer is no, not necessarily. Because even though it's in the product code description, they might not be applicable to Your device.
So, the same regulatory, or maybe in this case, the same quality logic applies here.
This is a starting point.
This is not a stopping point.
Depending on your device, your technology, your manufacturing methods, even your business goals and so on, there may be some additional sections that you should put into your quality management system that are not specifically specified by the QSR. Or alternatively, there might be some of these sections that are specified by the QSR but might not be applicable to you.
And by the way, one last thing, Etienne, if there's a section that I just read off from the QSR, a quote unquote required section that for whatever reasons you feel is not applicable to you, don't just leave it blank. Or worse, don't just leave it off.
Because if I am, in this case, an FDA reviewer or inspector and I come in and I see something is missing or blank, I don't know why it's missing.
Is it missing because you know about it, but you just determined that it's not applicable? Or is it missing because you just didn't know about it, that you forgot about it?
Or in my case, you know, I forgot design control.
Etienne Nichols: Well, design control is one that. Yeah, yeah. For example, if you're a Class I and you know one of the Class I’s that it doesn't apply to, then maybe it makes sense.
But certainly, a justification would make sense as well.
Mike Drues: Correct?
Correct. So bottom line, this is a starting point, this is not a stopping point. And at the end of the day, you have to use your own good judgment. And by the way, this is what FDA specifically says.
They expect manufacturers to use their good judgment, their professional judgment, to take this whole quality system, regulation philosophy, if you will, and customize it.
Make it specific for your device, your technology, your goals, and so on and so on.
Etienne Nichols: Yeah.
One of the examples or one of the illustrations I've used in the past with companies is in my past when I would ride motorcycles in the industry, I had a motorcycle license as well as a Class A CDL license.
And when I would go around a curve and see a 25 mile per hour suggested speed limit on a motorcycle, I knew I could double it. Whether I should or shouldn't is a different question.
But I knew I could. If I was driving a semi, I might want to cut that in half. So, I look at that like Instead of the FDA putting up a 25 mile per hour speed limit, they say, this is the gradient, this is the coefficient of friction, this is the angle. This is where the wind comes out. You got to figure out what you're driving and make sure it can make it around the curve.
That's kind of how I look at that.
Mike Drues: That's the engineer coming out in you, Etienne, and I love it. And just two things I would say. First of all, be careful what you say here, because we are doing a public recorded podcast, number one.
Number two, more importantly, FDA often says, we suggest that or reconsider that. You.
Blah, blah, blah. That's a very sanitized. That's a very politically correct way of FDA saying, we expect that you're going to do this unless and until you come back and convince us otherwise. Right. So, FDA will rarely ever come out and say, you must do this.
They'll say, we suggest, blah, blah, blah. And by the way, one of the things that I often fire back when they do that is they say, well, I'm happy to discuss whatever it is that you're suggesting.
And notice that I'm parsing my words very carefully. I'm not saying I'll do it, I'm saying I'll talk to you about doing it. But before I do, tell me why you're suggesting that. Yeah, yeah, I think that's a reasonable ask from the. Yeah, that, that, that's exactly right. That's a reasonable ask from the manufacturer. And you should not let FDA get away. And I've seen this happen before, saying something to the effect of, well, we're the FDA. We can ask you to do anything that we want.
Quite frankly, that does not cut it with me.
Right. So, they should be able to justify whatever it is that they're asking, and hopefully they'll be able to provide a better justification than, well, in CFR, blah, blah, it's a such and such. Because that to me is not necessarily a good justification for doing anything.
Etienne Nichols: Yeah, I totally agree. And we're looking at this through the lens of the FDA primarily for medical device companies. And when I talk to companies, there's three legs to every medical device, stool, if you will.
And that's obviously the legal or regulatory. I look at that as kind of legal and regulatory category. But there's another which is ethical. And we like to think that they're the same and there's a lot of overlap, but it's not always you can, you can be legal without being ethical.
It's possible.
And then there's possible.
Mike Drues: And I see that from my, from my product liability experience, it is definitely possible.
Etienne Nichols: Right, right. And then, and then the economical. Obviously, money is the air companies breathe, so they have to be economic. So, I mean, if you think about those three. We're primarily looking at it through a regulatory FDA lens.
But yeah, there's, there may be things on that list that are left off that don't meet one of those three. So that's, that's kind of my. I guess as I mull it over my mind, that would be my answer question.
Then next, if we were to move on a little bit further, do I need a full quality management system in place if I were to, if I'm attempting to get FDA clearance or approval of my device? Maybe that's two different questions, two different scenarios.
But how would you answer that?
Mike Drues: Well, I'll parse it out in a few different ways. The short answer to every question in regulatory, as you know, Etienne, is it depends.
So, in this case, what does it depend on?
It depends largely on your pathway to market.
So, for example, if you're doing a 510(k), and as we all know, the vast majority of devices in the United States are brought to the market under the 510(k), if you're doing a 510(k), a 510(k) has absolutely no manufacturing requirements in it whatsoever.
In other words, you can easily get a 510(k) without saying anything about how you manufacture the device or anything like that. I'm not suggesting that you should, but it's not a requirement. Okay, so you do not have to have a quality management system to get a 510(k).
When it comes to the De Novo, it's a little grayer.
In most cases, you do not need a quality management system either.
However, just a couple of years ago, FDA updated the De Novo a little bit and now they do have the.
Their authority, they call it, what is it called?
Etienne Nichols: Discretionary enforcement discussion.
Mike Drues: Enforcement discussion. Thank you.
That in some cases, some De Novo cases, they will ask for a manufacturing information, which usually includes your QMS rather. And then finally, when we get to the Class 3PMA universe, then you know, manufacturing requirements are part of your PMA submission.
In other words, as a general rule, you cannot get a PMA approved without including some level of manufacturing detail in there. How much detail? That's open to interpretation, but some level of detail. And because I think it's so important for people to understand not just the what is required, but the why it's required.
The reason why manufacturing information is required in a PMS, sorry, in a PMA, but not in a 510(k), is because as a general rule, PMA devices are more risky, they're more complex pathophysiology’s. Maybe the patient has comorbidities, maybe the manufacturing methods are more complicated than for a 510(k). Again, I'm generalizing here, but as a general rule, I think that's the case. So, it makes sense for FDA to want to know for a PMA, how you're going to make this device, whereas for a 510(k) maybe it's not necessary.
Etienne Nichols: Yeah, that makes sense. And I guess with the FDA or the 510(k) or Class II pathway, you may not need a preapproval inspection, or the inspection may not happen for some time, you know, at any point. But I think you do need to prepare, be prepared at any time.
Would you agree?
Mike Drues: Yes.
Etienne Nichols: Yeah.
Mike Drues: Well, let me put a small caveat on this because this gets into FDA registration.
So, one of the first questions, or. Sorry, one of the many questions that companies ask me pre-market, because later on, we'll talk a little bit about post market.
One of the questions they asked me about pre-market is when do we have to start the FDA registration process?
So, as a quick reminder, the registration is on the company, the 510(k) or the De Novo or the PMA is on the device.
The registration is on the company, the 510(k) or the PMA is on the device.
According to FDA's website, they say allow 30 days for the registration process. I think that's a little ambitious. What I usually say to my customers is allow 60 to 90 days for the registration process.
So, to make this simple, figure out when you plan to launch your product, to make your product commercially available here in the United States, and then subtract two or three months, and that's when you begin the registration process.
You can do it earlier than that if you want to, but what the heck is the point of paying the registration fee if you're a startup and you don't even have a product on the market yet?
So that can be weighted, but it's not until you get FDA registered that you then go on FDA's radar, as I like to call it. And then sooner or later, whether it's in a week or a month or a year or five years, sooner or later FDA will come knocking on your door and say, hey, we want to see your QMS.
So, there is no, like, definitive point in time, but that's sort of the logic that I explained to my customers. Does that make sense?
Etienne Nichols: Yeah, that does make sense. And I'll just go one step further to mention that if you're a small business, which most medical device companies starting out are, there's ways to get that annual Establishment, establishment registration waived. Which is not much like, well, 115 or something. 11k. But just throwing that out there.
Mike Drues: Yeah, and I thank you for adding that. And I would just also add to that that this year 2026 was the or is the first year that FDA is allowing or at least creating the ability for small companies to get out that registration up through 2020-5.
I mean, for decades there was no exception, no small company discount, if you will, for FDA registration. There were small company’s discounts for, for 510(k)s and PMAs and everything else, but not for the registration.
But now there is.
Etienne Nichols: Yeah, yeah. So definitely look into that. And maybe I should have asked this previously, but to. To riff on George Orwell's book Animal Farm, all animals are equal, but some are more equal than others.
Question for you. Are all sections of my QMS equally important in your mind, or are some sections going to be more important than others? I have my opinions and thoughts on this.
I'm curious what yours are.
Mike Drues: Well, do you want to start with sharing your opinions or do you want mine first?
Etienne Nichols: Well, I always think it's interesting to ask what you think the most important part of a QMS is.
Mike Drues: Okay, so here's my response and then I would love to hear your similar or drastically different opinion.
That's perfectly okay with me.
So, your QMS is important.
All of the sections that are in your QMS are important. I mean, after all, if there was one section in your QMS that is not important, then why the hell is it in there?
Right? So, everything in there is important.
However, not all sections are important at the same time.
And this is when we get to pre-market versus post-market. If you have, let's say, hypothetically speaking, a small medical device company, and remember, here's a statistic for you and our audience, Etienne, and 80% of medical device companies here in the United States, 80% have 50 or fewer employees.
80% have 50 or fewer employees. So, with all due respect to my many friends at Boston Scientific and Medtronic and the other big guys out there, that does not represent the typical medical device company.
So, if you're a small or startup company, and let's say you don't have any products on the market yet and your first device is under development, then there are certain sections of your QMS that you should definitely be thinking about and working on right now, such as design controls, such as risk management, and so on and so on. Those things should be working on from the very beginning.
However, let's be honest, Etienne if you don't have a product on the market yet, then what the heck is the point of spending a lot of time and money putting together a very robust complaint handling system, a very robust training system, or maybe even a CAPA system?
So, I'm not suggesting that those parts are not important. Of course they are very important.
What I am suggesting is if you're working in a small organization with limited time and economic resources, focus on the ones that matter the most first and the others you can get to a little bit further down the road.
Yeah, that's my sort of response to that question, Etienne. And by the way, just to highlight what you mentioned about Greenlight a moment ago with the ultralight eQMs, I don't want to take complete credit here, but this was an idea that I suggested to John Spierer and a number of my friends at Greenlight many years ago.
For companies that don't need the entire QMS, why did they need to buy the entire Greenlight system instead? Why not offer it sort of a la carte where you can buy access to individual components and then add the other ones on later on?
So, I'm very, very happy. I don't know, I think you've had this now for a few years, but I'm very, very happy that Greenlight now offers that as an option to especially smaller companies.
So again, I'm not saying that any sections are not important. What I am saying it's a matter of triage.
Some you, some you should be thinking about right away and others you can put off until later.
Etienne Nichols: Yeah, and I'll just kind of piggyback off that just a little bit. With Ultralight, it's a…
I think historically Greenlight Guru's goal was to provide something that would really give you everything you needed for, from a quality standpoint.
And with Ultralight, the goal is to really be much more agile, much more ultralight, really just like it sounds, you know, give you exactly what you need when you need it and then build up from there.
But to answer your question, because you turn, you asked me first, you know, what I consider the most important part.
Like I said with.
Well, if I were to just talk about Ultralight with document control, building those SOP’s so that you actually have processes that are documented, that's all so important. But when I look at Quality System Regulation, what's the most important thing in my mind?
I think it's management responsibility. That's kind of unexpected. I think most of the people I talk to, that's not their answer. But if management is not on board with equality mindset, I don't think any of it matters.
Mike Drues: I would agree with you, but I would also add, Etienne, that those words are easy to say or they're easy to put in a PowerPoint slide, but, you know, the devil is in the details, so to speak.
But one other quick example I would offer.
Coincidentally, I have a customer I'm working with right now. They've been a customer of mine for a few years already.
They're working on a.
A Class 3PMA device. It's sort of a. It's a device that will be used in cardiology.
This device will not be on the market in less than six years, probably longer than that. And I know from the 510(k) folks in our audience, and especially the software folks in their audience, they probably couldn't imagine having a device under development for six years or more.
But that does happen in the Class III universe. Well, in that kind of a scenario, Ed Ian, do you think that company should be investing the time and the money putting together a complaint handling system, for example?
Etienne Nichols: No, that's. That wouldn't be my focus.
Mike Drues: That wouldn't be mine either. Right. Because it's going to be, you know, many years before they even get a complaint. Hopefully they won't, but. So anyway.
Etienne Nichols: But design controls and risk management, that is absolutely important.
Mike Drues: Yes. Those are even for a very long PMA kind of devices I just described. You're exactly correct. You're preaching to the choir on that, that one. Design, controls and risk management. This is another interesting pre versus post market difference because I see a lot of companies, especially smaller startup companies, and especially in the software space where people are coming from, you know, consumer software and stuff, they're not really used to the, you know, the medical device development process.
A lot of these documents, just like your design control and your risk documents, a lot of them are created retrospectively or after the fact.
I'm not going to go so far as to say that that's wrong or that that's bad, but clearly that defeats the whole purpose, the whole philosophy of doing this. Ideally, you should be doing it in parallel to your development, not afterwards. In other words, you shouldn't get to design freeze. And then at that point say, well, gee, maybe we should figure out what our user needs are and our design inputs and maybe we should put together a risk management plan.
I think that that's kind of like trying to get the horse back in the barn once it's, once it's already gotten out.
Etienne Nichols: Yeah, well, okay, so let me just kind of give my, my thought on that because from the consumer world that may be what a lot of people do, but it's not best practice even in the consumer world from what I've seen.
Yeah, so my background was I had my project management professional PMP through PMI and manage different projects from that standpoint but also got into software a little bit towards the end, project management, I guess, experience. And I got the certified Scrum master and got to experience some of that from Scrum Alliance. And the best, the best-in-class companies go through that epic. They do their epics; they do their user stories before they actually have individual lines of code. That's the best. And so, I look at its kind of like when you look at the standards, whether it's ISO 1345 or you look at the requirement of Part 820, Part 820.30 specifically with design controls going through that user needs, design inputs, design outputs, that's.
It's not just a requirement. What they're reflecting is what the best in class or what should be the standard across industries.
Mike Drues: I understand and thank you for adding that.
To be honest with you, in my little over 30 years, I've only worked in the medical device and the medical technology space. So, I've never worked with consumer products or automotive or aerospace or whatever.
And I'm glad to hear that those are also best practices and those areas. I mean to me that's just engineering common sense.
Etienne Nichols: Right?
Mike Drues: All I can say is, at least in my experience in dealing with some people coming from those industries, they're not used to this kind of thinking in those longer development cycles. But I'm sure there are exceptions.
Etienne Nichols: And I don't know what I love about that is, even if so sometimes they don't seem exactly apples to apples. The medical device industry could learn a lot from what they bring in. And it seems that we are evolving to a certain degree to meet some of those requirements.
And that's great, you know, so.
Mike Drues: Yeah, absolutely. Question is, I have a friend at Cornell who teaches a product development course in the biomedical engineering department. And he uses, remember the challenger disaster with the.
He uses that as a case study for medical device companies, you know, in terms of what they can learn. So, I agree with you 100%.
Aerospace, automotive. I had somebody tell me once, I've never worked in automotive.
He told me that the regulatory requirements in the automotive industry are in many ways even more rigorous than they are in the medical device industry.
I find that a little bit hard to Believe, but he's the one that worked in those, both those industries. So, I'll take and work for it.
Etienne Nichols: Yeah, I mean, I mean those are, those are all I just remember from engineering school, there's lots of good examples of failure and we could learn so much from failure. Like I think it was the Tacoma Bridge and the resonance frequencies or the.
Mike Drues: I remember that one as well. Although as somebody who still teaches on a part time basis, I sometimes question, you know, if the engineering that we're teaching today is the same as the engineering that you and I learned, you know, back some years ago. I don't know, but we'll leave that in the.
Etienne Nichols: Yeah. Well, okay, so if we get back to the QMS and what you need, when you need it. That's the second question because that's a question I get all the time. Well, when do we really need to start these things we, we mentioned design controls, risk management. If I were to say the four immediate musts, it's, it's from, in my mind it's document control, design controls, risk management, and likely supplier quality management.
Unless everything's done in house, but that's unlikely. Those are the four in my mind. But, but when does, and if you differ, that I'd love to hear that as well.
But, but when is this required?
Mike Drues: Yeah, great question. And I'm going to give you two answers, first from a regulatory perspective and then from a practical perspective.
So, the regulatory perspective and quoting from the QSR here, it says the QSR applies to finished device manufacturers who intend to commercially distribute medical devices.
So, if you are a finished device manufacturer who intends to commercially distribute a medical device here in the United States, then that is who the QSR applies to. But notice it doesn't say the when.
And you mentioned, you know, design controls earlier.
The one of the many interesting things about the design controls, and I'm specifically referring to the design control guidance that came out back in, when was it? 1996. 96, I think.
Yeah. And some people have said we should update it and I say absolutely not.
Even though it's a few decades old, that is still a good guidance. You know, we shouldn't, if it ain't broke, don't fix it. But nowhere in that guidance does it say when the design control should begin.
So at least from a regulatory perspective.
So, my advice to companies from a practical perspective is like we talked about before, triage the sections of your QMS.
Start with those sections that are most important right away, even in product development, as you mentioned, design controls, risk management, maybe DOC controls, if you want to put that in there, and so on and so on, and then the others you can defer to later on.
There was something else I was going to say now and I.
Etienne Nichols: And well, I'll buy you a little bit of time because I just looked up, I just, I was thinking you were talking about the design controls in 1996.
The guidance is what you were mentioning that came out the following year, 1997. I know we have a nitpicky audience. I'll throw that out there just in case.
Mike Drues: Thank you for fact checking. You know, that's.
Yeah, that's very important.
No, thank you for doing that.
Anyway, so.
And again, in FDA, one of my favorite sections of FDA's website, especially on the quality side, is when they describe their philosophy, if you will, of the Quality System Regulation. It's what I call the preamble, because FDA doesn't. And we can put a link to it from the podcast if you.
If you want. But FDA doesn't describe what the requirements are in this preamble. Rather, they described why they are important.
Why should anybody care? And FDA is quite clear, and I'll read just one sentence from it.
Manufacturers should use good judgment, and that is exactly the phrase that FDA is using good judgment when developing their quality system and apply those sections of the Quality System Regulation that are applicable to their specific products and operations.
In other words, FDA is saying, hey, this is not our responsibility to tell you what to do. This is your responsibility to figure out what to do, take all of the requirements, including the Quality System Regulation, use that as a starting point and then personalize it or tailor it or make it specific to your particular situation. One of the big frustrations that I have, and we can talk about this more a little bit later if you want, Etienne, is how many quality management systems are literally copy and paste or carbon copies or substantially equivalent, pun intended, to some other medical device company. And that drives me absolutely nuts.
If I hear a little test. If you read your QMS or a portion of your QMS and it could be applied to some other company, in my opinion, it's not a good QMS.
It needs to be specific for you. You could start out by looking at what the requirements are or what other people do. And of course you should.
But that's not the end, that's the start. I've seen here. Here's one example, Etienne, and I'm sure in the greenlight world you probably have seen many more.
I spent some of my time evaluating companies, quality management systems. I don't market myself as a, as an auditor, but I spent some of my time doing that large, not out of my regulatory experience, but because of my product liability experience.
Most of my suggestions to companies, especially for their QMS, doesn't come from my FDA experience. It comes from my product liability experience.
So, I was reading a company's QMS and they had examples of a device in their own QMS that I was not aware that they even made.
And so, I asked the company, hey, do you make this device? And they say, no, Mike, we don't make that device. Why do you ask?
Well, why the hell is it right in your own quality management system?
So, if that's not an example of copy and paste, it's also an example of they're not even reading what they're copying and pasting. I wish I could tell you that I'm making that up, Etienne, but I'm not.
That is a hundred percent true.
Etienne Nichols: Well, this is going to be a crazy example and you're going to have to forgive my lateral thinking here, but when I was a younger man living in Oklahoma, I was in rodeo and I.
You would ride bulls. That was just what you did when you were in Oklahoma. And you got a total of 100 points possible.
So, I could get 50, the bull could get 50, and you had to have a good bull. So, when I look at this, I look at it like, okay, the caveat, I would say is the similarity between quality management systems is they all have to meet the same regulatory agency requirements if it's the FDA, if it's EU, health, Canada, whatever.
So that's the 50, you know, quote unquote, 50% there. But then your device has to go on top of that. So, there's going to be some similarity.
But that device should never be the same calling out someone else's devices. And I only say that because. So, Greenlight Guru, we offer quality management system standard operating procedures, SOPs as a template package.
But they.
I hope no one ever thinks you can just buy that and put it in your EQMs and be done with it.
That should never happen. It's kind of.
Mike Drues: Some people do.
You can buy, as you probably know, you can buy these forms on the Internet and just print them off. And here's my Quality Management System. But again, in my opinion, that defeats the whole purpose of having a QMS.
You know, and as I've also said many times, Etienne, and you know, regulation is about two things. It's, you know, your ability to understand the words.
But then the second part, it's your ability to defend your interpretation because regulation can be interpreted many different ways. So, I love the metaphor that you just use, Etienne. And let me use sort of an.
An equally simple metaphor. Let's say you live in a. In a homeowner's association where there's a requirement, your house must be painted blue.
So, the question is, what does that mean?
What shade of blue does that mean that the entire house has to be blue? Maybe you paint your house blue, but your garage door is going to be red or something like that.
What about the trim? And so on and so on. So even using that simple example of you must live in a blue house, that can be interpreted, some people might even say manipulated in many different ways. Right?
Etienne Nichols: Yeah.
And I'll say one other thing about the good judgment that you mentioned, because I worked at one company once where there was a big argument as to whether or not engineering judgment could even be a thing, justifiably, which is a struggle in some cases.
Obviously, you need evidence in everything you do, but engineering judgment should have some leg to stand on.
Mike Drues: But I'm curious, who is questioning the validity of the engineering judgment? Was it an engineer or was it somebody else?
Etienne Nichols: It was quality.
It was the quality department.
And, you know, their, their goal was to cover their, you know, just not, you know, have absolutely ironclad defenses. And that makes sense to a certain degree. So. But if you have, going back to that question, when to start, I'm gonna, I'm just gonna try to get real hyper focused on that, particularly design controls.
In my mind, and I want to bounce this off you, in my mind is you. If you have a prototype that you plan to pursue, maybe it's a, you know, there's a lot of engineering that goes between.
We talk about design controls, user needs, design inputs, design outputs, design inputs, and design outputs. In between those two is a whole lot of engineering iteration that we barely talk about.
Mike Drues: Right.
Etienne Nichols: But if you have that working prototype, there's a lot more work to be done. But if you have that you have some user needs in your mind that you're pursuing, it's time to start writing them down or you will start forgetting them.
That's my.
Mike Drues: I agree 100%.
And this is one of the reasons why the design controls and equally important, the risk management, you should be working on that long before you get the design freeze and certainly long before you get FDA registration.
But I would actually take that, Etienne, in a step further.
All of these parts of your Quality Management Systems, they are never finished, they are never complete. They are all works in progress.
So, I mentioned earlier, for example, that a CAPA could probably be deferred until your device gets onto the market or close to the market. But in some cases, maybe not. And here's why.
If you do your preliminary risk analysis, for example, and you're still in development, you're still maybe working on a 510(k), but you for whatever reason at some point realize that you missed a risk, especially if it's an important risk.
Why not institute a CAPA at that point to ask the question, why did we miss this risk and what can we do next time to mitigate or ideally prevent that from happening?
As I talked about before, Etienne, and this is a topic of a different discussion, I think the whole approach to CAPA is 100% back *** word, 100% back *** words. Because it's corrective action, preventative action. Why is the emphasis on waiting for a problem to occur and then fixing it? I think instead we should have a paca, a preventive action, corrective action. The emphasis should be on prevention. You know, what is it?
An ounce of prevention is worth a pound of cure. I mean, whatever cliche you want to use, they all have a lot of truth.
Etienne Nichols: Well, I, I can kind of get where you're coming from, but at the same time, I struggle with that myself because, well, two things. One, risk management should cover a lot. I mean, that is your preventive action is, is risk management, good risk management, and the fact that you should be taking a risk-based approach to all processes, there should be, you know, that is your preventive action. If you're, if you're not doing that, then your cap is not going to work anyway.
Mike Drues: That, yeah, yeah, I would agree, but I would put a, and maybe I didn't explain exactly what I meant as well as I should have.
First of all, what I'm talking about is in the regulatory world, what we call an unanticipated risk.
An unanticipated risk. So clearly the risks that you identify, you can mitigate them as much as practical. And by the way, I hate it when people say we're going to mitigate these risks as much as possible, because that is never the case.
We mitigate the risk as much as practical. In other words, words, we want to do what we can to minimize what we call residual risk.
But you can never anticipate all risks.
You could try, but I guarantee that you can never anticipate all of them.
And as a subject matter expert in Risk for the FDA. I see this happen a lot. But anyway, that's a.
Etienne Nichols: Well, with all due respect, if you can't mitigate it through risk management or you can't anticipate it through risk management, how do you anticipate it through preventive action?
I mean, neither one if, if they're unanticipated. I, I, that's just my thought.
Mike Drues: Well, okay, so. Fair question. And again, this is probably, you know, we're getting into a little.
Etienne Nichols: Yeah, no, it's just, it's a difference of view, I think.
Mike Drues: But, yeah, no, no, I think you and I are singing the same song, but just in a slightly different key.
So, here's my response.
My question is not what could you do to mitigate the unanticipated risk?
My question is, why was that an unanticipated risk? Why did you miss it? For example, were there certain tests, maybe benchtop tests or even animal tests that you could have done, but for whatever reason that you didn't do to possibly identify that risk, or even a less excusable.
Let's say that you're working on a 510(k) device where 510(k) is just a fancy way of saying, this is me too. This is basically the same as somebody else. If you don't go out and look at the risks and potential harms that resulted from that device.
And this is one of the recommendations that FDA put in one of the new 510(k) guidances that came out like a year or two ago.
Look at the risks of a device that's similar to yours, that's already on the market, and ask yourself the question, is this a risk to, that could happen to your device if you don't do that or if you miss that, that, in my opinion, is professional negligence, flat out 100% negligence. And I can tell you, when I work as an expert witness, I love cases where I can point out that the company didn't anticipate this risk. However, it was reported in the publicly available literature that other similar devices had this risk.
You know, I hope, Etienne. And it doesn't take a JD after your name from Harvard or Hopkins or Stanford to hear ka ching, ka ching, ka ching.
So, I don't know if that clarifies, you know, the discrepancy, but like I said, I think we're saying the same thing, but in slightly different ways.
Etienne Nichols: Yeah. And it's just a matter of when and how you do something, I think. Yeah. The goal is to make safe and effective devices. And I guess CAPA in my mind is more for the systemic issues of the company itself could be product related as, as well.
Mike Drues: Well, but my, and by the way, we do not have to agree on everything. I love to disagree.
Etienne Nichols: So, you mentioned something that you, when you were quoting the FDA about for manufacturers who intend to market or manufacture a device.
What if I never intend to market my device?
Mike Drues: Yeah, excellent question, Etienne. And let me spin it around before I answer it. Can you think of any examples of any situations were, for example, a company would want to get a 510(k) from the FDA and but never intends to market that device here in the US?
Etienne Nichols: Oh man. Yeah, I talk to CEOs all the time whose goal is to be acquired.
That's, that's most of their goal, you know, impractical. I'm afraid that bubbles usually burst before it's all over. But.
Mike Drues: Yeah, that's certainly the most common scenario. They want to, you know, license or to sell the technology to somebody else and then let you know the big guy.
But there are a couple of other possible scenarios that I've run into over the years and that is that they, that the small company wants to simply demonstrate competence to investors or potential investors that they can do it.
In other words, we've already demonstrated that we can get a 510(k), give us a boatload more money and we'll get another one with, you know, more bells and whistles. And a third scenario that I've run into is where a company wants to create a device either via De Novo or 510(k) that they then want to use as a predicate for their next generation device.
So those are a couple of other scenarios. The reason why this is important, Etienne, is because there has been some discussion over the years of making FDA registration and making, you know, a quality management system a prerequisite to a 510(k) or De Novo.
And I'm adamantly against it because once again, if I'm developing a device but I have no intentions to market or sell it, then why should I spend a ton of time and money talking about all of these complaint handling and manufacturing methods and all this kind of sense?
So this is again example of what FDA calls using our good judgment, our professional judgment, if we're going to call ourselves medical device professionals, and I do not use that word professional loosely, along with it is the responsibility comes the responsibility of, quite frankly, knowing what the heck you're doing and not relying on FDA or somebody else to tell you what to do.
Etienne Nichols: Yeah, yeah, that makes sense. Okay, question. I know we're getting Close on time. Are you good?
Mike Drues: Yeah, sure. A few more. A couple more minutes.
Etienne Nichols: Yeah. So, a couple of questions, I guess in my mind. I'd like to know if there's what, what you think about the differences between pre-market, post market.
Obviously, they may not have to, in different cases, have to have a QMS if they're not commercializing, but if they do, does that look different? I mean, we already talked a little bit about the differences, but pre-market and then once you're commercialized.
Mike Drues: Yeah, great question. We've already talked about one of the, one of the big ones and that is, you know, triaging your QMS and starting out with your design controls and risk management and, and so on and so on.
I suppose the biggest difference is again, I'm talking the scenario where you have a small company or a startup without any devices on the market yet, and you probably have not even gotten to FDA registration, or maybe you have gotten FDA registration, but you're still not on the market yet. One of the big differences is you don't have to worry about somebody coming knocking on your door and start looking for all of this stuff.
But as I said before, once you get FDA registered, you are now on FDA's radar and sooner or later that knock will come.
The other thing that I would say is kind of like, you know, the theme of post-market surveillance.
Post market surveillance, in my mind is not something that is limited to just looking at, you know, what is happening to patients as they're, as you're using your device on that.
Post market surveillance, to me is a philosophical construct which should also apply to all of your systems, all of your components within your quality management system, like, for example, complaint handling and stuff like that, to make sure that those things are working, in other words.
Well, we can talk about that in a, in a minute.
Etienne Nichols: Well, I mean, maybe we just pull that thread. How do you know if your quality management system is working? Especially, you know, it's, it's words on a page to a lot of people, I think.
Mike Drues: Yeah, great question. And once again, let me, let me spin it around to you just initially first, Gideon, and as always, I really appreciate you, your ability to, you know, play a little bit guinea pig here.
So, if your quality management system is compliant, that is, if it's ticking all of the regulatory boxes, can you assume that it's worth working?
Etienne Nichols: Personally? No, I, you know, I. An ISO 1345 lead auditor, I can tell you that that's not the case.
Mike Drues: Well, I happen to agree with you 110%, Etienne. But I can also say that in my experience, anyway, and again, I'm stereotyping. I'm generalizing. There are exceptions, but most people don't think that way.
Most people make the automatic, automatic assumptions that if my QMS is compliant, that is, it ticks all the boxes, then it must be worth working. I find it interesting, fascinating actually, that for medical devices, we're required to show, among other things, the efficacy of our device, but we are not required to show the efficacy of our systems, like, for example, the quality management system.
So, for example, one of the practical ways that I suggest to companies to test these, the efficacy of your QMS is purposely inject a problem into the system somewhere. Now, telling anybody or many people purposely inject a problem and then watch what happens and see ultimately, if your system is capable of detecting the problem.
If your system detects the problem, then terrific. You've now validated your quality management system, or at least one portion of it. However, if you're. Your system doesn't identify the problem, now maybe you got to go back and say why? And maybe a CAPA. Why did not my. Why did my system not identify this problem? You know, I've made this suggestion to many companies over the years, Etienne, and some companies are receptive to trying that.
Others are not.
For those that are not, why do you think they don't want to do that? Why do you think they don't not want to purposely inject a problem into the community?
Etienne Nichols: Oh, man. I think it's the same as when I'm on a panel and I ask them people, I'm like, what's your favorite failure? And a lot of people say, I'll pass.
Okay, I have a few of mine. But if you don't want to talk about it, it's interesting that you say that because a friend of mine who is an internal auditor for, you know, external.
He goes to companies and does this for pay.
Before he goes and does his internal audit, he actually sends in a complaint anonymously. And then he finds out, where did it land.
Mike Drues: You know, I love that. That's excellent. I love that.
But this is, you know, one of my many favorite adages is there's no better way to avoid finding a problem than not to look for one.
If you have what you consider and even what FDA considers a compliant quality management system, and you test it by interjecting a problem, or in your example, submitting a complaint, and your system, for whatever reason, doesn't detect it or it misses it. Now, what have you done?
Etienne Nichols: Done?
Mike Drues: You have totally Invalidated your quality management system?
Etienne Nichols: Absolutely.
Mike Drues: And since your system you deem to be compliant anyway, now you've gone to look for a problem and oh, by the way, who asked you to look for this problem?
Nobody.
So, do you think this is going to make you the regulatory as a quality person, the most popular person in your billboard?
Probably not, right? This is why one of my very good friends who's a senior VP of regulatory and quality at a Fortune 50 medical device company, I won't mention which one, but he and I were very good friends in graduate school.
He said if you're working in regulatory or quality and people like you, you're not doing your job.
But anyway, test your systems, including your QMS, because to me that's just as important as testing your device.
Absolutely.
Etienne Nichols: So, what did we miss? I know we're basically at time here. Anything else that you consider to be important?
Mike Drues: Just real quick, two things. First of all, this is something that I mentioned coincidentally in my webinar that I did yesterday for greenlight on medical device software.
And that is don't be afraid to create your own definitions for things like you mentioned complaints.
You shouldn't take one of the canned definition of complaints and just paste it into your QMS in the complaint handling section.
This is why so many people, so many companies have a hard time or even getting in trouble with mis-categorizing complaints as either reportable or non-reportable because they're using a generic definition.
If you read your definition of complaint, and again, that's just one of many examples, and it can apply to, you know your company as well as you know the medical device company down the road, it's not specific enough.
That's one suggestion. But the most important, I would say in this particular case, Etienne, when it comes to quality management system or Quality System Regulation or even regulation in general, the FDA makes it very, very clear, crystal clear on the website that I referred to earlier to use your good judgment to take these general principles of Quality System Regulation that are applicable to medical devices all across the board.
Whether you're working on a band aid or a totally implantable artificial heart, it doesn't make any difference. Take these general purposes and personalize them, tailor them to your particular needs, to your particular devices and technology, to your particular business goals, and so on and so on.
Please don't, you know, just simply, you know, copy and paste or worse, you know, buy some, you know, pre-printed set of forms and you print it off and you put a, put it in a three-ring binder.
And on your shelf, or I guess I'm dating myself, you put it in your document control system and you say, here's our quality management system. And if I go through your company and I, you know, pass somebody in the hallway and I ask them, what do you think is the most important or what do you think is the most challenging part of your quality management system?
And if your employee looks at me like a deer in the headlights, like they don't know what the hell I'm talking about, this is all a colossal waste of time and money.
So this is not just simply, or it shouldn't just simply be a matter of ticking boxes of dotting I's and crossing T's, in my opinion, and I'm going to be brutally honest here, and some people might not like this, but people that practice that way, quite frankly, they should not be in this business, pure and simple. I don't know if we're allowed to say that anymore. You know, everybody's equal, everybody shows up, gets a trophy, fee. But if we're going to call ourselves medical device professionals, that should mean something.
Etienne Nichols: Well, that last point is actually why I consider management responsibility one of the most important parts. Because we talk about whether the employees understand the quality manual or the quality policy and so on at different points.
What do they actually care about? They care about what's being measured and what's being emphasized from upper management. If you're up, you mentioned something about it being words on a PowerPoint.
There’re more ways than that than to. To actually tell whether that's true. If at every all hands, they talk about the sales goals and go on about our economical and fiscal future, but never mention anything about quality, that's telling. If they do and are willing to show the sacrifices they'll make for quality.
Mike Drues: That’s another story and one very last thing. And then we can wrap this up at the end of it. Not to put my head further into the lion's mouth, but you mentioned the responsibility of senior management, which again, I am 100% in agreement with. But let me ask you this question, and it can be a rhetorical one.
How many senior management people have read their quality management system?
Yeah, I'll leave that as a rhetorical. It's kind of like in politics, you know, how many Congress people have read the complete bills, the Omnibus 20, 24.
Etienne Nichols: Yeah. Oh, man.
It's actually a pretty good read.
I'll say one other thing. I know we gotta go, but you mentioned the complaints and how generic or specific they are at Greenlight Guru, we call it customer feedback. And I, I like that because I never really thought about that until coming to Greenlight Guru.
What we actually say, is it positive feedback and if so, how positive is it negative? How so? You can different levels of escalation.
Mike Drues: And so yeah, actually I, I, I teach a three-day course for industry on post market surveillance and complaint handling. And one of the things I talk about is why do we call it a complaint?
Because as you just alluded to, that sort of has a negative connotation.
Some complaints in fact could be negative, obviously.
But what if a company, I'm sorry, what if a customer has a positive suggestion on how you can change the design of your device to make it more effective or how you can maybe use this device for a different indication or so on and so on.
So, kind of like I said, CAPA is asked backwards. Why do we call it a complaint that has an automatically a negative connotation?
Etienne Nichols: Yeah.
And so QMSR is coming up. It may be passed by the time you're listening to this, but if you're not ready for that then, and if you, these are things that are resonating customer feedback as well as other things.
I definitely recommend you check out Ultralight and get a hold of Mike and see what he can do to help you with your, with your systems as well. So really appreciate everybody listening.
Mike, this has been a good conversation. I feel like we don't agree on everything, but I think we do philosophically agree and it's always a fun conversation. I agree.
Mike Drues: And to be honest, if we agreed on everything, it would be boring.
Etienne Nichols: That's right.
All right, we'll let you all get back, get back to the rest of your day. Thank you so much and we'll see you next time. Take care.
Mike Drues: Bye bye
Etienne Nichols: Thanks for tuning in to the Global Medical Device Podcast. If you found value in today's conversation, please take a moment to rate, review and subscribe on your favorite podcast platform. If you've got thoughts or questions, we'd love to hear from you.
Email us at podcast@greenlight.guru.
Stay connected for more insights into the future of MedTech innovation. And if you're ready to take your product development to the next level. Visit us at www.greenlight.guru until next time, keep innovating and improving the quality of life.
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.