Overcoming AI and Data Security Challenges in MedTech with May Lee | Ep. 37

Hello and welcome back to another episode of the Med Device Cyber Podcast. Today, we are going to go over some of the global regulations and requirements, as well as talk about some pretty interesting things regarding what the future of medical device cybersecurity looks like in a post-quantum computing, encryption-breaking era. I'm your co-host, Trevor Slattery, joined by our co-host, Christian Espinosa, and we have a special guest from CS Life Sciences, May. How are you doing today? "Really good. Thank you for the invite." "No problem. Where are you coming from today, May?" "So, I am based in London. But I'm actually originally from Arizona. I grew up in Arizona, Chandler area. I know you guys are based in Tempe, is that right?" "Yeah, I'm in Tempe looking at the Tempe Town Lake right now. Trevor is actually coming to us from Belize, I believe." "I think he's at the lobster feast eating lobster or something." "Exciting. Jealous." "It's been a hard week." "Yeah, originally from Arizona, I did my engineering degree at Arizona State and then went on to basically working for medical device companies. I've always been in medical device companies for the past, I think, ten or eleven years now. From startups to like big corporations like Philips, Cochlear, for Cochlear implants, and now I'm in consulting." "Awesome. So I know we have quite a bit to cover today, so we'll kind of jump into it. I know, May, you could describe a little your role with CS Life Sciences before we jump into our discussion." "Yeah, definitely. So my role at CS Life Sciences is quite unique in the sense that we work in the hardware-software team. But my specific expertise is related to AI, so artificial intelligence and machine learning. We are seeing a lot of companies nowadays where they want to incorporate AI, they want to incorporate machine learning into their medical devices. So that's a lot of different competing regulations. What I do is I help them kind of parse out the requirements that they need to meet, what are the absolute musts, what are nice to have, what are future considerations. So really, we work with any level of companies, from startups out of a university spinout, or, you know, a bigger corporation that just needs a little bit extra guidance in terms of the technical support." "Cool. So let's jump into a little bit here. From your experience, how do you feel the industry is shifting in terms of cybersecurity and quantum computing, just like in general? Because it sounds like you've been in the industry for a while. How do you see things shifting?" "Yeah, so that's a really interesting topic, and I think one of the things that people are more aware of now is definitely the cybersecurity aspect of compliance. So traditionally, of course, you know, there's hardware, software, and you're worried about design control. You're worried about, you know, safety and performance of the device. I think when I started in the industry, I don't think cybersecurity was quite that big of a topic. But now, all I'm seeing is, you know, one of the first few questions clients ask us is, you know, what do we do? How do we make our device more secure? And you're seeing that from the regulators as well. You know, they're coming out with more guidance, guidances, more regulations, standards of secure by design, essentially. So it's moving out of thinking about compliance maybe at a later stage or like post-launch security compliance. But now it's really weaving the security requirements into design control itself, thinking about those security aspects right from the very start." "You think the industry is actually shifting in that direction? Because I don't know. What do you think, Trevor? From our perspective, it feels like maybe it's a shift, but it's like so slow I can't even recognize it. It's like a snail crawling across the sidewalk or something. I don't know. What do you think, Trevor?" "It's pretty gradual, for sure. I think that there is a little bit of a shift, but like you said, it's pretty slow. We're seeing some companies try to come in at this earlier stage, but we're seeing still far too many companies, unfortunately, coming to us at the last minute saying, 'Hey, we just weren't even aware this was something we needed to address. We just submitted to the FDA, and they rejected us. What do we do now? We're lost. We're not sure where to go from here.' And I feel like unfortunately that's still the majority of what we're seeing. But maybe it's down to eighty percent instead of ninety percent like it was in the past." "Yeah. No, that's fair. I think a lot of what I've seen in terms of the clients that CS gets, I think they're more very much like software development heavy, AI development heavy. And when you incorporate the AI side of things, you know, data privacy protection, security-related concerns might be more at the forefront of their minds. That could be it." "Yeah, maybe. So, I guess they're a little bit more on top of things if they're developing software with AI. They have to look a little bit more towards the future. And I know the FDA just finally finalized their cybersecurity guidance in, I think it was, June 27th, is that right, Trevor?" "June 27th, I believe." "They came out with it, like they released it a day before, and it was like future-dated, sort of. So with that guidance, what have you seen from your perspective, May? Are you actually seeing it change anything? I know it's only been, you know, a few weeks or whatever, but what's your perspective on the new guidance?" "Yeah, I think traditionally with the FDA's, you know, cybersecurity requirements, it's quite burdensome, isn't it? I don't know if that's what you've seen in your day-to-day as well. The level of detail and the level of documentation that needs to be generated is really hefty. I think one of the important things that I've seen in the guidance is being able to, I guess, incorporate a lot more total product life cycle requirements and being able, like I said earlier, to weave it into your design control requirements. I think right now one of the important things is like the updatability of the device, right? Being able to adapt, being able to be updated to, you know, meet the latest security requirements plus address any outcoming or ingoing, or that was wrong, upcoming or foreseeable, non-foreseeable security risks and having kind of a really robust mitigation plan to handle all of that." "Yeah. And what is your perspective? And I'll ask Trevor after this. From like the US requirements from the FDA versus the EU MDR, which one do you think is more stringent, and kind of which one has more regulatory standards? And just like, I guess your perspective on both of them, a comparison?" "Yeah, I think it's different in a sense where I feel like, from what I've seen at least, the FDA does a pretty good job at like spelling out their expectation in what they want to see in a submission, for instance, or in a design of a document. I think with the EU, outside of the EU MDR, of course there's NIS2, there's the Cybersecurity Act that is more, I guess, generic in a sense where it doesn't just cover healthcare. So there is more complication in trying to translate a lot of the requirements to align with EU MDR requirements, where, you know, the cybersecurity kind of callout is in the GSPR, so the General Safety and Performance Requirements, you know, requiring state-of-the-art cybersecurity and requiring software life cycle controls. I think fundamentally the philosophy is the same, but I think the guidance we have might just be a different level." "So, it sounds like you think the FDA guidance has a little more clarity and the EU guidance is a little more trying to put all these pieces together. Is that a decent?" "Definitely. Yeah." "What are your thoughts, Trevor?" "Yeah, I totally agree. The FDA guidance is very mature from what we can see for a lot of different countries' regulations. EU MDR and EU cybersecurity regulations try to lean on certain other standards like we look at IEC 62304 and 81-5-1 as some of the main points of conversation for talking about how we're designing medical software safely and securely. While the FDA, of course, utilizes those same standards, they have a little bit more of a prescriptive approach in my mind than the MDR, than the European guidance, which is a bit more of a clear and I guess easy forward path for a medical device manufacturer. Having said that, I feel like the FDA requirements can be a little bit more burdensome in that light." "And what is, I know we mentioned a little bit in the intro, we're going to talk about quantum computing. Is this really a concern for medical devices? I mean, I'm not like a quantum computing expert. I understand the concept, but what are some of the main concerns? I know you can break cryptography and all this, but from a medical device perspective, what should we consider in terms of quantum computing?" "Yeah. So, I'm not going to claim to be a quantum computing expert either. Definitely not, you know, Brian Cox level. So I think one of the biggest concerns is, you know, health data is very valuable, and I think recently we've seen quite a lot of incidents where it's, you know, they obtain the data now to decrypt at a later time once quantum computing comes in. And I think one of the things is, you know, with software, firmware, network connectivity with a medical device, hospital networks, your electronic health records, all that. Now there's like kind of an interconnectivity where if you, for instance, have a pacemaker, that pacemaker data connects to the hospital system, then the hospital system connects to a multitude of different patients. So it's quite scary in that, not to fear-monger or anything, but, you know, health data currently, I think it's like one of the biggest, you know, ticketed items. And I think also coming from Information Security Europe, the conference, there was a lot of talk about how, you know, it is not that distant of a future now, and people are gathering and mining these data just to decrypt later." "What are your thoughts, Trevor, on quantum, the risk associated with quantum cryptography and quantum computing?" "There's a little bit of a balance there. So, with the whole 'harvest now, decrypt later' problem, it's due to the fact that we're currently not using, in most applications, future-proofed encryption methodologies. And encryption methodologies change all the time. What was once secure is no longer considered secure. We can look at things like MD5, Triple DES, which once upon a time were acceptable, but now they're known to be vulnerable to all sorts of different cyberattacks. Where we find a little bit of challenge there is that post-quantum encryption is often going to be intensive from a resource perspective on a device or on a system compared to traditional encryption methodologies. And we even see that with what are considered the state-of-the-art standard encryption through FIPS 140-3 and comparing that to some of these once upon a time safer encryption methodologies like MD5, like Triple DES. So I think that there's a little bit of a balance there, and the hardware needs to keep up. Often times in hospital networks, we're using twenty or thirty-year-old hardware, or you'll still see Windows XP and Windows Vista in hospital networks, which aren't going to be that hardware is not going to be as capable of supporting these future-proof encryption methodologies. So I think it is a little bit of a balance to strike there, but as long as the hardware can keep up and as long as the data is being protected from that lens, I think it's an important push that the industry is going to start leaning towards." "Well, I mean, if you've got like an implantable that's battery-powered, I don't think it's feasible necessarily to have what you call future-proof encryption. But I think the whole idea is there is no such thing as future-proof encryption, right? If in a quantum era, like an AES 512 or something can still be broken later on, isn't that the whole idea with this quantum readiness?" "It's about going for instead of trying to do like a one-to-one hashing. It's a little bit, you know, and I'm definitely not an expert on how the actual math behind it works, but it's going away from traditional encryption practices and working in a way that is not going to be affected so much by speed and effort, which is the current vulnerability with just about any encryption methodology. And it should be just a risk-based approach for that pacemaker. What information are we expecting it to transmit? Is it going to be just device data, information about the runtime, or is there going to be very sensitive patient information? If there's nothing that's going to be sensitive if it's breached, what is really the impact?" "I mean, the kind of the elephant in the room is pretty much all of our health data has already been stolen. So, does this even really matter?" "I mean, that's fair. I think, yeah, you see it on the news like almost every other day, right? There's this hacking here, this hacking there. But yeah, I think in terms of just, you know, being aware that this is coming is quite important because you build it into your design controls and your risk management, right? So it's the manufacturer's responsibility to ensure you do everything you can. It's your burden to ensure safety and performance. One of the considerations is this, you know, looming idea of post-quantum computing. So that, you know, now it seems like it's more of a foreseeable risk than, you know, maybe compared to five years before." "Yeah. So it's something we should keep an eye on, and I think one of the challenges that we face quite a bit when we have discussions with clients is there's this idea that everything needs to be encrypted. And as Trevor kind of alluded to, if it's just diagnostic data or something from a device, it doesn't necessarily need to be encrypted. But I think there needs to be a balance there and only encrypt the data that is necessary to be encrypted. But from what we see, there's a push to encrypt everything by default, which, you know, I don't think is necessary." "That's fair." "Is that a trend you're seeing as well, May? Because I know Trevor can speak about this." "Yeah, I think one of the things, you know, that we've always tried to promote within CS to our clients is like that pragmatic approach, right? We always look at what is necessary to meet the regulations to be compliant, ensuring safety and performance of the device while not burdening ourselves into, like you said, encrypting everything, over-compliance, overworking a device, because ultimately, we want to bring these solutions to the market as soon as possible. So there is, you know, like I think the theme of what we've been talking about is there is a balance in everything we do." "What are your thoughts on that, Trevor? The over-compliance. I like that term." "The regulators want to see these products go to market. They're just there to make sure that it's done safely and securely. They aren't trying to stifle innovation. They aren't trying to prevent these from going out. So if you're able to explain and justify your level of risk, they're always open to listening. Of course, there's a push for encryption on data. What that means and how far that goes is going to be flexible when you're actually talking to the FDA, when you're talking to the MDR. If you can present your case and say, 'This data is not sensitive. It doesn't need to be encrypted,' they're going to be understanding of that. And that's been something that we've done in the past when we're handling the cybersecurity for our clients' devices is we say, 'What's really the impact? If I compromise this data, there's nothing else I can do with it. It's not sensitive. I can't sell it. I can't use it to do anything else in the machine. So, it's not going to be the end of the world if an attacker sees it either.'" "And we talked about FDA, EU, and I know China, the NMPA. Are they, are these like the top three you think in terms of medical device regulations that need to be followed?" "I'm going to give you like a very lawyerly answer and say, it depends. It depends, of course, on like, you know, your business strategy. But I think, you know, a lot of countries are looking towards FDA and EU and China as, you know, that driver of regulation, of policy, of providing guidance to what they should do within their own countries when developing regulations, like, you know, with different new regulations like the EU AI Act. A lot of countries are looking to use regulation to frame their own regulatory framework. So I think, you know, it's very dependent, country dependent, but the underlying theme is, you know, a risk-based approach, ensuring appropriate, you know, management of the safety and performance of your device." "Which one of these three are the most stringent? I'll throw over to Trevor. I think I know what your answer is going to be, but maybe I've changed your mind." "Typically, I think that the FDA is going to be the most strict as far as their requirements, and the NMPA is going to be the most unique. If you're trying to submit to every regulatory authority in the world, you're going to have to change the most for NMPA just to comply with Chinese cyber law. And let's say you're using top-of-the-line, state-of-the-art FIPS 140-3 encryption in America. You can't use that in China if you're handling sensitive information. You need to use cyber law-approved encryption, which is going to be SM234, and using those are not FIPS 140-3 approved. So they won't be accepted in America. So you're likely going to have to effectively make two separate devices for this. And, you know, this is usually the prime example that I bring up, but the Chinese NMPA regulations are pretty far detached from what we're seeing in the US. But I think in general, the US has the most strict controls." "I was just in Hong Kong and Shenzhen, China, I think last week. And one of the loopholes I was discussing with some people is if a device is FDA approved, you can bring it to Hong Kong, which is a special authorized region of China. And then once it's been in Hong Kong for a while, it can then be brought to China and get NMPA approved without having to go through the entire process. Don't know if you've heard that before, but there are some ways around this. And I think the FDA has set the bar, as you said, but China has different encryption standards, so that's a whole different ball game there. But one of the challenges, I think, with a medical device manufacturer, if you don't understand your regulatory strategy and what market you're trying to sell to, it could be very cumbersome to try to meet all these different requirements later on if you haven't designed them in properly. Because I was talking to a manufacturer while I was over in Hong Kong, and they wanted to sell to China, but they decided to put their deployment on, I think it was, Google Cloud Platform, which I don't think is allowed in China. So they deployed like their software as a medical device in a cloud infrastructure that's not supported in China. So now they have to, like you said, Trevor, have to come up with two different versions of their product in order to sell to both markets." "I know often times when I'm talking to our clients, and they're early phase, and I say, 'Okay, lay out every market you're looking at going for.' If they haven't decided on a cloud service provider, and they say, 'Well, we want to use AWS, but we're looking at selling to China at some point.' I say, 'All right, scrap everything. Start over. You're moving to Azure now. That's the way you're going to get through this.'" "Yeah. Yeah, I mean, that's, it's really interesting you brought up that loophole, Christian, because that is exactly what we did in a previous company that I worked for. We wanted to launch in China, and that was the strategy we took, and that was the strategy recommended by our Chinese" "Strategy to go to Hong Kong and then to China?" "Okay." "Exactly. And I think also it's quite culturally different as well, you know, the way the Chinese businesses and the Chinese government conducts their business. I think there's that difference in culture that I find, you know, with my experience with Chinese regulators, is very different to how you deal with, you know, FDA regulators or your notified bodies. There's almost a sense of like ceremony to it, if that's the right word." "Yeah, I agree with that. When I was in Shajhai, part of Shenzhen, we went and did a tour of a hospital, and it was interesting. We couldn't go to one of the floors because there was a celebrity there. So, I don't know if they would do the same thing in the United States, maybe. So, I guess it depends on how popular the celebrity is. But I was talking to some people there as well, and I guess there's a private hospital in the United States where only the celebrities go because they actually have super high security and they don't want to leak, you know, what disease or what ailment a celebrity has. So it's interesting, like, I guess if you have more money, you can pay for better security almost in our, in the United States health care system and also in other countries as well. I don't know how true that is, but they give the perception there's better security." "Cool. Let's jump back to quantum computing, because I know, we talked about different encryption with China versus the United States. And with quantum computing, I know Trevor, you're talking about future-proof encryption, but I thought the whole idea was there is no such thing as future-proof encryption with quantum computing threats. Maybe you can expand upon that a little bit, because I know in the past, like if you use AES 256, it's like DOD grade encryption. But the whole idea is if you harvest now, we can decrypt that later. So, is there really going to be a type of encryption that will be future-proof or not really?" "The same way that you can use quantum computers for decrypting, you can use them for encryption as well. And it's fundamentally different from how we look at encryption right now. And again, I don't know the full details of exactly how it works, but essentially current encryption is based on you run it through a whole bunch of math which gives you a one-way function to get an output, and then you compare the output of those functions. With quantum computing, you're running it through quantum encryption as well, which on standard computing, you have any bit that you're assigning for these mathematical operations or for the outcome that can be zero or one. For quantum computing, it can be both at once. And so, you're relying on physics as opposed to math, which I do not know the details at all. That's about as far as I'm going to go on the explanation, but it's a fundamentally different process. So, the quantum encryption is not as easily broken by quantum computing the same way that traditional encryption is not very easily broken by traditional computing. Having said that, it doesn't work in reverse. So there isn't going to be a very easy way for us to have encryption from standard like one-way hashing or one-way mathematical operations that can't be broken by quantum computing at a much higher rate. It's going to be a difficult problem to solve. So the solution is to use quantum computing for the encryption as well." "And I don't, I don't know enough about it to know if it's more resource-intensive than traditional encryption. But yeah, it sounds like this is something we definitely need to keep an eye on and figure out a strategy for. And I think it's interesting that the qubit can be a zero and a one simultaneously versus just a bit. And it's interesting with trying to break quantum encryption, it depends on if you're actively trying to break it since the whole concept behind quantum computing and quantum encryption is the visibility of it changes the state of it. So the visibility of encrypted information is going to alter whether or not it can be broken through that encryption." "So we're going to have to develop these quantum-safe devices and quantum-safe environments to deploy them on. It sounds like in the future." "The quantum-safe devices will be the quantum devices. So we'll see, we'll see when we get there. I think it's" "I think we're like, I think we're going to be like twenty years away, based on now the legacy devices out there right now." "Oh, yeah. Yeah, the legacy device issue is definitely a big concern." "Yeah." "Yeah, it seems like at some point a line needs to be drawn to remove those legacy devices. But it's a bigger problem than just removing a device because you've got to retrain physicians on how to use a new device, and you've got to deploy these new devices and test these new devices. So, you know, this is a much bigger challenge than a lot of people realize because I know a lot of people think, yeah, let's just say by the end of this year, we're going to remove all legacy devices that are more than five years old from a hospital environment. But it's not that simple of a problem." "So in terms of total product life cycle, and we sort of started talking about this, I know Trevor and I just released a podcast episode on the total product life cycle. It sounds like we're seeing a shift where more devices are starting to be secure by design and have that from the design to disposal mindset of security along the whole way. Is there anything that if I'm a manufacturer listening to this episode that I should think about from a TLC perspective that may not be, I may not have heard of, or something that would be a big tip for me?" "Yeah, I think one of the other things that we didn't quite touch on, which is equally as important, is, you know, your supply chain, right? Like what type of software components are you using? SOUP items, off-the-shelf software components, what are you using? And, you know, how much visibility you have on the developers, the tech, what are you actually integrating into a device that's under your responsibility? So I think third-party risk management is going to become more important, not that it's ever less important, but really like something to think about and highlight, right? As you're developing a software as a medical device, AI as a medical device, you know, you're taking, like, for instance, an LLM model from a third party and you're integrating it into your device, you need to be, you're the one responsible for ensuring that it's performing in the way that you intended to and that it's safe for use, it's secure, and all the other considerations and design." "So, are we looking like for, I know there's a software bill of materials, but it sounds like we should also be looking at the total supply chain, including the hardware components that make up our device which those may have firmware on them as well. Yeah, I used to do a lot of testing with aircraft, commercial aircraft, and this is one of the concerns we did because a commercial aircraft is an integrated system with a lot of different components, and we had to look at every single piece of hardware that went into a component on an aircraft and test those from a cybersecurity perspective because, you know, one little component, if it was contaminated, could be leaking information to an adversary. Could be used in a negative way later on. And I think medical devices are getting very similar to that because the FAA mandated very specific third-party component risk assessment procedures. And I think with medical devices, we're going that direction, not just from a software perspective, but also from a hardware perspective as well." "What are your thoughts on that, Trevor? Because I know we have a lot of devices that you refer to as a three-piece suit. I think that has like the device, the mobile app, and something in the cloud. If we're looking at the total product life cycle and the supply chain management and the third-party integration of all these components into a device, is it even feasible to make sure it's fully secure from your perspective?" "Having, if we're talking about perfect security, I don't think it's possible. Proving perfect security in ten lines of code is nearly impossible. So, if we're trying to talk about a device with so many interconnected components, so many things in the software bill of materials or the SOUP that we can't control and we don't know how secure it is, I don't think it's ever going to be possible to have a one hundred percent secure device. There will always be some problem that could be discovered with enough time. Now, having said that, I think that there is, you know, of course, we don't want to take any shortcuts, but there needs to be a point where it's good enough security. Since we can't have perfect security, we need to make sure that there is no risk that is going to be significant to the patient, no risk that's going to be significant to the patient's data. Very minor things like a vulnerability that's disclosing information about the tech stack in the device is not going to be something that is as significant as a vulnerability that could potentially lead to harm to the patient. So there is a balance there, and having that sort of risk analysis approach is a good way to prevent trying to essentially create a device that's just buried in the sand in the desert in Nevada, which is the only way that you're going to have a perfectly secure device because nobody can use it." "Well, if I know where you buried it, it's not actually secure." "Well, there you go. Now, it's not even a perfectly secure device. I can dig it up and, you know, take it apart. So it's, it's, the more we talk about this stuff, it, it sounds like super challenging. Like if I, I try to put myself in a MedTech innovator's shoes, and all this regulatory requirements, the different market requirements, the quantum computing requirements, it's, it's, uh, it's very challenging for an innovator to come up with something. So from a strategy perspective, at what time should they engage your organization, May, to try to figure out the roadmap for this?" "Yeah, I mean, I always say as early as possible, right? Even honestly, even if it's just an idea, you know, reach out. We can discuss with you the types of things you need to think about, you know, at the first initial even feasibility stage, right? We can help you define your business strategy by explaining to you, you know, maybe go to this region first because then you can leverage, you know, information from this region for another region. So we can have those conversations with you. It's always helpful to have that kind of mindset and start from the very beginning. We try our best to give you a very good roadmap, very pragmatic. And, yeah, just we're happy to chat about, you know, anything from business strategy, regulatory strategy, is this document right or not? Kind of conversations." "When do people typically come to you?" "Um, we have a range of inquiries, actually. So, a lot of our clients, especially with like the software AI clients, they're quite new. They're like university spinouts, right? It's someone's PhD project, and suddenly it's like, you know what, we could do this as a company. So that's when they reach out to us. So, we work with a lot of university like accelerator programs to kind of get the word out there that we're here to help from a regulatory perspective. But we also work with more mature companies as well. So, if they're planning on introducing AI into their device, that is where we'll be like, you know, this is what you need to supplement in your technical documentation to meet the AI specific requirements." "Okay. I think we advocate sooner than later. What, what is the overall view you think of our clients, Trevor? Like when do people typically come to us? I know we're trying to shift it to sooner by raising the awareness. Do you think that that's working? And when do people typically come to us from a cybersecurity lens?" "I think it is getting better, but it's still a little bit of a slow progression. A lot of times we have people come to us. I think the worst time to come to us is after you've already submitted to the FDA, which is unfortunately a lot of what we see. They submit to the FDA, they weren't aware of the cybersecurity requirements, they get rejected. And redesigning a device with security in mind in a review cycle window is very difficult and very stressful. So coming to us as early as possible in the process, right when you're starting to design that software and before you get your hands on the keyboard and start writing any code, we want to talk about what standards are you writing the code to, how are you ensuring you aren't introducing any vulnerabilities through your coding practices, through your development practices, through your environment. I think that's the ideal time to come to us. But for the regulatory documentation and testing, I think the sweet spot is between six and four months out from the submission. That's when we want to prepare everything, do all the penetration testing. At that point, it's assumed we're going to have a close to final product, and that's where we like to do the actual testing." "Yeah. So it seems like we're both advocating from a regulatory perspective and a cybersecurity perspective, which cybersecurity kind of falls under regulatory, but it also falls under design as well. The sooner a client, a manufacturer, reaches out to us just for some consulting, basically, to get them on the right path, the better and the more cost-effective typically. So we're kind of coming up on time here, so I'd like to go around and ask for last words of wisdom for our listeners. So I'll start with you, Trevor, then I'll go over to May." "I'm going to go back to the classic here. We want to see you considering cybersecurity early and often. And it's not something that you should leave towards the end. Make sure that it's at the front of mind as you're going through the design process and don't leave it to the last minute. It's going to lead to cost overruns and time overruns." "All right. Early and often. That's the t-shirt you want to get made. I know. All right, May. What about your last departing words of wisdom here?" "What really resonated with me within our conversation is the idea of reaching out early. So before, like Trevor said, you know, key figures the keyboard, get yourself a good regulatory consultant, a technical consultant, someone that can really help you develop that roadmap. And that is more cost-effective. That will save you time, get you to market faster, and really remember that the regulations aren't here to stop you from getting to market, to bringing your ideas out in the world. They really are just to ensure safety and effectiveness, right, of the device, of the solutions. Regulators do want these solutions. They want to see innovation. So working with them instead of against them will be so beneficial in the long run." "Yeah, I agree with that. My parting words of wisdom are to begin with the end in mind. That's my new tagline, Trevor. Kind of like early and often. I like to say begin with the end in mind. Figure out which markets you want to go to ahead of time, and then you can plan your strategy and work backwards from there. And you can also look at how I'm going to get reimbursed for this thing and how I'm actually going to make money because a lot of people don't think about that and they come up with a cool product, but there's no one, no adoption of the product because there's no reimbursement category for it. So there's, there's a lot of things to think about, but you have to think about the end first and work backwards from there. So thanks everyone for tuning in to this episode. I hope you found it valuable, and we hope to see you on the next one. The end."