Overcoming Digital Health Data Collection Hurdles for On-Premise and In-Home Healthcare Deployments

Thank you all for coming to today’s webinar about the digital health data collection hurdles that you’re gonna see on on premise or in home health care deployments. My name is Ryan Carlson. I’m the IoT and technology evangelist here at the Soracom Americas. I’ve been spending about the last twenty years of my career prior to coming to Soracom building digital products. And about six of those different products that went to market were of the health care nature, both in surgery theaters and also in homes or in remote practice locations. There’s a lot of crossovers. Healthcare by no means is unique. It’s just a little bit different from from other IoT implementations, whether it’s industrial, chemical utilities, commercial, and so forth. This is brought to you by Soracom. Soracom is a mobile virtual network operator specifically for IoT with global cellular with over four hundred and twenty carriers over a hundred and eighty countries. In two thousand fifteen, Soracom was started by people at AWS, saw the power of the cloud, and felt that that needed to be applied to telecommunications infrastructure. Now the company exists to allow smart devices such as health care to easily send data out to the cloud, connect with multiple carriers, and most importantly, stay connected wherever deployments might take them. A single eSIM, iSIM, or removable SIM gets you all of these different scales from enterprise all the way to actual startup products themselves. You get mission critical connections for health care with a strong focus on security, and we provide private networking, automatic failover, and native VPN support without lead times or the contractual lock ins that you’ll find that come with local carriers. We’re here to talk about digital health data collection hurdles for on premise and in home health care deployments. This title is very specific in that if we’re talking about hospitals or some of these other networks, remote clinics, yes. Big huge health systems, maybe not. But a lot of these technologies are going to apply because there’s some changes in the trends in what we’re seeing in digital health. First and foremost, let’s all take just a few moments. Let’s reflect on the reactions that we will get when we would hear the words cloud and data used in the same sentence in healthcare settings. I’m going back going back years and years and years, probably around two thousand seventeen, two thousand eighteen. And you got a whole lot of no way, never gonna happen, not secure, and how the world has changed. And so I say this because when we bring up things like cellular or Bluetooth or, even even Wi Fi, we are now looking at next generation technologies in all of these different wireless spectrums. Constraints that are existing today do not guarantee that they’re going to be existing tomorrow. And we’ll even have some interesting reflections on the current day technologies and where modern innovation is taking them. The one thing that I can say first and foremost is that twenty twenty one was when I spent my time in the health care industry, specifically around health data. And I watched the entire industry through COVID being dragged about ten years forward into the future as we saw both data policies, technology roadmaps accelerated. My wife is a provider, does telehealth, and telehealth was not covered where we live by all but maybe one insurance policy to where all of them would then cover telehealth, which opened the doors to an entirely new set of treatment types, distributed clinical, research programs. And remote health solutions are now primarily cloud based since we’re seeing a decentralization of ownership over these types of technologies. So it’s third party vendors that are responsible for maintaining and improving or even facilitating the services. Remote patient monitoring is prescribed and home health is subscribed. So prescribed solutions in particular need the data in order to demonstrate patient compliance, and that’s where you’re gonna have your CPT codes and you need to show and demonstrate usage. Whereas subscriptions, it’s not so much about can you get paid by people just going through the motions. You actually have to have a product that is good enough to drive a meaningful user experience in order to justify making those ongoing payments to whatever that program might be. So the question is, how does this change business requirements and engineering requirements? I hope to dig a bit deeper into that. But if there’s only one thing you remember, it’s gonna be a common language for talking about remote data collection for digital health solutions. I found this very helpful for working with providers, practitioners, executives, business units, business development, sales, all the way down to engineering and product management. We’re gonna be doing this by talking about a water utility. This is the IoT utility model. We’re gonna be talking about water that’s being pulled from the ground. This is the point of collection in which a pump is placed. We’re gonna have the lines of transmission, so you have your large Super Mario Brothers tubes that are pulling the water to a point of aggregation. Sometimes it looks like a cute little tea kettle, but in the most part, you’re gonna be having water treatment facilities where all of that collected water, that resource is all in one place is where we’re gonna look at the alkalinity or the iron content in the water, and we’re gonna treat it right there. The point of distribution is where we’re gonna have all of the different requirements for inputs, output, size, pressure, and even some of the regulatory pieces such as wastewater. Utilization is the final point in this journey in which we’re gonna have homes, commercial businesses, or manufacturing facilities that all have different requirements for how they’re going to be using the water that’s collected. In the utility world, the first mile is the point of collection taking the resource from where it originates to where it is aggregated, and the last mile is from where that water is all in one place with our resource to where it’s gonna be utilized. So when we’re talking about resources, let’s now go from water to data. The data might be temperature, gallons, check engine lights, oil pressure on that pump. So at the point of collection is going to be the sensor that is going to be having a a variety of means of collecting that information. Transmission is going to be how that moves from the point of collection out to the point of aggregation, oftentimes satellite, cellular, Wi Fi, Internet service providers. It’s gonna go out through a public Internet connection to that point of aggregation. And where you’re gonna have instead of a water reclamation facility, you might have a data lake or your application servers. This is where you can have all the data at rest and do things with it while it’s all in one place. Distribution is often the rules, the permissions, the security guidelines, the APIs, the integration documents, software developer kits, all of those things that are going to align with the utilization of that resource. So mobile app development, administrative web interface, or an analytics platform that’s gonna be ingesting certain parts of data. The IoT world is going to be really broken into these two camps. So we’re gonna use some traditional centralized on premise IoT data collection as the example. We’ve got an on premise sensor at a at a hospital. IT controls the infrastructure. That data then flows into the electronic health record system sitting at the facility. The distribution is gonna be a VPN or a health information exchange where the utilization is either that EHR client interface or it’s gonna be a health record that might be pulled in someplace else due to a release of information or request of some kind from another provider. The EHR vendors themselves did a great job of creating walled gardens in that utilization space, and ROI requests have limited access to the data. And now what’s interesting is that when we’re looking at on premise facilities, on premise data collection actually has far fewer hurdles in controlled ecosystems, which makes sense. Whereas the sharing of electronic health information has been the focus of industry legislation since the two thousand fifteen. So we’re looking out to even specifically in the United States. The the idea of reducing data blocking and increasing data interoperability is a big focus. But now when we’re looking at remote patient health monitoring through the lens of the utility model, in the first mile, we might have that device. It uses Bluetooth to connect to a device where a patient is gonna answer questions about how they’re feeling that day. It’s gonna use the cellular radio within that mobile device to go out to the public Internet. It’s gonna put the data out into the cloud. An application server is gonna ingest it, and an API is actually what the app is using to bring it full circle, or it’s even gonna be using some sort of additional, maybe FHIR or some other means of pushing data into those EHR workflows. The challenge is that data collection issues most often occurred in the first mile of remote digital health solutions. This is where I see more and more stumbling, whereas data use is the common topic that dominates last mile development. We’re not here to talk about last mile. It is its own can of worms. And the more sensitive nature of the data, is it a clinical trial? Is it gonna actually have identifiable health information? So if you can’t collect it, it doesn’t matter where it needs to go. Let’s go ahead and define data collection hurdles in this space. This is a model that I’ve been using for years, after doing usability work and in field contextual research. And the first tier so think of this as if you can’t move up the pyramid, device functionality and user interaction, which is gonna be, is it is the form and functioning gonna be something that people can use? Does it have enough power to reasonably last throughout that use cycle? And it’s also gonna be the accuracy of the data itself. And we see this with wearables on the fidelity of the data is increasing year over year and becoming much, much better. The next step is network connectivity and data transmission. So if you aren’t getting enough signal where you’re deploying, if you don’t have a reliable means of maintaining a connection if something were to occur, or you don’t have the bandwidth to process that information, you may be having some issues. Moving further up the actual dependency chain is gonna be your data security and compliance, your HIPAA, SOC two, HITRUST. This is gonna be your ability to have secure transmission, encryption, and overall data integrity of that data that’s moving. Again, this depends on what data it is you’re moving, where you’re moving it, and whether there’s identifiable information in the first place. Next on this ladder is the cloud processing and systems integration. And this is where it gets a little bit tricky. Is our EHRs, HIEs, practice management systems, the processing of the data itself? Are we using AI for anomaly detection? Are we doing some sort of normalization of the data to create data liquidity? And more importantly, how are we dealing with data interoperability for the ultimate end goal, which is creating actionable insights and having a clinical response. This is the ability to send notifications to providers, the integration into what is thousands of permutations of different workflows even in the same EHR depending on the clinic? And, also, how is it that you’re having those closed feedback loops with the, care providers or a care team for, an end user? And we’ll go into some examples of what actual systems look like and and how they’re addressing these steps. Now when we’re talking about the actual data hurdles themselves, let’s go back to our utility model and layer these in. That first layer, it’s complex to use. It’s cumbersome to provision the device, and kitting requires multiple SKUs. We see this a lot in Internet of Things. This is not unique to health care by any means, but specifically around device provisioning and then kitting. And we’ll get into some examples of what that looks like. Internet availability, reliability, and failover responses is something that I see far too often. It is the afterthought in a Internet of things application. There’s a lot of times where you might even say, how are we gonna get the connection? Oh, we’ll just assume Wi Fi. And that is actually how most product development is done at the bench is that you’re gonna have an, development kit. It’s gonna have an Ethernet connection or a Wi Fi chip built right into it, and that’s what we build to. And this is the same thing even the video game industry went through with developers building on these immense machines, not realizing what the end user actually has. And so the experience and the the follow through, we we quickly learn. Maybe we’re not aligning to what our customers need. Going up the tier is gonna be device and data security. There’s always gonna be the gotchas. If you’re trying to get that SOC two or HITRUST compliance if that’s something that is is required. There’s gonna be the private network support. IT is the number one gotcha in so many of these scenarios. And so if you’re looking for a blocker, I highly recommend just ignoring IT and wait till the last minute and try and come up with a response. We’ve all filled out those security surveys every time you’re trying to go through a sales cycle and trying to sell your device. So there are some things. There are some tactics that can be used to address this. And data privacy and data handling, this is really on all of us in the health care space to make sure that we’re keeping on top of that. Tier four, this is in the last mile. It’s all the interop. It’s the EHR integrations. And, honestly, FHIR has super limited support, and it’s less than ten percent of the overall standard has been implemented. We’ve gotta find different ways. And, unfortunately, it’s the more complex our solution, the harder it is to implement some of these pieces. The last one is just the every provider’s got a unique workflow. So knowing that we’re gonna have to to deal with that. Last mile considerations, let’s go ahead and look at the low hanging fruit for today, and that’s going to be the first mile. We’ve got reduced complexity and extra steps. We wanna make connectivity simple and reliable. That second part is something that is nonnegotiable when we’re talking about telemetry for health considerations. And then the last one is skipping the public Internet using cloud native cellular networks. The low hanging fruit here is making sure we’re thinking about how are we gonna answer that security survey or how are we protecting the data that’s going through the system. Here’s some design patterns that are used in digital health solutions. So I’m gonna give you a couple of different examples. The first one is a Bluetooth device or the mobile phone as a gateway. This is something that IoT has been looking at from the consumer world for ages, and this is where most of the early remote patient monitoring equipment has gone. So a device gathers data. It uses Bluetooth to communicate to the device. The device syncs to the mobile device. It uses its own cellular network to connect to the public Internet. The data is stored in a private cloud instance somewhere, AWS, Azure, or even a private hosting. And then this data is securely accessed via either a portal or a push to a provider, into their EHR, EMR, whatever it might be. Now the setup process is we’ve all been here. Right? Okay. Put the device into pairing mode. Now we have to go to the app on the device, and we wanna pair it with the mobile device. We’re gonna have to put on the appropriate credentials. Then that device goes out to the cloud to authenticate, and it’s gonna exchange a handshake. It’s gonna get some new keys, and we’re gonna get the secure credentials to now allow every time we want to take that blood pressure, do the diabetes test, upload our our weight that we’ve been standing on a scale with, and and get the answers on the other end or send that information of a provider. We need to make sure that we’ve gone through that process. So if you’re not providing the mobile devices with the actual RPM device, these steps have to happen at the patient’s house. And so now you’re assuming that the patients have that. Now we’re gonna look at enterprise Bluetooth gateway. Now this is something that is super cool, and it’s for larger multi sensor monitoring deployment. So it could be elderly care facilities. It could be clinics. It could be any number of different locations. So we’re gonna have one to many connections. We’re gonna have lots of different devices. Bluetooth is encrypted. Bluetooth is super low power, and it’s really great at continuous monitoring and sensing without having to worry about the high transmission rates that Wi Fi or cellular might be having. And our friends over at Casia Networks, they’ve got a number of different devices. One of them even has a SIM slot right into it where you get to choose your backhaul. So including cellular is the primary failover, so you can deploy multiple devices rather than having to have multiple individual SIMs to manage. You can have yourself a bunch of Bluetooth sensors, and then all of the information then goes through the cloud out into the last mile. There’s also some interesting things that are that why I even put this in here is because Bluetooth roaming is a thing. So if you’ve got mobility as part of your package, if the if the sensors are actually looking at gait analysis and looking at how people are moving during physical recovery or occupational therapy, I mean, it could be any number of things or even asset tracking with a Bluetooth locationing. So by placing a number of these devices all in one place, you actually can set up an basically, an access point network very similar to Wi Fi, but at a fraction of the power, a fraction of the actual data that needs to be zipping around, and you can still have the secure backhaul that goes out. The other thing that is also really neat is the ability to have some edge computing in a containerized service. So there are some of these gateways that you can build your own native app or your server software into indoor or outdoor units. That way, it can greatly reduce the amount of processing that needs to happen over the airwaves, especially if you’re using cellular as the primary backhaul. There’s some, really neat opportunities to leverage where I see Bluetooth is evolving, and it’s not just for those one to one relationships, one device to one smart device, like a a tablet or a phone, like we would with our AirPods or whatever. Alright. Now we’re gonna be looking at device connection and data via Wi Fi network. So this is something that should be really familiar. Gather data, send it over the network, ISP moves it over the public Internet, all goes out, and so on. The difference here is that in order to maintain IPsec or the actual security, you’re gonna need special secure networking hardware. These are devices that you’re gonna be putting on premise, and they maintain that secure tunnel where it’s packaging up and and keeping that data from being accessible via public Internet. And that’s where you’re gonna have to pay to put the hardware on either end of this chain in order to maintain some of these secure connections. So we know that remote patient monitoring, by and large, is about keeping costs down. So every additional piece of hardware that needs to be provided, unless this is a permanent facility or something along those lines, it’s a harder ask. The other piece too is a lot of RPM devices or remote patient monitoring relies on batteries, and Wi Fi does use a fair amount of power. And so you you just need to be thinking about, is that is that what you wanna be doing? Because it’s gonna be for permanent installations. Security has to be addressed using specialized hardware, or you’re gonna have to have some sort of code added in. Now you gotta enter setup mode. You log in to the mobile app. You access the device’s Wi Fi. Right? We’re like, join the network of blood pressure cuff one two three, and you log in. You put in the network credentials for the Wi Fi. The cloud authenticates the app and the device, and then it sends its credentials, and it does the handshake, and now everything’s great. But who’s doing this? Is the Internet already at the location? Is this grandma’s house? Because she doesn’t have Internet. Unlikely. So we need to be thinking about using the appropriate technology. This is great for permanent facilities where there’s preexisting IT or support, but relying on Wi Fi in a home health scenario is difficult. If our goal is to reach the largest patient population possible, we need to be considering these things. Here’s just a a throw out here. You’ve got local Wi Fi networks with a cellular backhaul. So one of the things at Soracom we’ve done is we, created our own line of USB modems. There’s nothing fancy here. They just happen to be pre certified. You can plug them into a device. They’re global ready, and they already take advantage of, a bunch of our different cloud based services, which we’ll touch on a couple of those on how to make advanced data collection even easier and reducing effort upfront. Let’s look at built in cellular connectivity. So your device gathers data. It syncs to the cloud. It goes over the public Internet. The data is stored in your own private cloud instance someplace, and then there’s the secure access. But now because it’s a per prescribed device, the setup needs to happen at advance. You’re gonna pre provision the device. You’re gonna pull them off the shelf. You have to look at all of the unique serial numbers. Then you’re gonna have to go, okay. Where is this patient located? Are they gonna be in a AT and T, T Mobile, Verizon, US cellular, Orange? Are they a different part of the world? Are they in Canada? Oh, gotta put a Rogers in there. So you have all of these additional SKUs because you’ve got the device, its own serial number, its own pre provisioned credentials, then you’re gonna have to be putting the SIM in. You activate the SIM. You power on the device. The device then you ship it. Now you send it over to where it needs to be, where it’s prescribed. The device will connect. That authenticates the connection. The credential, the handshake all happens, but there’s a bunch of work that needs to happen upfront. One of the things that you can do in cellular, in order to alleviate the burden on security is you can do, secure transmissions via what’s called a private APN. This is where you’re contracting with one specific carrier. So here, you actually are getting married to one particular local carrier, and they’re gonna set up their own servers where and they’re gonna issue you your own SIMs. So you have to install a unique SIM that only works on that private APN. Again, I have the keys to your own Airbnb that all set up for you in their their data warehouse. And then your devices then will communicate over your own network. There’s no other shared traffic, and then you can configure on the other end your VPN, your private network. Then you’ve got all your other development effort that’s gonna be required, but, it’s costly. It takes three to thirteen months. There’s contracts. There’s minimum requirements. It’s a pain. I know because I’ve had to set up three of these. And so cellular connectivity with cloud native IoT network like Soracom. We’re doing some really neat things by changing telecommunications infrastructure. So we’ve got our devices. We’re gonna install the SIM, whether an ISIM, an eSIM, or a removable SIM. So iSIM’s integrated into the electronics. ESIM is soldered on the board, which is great for small, tiny, wearable devices. And so at the factory, it’s put in. The supplier sets the SIM to a ready status. So they’re going to all automatically receive it, and it’s ready to go. So once you power on the device, it then activates that SIM, a SIM that works on lots of different networks too. Now that the device is up and running, it can do secure transmissions via virtual private gateway, which means it can skip the public Internet. There is no private APN requirement. You can have this set up within minutes. It’s awesome. No minimums, no contracts, no requirements. You can do it for one SIM if you want. Devices sync directly to your private cloud. And so if you happen to have your application living out on AWS, your development team is gonna be familiar with something called VPC peering. This is how to make two clouds talk to one another in a secure fashion, and that, again, takes a couple minutes. Then you’ve got your secure data storage. It goes out all the normal places. One thing to point out too is that your device is gonna connect, but what if it loses signal? What if a carrier has an outage? Depending on the weather or what time of day, what what side of the mountains you’re on, one carrier is gonna be better than the other. Well, Soracom’s the radio within your devices will have the option to switch and and make sure that there’s continuity of service. And we’ll go into some examples of Soracom customers that have deployed the stuff in some of the most rural locations serving very large patient populations where they were unaffected by some of these big outages that affected millions of customers. The other special thing here is device authentication via SIM rather than requiring a bunch of credentials being loaded during manufacturing. You can use the SIM, and we’ll get into those details more. And then the credentials and the handshake happens. In data collection, you wanna know that the device is not cloned. You wanna know that it’s valid. You wanna know that it’s secure. And the only way to do that is actually having the credential and authentication process that happens, between an IoT device and your cloud application. Soracom’s secure networking is why IT loves working with our customers because it allows people to bring their own private network. And so whether that’s a direct connection through a fiber channel, AWS, Azure, their own VPN corporate networks, there’s a lot of large energy, health care, and utilities that all use Soracom specifically because it’s something that we natively support out of the box. The other thing too is that we ourselves are built on top of AWS, so we consume cloud services so we can quickly scale whenever there’s a need to ramp up traffic up and down. It also means a lot of native support for different services like Kinesis or Lambda functions or doing some function calling. It’s pretty cool stuff. There’s also a whole series of cloud data adapters for getting access to Power BI, various machine learning pieces. So what we found is that by sending small bits of data upfront and offloading processing on smaller remote patient monitoring devices, we can have the cheap processing of the cloud process data on your behalf. So let’s send small bursts of data from the IoT device out to the cloud and and and put the heavy lifting out there. One, it reduces processor. It increases battery life, and it reduces the amount of data that you’re having to pay for because that’s what’s transmitted, especially if you’re transmitting over cellular. So when you have a device, a user is going to register their device. This is just an individual user. They go to the they they turn on their device. We went through this on the utility model. It goes to the cloud service. It sends credentials back to their device to say, yep. Ryan, this is your blood pressure cuff. It then securely copies the credentials and the configuration down to the device, and then the device has to go back to the cloud, authenticate, and connect. That’s why whenever we’re setting up smart things, it doesn’t always feel super smart. Right? There’s a lot of extra moving parts, especially if we’re using older methods for doing this. When we’re talking about building a hundred thousand or even ten thousand units and we’re sending them out to a contract manufacturer, we, as the company, we need to make sure the device gets registered in the cloud, and we’re going to get a bunch of credentials that are created, and they’re gonna be put onto sometimes it’s a USB thumbstick, a zip file. We’re gonna have all of these credentials, ten thousand or even a hundred thousand of these credentials, and they’re gonna be sent overseas to our contract manufacturer. And they’re gonna be embedding each unique encryption key or the half of the encryption key into each one of these devices. This is, again, to make sure things are true, valid, and, we can trust the data that’s coming from the device. Then as that device gets turned on, it authenticates and connects. So, one, before we even get to do anything, this means that we’ve got a whole lot of operational overhead of just even putting the devices into the system. There are staff that you hire specifically. The more sensitive the devices that you’re creating, you don’t want backdoors. You don’t want people getting copies of these credentials. These are the launch codes. It’s you’re not launching things necessarily, but, right, like, it’s access to the device and the data. And so there is a chance for breach, and there are a lot of security contracts that will have clauses in, like, chain of custody. Are you keeping track of this stuff? And a lot of times, it’s gonna also have, you know, higher cost and lead time. There’s these HSM hardware security modules that are used to generate these codes. It’s a whole level of infrastructure that nobody building IoT devices actually is anticipating. I don’t wanna say anybody, but in all the projects I’ve ever been on over twenty years, this is one of those areas where, like, we have to do this, and it adds cost. One of the things we’ve got is secure provisioning and data payload services, with Soracom. It’s where the device initiates a connection in the field. Soracom Krypton registers the device. The cloud service issues the credentials, and then the credentials are loaded into the device at the SIM level. At no point did anyone have to load anything into a device because the SIM itself is already a secure encrypted hardware module. It already has a unique identity that can’t be copied. It already is registered within the Soracom system when you buy the SIMs, eSIMs, iSIMs, whatever it might be. And so you could create a hundred thousand devices. They’re all identical. There’s nothing unique that needs to happen to them to fulfill this part of the the credentialing process. So this is those if you know, you know moments. The last step is the device uses the credentials to access the cloud service itself, and it’s all dynamic. There’s also an endorsed service that Soracom has, which allows you to use the SIM, but it could also use Wi Fi, Ethernet, or another type of Internet connection to pass that final credential sharing. So talk to a solutions architect if you wanna learn more how that works. Let’s get back into some examples here. So direct cellular connections, they actually drive a remote patient monitoring compliance. In a podcast interview that I did with Darby Davenport, who is the operations for telemedicine at UAB Health Systems. They went from having devices that had to use mobile apps or tablets. They used another vendor to prepare and train, and they’d have patients being discharged from the hospital. And there was a lot of moving parts. And then they moved over to using, a, like, a scale as one of the most popular devices that goes out for monitoring patients, going through recovery. And, this device has a SIM chip right in it. It has a direct cellular connection, and I recommend checking out the interview. You can look at managing remote patient monitoring operations for rural areas. It’s on the what to expect when you’re connecting podcast. But you can hear firsthand. You don’t have to believe me. Listen to Darby, the person who lives in the trenches, and the adoption uptake is significant to the point where people actually use it. And she points out that CPT codes are how they get reimbursed for sending these devices out into the field. And if people are unwilling to use it, it becomes a paperweight, and they’re out the bunny. So the only way that they’re gonna get that reimbursement is by getting people to use it at least a minimum of, I believe, fourteen times per month. And so the easier you make it, the more likely they’re to do it. And this is where that that dependency scale, where connectivity really makes a big difference because a a a lot of the people out in rural Alabama, they don’t have Internet at home. Then we’ve got tracking patient behaviors without adding any extra steps. I think what doctor Nagesh Gadaba has done, he’s got a device called RxKeeper, And he was talking about this idea of this ninety ten rule. Ten percent of his of patients for medication adherence, they require something that’s a bit more sophisticated. There’s gonna be some additional tracking that’s required. But ninety percent of them, really, based on all the usability studies and all the real world evidence that he’s got, is that the more simple, the better. And people who are sick don’t need one more thing to worry about. What RxKeeper does is there’s a medication alarm. The lid on the device opens, and their inside is one of the Soracom LTE M smart buttons, and it’s got a stereo plug in there where you can have a sensor like a door and window sensor. And in this particular case, when the lid opens, it sends a preprogrammed response directly out to the cloud and updates the portal login and then can update workflows on the provider end. Because what we’re not looking for is did the lid open. What we’re looking for is did the lid not open for consecutive days. That will identify whether someone is interacting with their medication, period. There’s also some of the things that they’ve done as well where instead of it just sending a response, when you open the lid, you actually press the button for I’m not feeling well. You double click it. I’m okay. And a long press if you’re feeling good. And so this could be used in clinical trials for just how are you feeling as the medication is taken over time. So very clever clever application of Internet that’s just already existing. No one needs to touch an app. They don’t need to do anything. It’s just go through the normal motions. One of the things that we know is that great products fail if connectivity isn’t working. Andrew Aker of PatchRx, is also in the medication adherence space. And there, he points out that reaching very diverse patient populations with in home health care solutions requires that the products be well designed. But, like, a lot of these, even even with, RxKeeper, they started with Wi Fi design. So they started with trying to make make it so people had to bring their Internet, or the prescriber would have to send a preconfigured router with them, and then you have to hook that up and get that all figured out. And instead, it it’s changed to where they’ve got a one to one ratio of a smart cap per bottle. It’s gonna have an identifier inside. There’s a cellular ESIM inside of a gateway sitting over by an outlet, And so this is where it’s soldered inside. So you’ve got a very tiny device that is maintaining the cellular connection, and you just tap when you take your pills. You just wave it by the sensor, and it lets your doctor know that you took that medication. The thing that we we know, those of us who are making devices, is that cellular is going from add on to assumed. It used to be you always just had an empty SIM slot to fill. That’s if you decide to even spec it into the device. ESIMs are making it so you can solder right onto the board, which is great for vibration dropping, security, tamper resistance nature. But to reduce power consumption and processor requirements even more, there’s now ISIMS, which is the SIM that’s just inside the radio module itself. And so we’re seeing this trend that even if Wi Fi or a Bluetooth connection is the primary means of getting data from the sensor, getting data to the cloud, you need to have a plan for what do you do when things go wrong. Speaking of things going wrong, people worry a lot about, is this gonna be expensive? What if a device runs away and we rack up a bill? One, that will absolutely happen. The more devices you have, the more likely it is to occur. I’ve spent thousands of dollars of other companies I’ve worked for of their money during testing and pilot programs by having devices that kicked out junk data or they something was misconfigured. And next thing you know, you’re looking at a twelve hundred dollar bill. And so one of the things that Soracom has done having seen that happen way too often is they have got a whole tool, which is an event handler, which allows you to configure not only alerts, but also set in thresholds. And you can set blanket thresholds across each individual SIM at an account level, at a customer level, to where it can even throttle a speed class so you can get notified. It throttles a speed class to keep the stop the bleeding, or you can just have it pause a SIM until someone from a support team can just see what’s going on, do an RMA, do a swap out, whatever that might be. No more overages. It’s gone. If if you configure this, and and it’s something that’s by default when you log in to your free operator ID account at soracom dot io, go ahead and check it out. You can get a console account, get a SIM. Let us know if you wanna do some testing. We’ll hook you up. Couple other things that people love as far as data collection is on demand road access is one of the tools that Soracom provides, and we call it Napter. This gives you the ability to remotely access any deployed device with a cellular SIM chip in it. No code. No development. This is great for pushing firmware updates, for doing remote maintenance. You never have to ask anyone, okay. Go to your app. Click on settings. Go to this. Do that. You can log in. It’s just as if you plug a cable into it. We open up a port within the SIM, a communication port. And for those in the know, you can SSH in and just issue commands and look at logs. You can also do remote packet capture as well. It’s another tool that we have. Throw it right into Wireshark and diagnose what’s going wrong with your device in a secure fashion without opening up any public ports. It’s awesome. Soracom ARC is the ability for you to create hybrid networks of devices so you can mix and match cellular, satellite, Ethernet, Wi Fi, or they all can use that same virtual private gateway, that secure service that replaces a private APN. If you want all your data going through one secure pipe directly to a corporate network or a research database, this is your way to do that. And so as long as you’ve got, for devices like a SecureLink with any sort of WireGuard compatible, network appliance, you can make it happen. So, again, if you’re in that world, you’re gonna recognize WireGuard. It’s awesome. Super easy to do, and, almost all of the devices have the capability to do that with a checkbox for zero dollars. Cool stuff. So my question is, how does your remote health care solution stack up? Are you reducing the complexity in extra steps? Are you making connectivity simple and reliable? And are you simplifying security and private networking by looking at things like cloud native cellular networks or alternatives to, private APNs or having to have appliance hardware for doing IPsec? If you’ve got any questions, you can email me at ryan at soracom dot io. I’d be happy to answer any questions that you have or put you in touch with the resources if you’d like to discuss, your project, your ideas, or things that you’re looking to accomplish, and and and close that data collection gap. Alright, everyone. Thank you so much. Take care.