In this episode, host Etienne Nichols sits down with industry veteran Mike Drues to explore a critical theme in modern MedTech: the danger of "not knowing what you don't know." The conversation centers on the growing trend of companies making avoidable, "boneheaded" mistakes despite a robust regulatory framework. Mike Drues emphasizes that while technology evolves, the fundamental responsibility for safety and effectiveness remains non-delegable.
The discussion dives deep into a landmark regulatory event: the first-ever FDA warning letter issued to a company for GMP violations specifically linked to the unauthorized use of Artificial Intelligence in manufacturing. They break down the legal and ethical implications of relying on AI agents to generate specifications and production records without human oversight or process validation.
Finally, the episode tackles the controversial idea of individual accountability in regulatory citations. Etienne and Ryan debate whether naming specific professionals in warning letters would curb the repeat of industry-wide errors or if internal company culture provides enough of a corrective force. It’s a sobering look at why professionals must keep their "brains at the door" and treat AI as a tool, not a replacement for human judgment.
Love this episode? Leave a review on iTunes!
Have suggestions or topics you’d like to hear about? Email us at podcast@greenlight.guru.
Think of Process Validation like a recipe for a cake. If you’re a baker, you don't just hope the cake turns out right every time; you test the oven temperature, the mixing time, and the ingredients to prove that if you follow the steps, you get a perfect cake 100% of the time.
In MedTech, when a company uses AI to make decisions or manufacture parts, they must "validate" the process. This means proving that the AI (the oven) works correctly and consistently before selling the product. Claiming "the AI didn't tell me I had to test it" is like a baker saying they didn't know they had to turn the oven on because the recipe didn't mention it.
"The responsibility for meeting these requirements may not be delegated, even though the actual work may be delegated. This applies to artificial intelligence agents." - Mike Drues
"True knowledge is knowing what you know and knowing what you don’t know, and most importantly, knowing the difference between the two." - Mike Drues
We want to hear from you! Do you think the FDA should start naming names in warning letters? Should the "Quality Unit" be legally required to be a human? Send your thoughts, reviews, or suggestions for future topics to podcast@greenlight.guru. We read every email and pride ourselves on providing personalized responses to our community.
This episode is powered by Greenlight Guru. In an era where you cannot delegate your quality responsibility to AI, you need tools that empower your human experts. Greenlight Guru’s QMS (Quality Management System) and EDC (Electronic Data Capture) solutions provide the "regulatory logic" and data integrity needed to ensure your team stays compliant, from clinical trials through post-market surveillance. Connect your quality processes and clinical data seamlessly to avoid the "boneheaded mistakes" discussed today.
Etienne Nichols: Hey, everyone. Welcome back to the Global Medical Device Podcast. My name is Etienne Nichols. I'm the host for today's episode. With us today to talk about this is going to be a fun topic, I think, but Mike Drew's a familiar voice on the podcast.
What we're going to be talking about is what you don't know can hurt you. Knowing what you know, what you don't know, and most importantly, knowing the difference between the two.
So, to get into this, I'd love to discuss some of the. Some of the. The questions that we've kind of kicked around.
This topic seems like an unusual topic for a medical device podcast. It could be applicable across any industry. But I'm curious your thoughts about how this could be applicable to the medical device industry.
What are we talking about today?
Mike Drues: Well, great question, Etienne, and as always, thank you for the opportunity to have this discussion with you in our audience today.
Yeah, you're right. On the surface, it seems like sort of an unusual topic. But look, as I get older and I have been now practicing in the medical device industry for more than 30 years,
I continue to get more and more frustrated when I see companies and the people in them doing some of the most, if I can use the word, stupid things, making the most boneheaded mistakes, and they seem to repeat them over and over and over again. And I haven't had any statistics, but I think the frequency of repeating these mistakes is growing and growing and growing.
And that's why I wanted to have this discussion today. And by the way, Etienne, I can't help but point out there are some significant ironies to what's happening in our industry today.
And the first one I thought I would share with you something that we've talked about before.
One of my most favored sections of FDA's website on the quality side is what I call the Preamble to the QSR where FDA explains not so much what to do, but why to do it.
And I just like to highlight just a couple of sentences from that, and we can provide the link and the resources to the podcast.
But as always, you can chime in here.
FDA says manufacturers should use good judgment, and that's the key phrase, good judgment when developing their quality systems and apply the sections of the QSR regulation that are applicable to their specific products and procedures or operations.
It is the responsibility of each manufacturer. It is absolutely not the responsibility of the FDA. It is the responsibility of each manufacturer to establish requirements for each type or family of the devices that will result in devices that are safe and effective.
And finally, the last sentence I wanted to highlight, Etienne, is the responsibility for meeting these requirements may not be delegated, even though the actual work may be delegated. And this applies, by the way, to artificial intelligence agents.
You cannot delegate the responsibility to artificial intelligence agents as we're going to talk about in one of the case studies that we're going to get into here in just a couple of minutes.
So, you know, it begs the question, you know, do we need more regulation to, you know, try to prevent or minimize these problems?
You know me well enough to know the answer to what I think that is, and absolutely not. We've got plenty of regulation. What we don't have is enough people understanding the.
Not so much the letter of the law, but the spirit of the law. We'll get into some examples in a moment, Etienne. But any thoughts on anything that I just highlighted from the preamble to the QSR?
Etienne Nichols: Yeah, one thing I just. Yeah, I'll emphasize that the preamble to the QMSR is terribly important. And what's interesting to me about that is if reading that is how to know what the FDA's thinking is behind the QMSR or the regulation.
Now, when typically, when you go into a pre. Sub, that is one of the questions people have. What is the FDA's thinking on this? We ask those questions. So why would you not go ahead and read it to get the thinking around your quality system.
But to your point. Yeah, go ahead.
Mike Drues: By the way, and I, I want to give you credit, I was referring to the QSR.
You, you know, are referring to the newer QMSR. But you know, Shakespeare said a ruse by another name still smells as sweet. That preamble, especially those highlights from the preamble that I just shared, they are equally applicable to, to both. You know, I don't want anybody to think, especially for the.
The more junior folks in the audience, that this is anything new.
On the contrary, you know, these, what I call this regulatory logic. This goes back decades.
Etienne Nichols: Yeah.
Mike Drues: Please continue.
Etienne Nichols: You know, my dad told me, never check your brain at the door when I started working.
That's the thing that I always think about when you say you can't outsource your thinking to AI.
Yeah. So anyway, so let's talk about specific examples because I think that's what helps people the most.
You brought up AI. I know there's a generic kind of across the board. Everybody's moving towards using it more and more. I mean, if you're not using it, I'd almost be shocked right now.
But you brought it up for a specific reason, I think. So, let's talk about any specific examples you have.
Mike Drues: Well, before I get to that specific example, Etienne and I got to just share with you an example that just happened to me yesterday. And earlier this morning, one of my current customers, we're getting ready to go to the FDA with a Sprint discussion. We, that particular customer got a BDD, a breakthrough designation. So, we're doing a Sprint rather than the pre sub.
They used AI to generate the justification for why additional clinical data is not necessary in their particular submission.
Well, let's just say Etienne, I had a, a little bit of a different view. I would have, you know, argued this differently than the AI did.
So as my customer pointed out, And I agree 100%, I think the AI tool is a great tool, great resource to maybe create sort of a rough draft.
But that should be your starting point. It should not be your stop.
Etienne Nichols: Oh yeah.
I look at AIs as a kind of think of it as an intern with a PhD. You wouldn't, you know, just turn in your interns research to the FDA. That's not what you would do.
Mike Drues: So exactly. So anyway, so the example that I thought that you and I could bat back and forth a little bit is a very recent example. We're recording this podcast today.
It's May 1st.
This example was from a warning letter that FDA published on April 2, just, you know, 29 days ago.
So, the examples that I'm sharing here are not examples from, you know, years or decades ago. I'm talking about examples, you know, literally within a few weeks, a company called Pure Parolia, which technically is a drug company, but nonetheless, they got a warning letter. And by the way, I'm going to be talking about this case a little bit more detail in my webinar that I'm doing for Greenlight just next week.
But they got a warning letter from the FDA. It was the first warning letter that FDA issued for GMP violations related to the use of AI in the manufacturing process.
Let me say that again because this is an extraordinarily important thing for our audience.
It's the first warning letter in this case. It's for a drug company, but it could have easily happened to a device company.
First warning letter issued for GMP violations related to the use of AI in the manufacturing process. So, we're not talking about AI, you know, it's like an SAMD or some other kind of a device.
We're talking about in the, in, in the, in the manufacturing setting.
And specifically, FDA cited the manufacturer for using their AI to generate product specifications, procedures, master production or control records and so on.
FDA basically pinged them because they did. Apparently, they did not do a process validation, which to me is like one of the very most basic and obvious, you know, things that we need to do any, you know, validations, whether it's process or otherwise.
Anyway, when FDA asked them about this, and this is the, the incredible part, Etienne, the company responded, and this is directly from the public warning letter. The company responded by, by saying they were not aware of the legal requirement to perform process validation prior to distribution.
Why?
Because the AI agent never told them that it was required.
I mean, is it just me? I mean, this is like, beyond comprehension. And don't forget, Etienne, and the people that are doing this are making the pills that you swallow or are making the medical devices that are used on you or your spouse or your kids.
Yeah, and I know, Etienne, and earlier this week you published a column about this in. On LinkedIn, and we can certainly point our audience to that.
But you said in your column that the AI did not fail. Here I'm just curious if you want to explain to our audience what you meant by that. The AI did not fail.
Etienne Nichols: Yeah. So, the AI, I mean, if you want to look at as the AI was the quality unit. In that sense, yes, it failed.
But the way I look at this as. Because the, the actual citation that was cited was 21 CFR Part 211.22, Section C, the quality control unit shall have the responsibility for approving or rejecting all procedures or specifications impacting the strength, quality and purity of the drug product. Okay?
So, the quality unit. Quality unit is the ultimate. They are the ones who are supposed to have the responsibility for that. And that Entire section of 211of CFR outlines all of that.
So, if all they're relying on is the AI, they have failed. If you ask me, that's. That's my, that's my estimation and that's how I look at that.
Mike Drues: Yeah, I think that's an excellent point, Etienne, and I'll come back to that in a second. But one other thing wanted to point out, also sort of mentioned indirectly in the warning letter.
As a result of this, now we, and remember, Etienne and I work as a consultant for the FDA as well, we are now having discussions within the agency as well as outside the agency of should we put a requirement, maybe a quality requirement, that if you're going to use AI like this, that it has to be reviewed by a human being?
Yeah, yeah.
Etienne Nichols: I mean, without using that terminology, part well, 21 CFR part 211 actually says that the quality unit has to approve, has to review, has to ensure the safety of what they're approving. So.
Mike Drues: Right.
Etienne Nichols: I don't think it should go ahead.
Mike Drues: The question is here, does the quality unit, as you say, have to be a human being?
Etienne Nichols: I think it. Personally, I think it does.
And it goes back into an ethical question of.
Of why do we hold things accountable? Because if something's signing it off, there's an accountability there. I think the assumption is with accountability that there's a fear of punitive.
But it goes back on to what is the purpose of accountability?
Is it to punish someone when they do wrong, or is it to actually extract justice? I mean, there's a lot of things there that we could go down that rabbit hole.
We don't have to do that necessarily. But.
Mike Drues: Yeah, yeah, but I guess we'll leave it as a rhetorical question for right now because this is obviously not addressed either directly or indirect in any quality regulation. And that is, does the quality unit have to be a human being? I 100% agree with FDA that if you're going to use AI, and I'm certainly not adverse to using AI, somebody should be responsible above and beyond the AI. Right. I mean, to me, that's, you know, statement of common sense, and the fact that we might have to include that in the regulation doesn't really matter.
Make us look very good.
Right. So going back to what you said, Etienne, and in LinkedIn and just now that you think the AI did not fail, I think that's a legitimate possibility, but I don't think that it's the only possibility.
I would argue another possibility is that maybe the AI did fail.
Why? Because it depends on exactly what the company asked the AI to do.
Now, unfortunately, that level of detail was not provided in the warning letter.
So, it's a hypothetical. We don't know for sure, but I would have to allow for that possibility.
In other words, I like to think of AI. I like to treat them as a person.
Right. Not as a piece of software, but as a person. Just like in tax law, the IRS treats a corporation as a person.
So, if we treat the AI like a person, if the manufacturer asked me the same question, rather than the AI, what information would I tell them? Right?
Would I tell them, you know, that you got to do a process validation or some other kind of a validation? It kind of depends on what they're asking me.
So, I'm not disagreeing with you. I think it's probably likely that the AI did not fail.
But you know what they say, since we're talking about software, Etienne, and garbage in, garbage out, if we're not asking the right questions to the AI agent or bot or whatever the heck you want to call it, you're not going to get the right answers. Or you might get incomplete answers like here.
Etienne Nichols: Well, this might be one of those areas that's hard to agree because I think we kind of come at it from different maybe views.
I do look at AI as a machine or software, and I can understand where you're coming from. But even if I were to get on board with what you're saying, the AI could have.
I suppose I could see what you're saying. But even if you zoom out and you say, depending on what the company asked the AI did the AI fail or not, to me that's still a company failure because the company should not.
It's almost as if the FDA came and said, why didn't you look a little. Why didn't you analyze this properly? And I said, well, the coffee failed.
I didn't have strong enough coffee that morning to be able to focus.
To me, AI is a help, a tool, and that's something you use.
Mike Drues: But yeah, I think Etienne, and that's a, that's a very, very well said. And to be. To be frank, I think you and I are singing exactly the same song, just maybe in a slightly different tune.
Etienne Nichols: Sure.
Mike Drues: Right. So, let's take this a little bit further. Another that has resulted from this case, and I've actually been advocating this for a long time, long before, you know, just last month is. Now there's a discuss of fd when a warning letter is issued, not just naming the name of the company, but naming the individual or individuals involved.
I'm just curious, Etienne, what do you think of that idea? Not just saying the name of the company, but Etienne or Mike or whoever. What do you think of that?
Etienne Nichols: I still, I still think that I would maybe push back on. On doing that partly because.
So, the company itself is the world that that employee lives in and they are going to suffer the humiliation within that world.
It. It's slightly different in my mind than if a surgeon commits malpractice and kills somebody. Versus something is found that the process is burned up. So, I don't know, I see a slight difference there just because of the world, the world where they live in.
But yeah, I'm curious your thoughts too.
Mike Drues: Well, if everybody agreed on everything, this world would be a boring place.
Etienne Nichols: And I don't want to disagree on everything either, but I'd love to hear your thoughts.
Mike Drues: So, here's my.
So, here's my thinking. In the right circumstances, and that's obviously an important caveat. In the right circumstances, I say absolutely yes, that FDA should include individual’s names John Smith or Mary Doe or whatever in, in a warning letter in the right circumstances. Because if I give advice to my customers, which I always do, I personally, Mike Drews, am responsible for that advice.
Etienne Nichols: Yeah.
Mike Drues: And quite, quite literally. I don't mean to be overly, you know, brash here, but if I f up, I'm comfortable for that.
Etienne Nichols: Yeah.
Mike Drues: Right.
Now I would add that that street runs in two directions.
One of my many frustrations with the FDA is that when you have a meeting, for example, a pre. Sub meeting with the FDA and you want to, in your meeting notes following, following the meeting include what FDA said.
You cannot say John Smith, comma, FDA reviewer said, they will strip that out. You have to say FDA said, I am adamantly against that for the same reasons. If somebody's going to say something, they shouldn't be able to hide behind a company. They shouldn't be able to hide behind an agency.
This is, you know, we're professionals. You use the surgeon metaphor, which I've used before myself. Yes, admittedly, this is not quite, quite the same as, you know, one surgeon doing an operation.
This is a team in a company or in an agency like the FDA.
But there should be individual accountability here.
Thoughts on that? Thoughts on my response?
Etienne Nichols: Yeah, I do agree that there should be an individual accountability. I do see the individual accountability still.
I mean, and, and I think they're, I think we could probably be, we're probably closer than. We are different as far as how we think about this. That individual accountability inside that company is going to be known and it is going to occur most likely.
I mean, unless the company's very, you know, trying to cover something up, even internally, that whole company, that person will have that. But, and so the same, same thing could be done with FDA.
You could state that person's name and internally they can, okay, that reviewer said this, we can go talk to them, etc. Rather than it being to the world. I don't know that exposure to the world because the world is not a just and fair place quite often in the public arena.
Whereas in that company, what you've done to damage this company by using AI without approval or without any kind of review, they're going to suffer the wrath internally. And I don't know that they necessarily have to face that on the public side of things, but that's still my thought.
Mike Drues: Okay, fair enough.
And once again, I think that you and I are singing the same song, just in a slightly different key.
Let's take this a tiny bit further.
I pointed out one of the ironies at the beginning of our discussion about what we find in the QSR preamble. Let me point out another irony that I find about this case, and that is when you look at medical devices, whether it's an SAMD software as a medical device or a piece of hardware that has software, you know, AI in it, we have not gotten to the point yet. Of all of the devices that have been cleared or approved with AI, the vast majority, I would say almost all of them, are not allowed to implement anything unilateral.
In other words, they require confirmation from a physician or some sort of a healthcare professional first before whatever the AI says or does or is implemented. And this is obviously a form of risk mitigation.
The question is this is absolutely not the future. Right? This is where we are right now. And we've talked about AI in the past before, but this is not the future.
In the future, sooner or later we will have medical devices with AI that are allowed to implement things unilaterally without checking with a doctor or somebody first. But obviously we're not quite there yet.
You know, use the simple example, Etienne, of the self-driving car.
A lot of people are still kind of leery about self-driving cars, but that's, you know, for now, you know, in the future, as the technology improves and we get more experience and so on, you know, I think people are going to be less concerned about self-driving cars.
And I also find it ironic, Etienne, that lots of people today still have, you know, questions about self-driving cars. And yet when they don't realize that when we, when they get on an airplane, the vast majority of the flight, other than just at the takeoff and the landing, the vast majority of the flight is under autopilot control.
So that's kind of like self-driving car, if you will.
Right?
Etienne Nichols: Yeah.
Mike Drues: And one other thing that I would just mention, Etienne, and then I want to hear your thoughts on this some more.
I don't know if you're A Star Trek fan.
Etienne Nichols: I'm, I grew up watching, yeah, the First Generation for sure.
Mike Drues: The huge Star Trek fan. And when I talk about Star Trek here, I'm talking about the original.
Yeah, I'm not talking about the pseudo-Treks that came later on.
But when I first started thinking about this case, I was immediately reminded of an episode from the second season of Star Trek. It's episode 24, if anybody wants to look it up, called the Ultimate Computer.
And by the way, this goes back to 1968, where basically the episode was about a computer.
They called it the M5 that took over control of the Enterprise, and it didn't need any human input to say this is okay, or whatever. It just unilaterally would control the Enterprise.
Well, one of my many favorite quotes from Mr. Spock comes from this episode.
He said, computers make excellent and efficient servants, but I have no wish to serve under them.
Computers make excellent and efficient servants, but I, I have no wish to serve under them.
So, in this Etienne goes back to 1968.
So, this is a, you know, sort of a cautionary tale about over delegating human responsibility to technology. And the case that we're talking about here is a classic example, I think, of over delegating human responsibility to the AI technology.
So, what's my recommendation?
Maybe any medical device professional should study Star Trek.
Etienne Nichols: My parents would definitely agree with you on that for sure.
And if I go back to what you were saying earlier about AI still not quite there as far as making some of these unilateral decisions, we may be closer than we think too. And I don't want to be speaking out of both sides of my mouth necessarily, but I actually wrote about a company called Recovery AI.
Recovery AI where they're at post operative clinical support.
It's basically a chat bot that if you've had surgery, you go home, you're like, is this swelling right? Instead of waiting a week before when you go talk to your doctor, you take a picture, you Google it, and it says, no, you're fine, don't worry about it.
Well, okay, that, that they're in pivotal trials right now, which is interesting, you know.
Mike Drues: So, in other words, take that a step or two further, Etienne. And why should anybody have to go to medical school anymore?
Etienne Nichols: Well, there, there are definitely arguments, I think. So, I will actually, I'm, I'm going to take the bait for just a moment because I think let's, let's change the conversation to Vibe coding.
And why should anyone go to software engineering school anymore? And I think there are going to be fewer and fewer people who pro, but the ones at the top who actually know what's going on. I've used the example; I'm going to throw this example at you and see what you think.
I look at AI kind of like electricity. I don't see it as the difference in Internet. I think it's like the inflection point was electricity. Previously we, we lit our homes with a gas lamp and everybody, every family knew when it runs out of gas, you put more in it.
You know, if the wick, you cut the wick, all this thing you knew the troubleshooting.
You don't know that with electric, the wires in your house.
So, you, you think it's cleaner, you think it's easier, you turn it on and off. But you need a professional to install the wires. If it breaks, you need someone even more qualified.
So, I think it's going to be something similar.
And, but anyway, that's my theory exactly correct.
Mike Drues: And I would, you know, they, if they say, you know, they say if you're going to steal, steal from the best.
Socrates said a very, very long time ago, true knowledge is knowing what you know and knowing what you, I don't know. And most importantly, knowing the difference between the two.
So, as I said before, and I want to be absolutely clear on this, I have no problem using AI as a tool, maybe as I said, to generate a first draft or to act as a sanity check, but it's not a substitute for the most important tool, and that is the one between your ears, or at least it's supposed to be between your ears in some cases. I wonder, before we move on to the next example, Etienne, are there any other final thoughts or lessons to be learned from this particular example?
Etienne Nichols: The only thing I'll say is I'm just going to torture my metaphor just for a moment longer and I'm going to apply it to this with my electricity example. There's a reason we have the NEC, the National Electric Code, and it makes things more expensive, more difficult.
Early on with AI, I was sort of against, like, why does there need to be regulation for this? But the more I think about it, the more I do realize there probably does need to some be some sort of regulation around it.
And you know, and I know we talk about logic and whether or not there should be regulation and so on, but that moat to make it slightly more difficult so that only the people who truly understand the uses and the misuses are utilizing it properly.
That's just my thought.
Mike Drues: No, I agree with you. As a matter of fact, I strongly agree with you. Every single day I read regulation and I'm just like, why the heck do we need this?
This is a statement of the obvious.
And that street runs in two directions. Every single day I read where we do not have regulation and the company doesn't do it because it's not required. Even though in many cases, as a professional biomedical engineer, I think it's something that we should do.
Etienne Nichols: Yeah.
Mike Drues: Should we move on to another example?
Etienne Nichols: Yeah, let's do it.
Mike Drues: Yeah. So, regrettably, I can give another example also just from last month, April of 2026.
So, once again, I'm not going back in time here.
This does not involve AI, but it's still a good example of trying to avoid or trying to demonstrate what you don't know can hurt you.
FDA reported there were more than 2,200 medical device manufacturers that failed to be compliant with clinical trial submission requirements, saying that just about 30%, 29.6% of them were required, and I'm putting that word in air quotes.
Required to.
To publish their results in ClinicalTrials.gov. but for whatever reasons, they didn't.
Those things were missing. Nearly a third of clinical trials were not, which were required.
You know, regulation is all about the interpretation of words. So, I guess, how do we interpret the word required?
Right. And yet they.
They didn't do it.
So, in this particular case, Etienne, and going back to what we said before, if a company gets a warning letter for not reporting their clinical trial results on ClinicalTrials.gov, which they, in most cases absolutely should.
Excuse me, should the name of the people, maybe the head of clinical operations or regulatory affairs or whatever, should their names be published in that warning letter? What do you think?
Etienne Nichols: I don't know. I'd have to think about that for a minute.
Mike Drues: Okay.
Etienne Nichols: What are your thoughts?
Mike Drues: I think I know I say yes for the same reason that I give my customers my advice, my professional opinion, which fortunately, they pay me pretty well to do.
But along with that, that comes the responsibility.
If we're going to call ourselves medical device professionals. What exactly does the word professional mean?
Whether you're working in a company or the FDA, it doesn't matter.
And here's another question, Etienne, and it could be a rhetorical one, but I'd love to hear your thoughts on this.
With all of the regulation that we have, with all of the guidance documents that we have, with all of the webinars and the podcasts that. That we do that come out of FDA, that come out of greenlight, that come out of a lot of different organizations with all of the regulatory professionals that we have in companies and consultants and the FDA and so on and so on.
Why does our industry, or at least some people in the industry, I don't want to paint an overly brush here, but why does our industry, to continue to make such, what I would call, to put it politely, boneheaded mistakes?
Etienne Nichols: Well, and I've thought about this a little bit myself, and this might be too rosy of a picture because I'm sure there's, you know, but I look at it as maybe the flip side in that the industry is growing so much because I do think there is.
There is an influx of a couple different things.
There's software that needs hardware. There's.
Well, if we just look at hardware, it's. Or software itself.
Software industry is bringing in a lot of people who are not familiar with medical device regulation.
We're bringing in a lot of software engineers who are building companies because they see gaps or maybe they know doctors, et cetera. So, I do think that the industry has grown.
And so, in some ways I see it as an indication of a positive thing and that the medical device industry is growing. Obviously, with, with that cross section, you're going to have the beginners, you're going to have the senior. If it's all in the senior, more experienced people, that's a real problem. But if it's all in the beginners who are brand new to the industry.
Mike Drues: Well, I love your optimistic view, Etienne. And I consider myself, believe it or not, also to be an optimist. However, I call myself a realistic optimist. Sure.
I'm not one of these that lives in the world of rainbows and unicorns. I live in the real world. So, let's take that question that I just asked you half a step further, Etienne.
And we talked a little bit about the possibility of naming individuals in warning letters.
Do you think that if we publish people's names in warning letters that this might help that, you know, what do you think if we publish them?
Etienne Nichols: It might. It might. I don't know. I still. I don't think it would help as much as we think it would.
Mike Drues: Okay. Okay. Well, it's a hypothetical. We don't know for sure until we try. But I'm just throwing out ideas, you know, seeing, you know, we need new thinking here. You know, if, you know, Einstein said the definition of insanity is doing the same thing over and over and expecting the different result. We seem to be doing the same thing over and over and thinking the same way over and over and expecting a different result.
So maybe we gotta change something.
Okay, should we move on to the, to the next one?
Etienne Nichols: Yeah, what have you got for the next one?
Mike Drues: So, another common question that I get from people, and I know we've talked about this topic before, but there's a reason why I'm including it here.
Is my medical device a regulated medical device? What I mean by that is, do I need FDA's permission in some way, 510(k), De Novo, PMA, what have you, before I can market my device here in the United States?
Well, we've talked about this. Matter of fact, I did a full webinar for Greenlight, I think, a couple of years ago on what is a regulated medical device. And we can certainly put a link to, to that up there. But it's not a simple question.
As a matter of fact, in the software world, I find it fascinating how so many people are confused as to whether or not a piece of software is a regulated medical device or not.
Well, when you think about the regulatory logic, it's really not confusing at all. It basically comes down to does it fit the CFR, the code of federal regulation's definition of a medical device?
Now, I'm not going to take the time in today's podcast to go through that. It's many paragraphs long.
But my simplified definition of a medical device, and Einstein said, if you can't explain something, simply, you don't understand it well enough.
My simplified definition of a medical device is something, anything other than a drug that is intended to prevent, diagnose or treat a disease, injury or condition, something, anything other than a drug. Totally agnostic of the form factor, whether it's a physical something that you can hold in your hand, whether it's a liquid, whether it's a piece of software, whether it's an in vitro diagnostic, I could care less.
That is intended to prevent, diagnose or treat a disease, injury or condition. Bottom line, if it fits that definition of a medical device, then it is probably a regulated medical device. And again, Etienne, and notice I'm parsing my words carefully because nothing in the regulatory world is black and white. There are always, you know, exceptions, right? So probably, on the other hand, if it does not fit the CFR definition or my definition of a regular regulated medical device, then what it's called, it's what we call a wellness device.
And once again, we've talked about wellness devices in the past and by the way, just one thing that I wanted to identify or remind people of when it comes to wellness.
Whether my device is a regulated device or a wellness device is not a binary question is not a yes or no question.
I have a number of devices on the market right now that the same device is on the market under multiple regulatory identities. In other words, I might have one version of the device on the market as a wellness device, a second as a 510(k), a third as a de novo and some, albeit extreme example. A fourth is a PMA.
And when I say it's the same device, I literally mean the same device in terms of what it does, how it works. The difference is the labeling, what we say about it, what it's claiming.
Mike Drues: It's exactly what it's claiming. The intended use, and more specifically, the indications for use.
And just want to point out to the audience, we won't dig into this in detail here, but maybe we can do a podcast on this in the future.
Just a couple of months ago, In January of 2026, FDA made some changes to the wellness guidance, which, let me just say, I'm not entirely comfortable with, I think.
And this is the same. At the same time, FDA made some changes not just to the wellness guidance, but to the clinical decision support software guidance, the CDSS.
I think, in a nutshell, the changes that were made to both of those guidance were pure politics because it's no secret that the current administration is.
I don't want to go so far as to say, you know, making it as easy as possible for companies to get devices on the market, but they're certainly trying to lower the regulatory burden.
And I'm not opposed to doing that when it makes sense, but we just have to be really, really careful. Because one of the problems with the wellness thing, Etienne, is if a company has a wellness device, there is no backup. There is no safety check. There is nobody looking over their shoulder, the FDA or otherwise saying, is this really appropriate? Right. So, we just have to be really, really careful there.
The last thing that I wanted to mention here is, is a new program that maybe just not everybody in our audience is familiar with.
It's what we call the Tempo pilot program. Tempo.
Tempo. It's an acronym. And all we need is more acronyms. It's an acronym for Technology Enabled Meaningful Patient outcomes.
Technology enabled, meaning Meaningful patient outcomes. Who comes up with these things?
Can you explain this in a more confusing way if you wanted to?
Right. So, in a nutshell, the Temple program, which is a joint pilot program between FDA and CMS, the Centers for Medicare and Medicaid Services is for digital health devices.
And specifically, these are just a couple of bullets that I thought I would highlight from the tempo portion of FDA's website to promote access to certain digital health devices and at the same time safeguarding patient safety.
Well, that sounds great in theory, but you know, what does that mean in reality?
Evaluate a risk based, informed a risk-based enforcement approach that supports digital health devices intended to, and this is where the interesting part intended to improve patient outcomes in certain conditions.
And FDA identifies four condition areas that you can do this with. But I think the most important part is improve patient outcomes. The reason why that's significant ET in is because that puts significant limitations on the claims that you can make.
In other words, it's going to be pretty hard to make a director a strong claim that you're preventing, diagnosing or treating a disease, injury or condition. Instead, what we're talking about here is improving patient outcomes.
You can certainly improve a patient outcome without treating or diagnosing the disease.
Right? So that's a statement of the obvious.
Bottom line. It's, you know, it's again, more politics. It's encouraging innovation.
The way I like to think about this.
And if you do qualify for this new pilot, Etienne, what you can basically do is go to the FDA and request that they exercise their enforcement discretion essentially to lower the bar, to minimize or eliminate some of the regulatory requirements that normally would apply to that kind of a device.
So, cutting through all of the regulatory and political and legal gobbledygook, Etienne, this is the way I like to think of it.
This relatively new Tempo pilot program is like pre-market, real world evidence.
Pre-market, real world evidence. What do I mean by that?
I think most of our company, most of our audience is probably familiar with real world evidence. This is evidence that we get about the safety and efficacy of a device while it is on the market.
In other words, post approval, we've already got our 510(k) or PMA or whatever it is.
This is a way to get real world evidence on a device that is not yet cleared or approved.
This is, by the way, you mentioned earlier, one of my many favorite phrases, regulatory logic.
See, what I'm demonstrating here is the real power of regulatory logic. When you look at allegedly a new program like the Tempo pilot program, if you understand regulatory logic, you quickly realize that this is really not that new.
It's really a combination or as I like to say, pre-market, real world evidence.
And the other thing that this program reminds me of, and I mentioned this a moment ago, is it allows FDA to use their enforcement discretion, which is a fancy legal way of saying, well, FDA is not going to really pay attention to this right now, although that certainly could change in the future.
But to me one of the first things that comes to mind is clinical decision support software.
That's exactly what FDA and you know, we did, maybe this was a while ago, maybe with John Spier. I did a podcast that new guidance when it came out and basically what FDA said, look, clinical decision support software is a regulated medical device.
There's nobody can argue against it.
However, we are going to use our enforcement discretion to choose not to regulate clinical decision support software or at least not regulate it very much because quite frankly we have have more important things to worry about at the time.
And I also said that in that webinar that I think FDA will continue to use its enforcement discretion regarding clinical decision support software and possibly regarding Tempo Device as well, unless and until companies and the people in them start to do stupid things.
And when they do stupid things, I could just about guarantee that FDA is going to start regulating those again. Another regulatory metaphor, Etienne, is laboratory developed tests, LDTs.
You know, FDA used their enforcement discretion largely in past not to regulate them today because of Theranos and some other situations.
It's not quite as simple as that.
Comments on that much.
Etienne Nichols: Well, the only thing that maybe it's tangentially related is when, what, what did the FDA announce just a couple days ago? Real time clinical trials.
So that was interesting to me as well. So, it's kind of a similar, similar concept in the eye to, to expedite things, they'll accept the endpoints and the sharing of the data kind of in real time to expedite the getting through those continuous clinical trials.
So that was an interesting thing.
Mike Drues: Yeah, good example. And you know, just before we move on to, to some other programs that people should be aware of and may not be, I just gotta remind our audience, you know, some of the stuff that we're talking about is quote unquote new, but it's, you know, is it really new?
There's a, there's a philosopher that had a famous quote. It's escaping me at the moment, but I'll think about it in a moment.
All right, let's, let's continue on to beyond tempo.
So, what other programs should medical device manufacturers know about?
But for whatever reasons, many do not.
And as a result, if you don't know about it, how can you consider it right this is, you know, Socrates, knowing what you know, knowing what you don't know and knowing the difference between the two. If you don't know, for example, if you've never heard about the temple pile it, how would you ever consider using it?
Right.
Simple. Okay, so some of these we've talked about before and I'm going to go through them very quickly, some of them we have not.
The first is the breakthrough device designation program, the BDD or sometimes referred to as the BDP.
This is a voluntary program. In other words, I've had customers ask me for example, if I get a BDD, does that mean I do not have to get a 510(k) or PMA? The answer is no.
This is a voluntary program that goes on top of that it's applicable for devices or device LED combination products.
So, if you have say a drug eluting stent, that's a device led combination product, a BDD would be applicable. Whereas a pre-filled or a preloaded syringe is a drug led combination product and it would not be applicable for a bdp. Now on the drug side, on the CDER side of FDA, they have similar programs, but we're talking about devices and device LED combination products.
And here's the real important part.
Products that are reasonably expected, reasonably expected to provide a more effective treatment or a diagnosis of a life threatening or irreversibly debilitating disease or condition.
Notice here, Etienne, that the emphasis of the BDD is on improvement in efficacy, not safety. You can have a safety improvement in a BDD and oftentimes there is, but the emphasis is on efficacy. And the reason why I point that out is because there's a sister program to the BDP and that is the STEP program, which is the Safer Technologies Program or step. Once again, like the BDP, this is a voluntary program for certain devices and device LED combination products.
But here's the difference.
The products have to show a reasonable expectation to significantly improve the safety of a currently available treatment or diagnostic device.
It has to be an improvement in a currently available treatment or diagnostic.
So, and also the another important differentiation between the BDD and the step is that in the BDDD, as I just said, it has to be a life threatening or irreversibly debilitating disease or condition in the step. It does not.
It can be a less serious disease or condition than would be required in the BDP.
So, both of those programs companies should be aware of. And as you may know Etienne, I've got a lot of experience with BDDS as well as steps. More so on the BDD side, because improvements in efficacy is usually more exciting for people to talk about than improvements in safety.
Let's put it this way. It's. It's very, very difficult, not impossible, but very difficult to get funding for an angel or a VC if your device basically improves the safety of an existing device.
I wish it wasn't the case, but it's just a simple reality. And by the way, it's not either. Or.
According to the guidance, it says that if you have a BDD, you cannot do a step.
Or similarly, if you have a step, it cannot qualify for a BDD.
Once again, as I've said many times, Etienne regulation is about two things.
Interpreting the words, understanding the words, and then defending your interpretation.
So, when the guidance says it has to be a step or a BDD, it can't be both.
That's what an average regulatory professional will say.
A good regulatory professional.
Whether anybody considers me to be a good one or not, I'll leave that as rhetorical. But a good regulatory professional will say, yes, it can be both.
For example, if we have one version of the device that has certain labeling that makes, say, efficacy claims, and a second version of exactly the same device that has different claims, maybe on the safety side, because in the eyes of the law, Etienne, you can have the same physical device or even exactly the same software. I don't care what it is with different claims.
And in the eyes of the law, they are viewed as two separate medical devices.
Etienne Nichols: Yeah, yeah, it goes back to the claims. Makes sense.
Mike Drues: Excellent.
Etienne Nichols: I am going to have to.
I hate to cut us short coming up on time here, but any, any, just to wrap it up real quick, any last words of advice for the audience when you're talking about things that they need to know?
Mike Drues: Yeah, I'm sorry, Etienne. And I'm trying to have time and maybe we can do, you know, a part two to this, if you'd like.
Etienne Nichols: I'm sure there's probably enough to do that.
Mike Drues: Yeah, absolutely. But basically, to wrap this portion of our discussion up, I would say learn from other people's mistakes.
Etienne Nichols: Yeah.
Mike Drues: You know, it's. Don't let history repeat itself. And if you do let history repeat itself, this might sound overly harsh to some people and may even you might disagree with me on this, Etienne. But if you do let history repeat itself, if you repeat a problem that we've seen before, then maybe your name should be published in an FDA warning letter. Or. Am I being overly harsh?
Etienne Nichols: Yeah.
Mike Drues: Does it mean be a medical device professional.
Etienne Nichols: Appreciate all of your advice and thoughts, Mike.
And yeah, I think we should resume the conversation because this has been fun. Those who've been listening really appreciate you hanging in there with us and discussing this topic.
Mike Drues: Wait a minute, Etienne, did I hear you say regulation can be fun? That must have been a mistake. I must have misheard you.
Etienne Nichols: Oh man, if you spin it right, anything. You know, actually the phrase I typically say is regulations themselves are usually pretty boring, but the things that cause those to be regulations is never boring.
Mike Drues: That's a good. That's very well said.
Etienne Nichols: Thank you so much for listening. We'll let you all get back to it. Stay tuned for the next episode and we'll see you next time. Take care.
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 form.
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.