The Anatomy of Connected Medical Devices: A Non-Technical Guide to the Ecosystem

Hey, everyone, welcome. Let's see if we can… Days. Okay… If anybody would like to be promoted to panelists, just raise your hand.

In the meantime, let's see, I have to… Send a quick invite to somebody. Spencils… I hate that. Alright, this'll just take a second.

So, while we're waiting to get started. We have about 8 more minutes. I'm just gonna fill you guys in on some stuff. Let's see… I'm gonna put a link here to… post that I did yesterday about Last week's call, It's an article summarizing, everything that you missed, so it's a pretty useful Bing, please… Show some love to that, if you have a chance. Let's see, dropping it into the chat… Show…

Shit. Fast. Weeks.

Sean, can you make me co-host?

Yep. Sorry, didn't see you come in. more… make… Co-host. Confirmed. You're confirmed.

Thank you.

Sure. Mmm… And then the other thing that I wanted to share was that we have… A lot of upcoming events. A lot. One… well… 5, to be specific. And so I'm just gonna copy that into the chat as well. upcoming…

Let's see… LeanRAQA has launched a new Substack publication, which you might want to check out. I'm going to put the link to that. in here… If I can.

Wisely… Is the new…

Opening to the contractor, one second, Sean.

Okay. So the last thing is, new… lean… RAQA Kappa course, save 10%. In the link to that. Okay, so, Those are all my announcements. They're all in the chat. Please feel free to use the chat to communicate with, me and or Mark, or use the QA. If anybody would like to be promoted to panelist.

please go ahead and raise your hand. This webinar, will be recorded. The slides will be made available to all registrants tomorrow. Along with a link to the recording. Used to need a passcode, but now you just put your email address in, and you get in and can watch the thing, and it's pretty, One thing that, Zoom has gotten. better at… Because before, it was kind of a convoluted route. Some interesting things on the horizon. Next week, we're gonna have,

a guy I met recently who comes from Meta AI, or from Meta. was a product director. Hey, Andre, glad you could make it. And, he's gonna be demoing his, Reg tech startup, That, he's developed. for, medical devices. His name is Reese. So, check that out. That's in the link. And that's gonna be pretty interesting, and we're gonna get a demo in… hopefully, you know, different ways to access the thing and try it out, I don't know. But it'll be an interesting discussion. There's a lot of interesting things going on with,

with AI recently, including… our new AI-forward MLV100, which is gonna be released on the 20th, and I encourage everybody to… hopefully gonna be released on the 20th, and we have a release party on Friday the 20th, so… I want to get as many people that are in the MLV100 to join that call, and everyone else, As well, because it's… it's a new… online interactive version, and I can't wait to, demo the thing. Hey, Susan. Hey, Scott. Hey, Daniel. Welcome. How's everyone today?

Yeah?

We're good, we're good, good to see you.

Cold, very cold.

Very cold. Okay, well, I am still in sunny Fort Lauderdale, working from here. Update, my chocolate lab had little eye surgery yesterday. She had little cysts on her eyelids, and they needed to be removed. So, if you hear whining in the background, it's because she's wearing a cone. And we all know how much dogs like wearing cones. So, that, that's, what's new from South Florida. Let's see. So, today, I have been… I've known, Mark for a couple years, I think, at this point. And he's one of my favorite people to chat with. We have weekly chats about a whole bunch of stuff.

And he's… and… and we've… we've been talking a lot about connected devices, and… Although that seems… fairly obvious in a lot of ways. I think that there's really… for most of us who can't even really use the Bluetooth in the car effectively, the idea of having a connected device that is connected via Bluetooth in an emergency situation, and you're, like, trying to figure out how to pair your device with your iPhone or whatever it is that you need to do in order to make the thing work, I think you start to realize that, you know, a lot of that device connectivity is still

I'm gonna use the word janky, but I'm gonna use the word janky. And I'm gonna say, wow, what… I mean, like, yeah, seriously, hearing aid or, even my earbuds for… for… my iPad and my iPhone, I have a tremendously difficult time. Being Gen X. Maybe the younger people do better with connected, device connectivity than I do, but, yeah. So, with that in mind, I was like, Mark, why don't you come on and tell us in English how these things work? what the risks are, what, the advantages are, what the… you know… So, on that note, I'm gonna turn it over to Mark, and I'm gonna shut the hell up.

Hey! Good morning, everybody. So, like Sean said, here we're going to talk about connected devices. I get all kinds of… you get all kinds of just the wildest questions about the wrong topics, and… and I was hoping to share… all the background. that I wish all the… the non-technical people in… you know, developing devices in and around, you know, that people just don't stop to explain on the engineering side. A little bit about me. So, I'm the engineering director at Marcus Engineering. I lead the engineering team here. We do lots of embedded security, connected devices, you know, we build devices in medical, industrial, aerospace, and consumer market segments all over.

And, I'm not the mark in Marcus Engineering, so… Let's see. So, first thing is, what is a connected device? And so you may know that FDA defines this extremely broadly. You know, Sean likes to say, if it's not… if it's not made of wood, it's a connected device, which is almost true. But today. I'm… when I'm talking about connected devices, I'm talking about devices that have Bluetooth, or Wi-Fi, or Ethernet. Or devices that connect to a server, they connect to a record system, an electronic health record system, a hospital network, or just anything outside the device itself as part of its… function.

And, you know, the biggest thing is connected devices are really hard. There are a lot of moving pieces to understand, and lots of new areas for risk. And I think lots of people jump willy-nilly into making a device connected, because it's… it's fun, it's sexy, you know, if I go, we're gonna have Bluetooth, we're gonna have an app, we're gonna do this, we're gonna integrate with that, and it's… it opens up this huge… surface area for new risk, for new complexity, you need specialists in a whole bunch of new areas. And today, one of the things I want you to come away with is. Figuring out, hey, are we making a connected device, or are we accidentally making a connected device?

And that, I think, is one of the biggest things. So the first thing is, how do I know if it's connected? Sometimes I hear people say, oh, it's not connected because I don't have Bluetooth. was, like, Bluetooth, Ethernet, even if it's not wireless. that is still a connected device. Wi-Fi, if you… And some people don't talk about those things. Some people say, oh, it's not connected, it just connects to the… you know, just connects to Epic, the… their electronic medical record system, or the electronic health record system. Well, it's not connected except for the server, or, you know, well, we… it's… it's… we can just connect to it remotely for troubleshooting, or, you know, we can integrate, or all these things. These are all the keywords that you should be

listening out for. When you hear this, you're like, oh no, this is a connected device, even if people want to try to skirt the line or be selective. These are still connected. And lots of the things we hear about is even things like, well, we have Wi-Fi, but we're not using it. Or, you know, it's not really connected, this doesn't count. And if you have Bluetooth, or Wi-Fi, or Ethernet, or any of these interfaces, and you're not using it, just get rid of it. If you have these interfaces, and you don't use them, the only thing you're doing is spending all of the risk all the complexity of making a connected device, except if you're not using it, you're not getting any of the upside. You spend all this engineering time, you take on all this regulatory risk, all this post-market work that you have to do.

and you're telling me that it's for no reason, then you just gotta get rid of these things. And some people will say, well, we just will turn it off. it… it… Most of the time, your examiners are not terribly excited to hear about that stuff. If it's there, it's still a risk. You just gotta rip it out, just physically remove those parts. And lots of other people talk about expansion for the future, and things like that, and you have to be really careful, because it's all the same. You're taking on all this risk today for this future future. And, you know, I like to tell people it's easy to change stuff in the future.

You know, you're making a headache today for all this stuff. so, the… I want to jump into how do these work? I often get questions that are the equivalent of, you know, how many… how many miles per hour is my gas cap rated for? Like that, from people who are… When they haven't… Had the engineering team take the time to sit down and explain to them what on earth is going on? Like, what are the big pictures? What are the big blocks? How do they fit together? Because you can't understand the details unless you understand the big picture first.

And so, this… this is the most common way that we see connected devices today. We have some device. connected to a phone, usually via Bluetooth. And then that connects to a cloud service. on the other side. There's some other patterns I'll talk about later, but this is by far the most common one that we see. And so, the first thing we're going to talk about is we're going to dig into the device. So people think of the device as this one thing. This is… this is not how you should think about a device. You should at least understand some of the little parts of a connected device. And I like to split these in these, like, 4 big blocks. We have…

At one end, the thing that it does, the sensors, the effectors, the outputs, the inputs, there's… we have to do some work on those things, some processing. And almost always there's storage. Settings, just a little bit of detail, sometimes it's PII, sometimes it's really scary, and then there's transmission. So this is the part that makes your connected device a connected device. If we can get this data out of the device, or command this device to do stuff. That's the definition of a connected device. So, the first thing on the sensor side, so this is where the rubber meets the road, this is what the device does. So, tons of things, everything you can imagine, from EKG, EEG, pulse oximetry, pupil size, you know, measuring, sound to estimate

What's going on with, you know, different parts of the body, measuring if your blood is pumping, measuring if your GI system is moving stuff through, ventilators, electrocautery, all the things. And the… when you see this stuff, the… I want you to ask your engineering team, you know, it's like, what does this device really do? You know, what are the… what are the… not just what's the clinical things that it treats, but what does it do when the rubber meets the road? What are the functions? How does it do those functions? What are all the moving parts to get that done? And then the other one is what data does it collect? And this is really important to understand, like, what information's flowing through the system.

How can this device affect the world? And sometimes people are not very, Thoughtful or inventive when they're thinking about how can we affect the world. You know, you can have… things like a ventilator can shake and make noise, or you can have, you know, electrocautery that can go off at any time and affect things. You know, you can have stuff that makes sound, you know, make a piercing noise to affect, you know, annoy the nurses or disrupt their operation. And that's really in service of thinking about what's the worst thing that can happen. You know, I worked on, thermostats at Google, and those have a big, a really big…

security footprint, because people are like, well, what could you do with the thermostat? You know, it's not… you can't do anything bad, can't hurt anybody, it's not a medical device. Well, it turns out, if you, turn off or you disable someone's thermostat in the middle of winter, people have died that way. Or if you turn up the heat when you have pets at home. or you turn down the temperature, and you have children or vulnerable adults, you know, massive surface area for bad stuff to happen. And oftentimes, people aren't really thoughtful about what's the worst thing you could really do with this system.

And so that kind of takes us to the processing. And so, I always like to think about, you know, turning data into information, you know, like, we get these ones and zeros, this raw, squiggly lines back, and, you know, our device, they usually do something like turn that into a score. or turn that into a diagnosis or recommendation, that kind of stuff. As well as the storage. And that's… and Every device has storage. If people tell you it doesn't have storage, you should give them a funny look. Because it stores the firmware on the device. Almost everything is going to have settings. They're gonna have readings. Lots of devices will store all kinds of PII, name, ID, birthdate, you know, lots of different classes of information can count as PII. And then on almost all devices will have some kind of security information. They'll have keys, passwords.

They'll have… how do they access the wireless stuff? How do they know other things are connected? And when you're thinking about this portion of the system. you know, you want to ask them, like, where does the thinking get done? So, some devices do all their thinking on device, and they're turning that data into information. Some of them do it in the cloud. So, for example, your Fitbit actually uploads most of its data, and that processing gets done in the cloud, not on your device. And you'll understand, like, where is that work being done? And the other one is, do we store any patient information? And people might say no, and then you'll say, well, how do we know

what, how to ventilate these people properly. You might be like, oh, we put in their birthdate, so we know their age, and we put in their, weight, so we know how, you know, how much to ventilate, and those are both great classes of PII. And then the other one is, it's the security-related information. And part of what you're looking for is the answer to this question. Hey, we store these keys, or these things, which are sensitive for these reasons, you know, what's the bad outcome that happens? But the other thing you want to look for is, do people actually know what this is? If you hear people who… if you ask our engineering team, and they say, well, I don't know, or I'm not sure, or this is stuff, those should be red flags for you to say, hey, we need to stop

And get some… get some people who are experts in this area, or, you know, this is an area that we have not put enough effort in. And that's kind of similar to, where is our SBOM? You know, they're gonna… an SBOM, for most people who are not in engineering security fields, is this long, complicated list of gobbledygook. And… The main thing is not to look at it, and… review and understand, be like, whew, yes, this OpenSSL v4.6. It's more an activity to understand from your engineering team. hey, do we have this document? Is it… is it up to date? Do they think it's complete? Did they dig this out of some dusty corner from 6 months ago? Or are they sending you, hey, here's the latest version right here?

You know, do they understand what's in it? Are they checking it? And then the last one is, how do we update this? That's one of the trickiest things about connected devices, is updating the device. How do we, get new software? How do we fix problems? That kind of stuff. And it's one of the big things that the engineering team and other development teams will leave to the end or dismiss as not that complicated. If updating your device isn't top of mind from the beginning, that's a massive red flag. It's one of the hardest engineering tasks, and it's one of the things that I constantly see engineering teams underestimate.

So if they say, oh, we'll get to it at the end or something, you should really be worried about whether or not those functions are going to work, whether they're going to be done on time, those kinds of things. You want to hear people give confident answers, talk about how it you know, they're tested, it works. Whenever they develop it, they use the same update method the people in the field would use, those kinds of things. And then the… the last part here is the transmission. So, how do we… how do we get this stuff out in the world? And this is where the… this is how the bad people get in. the… when people are doing cyber attacks, most of the time, they're not doing it holding the device. You know, we're… we do lots of hardware security, we worry a lot about that, but to be honest, if you are standing in front of the device.

I can do just as much or more harm by picking up the device and beating the patient in the head with it as I can by opening it up and cyberattacking it. All the cyber attacks come from someone who's far away from us, and they do that through this communication method. And when we talk about transmission, like I said before, it's not just… wireless protocols that you should be thinking about. If something connects to a network, something connects to a computer or USB, those are all just as vulnerable, just the same. People think that it's, it's different, oh, it's not Wi-Fi, or it's not Bluetooth or something.

That's actually just… we're unlearning the lessons in the past. In the past, when everything was connected over Ethernet, those things were all just as vulnerable, and you should be just as worried about that surface area. And so one of the big things to ask is, is the connection required to function? And this is a big risk area. If you require Bluetooth connectivity for your device to work, you know, that's… that's something that you should be really worried about. You know, like… like Sean mentioned. you know, if you have a doctor fumbling for their phone to pair to, you know, tell if we have a shockable rhythm, you know, that's going to be a really bad time. We often see people who are excited about the connected features, but they're not thinking about

well, gosh, what's gonna happen in an emergency? Or what's gonna happen when, you know what, the Bluetooth doesn't like to work on my phone today? Those are all really… really scary things that people don't think about until they've been bitten by them. And that's kind of the same as the risks occur if we lose connection. And, I like to pose these questions separately, because… people think about them differently. Some people say, well, it's not really required to function, and then they say, well, what risks are there? And they're like, oh, well, you can't see all the data if you don't see it. Or, we don't show errors except on the phone, or you can do all this stuff, but you can't change the settings. There's all kinds of…

These use cases, and you need to understand which ones you can and can't do physically and over the device. The next one is, how does it get connected? This is something that often kind of gets left aside in lots of devices, where, you know, they're like, oh, we're going to connect over Wi-Fi, but there's this seven-step dance you have to do to get it connected to the internet, or get it connected to your phone, and then you connect it to Wi-Fi, and stuff like that. And then the other one is, can we connect in more than one way? So some devices will have Ethernet, and Wi-Fi, and Bluetooth, that kind of stuff, and you need to kind of treat all those interfaces separately, because if you are…

connecting over Wi-Fi, that's gonna have a whole separate set of risks than connecting over Ethernet. And those might even be connected to different places. And you might say, well, over Ethernet, we trust all that information because it's hardwired, and you shouldn't. or we're connected over Bluetooth, and that's how people change settings, and we have Wi-Fi just to report data. You know, understanding how those interfaces are used and how they're different is something that you should really ask and understand with your engineering teams. And then the last one is, did we reinvent the wheel? So…

Lots of people really like to… make something new. And engineers love making new things, that's… oftentimes why they become engineers. And it turns out that's really bad. You know, the, the work of Doing the last 20% that takes 80% of the time. That's not the fun work, and that's the work that the engineers would rather not do with an existing device. We're gonna go invent something new. And so here I have this example. This is a, a deep brain stimulator. And, some of you might see this Bluetooth here and be like, oh man, I don't want an implantable Bluetooth. That sounds really scary. And to be honest, I'm really heartened

when I see Bluetooth here. And the reason for that is. Saying, oh, this has Bluetooth, and Bluetooth is vulnerable, you know, people attacked this, this is a common thing, my iPhone has Bluetooth, how can that be suitable for this? Is… is kind of antithetical. If you… Have your own wireless protocol. you're gonna make all the same mistakes that Bluetooth did, except the Bluetooth has thousands of the smartest people in the world designing and building the protocols, and thousands of the smartest people in the world attacking it and breaking it down every day. They've made So many mistakes, so much new technology has been invented to attack and defend it, and so much complexity is there.

And if you say, I'm gonna make it myself, you're just kidding yourself, because you don't have… I promise you don't have Thousands of the smartest people in the world to go invent a new wireless protocol, to go attack it, to go defend it, to get all the best people. You're gonna end up in this situation. So this is a couple of years ago. There's the St. Jude Medical, now, Abbott, the Ascent, and a couple of related pacemakers. And so these guys invented their own RF protocol many years ago. And when they had about 530,000 of these implanted, they had a security issue in their RF protocol, and it was one that is well known to the people who do RF protocols, even at the time that this happened.

Something that, you know, kind of like the baby mistakes that people make. And as a result of this security issue, they had to go do a bunch of updates and a bunch of changes, and they had… I dug through all of their incident reports. And they had 11 remove and replace surgeries as a result of the security issue, and 18 people who got hospitalized for side effects and issues related to this. And this is really what happens when you invent it yourself. You know, you're kind of sticking your head in the sand and pretending it's not going to happen. When you use a protocol that, like Bluetooth, that's well known, you're not going to kid yourself into thinking, this has perfect security, or we're gonna do an awesome job.

You can be very realistic about what is actually, You know, what the risks actually are. Okay, so the next part we're going to talk about is phones. And this is… this is maybe one of the weakest links in the whole device chain here. Lots of people think about their phone on the app as, like, oh, the only purpose of this app, this phone, is to run my app. And I don't know, there's other stuff on the phone, but it's not that important. And what you should really think about is, this is the reality. I went and found the 5 most popular apps on the App Store, and they were not… they were not amazing apps here. This is, what's really on people's phones, and your app is a small part of the software.

Running on there. And so, you know, everything except for your app is a security risk and a performance risk. You know, these are all things that are… Massively impacting how you should think about the data that flows through your apps, what your apps can control, how they can affect reality, and the devices. And really, the biggest thing that you need to ask people is, is how do we… how do we manage the security, and how do we manage the safety of running on this uncontrolled device? You know, you hear all kinds of things about how We're gonna make our device, and it can be controlled through an app to do anything under the sun.

And, you know, like, oh, well, does that include changing your pacemaker settings so we force your heart into fibrillation, or, you know, turning off the ventilator, or, you know, setting the power on our, ultrasound to be higher than it will… the damage limits, or things like that. And those are all the stuff that you should really be worried about when you have apps on your phone doing stuff. And kind of the converse is that, Your phone is probably the most secure device that you own, and part of that is because the people who make iPhones, people make Google, products and services have the smartest security engineers in the world defending against this tidal wave of bad stuff. But that doesn't mean that users don't install, you know, all kinds of

From all kinds of wild places that can really affect your device. And so there are a couple of patterns that we see, how people… how phones get used. So, when you're… understanding the device, you should try to really understand what pattern do you fall into. And so the first one is people use their phone, kind of like a TV screen. It just views data. They can't control the device, they can't process the device, and this is actually one of the lowest risk ways to use an app, is just to view data. And so, we've seen Bluetooth thermometers, Bluetooth pulse oximeters, other kinds of diagnostic devices where they're just viewing the data. You know, it's being processed on device, potentially, you know, like a Bluetooth-connected stethoscope, and it's presenting some information back.

And one of the things that you want to ask is, you know, is this data live? And what happens if it's not? So if we're, for example, viewing, a, temperature. Like, if we have a temperature sensor used for triage, and then we are using it across multiple people, and we're looking at the data that's old, because our Bluetooth connection drops, because that never happens to anybody. All of a sudden, you might misdiagnose or mistriage somebody because you're looking at old data or outdated data. That's one of the most important use cases you should be thinking about. And the next one is alerts. So some people…

We use devices to get alerts when something bad happens. Like, I have not seen a Bluetooth ventilator used in this way, but if you imagine you had a Bluetooth ventilator that sent a Bluetooth alert, hey, when it needs, to be serviced, or when it needs help. I don't know about you, but I have definitely missed alerts on my phone all the time. And making alerts and apps good is really hard. So you need to make sure that, you know, do we expect to have safety-critical or important alerts? How do users get those? And how do they get those without their phone? And the next one is, you know, like, what parts of the phone do we rely on? So, one of the patterns we do see is that people will rely on things like the GPS from the phone, or they'll rely on the phones having a good internet connection, if you're in an area that doesn't have Wi-Fi, but maybe we're relying on a cellular

And this is something you really want to ask your engineering team about, to tell if they're thinking about it, and to make sure that you understand what parts those are. Because if you rely on your phone having an internet connection. Then you need to really think about what happens when that isn't the case. Or, you know, if you rely on the GPS or the, you know, other functions, you need to understand what and how and why, and then what bad things happen when we don't have that. Because not all phones are the same, not all phones will operate well, not everything is the new iPhone that works great, that's sitting on your desk in good cell connection.

And then the other… the last one is, do we get data from the cloud or the device? And… and this is something that you might be surprised to learn, that you… you have to ask this question, because lots of devices are actually designed where data gets passed through the device up to the cloud, and your app is actually viewing data from the cloud. It's not viewing data from the device at all. So this is actually how your Fitbit works, how lots of people's smartwatches work, lots of different trackers, and if you… understand it a little bit differently, or a little bit wrong, then, you know, that might really change how you view the risks and how you view the device ecosystem.

So the next one is remote control. So this is where we kind of step up from the last one. We're not just viewing data from the device, we're controlling data, or we're controlling the device. And so, you know, there's some Bluetooth bread pressure cuffs where we can tell it, hey, I'm going to start a measurement, or Bluetooth surgical lights, where I'm changing it, I'm turning them on and off, I'm affecting it, those kinds of things. And the best one is… the best question that you need to ask is, what is the risk of not being able to send commands? So, for example, in a Bluetooth surgical light, if you can't change the light, is that critical? You know, some people, some surgeries will set it up, and

We start surgery, they're on, and they're… They're the same throughout the whole surgery. And for some types of operations, people will change the lights all the time, they'll affect it, they'll turn it up and down, they'll move it closer, they'll move it further away. It's a big part of it. And… If all of a sudden your connection drops out, or you don't have your phone, you know, all these kinds of availability problems are things that you really want to understand. The next one is the worst possible message you can send. And this is something that really requires some… I… creativity. So, your engineering team might say, for Bluetooth surgical lights, well, the worst thing you could do is, I don't know, turn them off.

or turn them all the way on, or something like that. And you might find out, or talk to somebody who says, well, gosh, what if I turned them on and off rapidly? You know, they were flashing on and off. That could be a lot worse, you know, much more distracting. Or, if I'm sending Setting some settings for, like, a ventilator, for example. you might… your phone might say, well, gosh, the worst message I could send is to, you know, just be slightly hyperventilating. But you might find out that under the hood, you could send a message that would inflate 2x or 10x the maximum allowed tidal volume, and all of a sudden cause serious injury or death to someone.

It's not about what's the worst allowed command, it's what's the worst possible command. And the next one is, is there an override? And when you're asking about Overrides in the system. Especially in these kind of remotely connected devices, it's gonna tell you a lot about how much risk How much risk analysis and how much thinking through the engineering team and the design team has done, because if they… If turning off the lights, or changing the settings, or overwriting what somebody can do remotely is not top of mind for them, then that's… that's gonna be something that's gonna tell you that they haven't really thought through what's important here.

If they are thinking about that all the time, or they have a strong message for, oh yeah, this is how you stop it, this is how you disable connections, this is how you change the settings, then that, you should feel, you know, more comfortable that they're thinking about all those kinds of risks. And the next one is… you know, can the cloud send a command? So you might have this great device connected where they can control stuff, but the last one is. You know, maybe you say, gosh, your clinician is standing right there, they can see what's going on, they can make the right choices. But if you can send commands from the cloud, even if it's, you say, oh, well, they shouldn't, it shouldn't happen, it might not happen,

Those are the biggest things that you should be worried about, is, you know, could this happen? And consider all the risks of. You know, random commands being sent from over the internet. And then the last one is, does the phone have special access? So, a lot of times in these systems, the phone acts as a key. You know, this paired process, we trust the phone. More than we trust any random device. And… When you have those kinds of trust in a phone, there's a whole set of things that you should be thinking about, and you should be asking about. Related to how do we… how does that phone get special access? How do we deal with it? And what's the… you know, why do we have special access for this? And the answer should all be, you know, risk-related, about people doing bad stuff.

Connectivity, actions that somebody can take, and the limits that we expect to have on those actions. So the next one is the brain. So we think about this one where we're processing data on the phone, and a big area… one that we see in this area is continuous Bluetooth glucose meters. Where they are measuring, you know, they're connected to a glucose meter that's on the person, and then the algorithms that are processing, hey, what actions do we think the user should take? Here's how we're Creating these predictive insights, or here's how we're, calculating all these, you know, special values or these algorithms that are

you know, unique, why we're buying my meter instead of a different commercial one. These often are running on the phone. And when we're adding… when we're running stuff on the phone, when we rely on the processing and the horsepower and stuff like that, it's really important to understand, you know, what happens if we have a crappy phone, or what happens if your phone doesn't work that well. And those are big use cases that we often see missed. You know, people will test the phone with a brand new latest device, with one or two devices, and it turns out the world is a big place full of so, so many different devices, different people, different models of phone.

You know, people who truly support a broad range of models of phone have large engineering teams to do that. If you're talking to your engineering team about what devices have you tested it with, what do we support, that kind of stuff, and they tell you, hey, we support every iPhone and every Android phone. And they have one person whose job is to do that, you… you… there's no way that you're going to be able to have that kind of broad device support. You know, you need to either… You either want to see that they have a really specific list of devices that they support, that they tested it with, and that they expect their users to use.

Because if they tell you everything, you know, they better have a team of 10 people whose job it is to do compatibility, and buying phones, and testing and looking at field data. And so the next one is, you know, what happens if the phone's too slow? And that's kind of similar to, what if the app stops suddenly? Phones will kill apps all the time to save power, to save data, to make the user experience better, maybe because they're running low on battery, or because they're running slow. And you need to be prepared for that. You know, we see people who write desktop software, trying to write phone software, where they assume the phone will let you run forever, they assume it has tons of processing power, and those are… it's very different from that.

You know, you want to ask the teams about, if they ask… if you ask these questions, and they have good answers about, like, oh, if the app gets killed. we wait, you know, our users don't need it in the background, you know, if the phone's too slow, you know, we have messages, we warn people about it. If they have good answers to these questions, then that's a good thing. But if they… if they… brush it off, or they're not thinking about it, or they haven't put effort into this, you should really be worried about Whether or not this thing is going to work across patients, whether there's going to be risks because people use devices you didn't test, those kinds of things.

And one of the other ones is validation. When you see people developing hardware that works with phones. you should expect that they have a library of phones. If you ask them what their library is, or how they validate and how they test, and the answer isn't, I have 10 phones on my desk, or our engineering lab has all these devices, you should be worried about it, because you really… that would be typical In these kinds of high-end engineering practices, where we are Targeting devices, even just for a subset. And the next one is, what does the device do on its own? So, sometimes we'll push all the processing out of the device, and then that makes a bunch of risk controls really hard. So, if you have a continuous glucose meter, for example.

And… it can't, on its own, tell if something is going bad, if it needs to warn the person. You know, it can only do that when it's connected, and if somebody's phone disconnects silently, and I don't notice for the whole day, and all of a sudden I have bad outcomes because of that, You know, you should be really worried if devices can't perform basic functions on their own, especially for these devices that are autonomous, they live on… separate from people, those kinds of things. And then the last one is, PII. So, lots of people will have PII on their phones, on their apps, that kind of thing, and you want to ask people, your engineering teams, about if they have it.

Do they understand, hey, here's all the categories we have? Do they have a plan to protect that information? Are they storing it securely? If they can talk to you for many minutes about all those kinds of tasks and those things and how they're doing it, then they're probably doing a good job.

Mark, I have no idea what PII is.

PII, personally identifiable information. So that's, and there's the… and then… there's all of the health-related information that makes it HIPAA compliant. So, like, birth dates, names, dates of birth, phone numbers, all of this kind of sensitive information that is gonna get you in trouble with HIPAA violations if it gets out in the world.

Thank you. So, I just want to mention something before we go any further.

Yes.

Mark has built a chatbot that's going to allow you to interact with, this presentation and everything that he's put together, so you're going to want to hang out to the end of the call to get the link to that chatbot. Yes?

Yeah, absolutely. Okay, so we have the… the last one is a gateway, and so I talked a little bit about passing in information, and so this is another common pattern we see, where the devices Their only job is to take data from the device and pass it to the cloud. And they're just there to act kind of like, intermediate connection devices. And like I said, this is how lots of Fitbits work. This is actually, one of the most common patterns we see for devices, is where, they pass data, but they don't really do anything. And that's a good thing, you want that. And so, the biggest one is, what happens to the data when we're not connected? Some devices will,

I… Some of the devices will just throw away the data if you're not connected, and that can be really surprising to users, and it can lead to kind of weird risks. Like, if we're doing trending, or if we're collecting data, and we have these big missing chunks, because that data just kind of goes away, You can have really subtle and complicated problems. The next one is, do we store any data on the phone? Which is kind of the opposite of this. They might tell you, oh, we store data on the phone, and you should think about all the same risks about that personal information. Do we store it? Do we pass personal information? And you should ask about what,

what's the strategy for protecting that information? And for, keeping it from going somewhere. And the… the last one is, how do we authenticate to the device in the cloud? Your engineering team should have a really good message, a really good story about how they secure the information, how they secure those connections. And if it's not something that they thought about, or it's not something that they have expertise in, that that's another area you should really be worried. So, I want to talk a little bit about other device patterns. So, we talked about phone-connected, so that's where we have devices connected to phones, which usually connect to clouds. And then there's two other patterns that I want to touch on here that are common that we see.

So the first one is gateway connected, and so this is where they do the same thing as a phone connected. We have a device, and it connects to what we call a gateway. Just something else that then connects to the internet, to the cloud. And we see this a lot with implantables, so this is a very common pattern. Like those two I talked about before work exactly this way, where you put this device in your phone, and you then, I… or you put this device in your home, and then it autonomously connects to the user's implantables, and communicates up to the cloud, and sometimes can send commands back down from the cloud, so they can have their, physicians change settings, review what's going on, those kinds of things. And…

This is… has some of the similar questions, you know, where you want to ask about how do we store data, how do we store personal information, this private information? How do we authenticate to the device, to the cloud? These are really important things. You know, what's the worst thing that we could do? So, for example, when we have devices that can control implantables, you can get into really scary situations where you can send remote commands to cause all kinds of problems. And, you know, how do we update these devices? So, updatability is absolutely core to the, cybersecurity guidance for the FDA.

And if you can… if you can't… Update your gateway, and you can't update your device, it's gonna… you're not gonna be able to get this thing approved. Lots of people forget about the gateway as a separate part. They'll think about the device, they'll think about other parts, but the gateway is part of your medical device. And then the last one is, how do we secure the wireless? And if you hear from them, we designed it so it's perfect. We made our new thing, we did all this cool engineering work. You should be really scared. They should tell you that we're using a protocol that you've heard of, like Bluetooth, or Wi-Fi, or something like that, and that they are securing it in the normal ways. Because if they're not doing those things, they're making it up as they go along, and they are going to make mistakes that other people have made before.

And then the last one is this Hospital and Internet Connected. And this is where your device connects directly to the internet with no bits in between. And so, we see surgical robots do this, we see ventilators, infusion pumps, those kinds of things that connect directly into networks in hospitals or in the internet. And one of the things that people talk about is, like, well, if it connects to a hospital network, that's less risky than directly to the internet. That's completely wrong. There's explicitly, the FDA tells you that you should treat the hospital network as a hostile place. It's just as bad and scary as the open internet.

And you should really, really be scary of the open internet. This is by far the most risky device that you can make. When you make these kinds of devices, you need to make sure that you have teams with serious cybersecurity expertise. If you have teams who are… this is their first device, or they are not security engineers on board with you, and you're making a device that connects directly to the internet. that you should really be afraid of what's going on. This is the hardest, hardest thing that you can do. And the first one is, you know, who are the security experts? And lots of people will say, well, hey, we have all these smart software engineers who could build software, and

you know, the thing is that software engineers are not security engineers. You know, this would be the same thing as if you said, is if you heard from your engineering team, hey, who's doing the regulatory work? Who's doing the filings? And the engineers were doing it. And you would be like, man, that is not their area of expertise. They're gonna make all kinds of mistakes, they're going to share all wrong kinds of information. You really need people with background in security. to be doing security. And software engineers are not security engineers. And the second question is really kind of the inverse of the first question, because, if you don't have people who are experts in this kind of directly connected to the internet regime, it's really going to be a bad time.

And the next one is post-market security. So lots of engineers, lots of people who are designing devices for the first time don't realize that a ton of engineering needs to go into the after-you-get-to-the-art part. If you ask the engineering team about the post-market part, of security, and they say, I don't know, we'll figure it out in the future, or it won't happen, or whatever. they are not thinking about it appropriately. They are going to have a bad time with what's going on. And then the last one is penetration testing. So, tons of, tons of people. can get away without doing penetration testing for all kinds of connected devices. We see it a lot where people get approved with just doing testing at their security, they validate their controls, those kinds of things.

But if you're directly connected to the internet, you really, really need to have security penetration testing done by independent people. who have the required expertise in the field. It's critical to get this stuff done. So, that's, that's the end. So this is the… the link that Sean talked about here. So we've connectedchat.marcusengering.com. And, you know, this is everything, hopefully everything you wanted to know about connected devices, but were afraid to ask. You know, my background is strongly in engineering, and I find myself all the time talking about things, and people look at me like I'm crazy. And, you know, hopefully you can ask your dumb questions and get good answers, back without, you know, to help you build expertise, build background in what is going on, and ask all the silly questions.

This is my favorite, one of my favorite XKCDs on experts. I modified it slightly for us here. You know, it's so easy for people who have a strong background In engineering, in all these tasks, to, You know, lose sight of, hey, what knowledge do people really have? what stuff do people really understand when they're not in their field? And, you know, I think it's one of the important things to take away. Let's see, and go…

So.

Oh, go ahead.

You can read through the questions while I blather for a minute. So, he just went through, like, 30 slides, and on, like, 15 of them, they had questions to ask your engineers. Those questions right there are extremely valuable. I mean, I don't know how much time you guys spend talking to engineers, or how many of you are engineers, but I have to tell you that, you know, this… this kind of information, is not the kind of stuff that regulatory and quality people usually see. And I love it. So, you know. get the slide deck. I'm gonna send it, with their… with the email tomorrow. You're gonna have access to it. Remember, you need to hover the mouse over the name in order to download the thing from LinkedIn, whatever, it's a horrible thing. But,

If you don't get it, just email me. I encourage you to interact with this chatbot, and in the meantime, we're gonna do the human bot. Mark is gonna… answer some of the questions that were put in the thing. Carrie Beth also had a question. She wanted to come off of mute and maybe ask…

Mute.

Yeah.

Hi. Hi. Mark. Thanks, Sean. Good morning. I've been in regulatory with notified bodies for about 12 years, and a lot of devices have or… or the connectivity, and you talked about the sensitivity, and asking these questions with your engineers, but how are they tested? You talked about penetration testing. And what is the difference between that and, like, ISO 27001 that, you know, I'm familiar with in the regulatory, ISO field? I'm asking this because I've met with Fitbit. Apple, and, they don't seem to do it. They… they do them their… themselves, and…

I, you know, we know that, software as a medical device should have 27001, at least in my book, but, why is that not as common, and how can we This group talk about you know, why is that, and how, is it even better of a, let's say, a security method? Because I do find that it is, chosen when it comes to the stakeholders. When there's a need. you know, that's when it's, it's activated, right? But then I did have, and I still, I still have, clients, but, you know, the,

others that choose it, like DocuSign and Salesforce, have been my clients, so I just… I'm having a hard time Connecting when it's chosen, and why, and why it's not more often, even.

And so I think there's kind of two parts to that. So the first part is, What's the difference between penetration testing and, like, testing that you might do as part of, systems for doing secure software development, which is… and having secure practices, which is really, you know, ISO 27001 and a bunch of other standards. And the… the biggest one is independence. So, you know, with ISO 27001 and other security practices, you're self-identifying, hey. where are security risks gonna happen? Where are, not just security risks, but other risks gonna happen in our connected device? And we're going to have specific, things that we're going to do to prevent that. Like, hey, we're going to not accept messages that aren't properly signed and authenticated. We're going to, prevent someone from communicating with the device if they're further or made in a certain amount.

And those would be, kind of, validation-type activities, where we're going to test a bunch of specific security controls that we put in place to make sure that this one thing we did works properly. And then when we do penetration testing, that's, done with independence. So, if you're Google or Apple or a large company like Salesforce. You have enough… you have separate teams, they have separate experts inside those companies who are not part of the development team who can do that testing with independence. Most companies are not that privileged to have in-house experts in engineering to do that, and they work with outside companies. And penetration testing is usually undirected. It's not, hey, I'm gonna test the risks that you thought up to see if they're… you did… you…

protected those correctly, I'm going to go and, as an expert. try to find the risks you didn't think of, or try to find the gaps between the, the preventative measures that you did. And then choosing what kind of standard that you're gonna use to help guide your secure development framework, is, you know, an open question. Some people have their own, some people's are standard-based. And different companies, you know, if you're working with a company that mandates it, obviously you're just gonna use the one that they mandate. And if you're working… you're developing devices for the FDA, there are a couple that you can choose from.

And ISO 27001 is one that you can use, and there are some others and some other frameworks from NIST and other ISO standards that can help you, Can help you with that. Does that answer your question?

Yeah, it sounds like the larger companies are doing this in-house, and it's a push from, those, stakeholders, mostly. There was a question about AI software, and I… I know that there's, acknowledged a new, ISO standard, I think it's 24, is it? Iso… For AI. So, there is an AI, standard now to… to make sure that that's, going through security. Yeah, I thought it was 42, thanks, Mae, but it sounds like something else to me got confused. The 23, I think, is the business, so 42001, is still new to me, but we're actually certifying to that, too.

So anyway, there's some questions in here about software and, AI, and that is getting more and more, Used and recognized as a risk, so…

Not sure if you.

Excuse me?

mention much of that, but Madison.

I think the AI is emerging. One of the things we see is people treat AI software as different, And, the way we like to think about security for AI software is… we are… we will treat AI like a user. You know, people will give AI unlimited permissions to do anything it wants, and then it can… it's fallible, it can be tricked, it can be broken. And, we're a long way from AI that is infallible, that cannot be… You know, convinced to do things that it shouldn't. That can make judgment calls that are thoughtful. So you should always design your AI, your software that uses AI, where you replace AI with somebody we don't know. If you read your statement, they're like, the AI will understand the intent of the user and prevent them from taking an action. If you mentally, to rephrase that, too, somebody we don't know will

understand the intent of the user, prevent them from taking a bad action, you should be really worried about that. If your AI can never take bad actions, that's a good thing.

That's great. So I want to give Leo a chance To say what he wanted to say. We're running out of time. If you have questions, please put them in the chat. Please reach out to Mark, his email, or use the connectedchat.marcusengineering.com to ask your question, and then follow up with him, or whatever. Leo, where are you?

I am here. So, one thing was that Mark touched on cybersecurity, which was one of the many topics that we talked about at the NEMGO ESA, or Eisner Safety Consultants Summit we did this week at in Carlsbad, which we're gonna be, selling videos of the different presentations. From the summit. There was also 4th edition. We talked about a lot of EMC stuff, but cybersecurity, we had a presentation and a workshop. We talked about penetration testing and all the different standards on cybersecurity and FDA, I think we talked about the European requirements as well on that. I'm not an expert on cybersecurity by any stretch of mind, but we also had Rob Packard.

Presenting part of that work, that presentation, and also the workshop.

Cool. Rama, you've had your hand raised for quite a while. Do you have a question, or did you just…

I did. Sorry there's some background noise from my end, but I did have a question. So, we talked about connected medical devices. I'm thinking specifically about the ISO 13485 design and development verification, design and development validation. The specific wording in 13485 is that if the intended use requires that the medical device be connected to or have an interface with other medical devices. design verification, design validation are required, right? But here we're talking about, like, connected medical devices, and if we're thinking about SAMD, or phone, mobile apps, it really seems like

Even if we don't define, you know, like, a web app that's connected to a mobile phone, like a mobile app, or things that are not… or servers or environments that are not themselves Medical devices. Oh, sorry.

Oh, carry on.

Oh. It seems from the ISO 13485 perspective that verification and validation aren't needed if those external connections Aren't classified as medical devices, right?

Well, it gets into a tricky area, the… If you… a device that can, for example, change the settings on a… you know, an infusion pump, or is taking information from a glucose meter and presenting it to you. I think you'd be hard-pressed to define that as not part of the medical device. You know, it's providing essential functions for your system, even if they're optional. You, you definitely I would be really surprised if you got away without doing verification, validation on all the things that you could interface with.

And even if you are interfacing with stuff on the other side, where… it's providing part of those functions, and you say, hey, my verification validation was at the interface here. But I don't… this other software we're going to ignore because it's not important. You know, I think if you do risk analysis, you'll see, hey, what happens if I correctly pass the temperature to the other uncontrolled software, and that other uncontrolled software makes a mistake when it displays it to the user? You know, oftentimes when you do those risk analyses, you'll find out that it's so important to validate that other software, and all of a sudden that becomes part of your device, or it's a separate, you know, SAMD portion.

Where this can get really tricky is when you interface with other people's software. So we've had instances where people say, I want to integrate with another company's app, or I want to integrate with this other off-the-shelf software. And that's where you can get into a really hairy situation, where you're either validating, You know, off-the-shelf software, which is a whole other area of work to do, or you need to have strong ties with a company who you're integrating with to be able to do the right kind of verification, validation to avoid to avoid risks. You know, I think people… and we've had people do this all the time, where they try to skirt

The verification and validation. By saying, hey, this isn't a device, or, well, we're gonna exclude this from the scope, and you know, the reviewers have been quite negative about people doing that, you know, trying to, like, sweep it away, so…

And I think, like, just to… just to kind of just give some insight from what I've seen, SAMD, like, software, development, like, manufacturers, from one end who utilize just, like, a software FMEA that has no impact on, like, maybe patient safety, there's no safety-related risks. And then the other side of that is manufacturers who do a traditional, like, FMEA for safety. and then have the difficulty in bridging the gap when their device starts becoming connected. You know, what is the level… because… inherently, SFMEAs relating to software is focused more on vulnerability and exploitability, but from the other perspective, with the standard FMEAs, it's focused more on patient safety. So I think the question comes is, where do these connections overlap in terms of the risk analysis?

And I think, I often…

Those are great questions.

Yeah.

We're really 5 minutes over, and so what I want to do is wrap this up for right now. I encourage everybody to take a look at the upcoming events, which were put into the chat. Hopefully you're able to see them. I'll also put a link to that in the follow-up. I also encourage you guys to keep talking about this, and I hope that Mark will have a chance to follow up with each one of you. That ask questions that we did not get to today. Apologize for that. Yes, really informative, I agree. You know, if you want to drop into the chat something that was eye-opening to you, something that you did not know before this call, that would be awesome.

Because, I mean, I learned about 30 new things, not surprising. And, I want to thank Mark, I want to thank all of you for your time and attention. And please help us spread the word about these calls, because as you've experienced today, when they're good, they're really good. So, I appreciate, all of you. On that note, next week, MedTech, Reg, RegTech for medical devices. And please tune in for that, and all the other great things that are coming up. Wow. Any closing remarks, Mark?

No, thank you all for chatting with me. Like I said, feel free to reach out to me. I'm always happy to chit-chat with people, it's much more fun than what I should be doing. And, you know, please feel free to go chat with the chatbot, and let me know if that's useful for you, too. try to pour a bunch of this expertise into it, and I'm excited to see if, you know, how much that can help people, so…

Yeah, I'm excited about it, too. Mark and I have been talking about this a lot, and I think it's… I think, you know, making… making these calls interactive, even after the call itself, is really one of our goals for this year. So thanks for putting that together, Mark. Wonderful presentation, and I hope everybody has a fantastic weekend. Thank you all. Take care.

Thank you, guys.

Thank you.