How to add cloud connectivity to medical devices

Bold Type president Jose Bohorquez shares how to add cloud connectivity to medical devices in a June 2020 presentation to the Medical Devices Group (355,000+ members).

For those who prefer reading to watching, the edited transcript of Jose’s presentation follows:

I’m going to be talking about adding cloud connectivity to medical devices. I thought I’d split it up into three sections:

“What does connected even mean?” What does it mean to have connected medical devices?

“Why should I add cloud connectivity to my medical device?” What are the benefits to the different stakeholders?

“How do I do it?” So if you’ve sold me on the idea, I think it adds a lot of value, but how the heck do I now take my device that’s not cloud connected and make it a cloud connected device?

We could also talk about some things like usability and regulatory cybersecurity. But with medical devices, these are three key areas that are always important to think about beyond just the design of the product. When you talk about cloud connected medical devices, it’s even more important.

What does it mean to have a cloud connected medical device? When we talk about cloud connected, what we mean is that we take that device and we send the data to the cloud, the cloud being a big computer or a server that is accessible through the internet. If we just think of classic medical devices that are not cloud connected, whether it be an ECG sensor or a pulse oxymetry, or ultrasound – these are sensors. There’s also therapeutic actuators. You typically have some sort of mechanical housing that holds everything together. You’ve got some electronics inside – we’re specifically focusing on electronic type of medical devices – and that’s usually with some sort of microprocessor inside, either with the sensing technology or the actuating technology. You’re going to have memory and you’re going to probably have a battery that’s wireless.

To get that data from the device to the cloud, you typically need some type of gateway. As an example, most of us have some sort of device that connects to the cloud; it might be an Apple watch, or these days it could be your car. You need a mechanism to get the data from your device to the phone, and the most common mechanisms we use are Bluetooth and BLE. But it’s not the only way. You might go directly through a router to the cloud, and the most common means of doing that is wifi. We’re all familiar with wifi – all of our laptops connect to the cloud through wifi, or the majority do. The third mechanism, which is a bit more recent, is using cellular to connect to the cloud. We’ll talk more about those modalities later.

Not only are we able to get data from the device to the cloud, we’re also then able to access that data, typically through web applications or dashboards. There are several different people who might want to do that – it might be the physician who prescribed the product, it might be the medical device manufacturer who may want to evaluate some of the data coming from the devices. It might be the healthcare system payers, or it might even be the patient.

We’re talking about connected medical devices, but another word or term you’ll often hear is Internet of Medical Things. It’s a play on the Internet of Things, incorporating the idea that medical devices as things can now also be connected to the internet. You also hear about digital health, which encompasses more than just cloud-connected medical devices. There are now medical devices that are actually just apps on your phone, and the FDA now has a mechanism for marketing software as a medical device. Digital health incorporates both of those concepts – devices and non-device based digital therapeutics and diagnostics.

The last terms here are telehealth and telemedicine. These are terms that we’re hearing a lot of right now, given the COVID pandemic. They’re not new terms by any means, they’ve be around for decades,  but it does feel like we’re in a important moment where there’s more incentive than ever to really push those forward. And while connected medical devices are not the same as telehealth and telemedicine, they’re going to be a very important component, because they’re really enabling providers to take a lot of what’s currently done in a clinical setting and take it to the home.

Why should I add connectivity to my medical device?               Any medical device company worth their salt is always thinking about the patient, and connectivity brings a lot of benefits to the patient. We just briefly touched on telemedicine and we’re right now seeing the critical value it could bring to patients with a fear of going into a clinical setting. In this viral challenge that we’ve gone through as a society, one of the silver linings is this idea of telemedicine. The technologies have been around for decades, but what was missing was the drive in terms of the payers reimbursing physician involvement in telemedicine, and, in some ways, the culture in the healthcare system embracing it. COVID has awakened us to that power and the fact that telemedicine and telehealth are really here to stay.

Connected medical devices are gonna play a really key part there because there’s only so much you can do as a physician if all you’re able to do is talk to the patient. But if you’re able to send them devices that could take their vital signs, perform therapeutics or therapy, monitor their health, and those devices are easy to use and they’re accurate, and they’re connected to the cloud – now you’re giving a lot more power to that conversation between a healthcare provider and a patient.

A second major benefit is the ability to use connectivity to drive adherence, which ultimately drives efficacy. With therapeutics, one of the major barriers to getting high levels of efficacy is the level of patient adherence – if the patient is not adherent, no matter how good the drug or therapy is, it’s not going to have the proper efficacy. Where connectivity comes into play is that you now have a means of communicating with the patient, and in many ways determining if they’re being adherent to the therapy.

We’ve developed an app for one of our clients that provides a scorecard of how the patient is doing, in terms of their adherence. The device is a pelvic floor exerciser for women with urinary incontinence. It guides patients through a series of exercises that helps them strengthen their pelvic floor muscles, which then helps them improve their incontinence symptoms. From the home screen, the physician can see that on Monday the patient did the exercises once, on Tuesday and Wednesday the patient did it both times (as prescribed) so they get some of that visual positive reinforcement. The patient can also see their progress over time, as well as receive tips and some encouraging messages. They’re able to track some of their other symptoms and see how those are improving over time. The physician is getting a means of communicating with the patient to help them both track adherence and encourage it, which ultimately results in greater efficacy.

There’s another major benefit of cloud connectivity in medical devices – the ability to have the device in your hand but the algorithms in the cloud. Some medical devices, particularly on the diagnostics side require a substantial computing power, and if you’re sending a small device to a patient that’s sufficiently low-cost and easy to operate, you may not have the ability to put in the computing power to get really accurate algorithms. But if you can take the data, transfer it to the cloud, and then have the algorithms implemented in the cloud, you’ve got practically infinite computing power, and then the results can then be sent back to the device. You can take a small amount of data, send it to the cloud, have the cloud implement whatever algorithms – they might be artificial intelligence-based algorithms, machine-learning, or other types of algorithms – do all of that data crunching and send it back to the device. This enables a new separation of the overall system that allows us to bring devices to the home, which maybe in the past couldn’t be done.

And then lastly, the idea of over-the-year firmware updates or over-the-year software updates. So we’re talking about medical devices, but I have an example from Tesla to share. One of the really cool things they innovated on is the idea that you could wake up on Tuesday, get into your car, and get a message saying that your car has had a software update and it’s now safer, it’s now faster, the GPS is more accurate. It has additional or improved features that doesn’t exist the night before. And the reason this can be done is that we’re able to now send, from the cloud to the device – car or medical device – new software that improves the functionality of the product.

Any questions so far?

John Richard: I was working on a project where assuring patient compliance was a key part of it. We actually had the possibility of the therapy coming out of contact with the targeted part of the body, but we also had a situation where some more or less chronic injuries also came coupled with patients who found that they could stay on leave longer if their injury did not heal. And so, they would simply turn off the device for periods of time. I know that seems incomprehensible, but it actually was a large part of the business. They were able to monitor and assure patient compliance, and also monitor the effectiveness of the treatment. If a lead became disconnected, we could know immediately, and we could send something out to their iPhone.

Joe Hage: I know that Brent has the same idea for his CarePath device, where if the patient is supposed to be monitoring their urine output over a course of 10 days and we haven’t got a recording for the last 24 hours, surely they just aren’t using it and maybe this is a time to just send them a note or a text or something like that. This concept of algorithms in the cloud……you’re saying that I can be doing stuff here and sending it down and then sending it back?

Jose: Yeah, and that can happen in real time.  If you’re going on Netflix, your laptop or your phone is the device but the computing is really happening in the cloud and what you’re getting is data being transferred to your phone for visualization, but a lot of the computing is happening in the cloud. And the examples are ubiquitous. When you go on Google, you search something on your computer but all of the crunching and the algorithms to find the thing that you’re searching for are happening in a much larger cloud computer and then you’re getting all of these results on your web screen, or on your web application. It’s not a new concept at all, it’s been happening for a long time in other areas. But now that we’re taking medical devices and putting them in the hands of the patient with that cloud connectivity, we’re able to now leverage that power in the medical device world.

What about the manufacturer benefits?                                       One of the really interesting benefits coming out of the ability to update the product after launch is that you can really get the product to market faster without the fear of leaving some features on the table. As a product manager thinking about what that next generation product will be, you might have 50 features that you think would be really, really valuable to the patient but 10 of them that are really critical. They might be your minimum viable product, which is just that core set of features that the patient will benefit from tremendously. But you’ve also got another 40 that you know will be helpful as well, and one option is to wait and to build out the full 50 before launching. With cloud connectivity, one of the things you can do is launch the product with those 10 critical features and then improve the product over time through over-the-air firmware updates for the device, and then app updates on the application if there’s a mobile or a web app.

It’s a little bit of a more flexible model where you don’t have to wait until the product is perfect, and you don’t also have to wait until you launch a full new product. You can launch a product that meets the user needs and then improve it over time with software updates. And you can think of creative ways of monetizing this. You might have multiple versions of the device that are really physically the same but they just have different features enabled. We see this a lot in the non-medical world, now we’re seeing the ability to enable this in the medical space. So there’s a really big benefit to manufacturers.

The other one, of course, is data analytics. It used to be that if you launch a device and send it out into the field, you may not know things like – How often is it being used? Are people running into issues? What features are users really using often versus features that they never even touch, they might not even know about them? What are their frustration points.

Now you’ve got the visibility on the backend. As a product developer or manufacturer, you’re not able to really improve your product based on data from the field without having to conduct expensive studies or analyses, but with connectivity, you can really look at your cloud and incorporate some phenomenal analytics. There’s really cool tools now where you can literally see how many times has a patient hit a certain button on an app or performed a certain function on their device. You can slice and dice it by demographics, by indications, whatever it is that you want to evaluate, you can analyze the data.

There’s another tool that we use, which is called Smart Look, which actually allows us to see the screen as the patient is seeing it so that we can evaluate if there’s areas in the workflow where they’re getting stuck. Another area that’s really fascinating – and it’s not just the manufacturer benefit, it’s really the whole healthcare system benefiting from this – is that it is not easy to get data on thousands or even millions of patients in a very capital-efficient way. You have to have the proper controls, and certain things may require IRB. But you’ve got a platform now where you can send devices to many more patients, gather data, and have the ability to really understand diseases better by having a lot more data in a much more cost-effective way. The manufacturer can better understand a mechanism of action in one of the diseases they’re targeting, and then use that to develop more effective therapies.

Joe Hage: What percent of legacy medical devices that are legacy  could be adapted to have cloud connectivity? How expensive is it? Is it just basically you’re starting from scratch? I know you’re probably going to have to go through regulatory and all of that all over again. Does a manufacturer think –  how do you begin to quantify the economics that this is going to materially make us more profitable if we add this connectivity? How, if at all, does your organization help a prospect measure that, to determine whether they should go or not go?

Jose: It’s a complex question, right? It’s going to depend on the specifics, but I think almost all products can really benefit from cloud connectivity. And I say almost all, because of course you can think of hedge cases where maybe it’s not so powerful. It’s like in the non-medical world when you think about connecting your toaster to the cloud, then maybe we’re getting to the point where that doesn’t add so much value. But in the medical device world, there’s simplified versions of cloud connectivity that are not very expensive to implement and can add significant value on the other side. The device manufacturer, the company that owns and commercializes the technology ultimately has to do that business analysis. Where we help companies is, once we understand the scope, we can put together a budget and a timeline and walk them through the effort that’s required to get the product to the market with that cloud connectivity. They’ll understand what is the cost and the benefit, that analysis usually falls on them to see, is it going to  help me gain market share? Is it going to help me sell more products? Is it going to help me understand the market better so that we can develop better products and put a value to that? They’re usually in the best position to do that.

Joe: I would think somebody who’s a start-up looking to get bought out might say, “Look, here’s connected proof of the utility of this device, and how many times it’s used.” There are other ways that you could go look and see claims data and how often that procedure is performed, but it’s interesting to think about.

Jose: It gives you much greater granularity. And you get to answer questions not just like, “How many times has a patient used it?” but, “Are patients who are between the age of 50 and 65 using it more than patients who are between the ages of 40 and 50?” You’re able to slice and dice that data in a much more granular way because you just have a lot more of it.

Mark Fine: For medical devices, one of the things that everybody worries about is HIPPA and data security, and how do you build that in, and how difficult that is. Clearly it’s necessary, but also, in your experience, how difficult is it to add those features?

Jose: We’ll speak to that a little bit later in the presentation, but at a high level here, it’s a process, right? As with almost everything else in product development, in regards to cybersecurity the FDA has provided some good guidance. There’s good precedent in other industries, as well, and it all starts with just analyzing the product and seeing what are going to be the attack vectors, what are the risk factors? Is it things like people hacking in and actually affecting the device and making it work differently than it’s intended, or is it them just listening in and being able to capture data that’s being transferred either wirelessly or through the internet to the cloud server? Are there risks of a man-in-the-middle attack where somebody’s aiming to capture the data on one side, change it, and then send it to the other side, causing errors in the information, or you mentioned HIPPA, are you transmitting protected information that can identify who the patient is and their conditions? So you’ve gotta look at all those risk factors and attack them one-by-one. Much like anything else, a medical device is understanding the risks, understanding the potential harm to the patient associated with those risks, what are your controls gonna be, things like encryption and authentication, and just putting in the proper controls to bring those risks to a sufficiently low level where they’re outweighed by the benefits.

The last one that I’ve got here is the idea of creative monetization models. Again, in the non-medical world, this idea of devices as a service has been around for a little while. And in the medical world, one of the business or monetization models that’s existed for a long time is device and disposals. The disposal was creating an annuity, but  I think with cloud connectivity we get other means of annuities, things like charging for a device, not just for the capital equipment but on a per-use basis. So now that you’re able to get that information to the cloud, you can look at things like maybe not just making your business based on the sale of the capital equipment, but on the benefit that’s afforded to the user, whether it’s a patient or a doctor or the healthcare system, and monetizing through other means. That visibility and the control that can come from having central connectivity through the cloud, just enables other models as well.

Last, another key benefit is for the healthcare system itself. We talked about telemedicine, which certainly has benefits to the patient, but I think it also has significant benefits to the healthcare system, particularly in terms of efficiency. Now you can have the same doctor see more patients, carry out therapy more effectively, and maybe even discharge patients earlier. If you’ve got patients who are being paid per procedure and it’s capitated, and you’ve got the means of now sending them home earlier but still keeping tabs on them to make sure that complications don’t arise, that can be very powerful for the healthcare system as a whole.

Another major benefit is that you’re able to now see trends and not just snapshots. For example, with diabetes, if a patient is just checking their blood-sugar level periodically, they might miss some spikes. Some of the connected devices allow us to track things like that more continuously. If you think about going to the doctor and having a test done, they’re really taking a snapshot in time and it may not be representative of the worst-case things that happen throughout the day or the best-case, or the average, or how things correlate with certain activities or foods. Being able to record data continuously and send it to the cloud allows clinicians to look at the trends, not just the snapshot so that they’re properly sampling data and better able to manage disease or provide a diagnosis or therapy as well.

I alluded to this earlier, the idea of home monitoring allowing healthcare systems to release patients earlier but still keep tabs on them so that you don’t get the high cost of readmission, or at least reduce the frequency of those readmissions. There are other benefits I mentioned earlier – the idea of being able to carry out more effective clinical trials and clinical research where you may be able to use a lot fewer clinical sites and yet get more patients because you’re able to more effectively and efficiently issue the therapy or issue diagnostics and evaluate data.

Now the next question would be, how do I do it? Once you’re sold on the idea the next most important thing is how? One of the challenges with developing connected devices is that it is a more complex type of system architecture, you’re talking about industrial design and mechanical engineering for your mechanical housings. You’re talking about electronics, and you’re talking about the microcontroller and firmware, firmware being the embedded software that’s in the device itself. And now not incorporating the things that the device would normally do to measure or affect a therapy, but also incorporating the connectivity piece of it to the wireless communications and cybersecutiry portions of it. There is more complexity on the firmware side.

Let’s say that you’re using a mobile device as a gateway. You typically have to design at least one app, usually two. You want to do iOS and Android, and that has to have cybersecurity implications in place and also usability. You have to think about the code that you’re putting in the cloud. And then, to extract most of the value, you’ll want to have some sort of web dashboard or portal and the analytics around that.

Connected medical devices are more complex, are more expensive to develop, and ultimately the device manufacturer has to do their own analysis of the cost and benefit. But I think for most medical devices, the benefits do substantially outweigh the costs because they perpetuate over many devices.

If we look at what are our options are to wirelessly connect to the cloud, what are the different gateways? There’s three main ways. One is to connect to a phone or mobile app and then connect to the cloud. With that connection between the gateway and the cloud, you don’t have to worry about too much because it’s well established, ie. the Internet. But connecting to the gateway and then doing whatever processing you need to do there is the part that you have to think through.

If you’re connecting to an iOS or Android device, the two most common tools that are used for that are Bluetooth and BLE. BLE is Bluetooth Low Energy – the same radio, same hardware but it incorporates different protocols that allow you to consume a lot less battery. You can take a device with about four to six months of battery life on a coin cell because the wireless connectivity is done in a way that’s very energy efficient. With Bluetooth Low Energy, whenever the device isn’t communicating to the phone, it goes into a very, very low-energy mode. When the phone wakes up the device to get its information or to send information to it, then it’s going to consume more energy but it’s still more energy efficient than sstandard Bluetooth.

The second tool is wifi. It’s less common in most medical devices because it is fairly power hungry, but it’s not out of the question. There’s certain use models where it makes sense, and the benefit there is that you don’t necessarily need an app, you can go directly to the cloud through wifi.

The third one is low-power cellular. It’s a lot newer, it’s only been out for a few years now.  With your phone, when you’re at home you might connect to the internet using wifi, but when you leave and you’re away from your wifi router, it would use cellular, connecting directly to a cell tower. So what the industry did was take that same hardware, those same radios, and they created a Bluetooth Low Energy-like protocol for cellular. They created some low-energy protocols that you’re not going to be able to stream Netflix through, with a medical device that’s not the type of data that you’re usually trying to send. You give up bandwidth and you give up the amount of data you can send and receive in exchange for being able to use much less power and also be less costly.

Another example is NBIOT. These are wireless technologies that now allow a medical device to bypass a foreign application, such as a router, and just connect directly to the cloud. So a patient can still get connectivity wherever they are. One downside to using something like cellular is that there is a monthly cost. Bluetooth and wifi don’t have that, but if you’re using LTM, you can usually get service for about a dollar a month. If you’re trying to transmit and receive more data, it might be around $2 or $3 per month. But it enables a lot of really interesting uses. Any questions so far?

Andre DiMino: We found that the benefits of this can actually help with tech support and monitoring by incorporating certain types of physical sensors in your medical device, like temperature sensors, proximity sensors, and things like that. Instead of not knowing what the problem with the device is, you can monitor it remotely and possibly offer changes so it reduces tech support calls and the possibility of having to return the device for modification, which really helps the manufacturer in the tech support area.

Jose:Absolutely. And it’s also one of those areas where even for non-home use, just medical devices in the clinic, it can be really powerful in reducing some of those support costs as well.

Rick Stockton: Some people have a little bit more of a concern on privacy and things, or the sense of intrusiveness. Maybe some of the older patients, and maybe some of the younger ones, too. Setting aside the fact that you’re already needing some kind of medical intervention and there’s a certain amount of involvement of medical personnel, has anyone toyed with ideas designed to make people feel better about this level of proximity? For instance, the only phrase that came to mind was, “Hey, we’re just having a virtual nurse walking around “with you, making sure everything’s going okay”?

Joe: The answer is yes. Cory spoke at our last 10X, and he’s created a filing robot type of interaction that is particularly of interest to a more senior generation. It’s very intuitive to use, friendly, talkative. “Did you take your pills today, Rick?” kind of thing.

Jose: The next piece is how do we get that data to the cloud? And then, how do we host our server in the cloud? The cloud at the end of the day, as we talked about earlier, is essentially a server or a computer with a database and some API, some software on it that’s connected to the internet. You have a variety of options, but there are four main ones that we typically consider.

AWS, IBM, and Microsoft Azure are three big ones for effectively using cloud as a service. Leaning on some of them to host your web server, like Amazon web services, has a lot of benefits – getting things up and running more quickly, and scalability. All of these different services will provide you with different tools that you can use to get up and running faster and incorporate some functionality that you would otherwise have to develop yourself.

Your other option, of course, is to do your own private cloud, and so incorporate your own server. The benefit of that is that it tends to be lower cost in the long run, because as you scale, those hosted servers are going to become more expensive. Whereas, if you do your own private cloud, there’s going to be more of an upfront, but as you scale that cost is going to become lower. And one of the things you want to  be careful about is those cool tools that they give you to make things easier. If you become very dependent on those it then makes it that much harder to transfer to another cloud service or to a private cloud service in the future. So one of the things we typically recommend is using an AWS or a Microsoft Azure, but we try to design things and architect them in such a way that we can then transfer over to a private cloud without a lot of pain, and you can do that as well. There are benefits, pros and cons to both of them. But we do try to shy away from becoming too dependent on one of these portals or platforms, rather, because then it just becomes hard to move away from them.

The apps and portals, the things that communicate to that cloud, we think of these as two categories, one of them being the patient apps and the other one being the portals or web applications. On the patient side, one main use for these apps is to interface with the device. You might use the app to change settings on the device, or to get information from the device. In some cases, the app is effectively part of the device, meaning that the function, the thing that the device is trying to do can’t be done without the app.

Another major use of these apps is training and support. As was mentioned earlier, the app really gives you a means of reducing support costs by being able to provide a lot of that frontline support right there through the app. You can train the user on how to use the device and then provide support or troubleshooting if they do run into issues or if they were confused about how to use the product.

We talked about encouragement and adherence, but another benefit is logging of events. You can log events on the device itself but you can also ask other information from the user that will be helpful for them and for yourself, as a medical device manufacturer or as a caregiver to evaluate how different things are impacting the health of a patient. For example, if you’ve got a continuous glucose monitor and it connects to an app, and on the app you also have features that allow the patient to log what they’re eating and at what time, you can then look at correlations with how is their blood glucose changing in relationship with the things that they’re eating, the amount that they’re eating, the time that they’re eating. We talked about the female urinary incontinence product before, you can then correlate that with information like how many times is the patient going to the bathroom? What are their symptoms looking like? How many pads are they having to wear? So those correlations can be very helpful. And also, you can track progress. So whether it’s a therapeutic or kind of a diagnostic that measures things more longitudinally, you can track that progress of the patient and provide that feedback which hopefully will encourage positive behaviors.

You can also be creative with the app and add an element of community. Not all healthcare conditions lend themselves to adding the community aspect to it, but some do. There are devices and apps targeted towards new mothers, and you can imagine that there is value in a community where new moms can ask other new moms questions or get information from physicians or other experts. So it gives you a real opportunity to go beyond just the device, and bring other elements like community. On the portal side, there’s value to physicians, to healthcare systems, to researchers, and to the medical device manufacturer. So things like looking at patient progress, physicians really appreciate that functionality. Being able to conduct research, as we discussed earlier, in a much more expanded way. Looking at trends, both of individual patients and of cohorts. Improving the product, being able to see what features are being used more often than not, which ones are more confusing, what are the other things people are asking for? You have that means of observation and communication with the patient which will allow you to build better products down the line.

We talked earlier about how over-the-year software updates or firmware updates give you a means of improving the product while it’s in the field. But you may also decide that a device needs to be decommissioned for some reason, or that different uses of a device get charged differently. You may be able to do failure analysis of devices out in the field. There’s a lot of benefits that you gain on the portal side from having that connectivity.

There’s no such thing as a free lunch, everything has a cost, and if we look at the opportunities, the first two bullets here, reducing patient errors and frustrations. If you send the device out to a patient and you have no means of communicating with them or observing or providing information in a very digestible way, you’re more likely to have patients who don’t know how to use the product right or who experience frustrations. But if you’ve got that means of understanding what’s going on and providing support, it’s going to result in a better patient experience, lower cost of customer support, and hopefully lower returns as well.

One way to think of the app is almost like a super IFU. If you’re in the medical device world, you know that’s your Instructions For Use. It’s a very important part of your labeling and your overall product. The downside of a typical IFU is that most people don’t read it. It’s like a user manual, and people don’t really wanna sit there and read the manual But if you design your app correctly, you can give information to the patient in bite size pieces so that you’re training them in a more natural way, and in the appropriate time. You’re telling them how to do something in the moment when they’re trying to do that thing. It’s a much more effective way of really teaching patients how to use a product, and how to gain feedback from them.

The last point here is just building a relationship and driving engagement and adherence. We’ve talked about the adherence piece of it, but there’s also value for medical device manufacturers to build a relationship with the patient, for the patient to understand the brand and to knoe you may have multiple products that could be of benefit. Once you’ve got that communication means through an app, you’re able to build that type of longterm relationship with the patient.

So what are the challenges of apps? Well , the app may be part of the medical device, and that means it’s gonna be subject to regulations, whether it’s your IC standards for software development or risk management, design controls. Developing an app that’s part of a medical device is very different from developing an app that’s used for non-medical applications. A second challenge is that you typically are goingo to want to develop two apps. Not always – you may decide that you’re sending the mobile phone with your product because you don’t wanto to deal with this. But if you’re designing it to send a device and have it be able to connect to the patient’s phone, then you really have to consider that they may be iOS or Android, and that there could be dozens of models. So when you’re doing your testing, you really have to account for all of the different models, all of the different settings in those phones which may affect the functionality of the device. There’s a high burden on the testing side, of ensuring that when you release your product and when you release updates, it’s not gonna break for certain models of phones. And if you do have issues, that they’re not going to impact patients’ safety in an unacceptable way.

The next problem is that you get operating systems changing often. We all know that, whether it’s your iOS or Android device, you may get a new operating system and it can break things. Certain apps may stop working the way that they worked before because Apple or an Android manufacturer changed the OS, and so once you launch the product you still have to keep an eye on those updates and make sure that your app is still going to work.

And as a last point, I would say that user testing is really key. I think this is true with the device part of it as well, but on the app, it’s that much more important. You wanto to start early, you want to do it often, and importantly, you want to do it with the actual device.  Oftentimes you’re developing both a physical device and the app simultaneously. And it creates a challenge because you may be ready to do some testing with the app and the device isn’t ready, but there’s creative ways to solve that. You may be able to create simulators of a device, and that’ll help, but in the end you really have to get some user experience with the actual app and the actual device to make sure that you’re not missing anything.

Phil: You were talking about the cost. Obviously, there’s a significant engineering cost to this unless you can buy, IP that you can plug in, but there’s also documentation costs for compliance, correct? Is there such a thing as a package that you can bolt on and you’ve got a VinV for data and for the device itself? How does that work?

Jose: I’ve been working in a variety of ways. When we’re developing a connected product, we’ll usually go through the usual design controls process, so we understand the user needs, from that we start drafting requirements for the overall system. From that point, we typically break it down. We’ll do a set of requirements for the software itself, whether it’s a mobile application or a web application. We’ll do a set of designs for those requirements for the hardware portion of it, and we’ll do a set of requirements for the embedded or firmware portion of it, and you have to make sure that they all trace to the proper user needs.

There’s a number of reasons why you do it that way, and part of it is that the regulations around software development are different than the types of things that you have to do for hardware. You have to make sure that you’re following IEC 62304, for example, to make sure that you’re compliant with the specific requirements around software. On the verification side, it is more complex as well, so typically we’ll do hardware verification for the hardware itself, firmware verification, app verification. And then you wanto to do integration testing, making sure that everything together is working well, and then user testing to make sure that the overall system is usable and meets the desired functionality or the intended use.

Phil: Right, but what you’re saying now is I’m going to bolt on this new piece of software. A lot of the devices I work on have presentation need or they’ve got screens or whatever, now you’re talking about an additional data port, so now you’ve said, “Okay, so now we’ve got more hardware, more connections, more software in the cloud,” and you’ve also got that daily interaction between them. That’s not integration testing, it doesn’t scale linearly, right?

Jose: There are going to be some products where the benefits don’t outweigh the costs. There is a cost for both developing a connected device and really maintaining it, because as we discussed, whereas with a physical device, you might design it and really not have to mess with it for a long time, but when it’s a connected device, you’re always gonna be looking has a new update to iOS impacted the functionality of my product? Another portion is that you’re sending all this data to the cloud, you’re probably going to want to do something with it, so there’s some support costs to analyzing data and extracting value from it. But in most applications, I would say the benefits largely outweigh those costs, when you’re able to get better economics on the product, you’re able to get better market share. Or are you able to develop a new technology that would not be possible without the cloud connectivity?

Phil: Yeah, so do you actually provide that analysis of the return, or is that something you expect your customer to do?

Jose: There are really good people out there who can do the health economics portion of it. What we provide is the cost piece of it so we can help our clients understand what the cost is of adding this functionality to their product, and what can they expect as an ongoing cost later to support it. A consultant can help them figure out what the benefit piece of it is from a finance side.

David Hampton: Two comments, one question. One comment to the earlier person who asked about HIPPA. HHS has given a number of waivers, as has CMS, for HIPPA requirements to try to facilitate telemedicine during the COVID crisis. We’ve seen some similar things here in Europe. Whether it’s temporary or permanent, we don’t know, but they are relaxing some of their requirements for data sharing in telehealth environments.

The other thing about the interaction between cloud and devices…one interesting thing that we’ve seen is for scheduling and coordination. You have a telehealth session with a patient and then they need to go to a testing facility, and then they need to be seen by a specialist, and then they need to go to a pharmacy. That all needs coordination, which actually goes very well through things like calendar apps and existing capabilities on the smart phones. And you can handle notifications and everything else. So that’s where you have a lot of back and forth, synchronization of services between the cloud and the patient and the providers, and my question relates to that.

I had a question from an investor who was saying there’s really nothing in a medical app that’s not already in a smart phone except for the sensor and the backend data analytics. Somebody tells me they need to develop all this specialized stuff, they’ve already got a contact and a calendar and a locator, and it can do Bluetooth and everything else in their smart phone. What more do I need to consider if they say it’s going to be a medical application?

Jose: It’s indication specific, right? The product wouldn’t work without the phone application, essentially. So we mentioned earlier 62304. You have to make sure that you’re following the proper guidelines for software development. You have to make sure that you’re evaluating it in terms of usability; the app is now part of the device and you have to make sure that you’re meeting the usability requirements. Cybersecurity, we’ve touched on, and we can talk a little bit more about that, but you have to make sure that you’re properly doing that. And you have to follow design controls, as with any other part of the medical device, but once you do those things and then depending on the setting, maybe also HIPPA. It’s very indication specific, but there’s plenty of precedent and good guidelines from FDA on what needs to happen.

Peter Harris: You touched on cybersecurity. I think that as a subject that’s really global and endemic to our medical devices, it needs to be more than touched on by thought leaders like yourself and your teams and the people you associate with. In the States, unfortunately, I think we’ve got a track record of being in denial in areas of cyber intrusion by bad actors like China and Korea and North Korea and Iraq, and so on. And another category of bad actors here in the States, they typically seem to be based in the States, and those are scam operators. And so, I think that the card medical computing industry is gonna be totally bogged down and handicapped unless you guys in this commerce play a lot more attention than just a crossing reference to cybersecurity.

Jose: I can speak to it, just to provide some of that. FDA does expect cybersecurity analysis. I would say it’s usually just scratching the surface if you meet the FDA kind of requirements. They provide a good set of at least minimal things that you should be doing, but it’s ultimately a process of performing risk analysis to identifying your vulnerabilities, and then determining your controls, and looking at things like denial of service. A hacker can hack a device or an overall system to make it so that a patient can’t get the service they need.

Probably the most extreme case you can imagine here is a pacemaker, right? If they can hack into a pacemaker and turn it off, or have it do something that shouldn’t be done, it can ultimately result in somebody’s death. There’s malware, things like ransomware, like man-in-the-middle attacks – you have to consider all of these, and you have to consider it across the entire system. It will depend on the risk of the product, because the level of controls that you can incorporate into a medical device will vary in complexity.

Cybersecurity happens to be an area of expertise for us even beyond medical devices. We work with one client who is not medical, but their devices are used for privacy guarding of high-level government agencies. And it’s down to the point where even the manufacturing, even the way that the microprocessors get programmed has to be done in a safe, a physical safe, to make it so that unauthorized people can’t access that and embed malware or viruses or other means of attacking at the manufacturing place. Even down to the supply chain, making sure that the chips that are being used in the system don’t have back doors incorporated into them for hackers to be able to get into it later. Do you need to do that if the device isn’t life sustaining? Where it’s not sending identified information? Where it’s just really not sending data that’s gonna create significant harm? No, it’s a risk benefit just like anything else in medical devices, but you have to start with a risk analysis. You have to consider all the cases. If a bad actor does this, what is that going to result in, and how big is that risk? And then the controls you put in need to be commensurate with that. That’s part of the process that FDA might ask you to do. But the quality of that process, your ability to really understand those different threats will depend on the expertise of the team doing that analysis.

Peter: I hear what you’re saying, Jose. But my point is, that unfortunately we do have a history of denial and carelessness. For example, you guys have probably got the same notices that I’ve got about do not install the next Windows 10 update that you are offered by Microsoft because the Microsoft Windows 10 updates are triggering some error in Chrome that exposes user data. And this has gone on for a couple of weeks now, that I’ve seen this back and forth. There was some denial between the two companies as to who was responsible. Apparently it’s turned out that it’s Windows 10 updates that are triggering this adverse reaction in Chrome. And then, as we speak, I’ve got a check on my desk here for some pennies from Premera for a class-action settlement for personal data, professional data being exposed to scammers and hackers. So I guess the point that I’d like to leave us with and my thought is that tacking this on a piece-by-piece basis is simply not gonna work. It has to be tackled on an industry-wide basis and there has to be a driver in the industry that says that the entire industry is going to tackle this problem.

Jose: I agree. I think it’s certainly something that requires a lot more awareness and effort on the overall industry.

Phil: Obviously you’re aware of the Treck vulnerability that’s coming out this week, and we’re seeing some big players like Microsoft and HP are potentially at risk here, neither of whom have put forward a statement on this. So I guess it comes back to what you were saying, Peter, about isn’t there gonna be some finger-pointing. And it seems that that Treck IP block that’s being used in a lot of IoT devices from UPS’s to Enterprise control systems, we know it’s in some medical devices. I think it’s already been identified in the Fusion system. I mean, that tech is what, 10-years-old? The IP core, 15 years? It’s a different era, and if this turns out to be widespread, this could be major. This could be as bad as the PIP scandal for breast-implant materials. So what’s your take, Jose, on this? Obviously we don’t know how it’s gonna play out yet.

Jose: I can give you my thoughts on it, but if Mohamad’s on the line, he can provide more, he’s got a lot of expertise on this. What you see in the news is the tip of the iceberg. There’s been all sorts, even at the silicon level, microprocessors and processors that have back doors into them so that at any given point somebody can hack into them and extract information or change functionality. This isn’t by some small manufacturer, these are threats that have been embedded into things by companies like Intel and MD. There are a whole lot of threats out there, and part of what you have to do is figure out how do you design the system so that even if there is a breach there it doesn’t result in patient harm, it doesn’t result in information? And that can be done. The way that you segregate information within a system, the way that you create authentications and other means, mechanisms can make it so that even if there is a breach the harm is not substantial. And oftentimes that’s the best you can do. We’re all right here on GoToMeeting, and we all use our computers and we all use our phones. People can hack into your phone right now, listen in to your conversation, see everything that’s being recorded through your video, those are threats that exist. And yet, we still do it. Why? Because the benefits outweigh the costs. We can all go live in the mountains and be completely disconnected but then we miss out on the benefits, and it’s the same thing in medical devices. You’re constantly having to ask what is the risk of this product being breached? Does the benefit outweigh that? And, what can I do realistically to just bring that risk level down so that if there is a breach, the impact of it is not so bad?

Phil: Yeah, I mean, I completely agree. And it’s all about the failure-mode analysis at the end of the day. I know engineers that have been complacent to think that, “Oh well, that’s deployed everywhere, “so therefore it must be robust.” That’s not it, that’s not a hypothetical.

Joanne Evans: I was just curious about firewalls and security.  I worked at a company where we had three firewalls that were set up, if one got breached we got notified…..

Jose: I think firewalls are one of the many mechanisms that are used for protecting data, but there are tons of different mechanisms that you have to incorporate from encryption to authentication to SureElec firewalls. What you implement and how you implement it is gonna depend on the risk level of the product, on the architecture of the software, on what kind of data’s being transmitted and received. If we unmute Mohamad he can probably provide more intelligent information on that, because that’s his area of expertise.

Mohamad: I think some interesting points have been raised. Jose did mention something that I can unwind a little bit, which is ultimately it’s all about a cost benefit analysis. I mean, there are risks in everything and there’s costs to addressing those risks, and that’s really what it comes down to. You have to treat cybersecurity just like anything else from a medical perspective, with regards to patient harm. It’s just another potential source of harm that needs to be addressed.

I think some of the mistakes that have happened in the past are because cybersecurity was oftentimes an afterthought. Products had been created, and then somebody thought , “Oh, what do I do about cybersecurity?” That never works out well. Trying to apply security after the fact is not a good way to do it. Just like not considering harms correctly for any medical device and then deciding at the end after you’ve finished the product, oh, by the way, I just discovered a harm that I didn’t think about, the same problem will occur.

There’s all kinds of levels of security you could add that all have consequential costs to them that you can do depending on what your projected harm is from access. If it’s a device that’s collected data that, as Jose said, that really has no impact on a patient, you may not need that level of security. If it’s something that can clearly lead to a patient’s death or uncovering critical information to the patient, then certainly you want to employ cybersecurity capabilities. I think the other challenge is that cybersecurity is a never ending thing. We treat this as a continuum, so you do an analysis at the beginning of a project and you come up with various controls based on the risks that you want to mitigate. But then, periodically that has to be constantly refreshed, because attackers are varying their attacks. Their technologies are changing rapidly.

This is not just only in medical, it applies even beyond medical, is that it’s not enough to address cybersecurity by saying, “Oh, I did an analysis two years ago and it was fine.” Because the analysis you did two years ago is probably irrelevant today. It’s a new beast that we have to tackle, this idea of constantly analyzing, constantly reacting to threats.

Andres: I’m the VP of Product Development. I’ve been managing mostly the software operation and effort. I’ve been managing the application development team, the cloud development teams, the web application development teams….that’s what I do for Bold Type.

Elizabeth: Well, I’m Elizabeth Friedman from San Antonio, Texas. I am developing a product that has the potential for some interface with the connectivity. Right now we’re not planning to include that. It’s a very simple concept in the medication safety arena. I have to leave it at vague right now, as we are very much in the development stage, but  this topic is absolutely critical to what we’re thinking about doing in the future.

Elizabeth: Correct. Yes. For anyone to have the wrong thing. So your speaker here, Peter, I guess, Dr. Harris talked to be about obesity surgery. It’s something I’m interested in. It’s not related to my medical device product.

Jose: Cybersecurity is a topic that could easily take up a full hour. We wanted to give you just a little bit of a taster on some of those things, and tell you a little bit about our team.

I’m the president, chief system architect, I’ve got a PhD in Electrical Engineering from MIT. I’ve spent most of my career in wireless and connected devices, and a good portion of it in medical. Mohamad, who you guys saw, is our chief software architect. He’s an alumnus of Imperial College, he’s a former chief software architect at Motorola for their two-way radio division. He gained a ton of cybersecurity expertise there, as you can imagine, those two-way radios go into the hands of government agencies where cybersecurity is a big threat.

Andres, who you guys also saw as well, is an engineer by training with  an MBA from Harvard. He has focused the last part of his career in software development, leading software development teams. We do have a full-time quality assurance and regulatory affairs director, who’s taken over 20 products through the 510K process as well as some of the international processes. Overall though, our organization’s about 30 people. We can do sort of soup to nuts product development, but we do specialize and focus on connected wireless medical devices.

Joe: Rob Stupplebeen asks, “What are your thoughts about taking “scanned data or measurements and then pushing that to the cloud to then design and ship a physical, customized device? “For example, Invisalign.”

Jose: I think that’s touching on another one of those really fascinating trends in the medical device world of really personalized products. Invisalign’s one example, but in the dental space I think there’s other applications where connecting the data to the cloud, and on the back end being able to build personalized products and send them to the patients. It’s just another one of those applications. We’re looking right now with COVID at different diagnostics and tests where if the equipment is connected to the cloud, you’re then able to get that information out to the overall community much faster.

Andre Di Mino: We design and manufacture medical devices and we get projects thrown at us all the time. We’re certainly fine on the hardware side, the embedded side, and so forth, but sometimes we get requests from the incorporation of the remote control with access. I was speaking before about the tech support and so forth,so wondering how you would approach a project and working, in essence, as part of a team that’s working on a project like that?

Jose: We do that all the time. I think it’s one of the things that I love about this community is that we don’t do every type of medical device.

This happened two weeks ago. Project came to us, but it was a microfluidics, and microfluidics is not an area that we do a lot of work on, and we knew another company that was great at it, so we sent it over to them. We have other projects where we just work together with another group because they’ve got expertise in one area, we have it in another. We try to focus on connected medical devices.

At the end of the day, the way I look at it is we should always be looking for the wellbeing of the client. It’s trying to get technology to the market that’s going to help people out. Collaborating with other development groups is a very common part of our practice, so I would love to talk to you about any way that we can collaborate.

Joe: Mohamad, you had something to share with the group?

Mohamad: Rick had a question about potentially avoiding the need to have two apps, one on iOS, one on Android, potentially even a third one on Microsoft’s platform, by using what technically is called hybrid apps – web-based apps that run on phones. We’ve definitely looked at that, and we continue to look at it. It’s a continually evolving technology. The biggest challenge so far that we’ve found with them is connectivity to the devices, having the phone connect to the device is generally one of the most problematic areas from the sense of making it be seamless to the customer. Again, one of the goals here is to make the phone and the device work together really well and not cause friction for the actual user.

We continue to look at it, and I do expect that at some point, that will become a viable solution. It just, up until now, with the projects we’ve looked at, it just hasn’t reached a point of viability.

Jose: Remember that there is a lot of value in connecting your medical devices to the cloud, both for the patient and for you as the medical device manufacturer, and really to the overall community. It is challenging, but if you build the right team or work with the right partner, it can be done. I think in the majority of cases, benefits do outweigh the costs.