Invisible Risk: Cybersecurity Mistakes That Stall Market Momentum | LSI Asia '25

Trevor Slattery  0:05  
So we can start off with some introductions on our side, I'll hand it over to you first, Hima,

Hima Chetty  0:10  
thank you, whoever so I'm Hima Chetty. I'm Principal Consultant at CS life sciences. I work with software and hardware devices, doing quality and regulatory strategy to technical documentation for market clearance in FDA, UK, EU and also in Asia.

Sean Lavin  0:29  
Sean Levin, alpha Levin, advisors. I've spent the last 19 years working on Wall Street in various roles, with the last five years or so, helping early stage companies raise capital and potentially look at various exit

Trevor Slattery  0:40  
strategies. I'm Trevor Slattery. I'm the Chief Technology Officer at Blue goat cyber. We handle cybersecurity testing and regulatory documentation for Medtech device manufacturers. So one question I know that it's not always very common knowledge how prevalent cybersecurity problems are, and so I would just like to ask around who is aware of what is required for cybersecurity if you have a medical device. Yeah, 123, well, they work with me, so that's cheating, but it's a pretty big problem. And so one thing that I believe is a very big issue is a lot of manufacturers don't understand what their timeline should look like with cybersecurity, a lot of different things, your biocompatibility, your clinical studies, you set a little roadblock, and it's part of your roadmap. For your product development, you have a certain set of time to do it. But cybersecurity, you can hear a lot of opinions on when is the best time to start looking at cybersecurity. So I'm interested to hear your thoughts on where you should go with cybersecurity. When should you start thinking about this as a Medtech Innovator?

Hima Chetty  1:46  
I would say, from my experience working in big Medtech firms like I used to work at Philips healthcare and also now working with startups. For startups, I all have big companies as soon as you can. But I think the main important item that everybody should consider is to make sure that you have a good regulatory strategy. So you should include cybersecurity in that. What are the timelines? Because I think innovators are busy getting funding and trying to get the development in action. So software development gets the most amount of attention, and people do not integrate cybersecurity. It goes hand in hand. It's parallel process, so it should be considered as you're developing your software, not after you finish developing your product and you're ready for submission. That's like late already, and we see lot of examples with the clients we work with. They have developed a really good product. They're like, we are ready to go submit. And if you look at the FDA, the list of requirements for their submission, it's four times what it was, and so you have to be prepared. It's not just writing documentation, it. It also requires you to constantly maintain those procedures in place. So, for example, I had a client who had market clearance in 2022 and the guidance document for the FDA cybersecurity was published and finalized in 2023 so they were very confident that they are okay, and they had a major design change. The AI model was updated, and they were doing another 510, K, and they said it's already cleared. We have not we have done pen testing. We think that's enough. They went for it. And we have 16 findings in the deficiency report from the FDA on cyber security alone. And these are the kind of things you want to avoid, because now they are on a timer. Essentially, you have 180 days to go back to the FDA, and you don't need to be in that spot.

Sean Lavin  3:54  
So I've been asked to speak on a lot of panels in the past. This is the first one I've been asked to speak on where I know very, very little about the subject matter, which, which I think sums up why, why we're here. And I mean, companies should look very early. I probably talked to two or 300 companies each year that are and they all have ideas on the FDA path. They have ideas on reimbursement. They they know what their trials may look like, or how many patients they're going to do. I think cybersecurity has come up maybe once in the last two years on that conversation, which, you know, I think is a big part of what they're doing here, and I think it's gonna be very important to early stage companies. I remember the, the only time I can think of investors really focused on it was a 10 or 12 years ago, a large pacemaker company had had an issue, and there was kind of a break in our hack, in their cybersecurity, and that, you know, we probably talked about it for three months, and then it, then it went away again. And so it's and so it's, you know, now we're seeing the FDA bring it up. And I, I think early, early and earlier is the right answer. Yep. Have a

Trevor Slattery  4:49  
sort of anecdotal story that was following along. What you were saying. Hema, we were recently working with a manufacturer that was doing a resubmission. They changed a lot of functionality in their product. Added some new network connectivity and new interfaces, and they sent me their previous cybersecurity packet for the FDA. It was a one page Excel spreadsheet, and the updated packet that they sent into the FDA was not quite enough for the FDA to clear it. They came back with, I think, 14 deficiencies, and we just finished two months ago, a 360 day long review cycle. They came to us on the second wave of reviews, and we were able to get through after all that effort, but by the time it was all said and done, their cybersecurity packet was getting close to 700 pages long. Yes, yes. So they just didn't really have an idea of how significantly the landscape had shifted for cybersecurity and medical devices. They started too late. They already had this preconceived notion of how they could handle it. A lot of med tech companies will put their IT security team on handling the cybersecurity requirements for their device. It's a very different landscape. It's very different timing, and both of them need to be a continuous process. But I think that's still something that is evolving in the med tech space, is that understanding and some of that awareness? Yeah,

Hima Chetty  6:10  
I to add to that to Trevor, what you're saying that's absolutely right. Also small starters or mid size companies don't have a separate security team, so you need to really know who your experts are, and if they have gone through the FDA process, can they actually help you? Because software team cannot write your security documentation needed by the FDA, so you need to find good experts who will help you to do the documentation for you, definitely.

Trevor Slattery  6:39  
So I know we briefly mentioned it a little bit before, but one thing that I always like to hear about, especially when talking to investors, is understanding what a company's roadmap looks like. Obviously, that's a very major important point. Anytime you have a new startup you want to show your investors, you have a plan. You have a set amount of time to do things, but pushing into the story I just talked about this was a very large strategic they were able to weather the storm for a year. And so what are some of the risks that can come up from mishandling this on your roadmap, trying to push it to the end, and having delays that come up from that investor standpoint?

Sean Lavin  7:14  
You know, I would say almost all, or all funds dislike surprises, so it's a project usually is not unfundable Because it's too large or it's difficult. It becomes unfundable If dates get missed, or if trials don't get done on time, or if the FDA approval is supposed to be in 2025 and it moves to 2027 and when, when a company has to go back and raise the same capital second or third time because something didn't get accomplished that usually the value goes down, becomes, becomes much harder. And so I think this is going to be a surprising area for a lot of lot of both investors and companies. And I think it's something that should certainly be looked at and should build in. You don't want to, you don't want to find out three months before your FDA approval that you have a nine month project or a year project to work on. You're much better starting two or three years early and and going as you go. So I hopeful more and more companies will recognize that, and I think they will, but it's gonna it's gonna take time for that to happen. Yeah,

Hima Chetty  8:09  
I think education in on this topic is quite important as well. Every time I talk to innovators, they don't know about cybersecurity or they know and they think that it's some sort of documentation that needs to be done. Towards the end, they don't know how long it will take. So they don't tell investors the money is not accounted for, how much they will have to spend.

Sean Lavin  8:31  
I'll ask one. I mean, so an investor came to me today and said, I saw you're on this panel. What companies need cybersecurity? And they kind of went further and said, Is it, is it? Is it somebody who has a connected device? Is it somebody who has a zip drive, like, if, if I make a pacemaker that never talks to anything? Do I Do I need it? And that's, that's a question that, that's a very basic question that we need answer.

Hima Chetty  8:51  
Yeah, exactly. And I think that's where you have to be aware of what the standards are out there, what are the guidance documents out there, be aware of, you know, train your teams internally, or come talk to experts who will help you. You know, it's so fast moving. There are guidance documents published by the FDA all the time, and you have to keep up with it, and it's hard, because when you are trying to develop a product, the last thing you want to do is read pile of guidance documents and standards. So yeah,

Trevor Slattery  9:22  
one thing that on the topic of the guidance documents is staying up to date with them. Little bit sneaky from the FDA, honestly, but before they'll finalize a guidance document, it goes into a draft publication, which is what just happened with this AI guidance as of January, they'll get feedback from the community, from independent reviewers, and then they'll make any changes as required, and then finalize the documentation. Now, one thing that I feel like often gets overlooked when trying to think about a regulatory strategy or that documentation is estar which is the submission template for a medical device going to the FDA or going to healthcare. Canada can change without a review cycle, and it does all the time. We're on version 5.4 or so of v star now. And so sometimes they'll take a look. And oftentimes, when I'm talking to a manufacturer, they'll say, Well, we read this in the FDA guidance. Why do you think we should do it this way? And say, Well, what we're creating is it has to be on the bleeding edge of what's required from the regulators. What's the bleeding edge is this unfortunately unreviewed estar template, which changes and has a little bit of a disconnect from the FDA guidance document, so staying on top of things like that, understanding when are we going to move into version 5.5 of estar? What changes are going to be relevant? As far as cybersecurity, it's all very important stuff to talk

Hima Chetty  10:41  
about. Yeah, agree. I also had a lot of issues with the understanding of what is needed for each market, because FDA have the most stringent requirements for cybersecurity. And you're not going to just one country, right? You're always selling in multiple countries, so you have to be aware. So when you do your regulatory strategy, when I prepared regulatory strategy for my clients, I consider the country, what is the classification of this device in each country? Create a list of standards. What do you need to do on each topic? If you have aI models, if you have software development, you try and minimize and I think this is one point everybody misses, because everybody wants the product out as fast as possible, but they all go hand in hand, you will save so much time by doing and thinking about all this upfront. And especially for you, I would like to hear your thoughts, because every company that we work with they they don't want to read the guidances. No one does. It's most boring job ever, but I always come across we don't have the budget. Our investors have given us this much budget, and we so we are not going to go to EU. Or can we drop this feature because we have a USB port, so now we will have to do cybersecurity we don't want to do because we didn't consider so people are reducing features. People are taking away, you know, connectivity, because they now realize that, and it's not the product that the investors have been told about. What are your thoughts? Shawna,

Sean Lavin  12:12  
you're you're right. I had dinner with a CEO from robotic company, and he said to me last night, I mean, away from cybersecurity, you never launched the product you actually want to launch, whatever you can get to market so that you can raise the next round, or you can get acquired, and somebody else can build the second or third generation that that will actually be commercialized. And so I think in this case, if, if, if companies were given the choice, they they would not worry about it, but they're, they're not gonna be given the choice. And so I think as they, as they learn, the FDA and other other governments around the world, I mean, one person said to me, I, I don't want to me, I don't want to be arrested when I go to certain countries, so I want to do this, right? You know, I don't think anybody says, wakes up and says, I really want to do cybersecurity, but it's Amanda, it's like, it's like, getting a driver's license. And so I think that company is going to have to build that budget in. And that's, you know, that's why I kind of asked at breakfast today, or what is the right budget? Or, what should, you know, should a company be thinking it's half a million dollars? Is it $5 million dollars, $20 million like, what is the scale of what they need to to build in? I think the sooner companies can learn that, I'm sure there's a wide range based on what what they're doing, the sooner they they can plan, and funds can plan. And I don't think funds want to, want to miss deadlines or miss numbers, but if they don't, if they don't know they're gonna, they're gonna miss them, yeah,

Trevor Slattery  13:20  
I think the only way to entirely avoid cybersecurity is to put your device in a box and bury it in the desert and then no one can connect to it. No one's gonna hack into it then, but not getting much use out of that. So you mentioned briefly that some devices are moving towards as they're evolving. Of course, you know, everyone wants to talk about AI, that's the hot topic on just about every industry, especially in Medtech as well. I feel like this is similar to when mobile apps were becoming super popular in 2008 when healthcare apps became regulated by the FDA, and so before there would be a companion app, it was largely just a marketing ploy at that point saying, we have a companion app. You know, we have a companion app, and then the FDA says, Well, if you do have a companion app, now, here is everything you have to do under the regulatory approach. I think the AI regulation is still in its infancy, but we're getting there pretty quickly, and I know that the draft guidance for AI and cybersecurity was published in January by the FDA, so it'll likely become finalized guidance pretty quickly, which is something that an AI enabled device and AI enabled manufacturers need to be aware of. There is a whole other string of documentation and guidance that is about to become a relevant concern. Curious to hear your thoughts on how that's

Sean Lavin  14:35  
gonna remember the the app days. I mean, I remember early on in the app days, companies didn't know they didn't understand it. They didn't understand it. They didn't know what to do about it, and many companies went away from using phones. So they would build their own, because the FDA had various rules that weren't entirely ironed out, they would, they would build their own connecting network, instead of using an iPhone or study using whatever, whatever the phones were that were available then and then over, you know, three to five years, everybody converted to using phones because customers and patients. Want to Carry, carry two things. I I suspect a little bit that is going to happen here. The companies are underfunded, and they're they're going to try to find ways to, if they can't afford the FDA, they're going to go to Europe. If they can't afford Europe, they're going to go to the Middle East. They're going to try different things, but, but ultimately, something is going to be settled as a norm, and then everybody's going to follow

Hima Chetty  15:18  
it. Yeah, yeah. And that's a good point, Shawn, because they can run from it, but all the markets will catch up, usually, if they set the expect expectations. So in EU now, as you mentioned about AI, everybody wants AI. It's the new buzzword. I hope cybersecurity becomes the next where AI is the new buzzword. Everybody has AI and it, it's it's everywhere. And the biggest challenge I find is that there's not enough from the regulators on it. FDA have been publishing some guidance, but if you're going to sell in EU or UK, there's not enough guidance from the regulators. So we are still in process. Also, I am on a Standards Committee, not on the AI, but they're still in process of creating and writing and finalizing the AI standards. So that will also come in sometime, but in 2028 you know, that's far away, but you have to be prepared for that. Ai models. It's it's quite difficult. It's already a new, novel technology. FDA are quite strict. They need human in the loop. You cannot have autonomous AI, and everybody's expecting we will do risk assessment, and everything should be good, but it doesn't end there, because AI models can also go through data poisoning. Somebody can actually change your model, and then the output is still not the same. You still have to consider cybersecurity related risks for your AI model. And people often disconnect the AI model from cybersecurity, but it should be considered as a system.

Sean Lavin  16:52  
I'd also add, you know, how long does cybersecurity go so the small number of our companies that do bring it up for talk about it. Talk about it in terms of regulatory in terms of, if I do this, can I, can I get the FDA approval? Is this what the regulatory wants? If you have servers and you're in different countries, and there are different rules, I assume you have to keep these things secure long term, and that needs to be in the budgets, and that needs to be in the plan. And it probably isn't just a the day you get approved is probably also, I would assume, checkups and future looks from you got to keep this data secure, and so I think companies gonna have to budget for that. I don't don't know what that cost per per month or per server, but, but it's something that is going to need to go to budgets

Trevor Slattery  17:31  
the FDA wants to see, and really it's expanding into other regulatory markets as well. They want to see that continued total product life cycle for security. So even getting through great you've been cleared by the FDA. You get your substantially equivalent for your 510, K submission the FDA wants to see up until you plan to decommission the product that you have cybersecurity covered. I think with AI specifically, there's so much it's evolving so quick, at a rate that is rarely seen even in the tech field. And cybersecurity is trying its best to catch up, but every day, I try to stay on top of what the latest trends are, the latest attacks and what you know threat actors are trying to use as far as how they're exploiting attacks, so that we can do it better than they can, and seeing how AI security evolves. It seems like every time I turn around, there's a new vulnerability that someone's discovered in a in like an LLM, which are largely newer concepts. AI has been around since the 90s, but this modern AI that we're seeing is so rapidly evolving, cyber security is having a hard time catching up of what can go wrong, since it hasn't been run through years and years and years and years of testing and validation to understand what the problems can actually be. So I think that cybersecurity changes regardless, but as the technologies become a little bit more established, we might see a little bit more of a solid framework. Even reading the draft guidance for AI, they're listing all of the vulnerabilities that they want to see covered in when you're doing your testing, and that was only six months ago, and since then, I've seen probably four main new groups of AI vulnerabilities that have been released, discovered by independent security researchers that the FDA still hasn't updated into the guidance. So

Sean Lavin  19:14  
what backup? What are large companies doing in terms if something goes wrong? Right? I mean, companies think of you're doing your best to make things work well. You're using AI to try to have better results. But there, there are bad actors out there. If somebody manages to get in or manages to make AI work against you, what does it turn off? Does it stop? Like, how? What should a company be doing to to block a bad result with patients? That

Hima Chetty  19:35  
is a good question. Sean, in many cases, they might not know till there is a complaint in the system, and that's really scary, because bigger companies have dedicated security teams, and they're constantly monitoring I remember the first day of me joining Philips, the security guy was really worked up and really scared, and I was like, what happened? And he was like. Somebody left developer flag open on in our test environment, and somebody hacked into it. And I was like, What do you mean? And he was like, Oh, we get attacked, like, at least 1015, times every day and everywhere, our website, products. And I was like, really? He's like, Yeah, these don't get reported, don't get talked about, and it's constant, so, yeah, I don't know. Trevor, what do you

Trevor Slattery  20:23  
think? So before, I was far more focused on medical devices, I was doing a lot of security testing with hospitals and industrial control and automation systems. And I won't even begin to get into the hospital hacking horror stories. It's bad every single time. But these networks are just inherently insecure, and most products in general are inherently insecure. It's something that requires an extra layer of effort and a team usually dedicated, especially in a larger facility like a hospital, where you can assume you have hundreds, if not 1000s of employees. For every employee, we typically assume at least 2.5 connected devices, and so you're quickly getting up to you can see, often, 10,000 different devices connected to the internet in a hospital, and all it takes is one to be the weakest link. So on average, every single healthcare delivery organization in the US, on average, experiences 10 cybersecurity attacks a day, obviously not necessarily successful ones, but attempted break ins, 10 a day per healthcare delivery organization. So it does become a shared burden between the manufacturers and the HDOS, which will sort of tie me into my next question. Moving through the regulatory process is one thing understanding what the FDA wants to see, the nmpa, mdfs, wherever you're trying to submit, but after the fact, the hospitals are taking on liability if they bring in your device. There was just recently a very severe ransomware attack at a blood center in the UK where they were able to directly tie ransomware to death from treatments not being able or patients not being able to receive treatment. Receive treatment. So hospitals are getting, often, even times more strict than the regulators when they're talking about what the cybersecurity requirements are. So moving down past the regulatory side of the roadmap, moving into that, you know, getting acquired by insurance, moving into an HDL. What are some of the concerns that will pop up there, and how can manufacturers be a little bit more prepared to move into that phase of their product? Yeah,

Sean Lavin  22:29  
not sure. The concerns. I'm not surprised. We're seeing hospitals that are harder to get into than reimbursement or the FDA. So so often companies will will get their approval, they'll get the reimbursement, but it'll take two to three years to get to a hospital, to make the hospital any concerns or where they view the product safe, and nothing's gonna go wrong. I'm not sure how to how to alleviate that, but, but that that is happening at the hospital level? Yeah,

Hima Chetty  22:52  
100% and you you can see that most of our clients, they don't, again, comes back to planning and strategy. They don't think where they're going to sell and who they're going to sell while they're in development, and they don't ask the right questions. And so we had a product that went through the FDA. Everything was fine. They had their codes and everything, but then they got the requirement of, Oh, do you have SOC two? And they're like, No. And now they're sitting there thinking, how can we get SOC too and high trust? And you know, people are asking questions like, do you have cyber essentials to your 27,001 and these are the things that don't they are not thought about. They're an afterthought, because, again, it's lot of procedures being put in place. You need an infrastructure to maintain it. So I'm seeing a lot of these companies who are trying to sell the products, I think, asking your end users, what are your requirements to be able to sell our product, or even if it's a home health care environment, which is even worse, because there's so many connected devices at all, right? You need to think about that

Sean Lavin  24:00  
a different way. So companies that are in planning products, they have a certain path they go down to at hospitals. But when I talk to more software companies or companies that need to be within the IT system, they will say it's multi years every every major hospital. It's 123, years of working with the IT team to be accepted. Is there any way to get to a standard process or a standard level of security, that instead of having to talk to, you know, 1000 or 5000 hospitals, and each one has a different requirement or different thing you have to do that, that this could become the norm, you know, three years from now or five years from now, so that companies could just do one, one thing. Well, there

Trevor Slattery  24:34  
are pushes to move in that direction. There are different guidance documents, or not necessarily guidance documents, but frameworks such as the joint security plan or a single deliverable like an MDS two form, which are generally accepted by hospitals. But then you're moving into these areas, like SOC two, high trust, 27,001 and for starters, those are all very expensive to become compliant with, getting a consultant, getting audited by a CPA, getting all your. Penetration testing, it takes a lot of time. It's very expensive. If your consultant comes back with a lot of deficiencies or the auditor, then it's going to take a lot of time and a lot of man hours to remediate those problems. So I think that you bring up a great point, start at the end and work your way back. Understand who your addressable market is, who are you going to sell your product to, and understand what they're going to want in advance, and even looking at different HDOS, like understanding what John Hopkins requires, as opposed to Mayo Clinic, are vastly different, even though they're effectively doing similar things. So trying to figure that out, and it takes a lot of planning, you don't necessarily know well, this is every hospital that we plan to sell our product to, but trying to figure out at least what you can do for your baseline. It's like you said, No one's ever selling the product that they plan to create. No one's gonna go exactly where they wanted to go, either, but getting a good baseline and then trying to go from there. Yeah. So one other thing that is a very hot topic in regulations, in general, everyone's trying to wrangle away to understand this is legacy devices and legacy medical devices. Now, legacy devices are effectively thought of as any older medical devices. They can essentially be anything before the current 2023 guidance. So a legacy device can actually be a fairly recent product. Now, since the current cybersecurity guidance does not apply to those legacy devices. They were cleared under the previous guidance, and they already have their substantially equivalent marks, and they have their 510, K approval. There's a little bit of a question on, how can we round up these devices? How can we try to address security and from a regulatory approach, it seems very slow, and it's trying to understand more how to reduce the risk on some of these devices. A lot of hospitals are trying to reassess legacy devices and understanding that these devices they previously had are now not going to meet their same current requirements. So curious to hear on what you think, as far as handling an old, unsafe product that has been integrated so deeply into a system now that the HDOS and the regulators are trying to roll back what they

Sean Lavin  27:10  
had, it's a good question. We saw something similar, probably 10 or 15 years ago, where the FDA took a number of devices that had been approved many years ago and said these, these now require PMAs, and these were things like ECMO machines and things that hospitals rely on. And a number of the companies said, we don't make enough money. We don't make any money on these devices. We essentially break even on them, and we do them because we saw other things. We're not we're not going to run prema trials. And it went on for five or six years with the FDA. And eventually they, they use registries, and they they made agreements with certain companies, got different agreements and, and most things were left on the market over, you know, a decade of work in multiple different ways that they got there. I I think we're going to see some of that. I think there's going to be products that companies are going to simply say, I'm not going to upgrade, or I'm not going to change it, and it's good enough, and I'll sell it till they make me not and, and I don't know if that government doesn't move real quick, and so it will probably take a while, and I don't know the answer, but I don't, I don't think every device that has any connectivity is going to going to be changed tomorrow. So there's gonna be good, good actors and companies gonna be bad actors, and something in between. And I'd love to hear kind of what you think is gonna happen with these devices that are sitting there and not

Trevor Slattery  28:15  
secure? Yeah, I think it is. It goes back to that shared burden between the HDO, the user, the manufacturer, trying to assign what level of burden and what level of responsibility is very difficult in a case like this. And I'd imagine that the regulations, regulations are slow to evolve. Guidance documents are slow to change, but they will catch up in the same way that currently, the panic has to try to get caught up with AI before AI runs rampant. And I think that that was a very strong push for a while handling these legacy devices, it seems to have faded to the back burner, as far as a conversation point, but I do believe that we're going to see some regulations become more strictly enforced. Some of these manufacturers with legacy systems are going to have to go back and recertify their products within the FDA. One way that the FDA is effectively allowing the problem to resolve itself is previously, if you made an update to your device, you submit a new 510, K, you don't have to do anything for security. Again, it's fine. Now, if you have one of these legacy devices and you decide that you wanted to change the indication for use, you wanted to make a small tweak as far as how it works and how it operates, a significant enough change to alter what the actual use case of the product is. You're going to have to go through the 510, K process again with the same product under the new guidance. So there is an effort under that lens to try to resolve it, but it's not an effective rule that you must take your legacy products and recertify

Hima Chetty  29:43  
them. Yeah, I agree. You don't have to go and recertify them just because the guidance was published. I would say it's a really good time, though, to start working on, looking at the guidance document and reverse engineering some of your requirements, and also checking if you if you can do threat mode. And risk assessment and see if there is something that is high risk, and is your product vulnerable to one of these attacks, then do something about then you can go to fda, do a preserve, ask questions. They are really receptive. So I find that I've done so many presumes with some of these legacy devices. This is what it is. We can't just take it out of service. We can submit new submission, but these are the design changes we'll have to make. It will have to be a significant change, so we'll do a new submission. Are you happy? This is our strategy. This is how we are going to fix because we have to remember FDA do allow list of anomalies to be left. If they are, the risk is really low, right? So you can, and this is why it's important to do all your cybersecurity documentation. Catch up while you your your product is still out there. Just catch up and do your homework. Have your questions written down. Go do a precept FDA. Don't charge for a pre sale. You can go to the FDA, ask those questions. They give you nice written feedback, and you can do an art teleconference as well, and that's what I do. And you know, because, as you said, Trevor, it's evolving so fast, even FDA stands on what kind of how they're going to approach. Findings on each device changes every time I see that, they give me different response on AI products,

Sean Lavin  31:20  
I'd ask, are there any government programs working on this? Because we think of the large, very profitable med device companies, but, but of the approved products out there, probably 80 or 90% of companies are actually losing money at this point. And so even if they want them good actors, they don't, they don't have the ability to do this in many cases. And so I'm not sure if the answer is, but, but if the hospitals in government want these things to be safer, someone's gonna have to pay for and there's a time between where, where the venture guys have funded a company and the products approved, and there's, you know, three to five years where the company's not making money and that that company doesn't have the ability to fix these things, right?

Trevor Slattery  31:52  
Yeah, yeah. And those, you know, that's a really critical time frame. And since it's so recent, it's only really been about a year and a half. And so a lot of companies might get frozen. We work with a lot of companies that are going through an iterative cycle. They try to get their MVP out, something that they can get through reimbursement, get into a hospital, prove the concept, and keep building on it. Maybe they'll have a limited functionality, build it into a network, connected large infrastructure product, and then see how they can continue scaling it. But that approach is obviously going to be costly. It takes a lot of time going through the regulations. You need to redo a lot of your testing each time around. So some companies might get stuck if they weren't coming in budgeting for however much they needed to plan for their cybersecurity from the get go, since when they started this in 2021 2022 it was the draft guidance at that point, but it wasn't an actively enforced regulation. So a lot of manufacturers were choosing to skip it. They didn't have to integrate it into their products. And now moving into their second cycle, into their

Sean Lavin  32:52  
third iteration, and they didn't start then. I mean, the average device is 10, you know, 10 years for 510, K, 15 years for PMA to get to approval. So, I mean, these companies that are on the market today started, you know, 1010, plus years before this guidance document.

Hima Chetty  33:05  
Yeah, it's also important that I notice in legacy, if they are, like, really, 1015 years old, then there is no way, because now there are a lot of components that you can't do anything about it. Windows have stopped supporting and doing patches for their operating systems. And so you lot of people wanting to move to Linux systems, right? But it's going to be expensive. It's going to be full redesign. So bigger players are deciding to develop new more products, and for smaller companies, it's quite difficult. So I would say it's really good for startups to think about what are the components that are end of life and do not use those to begin with. What are the components that are in the CVE database? And you know, if you can already keep up with that, and S bomb is a good way to do that. And, yeah, that's the only way I see legacy devices being managed.

Trevor Slattery  33:59  
I've seen a lot of products that, you know, it is a very long development life cycle. And so they started creating their product 10 years ago. They're finally coming in, getting ready to finalize it, and look, and I say, Well, this, you know, this bit of your code hasn't been updated in six years. Let's take a look at what's going on. And oh, every single package you're using in here is insecure now, has been proven vulnerabilities. And, you know the core concept that these are built on, and so then we have to go and redesign encryption. Is a very big point where this comes in a lot if there's a specific encryption use case or a specific encryption library, as computing evolves, certain previously accepted encryption algorithms are no longer acceptable. And so we'll see sometimes that you're using MD five or triple DES, which you know at the time when they started creating this, that was acceptable, obviously, now we need to definitely step

Hima Chetty  34:49  
it up. Yeah, and to add to that, Trevor, that's a good point, even with pen testing or the final v and b, when you're doing cybersecurity documentation, sometimes you do your. Pen testing, and then you make changes, and people think I did it two years ago. It should be fine to submit. It's not in two three months. Forget about two years. There would be new vulnerabilities that are published. You have to keep that in mind every time before submission or your product life cycle, you have to at the end of each phase, I would recommend just run a test, you know. And, yeah,

Trevor Slattery  35:25  
definitely. All right, well, it looks like we're coming up on time here. I want to leave a little bit of time for there to be any questions. Yes,

Audience Question  35:37  
yeah, thanks. Thanks. Ray pedal and really great conversation. I took questions, maybe that you could elaborate on, versus, you know, from regulatory perspective, yeah, from a regulatory perspective, how should innovators think or differentiate between devices, s, AMD and services as they're developing. And then, you know, I think Trevor, you alluded to, you know, dependencies and implementation, right? Hospitals that are implementing med tech into their stack have some responsibility as well, how regulators thinking about that? Thanks.

Trevor Slattery  36:21  
Let you take the first part

Hima Chetty  36:22  
of that. Yeah. So SMD has clear definition in the FDA, right? So if your product has medical purpose, it's, it's, it's part of medical device definition. So, and you asked me about services so, and can you give me example of services like

Audience Question  36:43  
you know, like patient scheduling software that may handle medical

Hima Chetty  36:49  
data. Very good. Okay, so they, they are mobile apps that I used. They don't have a medical purpose, so you have to differentiate. The main differentiation is, it needs to have a medical purpose, so it's either treating, alleviating a disease, preventative. And so you have to look at the definition and you differentiate. So these for scheduling apps, they don't fall under the definition of medical device, so then they don't come under all the scrutiny from the regulators.

Audience Question  37:17  
Thanks.

Trevor Slattery  37:18  
Yeah. And when you're moving into the HDO, and you're thinking about any of these considerations, as far as the big one is interoperability, getting into that HDO, how are, how is your device going to interact with everything else? One point that I mentioned, you know, they're going to be up to 10,000 maybe even more, connected devices within a hospital. Really, all it takes is a single weak link to cause problems. So what level of interaction does the medical device have with the rest of the network? If around 95% of organizations use Windows Active Directory, and so is your device integrating into that Active Directory? Are you utilizing those Windows services? A networked device doesn't necessarily have to mean that it can connect into an Ethernet cable, move into your active directory domain. The FDA will define something with a Bluetooth connection as a network device. So understanding what the application is, what level of risk, if you don't have anything sensitive, no credentials stored on the product, you're going to be a little bit less concerned on that interoperability lens. And so when you're communicating with the IT team at the HDO, these are the maximum risk that you're identifying during your regulatory process. Is something you want to convey to them and say, This is what we identified as any of our it's actually an FDA requirement, the multi patient harm scenarios. How can you cause harm to multiple individuals or products with a single compromise?

Audience Question 2  38:41  
Thank you. One question I have for you guys is in terms of the phi, you know, which is a big issue about collecting, you know, personal health information. If you are not a software as a medical device, but you are collecting phi, connecting with wearables or software as a medical device. How do you define that song, that you are collecting the phi from a wearable device, but you are not a device, because you are the software. You're collecting the data through the wearable. It's a great zone. So in that interoperability, in that integration, how you define that, how can you work with the regulatory agency, say, I am not the device, I'm just the collections, you know, I'm just the software collecting the data. I'll

Hima Chetty  39:36  
just say one point, and then Trevor, you can carry on. I would say, is the wearable a medical device? Is it? What is the wearable a medical device? In that case, they're working together as a system, right? Well,

Audience Question 2  39:48  
they're separate. They can be separate. Lemme give you an example. An imaging technology is the one who is collecting the images, but then it's transfer to. A electronic data capture or any other system, and then they together create basically a report for the physician, right? But they're separate systems. How do you manage that? They're separate entities. There are separate products. How would you manage that?

Trevor Slattery  40:22  
So if you're not classified as a medical device, it may be the case that you're instead considered an MdDS, a medical device data system which can handle medical data without directly being a medical device, and being further exempt from that, then it's likely just going to fall under HIPAA regulations in the US, GDPR in Europe. So that's when it's a great time to meet with the FDA and say, Are you going to consider us an MdDS? Are we just simply General Data Store How are you going to classify that? Since you don't need to be an MdDS to store PHI, you can store PHI and a lot of elastic web services, even through AWS or through GCP, and a lot of these come out the box HIPAA compliant, but then you really need to lean into that HIPAA compliance and so ensuring that your product safe, or that's when you can also be a great idea to look towards something like SOC two, which is great for securing A cloud based solution.

Hima Chetty  41:21  
I think that's the end of the panel. All

Trevor Slattery  41:23  
right. Well, thank you so much. It has been great conversation. Thank you. 

Hima Chetty  41:28  
Thank you, guys.