Cloud Connectivity: What It Really Costs to Get Your Device Online and Keep It There

Hello, and welcome to Friday in Focus. My name is Sean Smith, publisher of MedTech Leading Voice. If you're not a subscriber, please go to MedTechLeadingvoice.com and subscribe. Excited about today, Device connectivity, what it really costs, how to get your device online and keep it there with Abbas and Alex, who I will introduce in a moment. In the meantime, while people are joining, a couple of announcements about, what is Coming up. So, next week, we are going to be… doing a launch party of sorts for Subtract to Ship MDR. Some of you may have seen announcements about Tibor Zeckmeister and Felix Lenhart's new book. It's essentially about the experience of the 11 mistakes that killed a medtech startup in the EU.

So, yeah, subtract to ship, it's gonna be good, and I'm looking forward to it. The following week. Michelle Lott has moved her regular webinar into the Friday in Focus slot, because there was a scheduling conflict for, the Culture of Quality webinar that she's planning. I will put, that in the links shortly. And then on September 18th, MedSec, cybersecurity company, is going to be joining us, Michelle Jump, so we're gonna have another Michelle, two weeks in a row. She's the CEO of MedSec, and she's gonna be, unveiling a new

Service, product, offering that, Is pretty interesting, so you guys will want to stay tuned for that. They, and then… Right, so then… That's looking forward, looking backward, this week, I was at the MedTech Symposium Super, project… from Project MedTech in Philadelphia. I spent the whole day there on Wednesday, with Francesco, and, we're on… on… We're doing this new thing where we go to a conference, and then we create a yearbook from the conference. And the yearbook is intended to capture, you know, all sorts of, information, photos, quotes.

interviews with people, with vendors, so that you get, like, a sense of what happened at the event. This is an experiment that we're doing, so when we launch the thing, I really hope that you all will support it and share it widely, through… throughout the, Throughout the ecosystem. Let's go ahead and get started. Before we get… so, housekeeping announcements. If you want to come on camera, just raise your hand. Francesco will promote you. If you have comments or questions, please feel free to use the, the chat function or the QA function, but for the polls that we're gonna do, we're gonna do a few polls, you know, they just have dots, but just write ABCD, you know, or NA if it doesn't apply. You know, don't get too concerned about that.

And now I want to ask, I'm gonna start with Alex, then I'm gonna go to Abbas. You know, when you were a small child, right, did you dream of one day working at a device connectivity company? Was this… Your objective in life, or did you have other plans?

I wanted to be a professional basketball player until genetics. Genetics made that a non-starter, at 5… 5'11", and definitely, without the ability to jump very high. That got nixed pretty quickly. But I would say, kind of on a more serious note, I actually entered school for finance, and for me, kind of computational finance and financial engineering was something that was always very fascinating to me. And then, you know, as life goes, you kind of, bounce around to different things, but, that was, that was the, kind of initial interest, though I would say what I'm doing today is far more fascinating. I'm much happier.

Working with a much, I would say, a nicer community in the, in the medical device space. So…

Fantastic. Now, Abbas, tell us about you. Was that your dream? To one day run the company?

Not really. I mean, depends, like, how small is small. So when I was really small, in the late 80s, I wanted to be an engineer. because my dad is an engineer, most of my uncles and cousins were engineers, so I knew I wanted to be an engineer of some sort, but it was mostly around, and all… my entire family is generally in the construction business, so they're, like, civil engineers, mechanical engineers. That's the kind of thing I wanted to do, until I… got my first PC early 90s, and then I was fascinated with it. So I wanted to be a software engineer since then. Whether I want to run a company that is around device connectivity, probably not. Like, that did happen until way late in my career.

But no, I wanted to be an engineer of some sort, and later on, dreamed to be a software engineer. So at least that part, I got it.

Okay, well, I always like to know a little bit about people before… before we launch into everything. If you want to move to the next slide… So, as I said before, you can have your cameras on. Chat is the easiest way to communicate with us. There'll be four polls. No long demo. And, I want to welcome everybody who, has joined us so far. Welcome. Hello. Let's get started. So, the first poll question is, where is your device on connectivity today? And you can do A, B, C, D, E, or F, which is…

N.A. doesn't apply. So while they're answering this question, we can, go ahead and get started. What are we here to talk about today, guys?

Medical Device Cloud Connectivity. the riveting topic. No, it's something I've dedicated the last, you know, since 2016 to kind of, working in this field. But, I'll give you some kind of… some background on kind of who we are and why we exist. So, maybe some of you might be familiar, we've been around for a while now with the name Galen Data. Galen Data was a company that, Abbas, I, and one other started. Co-founder Christ DuPont started in 2016 with the idea of making medical device cloud connectivity easy. And this came from working in the kind of custom software space, where, you know, going back, you know, probably 25 years now, there have been companies that need this kind of cloud connectivity. And typically, those were kind of large medical device companies, that had the money, and the time to be able to kind of launch these things successfully. And, typically, you know, if you're working with a, maybe a custom software

for a solution provider to build these things out, it can cost hundreds of thousands of dollars, and it can take, you know, months, if not, you know, a year, year and a half of time to kind of build this kind of cloud infrastructure. And the way that typically, looks and feels is, you know, you need these devices to be able to kind of centralize their data somewhere in the cloud. You need the ability to kind of, Visualize that data and expose that visualized data to stakeholders, so whether that be a clinician, a patient, yourself as the medical device manufacturer, maybe third parties, would need to be able to see that data.

You need the ability to kind of process that data in some way, and that started, with kind of small, like, lightweight analytics, and now has expanded to, you know, LLMs and all kinds of fancy AI tools. A lot of companies needed the ability to kind of create notifications and reports around, that data, so maybe a notification is a new patient is enrolled, or maybe something's wrong with the device, or maybe a diagnosis is ready, or something like that. Maybe a report needed to be generated and automatically sent to a specialist. Let's say if you're working, you know, with a, I don't know, a pacemaker or something like that, maybe there's a, a, a technician that needs to be able to see kind of data coming off of those devices.

So that needed to be created, oftentimes. companies needed the ability to kind of host firmware for their devices to be able to kind of pull so that they could update themselves, which is now, obviously a gigantic kind of, emphasis when it comes to things like cybersecurity. And then lastly, a lot of companies needed the data to kind of get into the, the EHR. So. you know, we would build these kind of custom solutions bespoke over years and years, and we saw this kind of repeated pattern of companies needed the exact same things. So, we decided to basically, or I should say a boss, kind of had this idea.

of building that as a platform, service. So basically taking all the things that these big companies were asking for, and then creating a software platform that would allow companies to kind of configure that infrastructure very quickly, instead of kind of building it from scratch. And then. You know, once all of this infrastructure is built, it's typically handed off to the medical device company to kind of manage thereafter, and they would become responsible for all the ongoing software concerns privacy concerns, regulatory concerns, any kind of, you know, the cybersecurity concerns, all of that falls in the lap of the medical device company. And as we saw, kind of, earlier stage companies needing that kind of infrastructure.

not being able to afford it. It's a long timeline, especially with, you know, the average burn of a medical device company, whether it's a startup or a large company, being quite high. You know, this… this kind of always bespoke custom norm became kind of an innovation bottleneck. So, we built this platform, launched a product in June of 2018, With the idea of trying to make these, cloud connectivity, you know, dependent devices. Be able to get to market a lot faster, be able to, get them kind of, through the regulatory pathway a lot, a lot easier, and then kind of manage all that ongoing operations, cybersecurity, privacy, regulatory concerns for them.

So that they can kind of stay a medical device company, not kind of morph into an IT company. So… You know, Post-launch, we now have, you know, clients that we're servicing all over the world, and kind of helping them out as being that kind of close partner from an IT perspective, to allow them to kind of, you know, focus on their device. So… addressing the slide kind of directly, you know, it's exactly that. When you decide that you want to connect advice to the cloud, you have all these additional responsibilities that kind of fall straight into your lap. And, you know, it's the… it's not just the upfront cost of paying that third party to kind of go through

you know, the build. It's also all of that ongoing support that lasts, you know, all the way through commercialization, you know, or through exit, and then on. It's not… a cloud isn't something that you build and then kind of put on a shelf and expect it to kind of work indefinitely. It's something that you always have to kind of maintain and look at and, you know, try to improve in a lot of cases, and so… That's why, kind of we exist, to… to make that… to make that entire process a lot more streamlined. Next slide. So, when you create these connected devices, these are kind of some of the four key things that you might have responsibility for.

And I think that a lot of this is overlooked these days when everyone is trying to think of, software in general as something that moves, kind of, very quickly. If there are… there are a lot of, kind of, maybe software-focused teams that are kind of moving into medical device that might not fully appreciate the kind of totality of responsibility that they're taking on. So, from, you know, from kind of a governmental side, you have things like the FDA, you know, CEMark, Health Canada. And obviously, that expands, you know, globally, with a lot of countries having their own you know, regulatory bodies, even though they may default to, kind of, FDA or something like that. You have the quality and software piece, so you do have these, compliance thresholds that, are kind of, these days, an expectation, so familiarity with things like that.

is very important, when it comes to, kind of, data and privacy. Obviously, the two big ones in our space are HIPAA and GDPR, but there's also A lot of other ones, especially, you know, now more and more states are creating their own kind of rules and regulations, so that is always a evolving landscape, and it seems to always be kind of Going more towards increased privacy, and less on, kind of, on more open architecture. So, I would say, Being mindful of those changes, especially as companies expand globally, is something that does require a lot of time and effort and energy. And then, kind of lastly, about the kind of the back-end platform, you know, no one is really building their own kind of data center these days. I think I've only talked to one medical device, founder who wanted to go down that path.

And that conversation is about 3 years old, and to my knowledge, they are still not connected. So, you know, you have these big, these big infrastructure providers, like AWS and Google Cloud and Azure and things like that. So that management, of that, of that infrastructure and the scalability and, you know, even kind of, like, the jargon, you know, typically requires an expert who knows that space very well. You know, if, if… you know, a team is more kind of medical-focused, maybe a doctor with ideas that, you know, they want to take to market, things like that. This requires some special expertise.

One of the things I'm calling out here is high trust, just because cybersecurity is such a concern these days. That's kind of the high bar these days for medical device cybersecurity. If people aren't familiar with it, it's kind of growing in Europe. I know, Sean, you have a lot of European followers, so… That might be something new to them, but I can tell you that it's… Because cybersecurity is under such scrutiny these days, you know, you can potentially be, I would say, handed, you know, a nice 500-question due diligence questionnaire from a hospital when you try to sell your product to them.

all about cybersecurity. We've seen it before, and having a HITRUST certification kind of allows that to turn into, I'm generalizing, but like a tick box. So. You know, as rigor increases, I think high trust is something that people should be more mindful of, and it's something that we have internally, and it took a lot of time and effort, but if anyone is interested in that, I know there were some questions earlier about, kind of, cybersecurity, as we were kind of getting the, the webinar up. Be happy to kind of talk about our experience there. Next slide. So, again, with this poll, if you guys want to enter your responses in the chat, that'd be fantastic.

Be very careful.

Curious.

to see these answers. Yeah, go ahead, Sean.

Yeah, you can do A, B, C, D, or E as an A, right? There you go. You got the NA. So, on the previous poll, by the way, there were a lot of A's, there were some B's and C's, and there were a few Fs for not… not… not applicable. So… And then this one, we're getting everything but in… We're… it's all… it's all over the map.

Yeah, I mean, you know, for us, when we launched this product, we were kind of first to market with this as a concept. So, you know, for us, it's taken years and years and years of kind of going out there and waving to people, shaking hands, and you know, going to conferences and stuff like this to talk about this as an option. Typically, medical device is something that You know, where you're kind of owning all the infrastructure, so kind of trusting a critical path vendor with something like cloud connectivity is relatively new, so I'm very curious to see. These, these responses. I see Jose has a… Let's see here…

Thank you, Jose. Good to see you. If anyone needs cybersecurity help, Jose. Great team.

Thanks, Halitz.

Oh, there you are. Good morning.

And likewise.

Thanks.

Yeah, we like it when our clients are using the Matrix 1 background, it makes our life easier.

Yeah, glad to hear it.

Right, so it looks like we got, you know, the full range on the responses. Thank you, everybody, for participating in the poll. If you didn't participate in the poll, please do. It helps us understand where you're coming from, what your needs are, and Helps the speakers, you know, figure out what people actually care about. So yeah.

From here, I'll hand it off to our CTO, a boss, who will guide through the next few slides. It's all you.

Hello, everyone. Thanks for joining. So one of the things we want to talk about, so what is the cost? Costs including both, you know, development costs, but ongoing operation costs, to get online, to get the cloud part of the connectivity, paradigm. So, basically, there's generally three parts, to get a cloud connectivity, right? So one is build yourself. So you build everything in-house, or with a contractor, but you build everything. And you own the infrastructure, so you own the migration, and own, essentially, the operation aspect of it. The second option is buy, like, something like us. You go buy, and you kind of,

use a partner like us to run the operations and jumpstart on the build part. And there is a kind of a in-between, a hybrid sort of approach, where you maybe take pieces of someone else's platform, but then you build on top of it some additional modules, additional capabilities, so you're not completely giving up the build, but you are maybe reducing the amount of build that you need to do. And those are kind of three different options. So we just want to talk about, if you want to build in-house, kind of what, what it includes, and what kind of things you have to consider beyond just the software. Obviously, you're building the software, but what else is part of that?

That of consideration of, kind of, your requirements, for something like this, right? So, obviously, there's infrastructure. As Alex kind of alluded, you would most likely use some sort of public cloud, not building your own data structure, data warehouses, but… But you still have to think about how the infrastructure will work. Like, you know, what kind of data are you storing? How much of the data are you storing? Where are you storing? How are you securing it? how you're moving data between different components. So there's a lot of, kind of, engineering thought process that you need to do beyond, oh, I'm using AWS, because AWS has, you know, 17 different kinds of data storage. Which one is the right one for you?

How, how do you, because there's cost differences, there is scalability differences, there is security differences. Between those, those storage, systems. And so you kind of think about infrastructure. How do you scale, when there is, when you go from, let's say, 5 customers to, you know, 5,000 customers, or 5 devices to, you know, 5 million devices? How do you scale? How do you scale regionally, right? So when you go from. let's say you launch in the United States, and then you go into other parts of the world. How do you scale it? Do you create multiple copies? Do you have a global infrastructure? Do you do dynamic routing? There's a lot of engineering.

thought processes around the, kind of, the infrastructure and the architecture, that you need to kind of think through. So, just, it's not just, let me build the… let me pull a database, let me build a nice little UI. There's a lot of… for a production system, you've got to think through, many things. Security posture, Allison knew this, cybersecurity is everywhere. Before the call, we were just talking to Sean about, you know, how cybersecurity with AI today can be interesting. But you gotta think about that as well. And when I say security, I'm not just talking about like, someone coming in, like a hacker coming in and trying to break your system, but also, like, misconfigured stuff, right? If you are supporting, let's say, you have an application that you're selling to multiple hospital systems or multiple patients, things like, you know, can a hospital system see

accidentally, maybe, data of patients that are not part of their system. So, like, access controls, you know, keeping things Not having sat across, patient across tenant leaks. So things like that, and not even… not even nefarious things, but just things that you need to make sure are isolated and properly managed. Monitoring the access controls constantly. But then also on the finished part, you know, how do you make sure that you are really protecting against all kinds of things? That happened. And on our infrastructure, we see every day all kinds of things that are thrown at us. Ddos, the people trying to, you know,

brute force passwords, trying to trick into, clicking links, I mean, all kinds of stuff, right? So all kinds of stuff happen, and you have to constantly have the security posture ongoing. It's not, something that's static. So you don't just, you know, do once and then say, okay, I'm good for six months. Doesn't work in the security, world. So it's a constant battle, and… as kind of says, you know, the bad guys have to win once, but the good guys have to win always. So that's kind of the… you are already in a bad situation, that you've got to constantly keep doing that fight. something that's very unique to the medical device, obviously the compliance aspect of it. So if you are in IT, in general IT,

and you wanted to go build an app that goes on the cloud, okay, you still have to do the infrastructure, you probably still have to do the security posture, but the compliance depends on different, industries. Some industry doesn't have… don't have as much compliance no matter, but in medical devices, we do, right? So, again, depends on how you how you kind of position the cloud piece within your submission. Maybe it's part of a device, maybe it's not part of a device, maybe it's a companion app. It depends on how you do it, but still, there is no zero compliance. At the minimum, you have to make sure it's part of your QMS.

That you have, you know, the regulatory… you have reviews, you have the kind of the… at least 2, 3, or 4, ICU4 controls in place, even if it's not part of your submission. So, even if it doesn't become medical device or something like that. you still need to make sure the QMS, controls it. So there is… there is some burden, an additional burden, that you have to think through in your… in your planning, in your effort estimation, in your kind of how this will work out, how it's on track with, with the other things, other workflows that are going on in terms of, you know, maybe your firmware development or your

Your hardware development or your clinical workflows and stuff like that. And the last is integration, right? So, I mean, if you're collecting data, the data has to go somewhere. It can stay in the cloud, but then you have to figure out how to display it. But most likely, especially if you are going to interact with the hospital systems, health systems of any kind around the world, you probably will need to eventually integrate with some sort of electronic health record, or electronic medical records, systems. And so that integration is, you know, maybe not day one, but something that will happen. So you have to consider that in terms of your overall planning, is how do we manage

integrations to these systems. Maybe if it's more of a laboratory-facing device, it might be LIMPS, or it might be some other systems, but generally we see, at least in our customer base, pretty much everybody has some sort of integration needs at some point in their lifecycle, even if it's not day one. So that… those are kind of the things that you have to think about, in addition to just, you know, building the software. Also, ask me any questions at any point, if you need to. I think we want to do one more poll, as I kind of… before I kind of go into some numbers. what is your best guess, and kind of, if you were to build this in-house, this whole infrastructure that I kind of mentioned, like, what would you think is generally the cost?

So again, I think we'll do A, B, C, D… An E as a no idea.

Haven't seen a single A yet. Which is good.

I mean, you can do it, but…

Yeah, you can do A. No, yeah, it was, just more kind of realistic expectations from the group. How well do you want it done? Good… good response.

It's great.

I see so many, so many names, you know, that are, that are here, here joining today. Seems like a, kind of a friends group that was having, you know, coffees on Fridays, and, and, you know, were, were gracious to Sean to, to now be invited to the, to the group, so great to see all these, all these familiar people.

Okay, I think we got… quite a bit of answers, and I see, I mean, just from looking at it, seems like it's C, D, maybe E's, but mostly Cs and D's. There's some, I thought I saw a couple of A's, or at least somebody says start with A. So, yes, I mean, that's, you know, that's realistic. Like, now, we would put a number here, that is close to that last value, right? Coughly 200,000. Now, this is, again, our estimation based on what we used to do. It also obviously depends on the complexity of what you're trying to build. Are you building a very simple app versus a very complex app, that is the kind of the…

delta there in terms of, how… how this works. We actually have a calculator that we built, based on, kind of, our experiences. We'll probably put a link, but it's on our website, but maybe, Alex, if you have time, you can grab the link and maybe put it, to kind of, you know, do this calculation.

write calculator in the, in the, chat, and you can send them the calculator if they write calculator in the chat.

Yeah, that's fine. So it's there if you want to use it, it's… It's based on our experiences, it goes through different, parameters. You can put a lot of inputs, depending on the complexity and the requirements, and it'll give you some number based on… realistic numbers based on what we used to charge when we built this, and we kind of verify this with a few other people that build that today. But anyways, this is, again, a very simplistic option. So in about 4 months, you can build something. I say 4 months, we use AI as a parameter here, so assuming that AI is helping you a lot to build, I mean, we have to acknowledge that, that that is the…

The bill part is getting much, much, much faster and much cheaper now. Because of, kind of the advances in AI that has happened. But then, you know, there's other things that the AI doesn't help very well, especially in kind of the lifecycle records, or call V systems, or making sure the right architecture exists, that you are validating that. So there's a lot of things that a build requires, where AI helps, and there's a lot of things the AI doesn't help. So, but you can get faster in the build part today, on the software build part today, just because, you know, we have more productive, systems, that build that, systems. But you still have, you know, once you build it, you still have to pay someone to operate it, right? So when I say pay, we generally mean, like, AWS or some sub-vendor, because you're not going to build your own, data center.

And so that's an ongoing cost that, again, we based on our calculator here. And then the cybersecurity part, somebody has to constantly look at these things, or constantly maintain that, even the minimum, just patch systems. You know, we patch almost weekly, because there's just so much out there. That happens. So there's a constant thing you have to do. It's not a system you build and forget. It's a system you have to nurture Pretty much every day. So that's all kind of cost that adds up over time, and so we kind of give this two options here, you know, our platform versus build your own. And we'll talk later, you know, sometimes our platform is not the right choice. But in many cases it is, depending, you know, what you have and what you're trying to build.

But you kind of see that delta here, you know, almost 3X in one year, and as it goes further, it becomes cheaper and cheaper. So, like, a 5-year cost saving is pretty high. so, the total cost of ownership over a long period is there. you could push on other numbers, so you can tell us this number is crap, which is fine, but these are kind of in our experience, and I don't think that they're too far off, where, based on your responses, that they're too far off from what you guys think as well.

There's a question from the audience real quick. Boss from David Hawks. Yeah, no, it was, what's the arc of the spend? What are events or milestones? So typically when, you know, when we're preparing, you know, one of these, proposals that might go out kind of earlier in our custom software days, like, what does that look like from a, you know, percentage up front, percentage later? What is the expectations that a team should have when it comes to spend?

So, I mean, the build happens early, right? So, again, it depends on the vendor. Some vendors want, you know, 50% app for some want 20% up. That really is a vendor, but from a big milestone is you are building, kind of, what I would call a verification-ready app. You can break down into milestones, sometimes. Again, it depends on how well you know what you want. So, we used to have customers that would know exactly what they want, and then we would have customers that have an idea, but not really what they want. So, if you know what you want, you can get quickly building to building, and getting to a VNV-ready app.

If you don't know what you need, then there's some exploration phase that you have to do to… so there's a more agile approach where you're building pieces, you're maybe validating it with your internal team, but also maybe with some either KOLs, or maybe some actual users, and so that phase then can be much longer, partly because we don't know what you need. But once you get to a VNV-capable app, obviously there's the whole verification aspect, and then the verification happens internally, but then the validation, which means now it has to interact with a bunch of other workflows. I said, if you most likely have a device, then you need to take that and then kind of validate the system.

Somewhere in that line, you have to think of cybersecurity, so part of your verification requires, you know, testing to be done, not just functionally, but cybersecurity testing, performance testing, maybe your other kinds of testing, depending on what you're trying to build. So all that kind of… I'm graphing right now, but there are milestones depending on, kind of, what you're trying to build. So, one would be getting to VNV, one would be to be done with BNV, then you go operationally, and then that is a continuous process after that. I don't know if that helps… I don't know if that answers, really.

I think if the… yeah, David, if you need a more detailed answer, we can kind of, we can chat offline. There was another question, is a licensed platform solution at all transferable to a different platform supplier?

It depends, I mean, not for us, but there may be other vendors that have that option, so it depends also what you mean, transferable. If it's, like, kind of a business continuity issue, then yes. If it's purely out of convenience, then maybe not. It depends on the situation.

I'll add, you know, if… we deal a lot with companies who, you know, just given kind of the life cycle of medical device, get acquired, and then, maybe the acquirer has their own platform, right? So this is not a… you know, kind of a third-party platform, but the acquirers, and I think that one of the things that we made very, that we very clear, kind of, when we were ideating this, was that we never wanted to kind of hold up an exit, so… the ability for the devices to be able to pull firmware apps to be able to kind of update themselves and redirect that data into the acquirer's infrastructure, if that's a mandate. Some companies decide to keep us when they get gobbled up.

But that's a critical piece of importance that kind of goes along with that, ability to kind of update the devices being of such importance from a cybersecurity standpoint, but also from a, from a business standpoint.

Yeah, and one, just because I saw a question, so one also to keep in mind is, you know. when you build something online, there's a lot of benefits, but that also comes with a lot of responsibilities, and in many cases, liabilities. So you have to also account for, kind of, the liability piece of it, say, so whatever insurance you need, and things like that as part of your cost. So there's more business Costs than pure technical cost that we show here. And to answer, I think it was Chris, we do take some liability if you use our platform. You know, it's not 100%, but there is a, there's a shared responsibility that includes shared liability as well. So we do have that aspect of, if you're interested in our platform.

So that sort of was the build part, the first, and then… so what did that cost to keep, right? So, you know, we talked about the, kind of, the infrastructure costs, like the AWS cost. Again, I put some numbers there that are on the lower end, again, depends on what you're trying to build. But then there's the cybersecurity part, and it's cybersecurity never ends, right? So there's one, you know, in medical device, if you're a classical medical device engineer, or a medical device executor. We talk about two kinds of risks. The safety risk. The safety risk is very different, because it generally doesn't morph very quickly, right? So if you have, let's say, a mechanical failure that can happen that maybe hurts the operator, you generally well know it, mostly, because

materials have been there forever, so you kind of have an idea. If you do… if you do the right research, you can test it very well. You can have, you know, a part move. thousands of times, see when the stress will happen, and when it will happen. You can generally mitigate it, and you will know that the mitigation is wholes, right, for a while. You may not know all the risks, so there may be new risks that may morph in the field. But generally, you have a good idea of the safety risk, and generally you are… Doing maybe a risk evaluation every 6 months, or every 1 year, because that's kind of the landscape of safety risk.

Cybersecurity risk doesn't work that way. It's very hard to test against everything. Jose will say that, even though we have good practices, but that doesn't mean, you are covering everything. It also changes, pretty rapidly, so you have to be on it for more… far more continuously, than… than you would do for a safety risk. It's Very hard to, kind of. create a probability model, for cybersecurity risk. In fact, we… internally, we never use probability, right? So we assume that there's a vulnerability, it is exploitable. you can't put a probability there. You can't say, well, maybe you think it'll mostly be exploitable. So again, it is very hard to do probabilities things that you can do in safety rest, because you have enough literature.

And then the profile doesn't change as much. So there is always this kind of constant pressure, to ensure that you are keeping a good security posture, and it never ends. So it is a… it is a continuous process. Someone has to own it, and that someone costs money, so you have to kind of account for that when you're hiring and building, and it also has to be the right profile. Right, again, we put some numbers here, but in our own internal organization, that number is much higher, because we obviously run a much bigger, infrastructure here, but it is something that Many times people don't account for, is the labor aspect of it.

that they account for in the P&L, maybe the payments to AWS, maybe the initial build, but that kind of the operation, especially the cybersecurity part of the operation, because it also requires some skills. It's not something, you know, I mean, a lot of IT people can't manage AWS infrastructure or Azure infrastructure, but doesn't mean that they understand cybersecurity as well. They understand the patterns or the right controls to put in. So we have to kind of, you know, consider that also, and it starts at launch, and it never ends.

I have a question.

Sure.

Well, it's really for Jose. You know, Jose, could you tell us for a moment, A, validate what they're saying, and then B, what's going on right now? What's cybersecurity? Are these prices gonna go up?

Yeah, I mean, so I can definitely validate that, You know, your responsibilities around cybersecurity. are not just pre-market, right? Like, from the moment you launch your device, you've got substantial requirements around cybersecurity. In fact, one of the things that you submit to FDA is a cybersecurity management plan that says what you're going to be doing, so you need to be reviewing your SBOM for any new vulnerabilities pretty much continuously on a daily basis. Because as Abbas was saying, like, vulnerabilities pop up in a moment's time, and if you leave them unassessed and unpatched for critical ones, it just means that somebody out there knows the vulnerability exists and can come in and exploit it. So you've got a responsibility to be continuously monitoring these things. So, you know, Baz is 100% right. Somebody's got to be responsible for that.

And then… and then there's other things, right? If there's a… if there's a vulnerability disclosure by a third party, you need to be able to act. If there's an actual incident. You need to be able to act. So there's a whole bunch of responsibilities. And, you know, the 608K number that he's given there, as he said, is probably conservative, because the truth is, especially with startups. your technical team probably doesn't have, like, significant cybersecurity expertise, and so if you had to bring on a full-time person with that expertise, I mean, you know, it's probably two to three times what's here.

And what's coming is very significant. I mean, right now, you know, if you followed, like, there have been multiple cybersecurity incidents in the last couple months. With AI agents. So, Claude, you know, they disclosed that they had their… they found that their agents that they were training kind of got out of their sandboxes and hacked multiple companies. OpenAI, there was an incident with Hugging Face, which is, like, a host of AI models, where the agent was just being trained, and again, it was in a sandbox, it broke out. So, like, with agents that are being where there's a significant attempt to keep them from hacking companies, those are hacking companies, right? So, when you look at all of the models that are not being properly controlled by Frontier Labs, right, like.

there's models… there's hundreds of models. People are familiar with, like, you know, Cloud and OpenAI and Grok and Gemini, but there's literally hundreds of models. And the companies that run those models, or the open source models, are not all led by teams that kind of have security and safety of the world in mind, let's say. So, over the next year, you're going to see very significant cybersecurity incidents from these agents being let loose. And we're in a tricky time right now, because the U.S. government has placed certain restrictions on the frontier labs precisely because of this power, but that ends up hurting on the defensive side, you know, because you want to be able to use these models defensively. So yeah, like, just the burden is going to go up here pretty quickly.

And yeah, chances are you probably don't want, you know, your little company where you've got one guy who's, like, running 7 things, you know, to manage your back end. If they're also responsible for continuously monitoring vulnerabilities and addressing them quickly, you're gonna be in trouble.

I would say this becomes a topic inside of, you know, Matrix One as an entity, we have many different kind of SaaS products, Matrix Connect being one of them, but every single, every single product that's being touched always has this, this cybersecurity question come about at some point in the conversation. So yeah, that, I think that is just the paradigm that we live in. Right? These days.

Thanks. And just to add to it, you know, there's also, like, a sales aspect to it, right? So again, if you're going to sell this into hospital systems, they won't understand your cybersecurity posture, so it's not just you saying, okay, I have this one guy that's going to do it. But what are the procedures? How are you doing this? So there's a lot of expertise needed beyond just the person doing the work, is to kind of get that… I've not seen, I mean, pretty much all our customers, they just followed us. their questionnaire, and we fill it up because we have all the answers. But that's… some of these are, a little bit…

complicated, and it required a lot of expertise and preparation. Specifically, if you go into, like, we just got one from VA, The VA has, you know, a lot more requirements than typical hospital systems, because they also add the government aspect to it, and there's a FedRAMP, and there's a lot of stuff like that. So you have to, from a sales perspective, also have to consider how you get these systems then into, wherever your target market is. And then you have differences between U.S. and Europe and other parts of the world, where the postures differ every time we go into Europe, especially Germany. Most of our customers, they have a significant higher barrier in terms of, you know, getting something online, just because

there is much more sensitivity and much more, maybe, conservatism in terms of bringing things online there. So again, we have successfully done that, but it does take a lot of work and a lot of expertise around that. There's a couple of questions, if maybe you can answer them right now, or maybe you can do it at the end. I don't know if there's a preference.

Slides, yeah, I don't know. Let's see what we…

Let's go through it, and maybe we can come back to the questions.

We'll breeze through these, yeah.

Oh… So, again, I think this is just a… basically re-saying the same thing I said, you know, standing obligation is managing access control and making sure that you know who has access today, so… and then as your workforce changes, you know, so people get onboarded, off-boarded, that you manage that right access of roles changes, and you manage the right access. have an audit trail, so people will ask, hey, I didn't do that, or who did that, or when did it happen? Having that audit trail, making sure every change, every data configuration is captured. Phi handling, not just for your customers, but also you, because you're going to, as a

If you're going to host this and run it, there will be PHI in the app, application. How do you secure it? And then how do you manage access to it, right? So that kind of management has to happen. Now, what are you anonymizing? Are you anonymizing anything? How are you anonymizing it? how you're exporting it for visualization? I mean, a lot of these questions you have to answer both in the product, but also in the operational aspect of it. And then a few things like uptime, I mean, it has to be up, so you just have to make sure you have enough, you know. Secondary systems or backups and things like that that allow you to kind of keep these systems up.

And, and available. And then, you know, data exports and integration aspect that we already kind of talked about. So I think, there is some cases, I want to talk quickly, where building is the right choice. So we generally think of four places where you should build. One is if you already have the right team, so if you have the right expertise in-house, if you, you know, the team is in the mix of, you know, software engineers that understand the clouds, they understand the kind of medical device lifecycle, the right cybersecurity people, the right IT people, the right kind of, you know, business people.

So if you have the right team already, and they're available, and the expertise is there, then yeah, I think building makes sense, because you can own the platform, and you can customize it very well to exactly your needs. Right? If… that's one case. The other case is if the cloud is the product, right? So if you are a digital health company with… that basically let's say it takes, images, from, you know, standard, CT scan or something like that, and then you are just running algorithms on it, and then you're presenting that algorithm output to clinician. Then the cloud and the kind of the process around that is largely embedded in your product. So if that is the product.

you probably should own it, in most cases, because then you are able to kind of move that at a much faster pace. So those kind of two, and then the third is where you have very specific requirements. that is not easy to serve with a custom, customizable platform. Then that's another thing I don't think… we have not seen that kind of stuff, but sometimes that happens. And then also, if you are, if cloud is, like, a very, very low priority. And you have a long runway, and you just don't want to think about it. And maybe you build a little bit, a little bit, a little bit, for, Over time, then again, you, that's another place where you can, build, and it doesn't hurt as much.

somebody said this is a good sales. I don't know if our sales team uses this, but sure. I think we should use it for qualification. But this was something I thought about, is like, you know, what, when do we… I mean, we have said no. We have said no many times to our prospective customers, that it probably makes sense, to build, you know, sell, because we don't want unhappy customers. So there's no point in having someone using a platform where it doesn't really match what they're trying to do, and then having this kind of, you know, weird friction, 6 months, 12 months down the lane, it's rather just not have a business, right? So I think it's…

Ultimately, we want everybody to be successful. Sorry, success with us, or success without us. Ultimately, just manages… we want success, in this industry. It's a small industry. It's a very small industry. So that's kind of a… I know we are running a little more time, so a little bit faster. So we have one more poll. This is the last poll. So, kind of, you know, maybe a question if you are holding up on this connectivity decision, like, maybe if you can say which, which of these is kind of maybe the primary reason, So, you know, the cybersecurity cost or ownership, cost of getting approvals, unknown regulatory, kind of landscape, no engineering, or, or maybe there's, maybe nothing.

So while they're answering that, I just want to talk about something that I learned about on Wednesday, and that was value analysis committees in hospital systems. And, I was just asking ChatGPT, does the Value Analysis Committee actually look at your cloud connectivity plan and your cybersecurity plan? And apparently, they do that in depth. Do you have any experience with that?

Yeah, so, I mean, we don't go in front of… so we don't go to the sales in front of the hospital system, so we don't have direct, you know, first-person experience, but a lot of our customers that do, eventually, that they take a lot of what we provide. into those, those situations. So yes, pretty much every, every hospital system that we know, that our customers have gone, have asked, for cybersecurity kind of information. That may include their own questionnaires, that includes sometimes, you know, what is the plan, how are you going to manage it. The security teams will look at, not just the question answers, but also kind of look at the, kind of, they are

our, you know, pedigree, essentially, you know, do these people know what they're doing? So there's a lot of… many times, there's literally an interview, so like, how do you do this? How do you do that? And even though the answer is inside the questionnaire, they want us to kind of, you know, probe us and really see, really, do you really, really know? these things, or you're just typing out because, you know, you put in chat GPD and we gave you an output. So yeah, I mean, it is all needed. Now, whether that is the exact committee, I don't know, because again, we don't have first-hand experience, but a lot of this information we provide.

I think a lot of it would kind of be, Yeah, probably, probably client-derived in that respect, just because they have their own, you know, they're the ones who are trying to basically, you know, prove their value to the hospital in different ways, so we might be a part of that discussion, and in some cases, they might speak at length about kind of what it is that we do, where we might be called in for questions, that we would answer to the medical device company. But, yeah, it's a… it's an interesting space, kind of, you know, right now with so many kind of cloud-connected devices trying to get into the hospital, and hospital systems making, kind of a lot of directional investments these days.

You know, kind of… That necessity of being able to provide value back to the hospital, when they might have conflict of interest with other devices that might come in at different price points, and maybe different, you know, connectivity headaches and things like this, how they kind of marry that, that decision, you know, for their patient's behalf. I think it's just an interesting thing to think through.

So, we're nearing the end, so I want to make sure that you get through everything that you want to say.

Yeah.

Yeah, this is one of the.

This is the last one. And I think this is mostly just kind of, I wouldn't call them kind of common sense questions, but I would say that these are, as you go through this process, these are the ones that are kind of organically going to pop up. you know, for what it is that we do, we are a critical path vendor, so we definitely encourage, you know, companies to ask us hard questions. I think that that is something that service providers shouldn't be wary of, especially if there is this deep level of trust that might be ongoing for years and years. So, here's some kind of core questions to ask. Kind of what are the costs? At the end of the day, you know, a lot of this infrastructure is built on, you know, the AWSs of the world, the, you know, the Azures and stuff like this, and their cost model probably needs to mesh with, you know, the services that that vendor is providing.

So, making sure that's harmonized. As far as the certifications, obviously that's a good way of kind of making things go quickly, as Abbas alluded to. You know, from a regulatory standpoint and from a sales standpoint. As far as the third question, you know, we've been talking a lot about cybersecurity, so basically, you know, kind of what is their plan? And even… even things like in a worst-case scenario, right? Outside of cybersecurity, what's the business risk? associated with working with a third party, whether it's maybe a small team who's building and then offering to kind of operate that cloud on the back end, whether it's a platform like ours, like, ask hard questions, I would say, is something that I would recommend. Let's see here, what evidence can you hand me? Absolutely. So, you know, how much audit support is there? Whether it be from the client side, a hospital side.

Whether it's from, you know, a third party auditing those companies, whatever it is, just make sure that they're supportive in a way that's, that can move the ball down the field. what happens to my data if I leave, and in what format? So you, if, you know, in our case, you know, we always export the data out and stuff like this. We try to make that process as easy as possible. You know, medical device software is kind of inherently sticky. When we decided that we wanted to make this company, we wanted to build the product that we would want if we were in the startup, or you know, project manager's shoes. So, making sure that you can kind of get off is just as important. We, you know, have 30-day contracts as an example. Some companies like to lock people up for a year or more.

And that might not just be conducive to the success of the company long-term. And then, kind of, where is the data stored and those regionality things, especially as these companies scale, you know, making sure that they can support you as the medical device manufacturer. You know, as you grow, you know, and make sure that you can hit your ambition, I saw there's… there's two questions. I think that was… that was by and large the end of it. Is there… is there an additional slide? Abbas to kind of wrap it up. Or is that kind of the, yeah.

Yeah, so I think we can take the questions,

There's two that I saw, I don't know. First one I'll read off is from Peter. What usually blows the 4-month in-house build estimate? We managed to build our prototype device in 3 months, and fully compliant with all applicable governance requirements. So, that's fantastic. Abbas, what have you seen that kind of can throw people off?

A few things. Mostly, it's if they don't know. Like, the major places we see that is they don't know what they want, so sometimes you… you have to kind of have a discovery phase, that may blow out, depending on what you find. Second is, in many cases, these are not just one the cloud will be one software, right? But it's part of an overall system, so sometimes you have dependencies. Like, many times we see, like, there's a device, and then there is the app, or there is the cloud, and there's all this integration that's needed, and then the integration doesn't go well. Because maybe one site doesn't have the right, timeline, or they're not up to speed to that point where you can start the integration and do full verification. So that then kind of

speeds up, or kind of, you know, delays, some parts of the build. People leaving, I've seen that happen. Important people leave, and then the knowledge goes away, and then you… if you don't have the right, kind of, setup, and with… with… the property building and stuff, that can happen as well. People do run with money, concerns, so again, funding sometimes goes away. So there's many things, but generally, it's mostly around scope. not being managed, or not being known up front. So if you don't know what you want, or you don't manage the scope, there's a lot of scope creep. And again, this is a classic product development problem. Nothing special about this thing, but that's where, in the build piece.

you have. What we also see is a lot of, kind of, follow-on issues. So, you build it quickly, and you get compliant, but when you go to cybersecurity testing, or you go somewhere else, some other testing, and you find a lot of issues that you may have to come and refix it. So, again, it depends on your process, so a lot of the process requires, you know, that you do you think about all these things up front, and so hopefully you don't have surprises at the end. But if you don't, if you leave your cybersecurity till the end and say, okay, my product is done, now let's have you know, Jose or someone else come in and test it, and that's probably a bad idea, because you're going to find a lot of stuff. You probably want that cybersecurity input up front, right? Things like that. So, I mean, it seems like, in the case of Peter, they've done it very well, so probably has the right team, you have the right team, and you could do it.

Last, last question here. How are you preparing, handling the shortening expiration times for certificate keys?

Yeah, so for us, I mean, we built out… our kind of assumption was always, you know, to build out a kind of a rotation, an automatic rotation, that the devices can do securely, that other systems can do securely, so that really doesn't matter how often, we need to, or how fast we need to expire these, these keys, as long as you have a way to kind of, you know, make the devices or make the systems rotate these things before they expire. We've not really had an issue, because again, we build that infrastructure up front. And we always had in our kind of policy rotation much, much sooner than what the standard expirations were, right? So we… for us, there's no impact, because everything we did allows us to kind of manage that very, very simply.

I know we don't have much time left, I don't know if there's any last questions, but before we leave, I just want to thank Sean and all the people for joining. Thank you so much for, you know, letting us join as part of this group, and thank you all for your attention this morning and all these great questions. It's been great, again, to see all these familiar faces, so I've really enjoyed this process, yeah. Great way to wake up on a Friday and have my coffee and chat with you guys about something that we've dedicated so much of our life to.

So… Yeah, thank you guys.

I'd like to thank you both, very much for your time, and everyone who came today and gave us your attention. Two things as we go. If you're interested in becoming a member of… MedTech Leading Voice Exchange, please, book a call with me, just, and we can talk about whether or not it's right for you. Lastly, you know, join us next week for Subtract to Ship. MDR with, Felix and Tibor. Two exciting names, and Final ask is if any of you know any interventional cardiologists that I can talk to, please, forward their information to me, or put me in touch. I am, writing a white paper on interventional cardiology, and could use a little guidance.

So, on that note, see you all very soon, and have a great weekend.

Thanks, everyone.

Thanks.

Hi, guys.