Startups, Regulations, & Risk: Insights from MedTech Guru Etienne Nichols | Ep. 7

About "Startups, Regulations, & Risk: Insights from MedTech Guru Etienne Nichols | Ep. 7"

"Startups, Regulations, & Risk: Insights from MedTech Guru Etienne Nichols | Ep. 7" is episode 30 of The Med Device Cyber Podcast, published on January 7, 2025, featuring Etienne Nichols (Head of Industry Insights and Education, Greenlight Guru). Host Christian Espinosa and the guest dig into the practical realities of shipping and maintaining secure connected medical devices - the kind of detail you only get from people who have done the work.

While the AI-generated summary, key takeaways, and full searchable transcript for episode 30 finish processing, the audio and video are already live on YouTube, Spotify, and Apple Podcasts using the links above.

Explore the full episode catalog to find more on FDA premarket and postmarket cybersecurity, SBOM management, threat modeling, and medical device penetration testing.

Host: Hi, welcome to another episode of the Med Device Cyber podcast. Today we have a guest uh from Greenlight Guru. We've got Etienne. Uh Etienne works with Greenlight Guru and they specialize in quality management systems. Uh we also have Trevor uh who you've seen before on our podcast. Trevor works for Blue Goat Cyber. He's our director of medical device cybersecurity, our in the weeds tech person who's does a lot of the hacking and leads our hacking team. So welcome to the podcast. Uh Etienne, you want to introduce yourself a little more formally than I did? Guest: Yeah, absolutely. Thank you so much for having me on. Uh yeah, my name is Etienne Nichols. Um, Greenlight Guru, well, I'll tell tell you a little bit about what I do at Greenlight Guru. So my position is the head of industry insights and education at Greenlight Guru. So I get to talk to a lot of professionals such as as yourself and uh um I head up uh a lot of different articles and content that we produce and try to just add that insight to the industry. So at Greenlight Guru, a lot of people look at us as a content provider in some ways. Uh and a lot of ways we are, but uh ultimately the way we uh make money I suppose is to sell software solutions to the industry and and what we specialize is in quality management system and clinical investigation solutions. Host: Yeah, I've seen a lot of your podcasts and you guys do create a lot of content. Guest: Yeah. Yeah, well, it's good that you've seen it at least. Hopefully it's been uh, you know, maybe helpful or beneficial to some way. Host: It has because when I first started doing this stuff, I didn't know what a QMS was or what ISO 13485 is. There's a lot of like acronyms and like there's QSR, QMS, uh 21 CFR 820. You know, there's all these things and it's it's it's it's if you're kind of new to med-tech, it can be super confusing. Because we we from cybersecurity we have all these acronyms and then you combine that with the med-tech and then the FDA and the MDR, you know, those are acronyms within themselves. It becomes a very confusing uh space. And plus you then you have the the medical acronyms, you know, that people use as well. So it's very acronym rich. Guest: Yeah, even when the regulatory agencies themselves are an acronym, you know, there's kind of a problem going on. An obsession with with acronyms. And there's a new one coming on too, QMSR, which you mentioned ISO and uh uh and FDA's uh QSR. If you combine those, you've got QMSR. That's what's coming next, uh quality management system regulation from FDA. And we could talk about a little bit about that if you want, uh just however, however you want to go, happy to go whatever trail you like. Host: Yeah, I think it would probably be useful just to establish a baseline and let people know from a high level what a QMS is and why they would even need one. A lot of our clients are startups and they probably haven't even thought down the road like we need a QMS. You know, they're they're they're busy trying to innovate their product and get it to market. So maybe you can explain like why they would need one and how it's beneficial to them. Guest: Yeah. So a quality management system isn't something that's unique to Medtech. It's uh, uh, I think the some of the fathers of quality, Deming and uh uh Crosby, you know, the quality is free guys from the 1980s. They really pushed this quality concept, the idea that, um, you can uh produce consistent, reliable product if you put certain processes in place and manage those uh with a very consistent way of managing. Host: Is this like Six Sigma? Didn't Deming come up with Six Sigma? Guest: Yeah, yeah, I think that's right. I I get them all mixed up. I've I've gone through different ones. Um, they start to crisscross over and and but but yeah, so it's so the the quality management system idea is not necessarily unique, but in most industries they have something called ISO 9001, which is the international standard for how you would lay those processes out. So you would have management review, you would have customer service, you would have a certain way of designing the product, a certain standard flow. Well, for Medtech, they built on top of ISO 9001 something called ISO 13485, which is the international standard for how medical devices should approach their quality management. You asked what is a quality management system? That's a good question. It's the company's defined uh way of approaching quality. How are you going to produce consistent, reliable, safe and effective medical devices? So in a nutshell, at a very high level, that's what a quality management system is. You go down a few layers, it's it's the the actual procedures you have in place, your uh your quality manual, your quality, um, the the different things you actually put in place to say we are going to follow these these different work instructions. We're not going to change them without going through a certain approval process and so on. Host: Okay. And with cybersecurity, you know, that's our focus. I know a lot of our clients add the cybersecurity documentation such as risk management. Uh they use a QMS so they can have a record of when they update it and a history of everything. From an audit perspective, if the FDA or MDR asks for evidence that supports the plan they submitted when they got clearance, would they pull all that stuff from the QMS or what's some best practices around that? Guest: That's a good question. So cybersecurity is something that the FDA has been increasingly uh ratcheting down on. I'm sure you guys could probably educate circles around me as far as how much they've ratcheted down, especially in the last 18 months or two years. But one of the things that they expect is that cybersecurity is going to be built into the medical device by design. So that's going to be that that is required to be in your design controls. Now, I'm mentioning something that is embedded within the quality management system. So the quality management system is the overarching company's approach to quality within that is your approach to designing product and that's typically called design controls. Design and development, however you want to approach it, whatever terminology you want to use. Within that design controls process, you need to be specifying how you're approaching cybersecurity, how you're implementing those controls. And so you mentioned if if the FDA came and knocked on your door and said, hey, we want we want to see how you're designing your products, we want we want to inspect you. Uh they would probably start with your top level procedures and then drill down. Okay, you say you are developing your product in a certain way and this is your approach to cybersecurity. Let's pull a design history file and let's actually look and see how that's actually done. So we're going to look through your procedure, we're going to compare what you've actually done in your design history file both to that procedure and the regulation and see how you stand up to it. Host: That's an interesting point you you bring up that the and we agree the FDA and just general best practices to design your device with cybersecurity in mind. We don't see that happen very often. We see most people try to bolt it on at the end, which is very costly, uh, and it doesn't support a QMS very well or an audit because it's not designed in as you mentioned. And maybe I'll throw this over to Trevor. Trevor, from your experience with our clients, like what percentage do you would you say like, what Etienne is saying like they've actually designed cybersecurity in because I know we've had conversations around functional requirements and non-functional requirements and cybersecurity being, you know, quote non-functional. Like what are your thoughts on this and based on your experience, like how many companies actually design this stuff in, cybersecurity? Trevor: I'd say at some level, uh, probably around 60% of the companies that we interact with are designing cybersecurity in. Host: 60%? Or six? Trevor: 60. Host: Okay, that's higher than I thought. Trevor: Well, this is where I get to caveat that number. That is to some extent where we go through and I say, hey, can you describe some of your security controls? And they go, yeah, we have an Excel sheet with 10 rows on it and it explains all of the things that we thought could happen and so we you know made sure that we have encryption in the database. And that's about as far as it'll go. I would say getting down to a point where I ask at the start of a project, hey, can you show me any non-functional requirements you have relating to cybersecurity? And they say, here's this, here's the threat model that we did throughout the design phase, here are all of our considerations, here's the traceability to the features that we built into the device to incorporate cybersecurity. That is a number probably closer to 5%. Guest: (laughs) And you know one of the things that I think about when I say designing risk or designing cybersecurity into the medical device is the risk management like you said, what are the different things that could happen and uh medical devices are required to follow ISO 14971. It doesn't really mention cybersecurity in that, but if you look at the 24971, which is the uh kind of the guide on how to implement ISO 14971, it does have examples on how to implement those cybersecurity measures. But I I would I would love to hear just just a brief snippet from you as to some of the advice we could give different from our customers even for example, um, in designing that in in other ways or is that the primary way you would say needs to be done? Trevor: So, ISO 14971 that is safety risk management. And part of what the FDA is trying to look for is separate but connected risk management frameworks. So ISO 14971 covers that safety risk management and then TIR 57 covers security risk management. They are both very similar. Uh TIR 57 is loosely modeled off of 14971. So they operate in a similar way and part of what we like to see there is there's a risk assessment phase. After you identify a problem you're evaluating what the impact could be before you move on to a control. Oftentimes as part of evaluating that impact you realize that a safety risk has a security impact or vice versa and then there's a direct point in both of those risk management frameworks where one can feed into the other or the other way around. So having those two distinct processes in place is a good way to address safety and security in tandem. Guest: You know there's another risk that I think about sometimes just because being on the quality management system side, one of the biggest reasons you would want a quality management system is traceability and you mentioned a few different assessments there. One of the things that we in medical device focus on the most, I feel like, is legal risk. So and when I say legal risk, I mean regulatory uh and I would I guess I would lump regulatory in with legal risk because like product liability for example. So you don't want anyone to get hurt, but we're looking at that through a regulatory lens. We're following the rules. We're going to be legally, you know, compliant. But then there's that ethical risk. We truly we actually don't want anyone to get hurt, so we're going to do some ethical things to make sure no one gets hurt. But then there's a third one that sometimes we don't always trace back to the company and that is you do that assessment once, you lose it in your Google Drive, someone else comes along, and you do it again. And so that's the third leg of the the company and you have that legal, you have the ethical, but then you also have the economical risks of having to do things over and over again or doing it at the end like you said and then driving it backwards. Um, so that's one of the things that I think we do a pretty good job of is making sure that the processes are a little bit more streamlined. So you do it one time and if it's done right, you don't have to do it as many times again uh or or redoing your work just because of lost or untraceable documents, but yeah. Anyway, I kind of took over. I didn't mean to, yeah, go ahead Christian. Host: No, as you're as you're mentioning that, there's something that comes up quite a bit. CAPA, a corrective and I think it's corrective and preventative, another acronym. We have so many acronyms. It's corrective and preventative actions, right? Guest: Yes, preventative, yeah. Host: Right. So, so that is typically in a QMS, is that correct? Guest: Yeah. Host: So can you explain like what that actually means when because my my impression is something happens, they have to show it, it runs through this process and how they actually take some steps from a quality perspective to make sure it doesn't happen again. And this could be a cybersecurity incident, it could be, you know, an electrical component that goes bad on the device. It could be any number of things, right? Guest: Yeah, absolutely. So, the CAPA is uh from the FDA perspective, it's part of uh 21 CFR part 820. and they have corrective action, preventive action, different things that you have to follow. Um, if you have a non-conformance or if you have a glitch, something that happens that uh needs to be fixed. It may be a one-off situation, maybe it's uh a particular user error and you do a certain root cause analysis and you think, okay, well that could probably never happen again. I don't know, you know, depending on how you do your analysis and you do a correction. So there's a correction, corrective action, preventive action to truly get the definitions. Now, I don't want to go too far down this rabbit hole, but ISO 1345 2016 is is harmonizing, um, or is or is FDA 21, FDA's part 820 is harmonizing with 13-1485. Those definitions go back to ISO 9001, which goes back to ISO 9000. So forget that if that was not helpful, but in ISO 9000, if you look at the definitions, correction is that uh that fix of the actual problem that broke. So something broke, you fixed it, that was a correction. Host: So you have to get to the root cause though and there's like the five Ys or the fishbone diagram or a couple of ways is that right? Guest: Absolutely. So that's where the corrective action comes in. So that's a a higher level. Now we're going to do our root cause like you said, um whatever the the fishbone, yeah, Ishikawa, etc. Um, I love 5 Y's. Whatever your your root cause analysis of choice is, you go back and then you put in those those corrective actions. Preventive actions, they're a little bit more um unusual I suppose. But it's more you look from the industry and the broader or across product lines and you see other issues that may be occurring and you apply those corrections to something that hasn't uh broken or or there's no issues at the moment but you're you're it's almost like an improvement process at that point. Host: So if we're doing cybersecurity there's a there's a product on the market it's already cleared by FDA or MDR. and we're doing post-market management. If there is a new vulnerability identified, that will run through the CAPA process, correct? From a QMS perspective? Guest: It could. So, uh if there's, I can see that going through the CAPA process. If it's just a new vulnerability identified, it could just go through the design controls process. and uh um, I could see that being an evaluated as a a change to the product itself and just apply typical risk management processes to it. But Host: Okay, so it would just be a a design update versus, I mean we you have to get the root issue anyway like we I mean we do post-market management so if an incident comes in or a reported incident we have to determine if it's a a true positive or a false positive. So we do some of that I guess analysis initially before and then the recommendation would be a change to a configuration or or into design update. Guest: Okay, yeah. I think I missed the part like you see something in the field. Yeah, yeah, I would I would expect that to go through a CAPA. Host: Okay. So, it's an especially big concern with hospitals. I mean, you know, I'm sure you guys have heard about the United Health Care breach and then various ransomware attacks against different hospitals and it seems like there's one that pops up every couple of days at this point. So, a lot of that is through an insecure component or a network device. Um often times it'll be like a firewall or a printer has a problem. You know, we've done a lot of penetration tests against hospitals and anytime I find a printer on that network I have pretty good luck getting into it and I've gotten in through X-ray machines, MRI machines before. You're able to cause a lot of damage with an unsecure medical device. So, hospitals don't want to introduce that level of risk to themselves. They have to remain HIPAA compliant and they have to go through their pen tests and if they get results back well this device is inherently insecure. They aren't left with a lot of options. So they want to try to cover that bridge before the problem comes up. That's an interesting point you bring up. I don't know that I've heard someone tell me that about cybersecurity specifically because it's just my own ignorance so that's really interesting to hear. But what's interesting is it kind of parallels very closely with clinical investigations. So I mean GreenLight Guru has a clinical arm and we talk to a lot of medical devices who need clinical investigations. Typically with a 510K you might not need a clinical investigation, but just like you said it's the the hospital, the clinician, the clinicians themselves may want that clinical evidence that your product is viable and may, you know, show that has a little bit more capability than the competitor product. So just to get to to market in a certain way, uh you may not have to do certain things, but I think that's really interesting that you point that out, that's a really good point I think. It's an especially big concern with hospitals. I mean, you know, I'm sure you guys have heard about the United Health Care breach and then various ransomware attacks against different hospitals and it seems like there's one that pops up every couple of days at this point. So, a lot of that is through an insecure component or a network device. Um often times it'll be like a firewall or a printer has a problem. You know, we've done a lot of penetration tests against hospitals and anytime I find a printer on that network I have pretty good luck getting into it and I've gotten in through X-ray machines, MRI machines before. You're able to cause a lot of damage with an unsecure medical device. So, hospitals don't want to introduce that level of risk to themselves. They have to remain HIPAA compliant and they have to go through their pen tests and if they get results back well this device is inherently insecure. They aren't left with a lot of options. So they want to try to cover that bridge before the problem comes up. Host: Yeah, I think we're we're running up on time here. So, uh, I just have a couple more questions for you, Etienne. Like uh, I know you guys call everyone in your company gurus, is that right? Guest: We have a subset of people who work at our company called medical device gurus. Not everyone wears that name, but uh what we do is we hire people from the field who, we have ex-project managers, product development engineers, uh quality engineers, human factors engineers, we have a lot of different people who have worn different roles or wore different hats in the industry. And so now what they do is they help companies uh who are coming on board the software and then understand the regulations behind the software and why things are the way they are to make sure that they can be successful. So yeah, it's a fun group. They're very passionate as well about what they do. They love the customers. Host: Okay, that'd be like our company calling everybody goats. Guest: (laughs) Some people probably wouldn't have a problem with it, but I don't know, maybe maybe someone might not like that. Host: Right. And then where where's the name Greenlight come from? Guest: It's a good so Greenlight, we really just wanted to uh greenlight operations for people. We wanted people to just be able to just keep going on to the market and then and then be on. So, we don't want you to have to hit the red lights of regulation. Host: I like that. Cool. Awesome. So where could people uh find you and find uh Greenlight? Guest: Yeah, if anyone's out there who wants to learn more, uh we like I said we put out content every day. www.greenlight.guru. I will say one other thing, if I may, plug a survey that we're doing right now. Um, we do a survey every year of uh the industry. So we call it the the state of Medtech industry survey. So 2025 is coming up. Last year we surveyed 613 Medtech professionals. So we're hoping to beat that this year. And uh so I don't know if we could put a link in the show notes or something but I'd love it if your if people in your audience would be interested in in fulfilling or filling out that survey. Host: Yeah, we can drop a link in the show notes for sure. Guest: Really appreciate you guys having me on, this has been fun. Host: Yeah, thanks for uh for joining us on uh another episode of our podcast here. Any final words of wisdom? Guest: No, just... stay cyber secure and make sure that your QMS is buttoned up. Love to uh and maybe someday I'm going to have to talk to more uh Trevor more about TR 51? Is it 51? Trevor: 57. 97 for post-market. Guest: Okay. Okay, more acronyms. Yeah, more acronyms, we'll talk about all the acronyms. Host: We'll do a separate episode just on the acronyms and unpacking those. Guest: Unpacking Medtech acronyms. I think it would be pretty, pretty successful. No, yeah follow me on LinkedIn. I'm always trying to put out additional um content there as well. and uh yeah, I'll uh hopefully I'll see you guys at uh an event coming up before too long. Host: Awesome. Well, thanks again for joining.