A Quick Introduction to Diabetes and IoT

Before I hop right in, it’s important to understand a bit about diabetes. Diabetes is what happens when your body cannot produce (type 1) or respond (type 2) to insulin effectively. The impact on the body is frequently quite severe — people who have difficulty controlling their blood sugar levels run the risk of losing feeling in their fingers and/or toes or even going into a coma if their blood sugar is either too high or too low. 

More on the subject:

• A re:Invent to Remember–What to Expect at AWS re:Invent 2018
• How to Use ELK to Monitor Performance
• An Introduction to Log-Driven Development

Unfortunately, this disorder is alarmingly common. The CDC reports that, as of 2015, approximately 10 percent of the US population was already diabetic and an additional 26 percent was at risk of developing diabetes within 5 years. The US population is about 330 million, so that means that approximately 118 million people in the country are either diabetic or prediabetic. In 2014, the WHO reported that the global number of people with diabetes is 422 million.

In order to help diabetic people lead safer, more independent lives, several healthcare companies have devoted engineering power to the development of monitoring equipment and, of course, apps to go with them.

One way to help diabetics — and others with chronic or terminal healthcare needs — be more independent is to utilize the ever-expanding IoT (Internet of Things) space. Over the past few years, there has been a rapid growth in the spectrum of cost, availability, and types of IoT devices. This provides us all with an ever-expanding space to creatively explore potential ways to augment our lives.

Problem Space

As it turns out, healthcare companies aren’t the only ones trying to help the lives of diabetics — so are their loved ones. In particular, one of our customers, who I’ll refer to as A.B., contacted us recently and told us that he had found a way to connect his brother’s glucose monitor to our logging platform with wonderful results. Let’s take a look.

Goals

• Monitor brother’s glucose (blood sugar) level to ensure it doesn’t go too low (4 mmol/liter) or too high (10 mmol/liter)
• Connect to an analytics platform to monitor health data over time to recognize patterns/triggers for abnormal levels
• Create an alternative to the built-in alarm so that the appropriate person(s) are notified in the event of a spike or trough in the glucose level
• Provide the appropriate level of access to the appropriate people for follow-up
• Monitor the device itself to make sure it’s working normally
• Set up an alarm system that will alert at the appropriate threshold

Setup and Process

The sensor and app, in this case, are manufactured by Eversense. The device sends glucose and device data to the mobile app wirelessly via a Bluetooth connection:

In order to ship the app data from his brother’s phone to our platform, A.B. needed to decompile the manufacturer’s Android app and add in our Java shipper. The logs were sent out in a JSON format that our app recognized. So in this case, he did not need to create a custom parsing configuration — the data could just roll in.

To keep an eye on his brother’s health data, A.B. created a dashboard showing health and device data:

On this particular dashboard, the metrics being tracked are:

• The number of measurements sent over time
• Error rate
• Blood glucose level
• Blood glucose distribution

A combination of the error rate and the number of measurements sent allow A.B. to see if the device starts to decline in accuracy, indicating that the glucose monitor needs to be replaced. As it turns out, this exact scenario has already happened — in order to show that the device was starting to fail, A.B. created a temporary login that the manufacturer could use to see current measurement and error rates to verify that it needed to be replaced. (Side note: the Eversense site indicates that the subcutaneous implants should be changed approximately every 3 months.)

Another goal of this configuration was to supplement/replace the monitor’s alarm. Currently, the built-in vibrating alarm isn’t strong enough to wake his brother if there is a problem when he’s asleep. To augment this, our client modified the app to use Android Tasker on his brother’s phone and Telegram to notify himself and other members of their family in case of a serious issue. Creating a built-in alarm also allows his brother to snooze the alarm in 4-minute intervals, similar to other native alarms, so that he can address the issue rather than having the alarm going off continuously.

In-Platform Alerts

While we were working on this blog post, we looked at creating alerts in the Logz.io app. For example:

These alerts use the same thresholds as the glucometer; the difference here is that now he can make use of any of our supported or custom endpoint types to ship the information to the desired recipients.

Beyond the Individual Use Case

A.B. was able to make use of our HIPAA-compliant platform to not only track his brother’s health data for ongoing analysis but also to notify relevant people in the event of an emergency and create a separate, secure login so that the device manufacturer could confirm when it started to fail. As IoT proliferates, the need to be able to securely monitor health devices will grow. Not only may companies be able to track device failures “in the wild” and in real time, but so will medical professionals. Imagine if solutions like A.B.’s were more common, so that a person’s doctor or treatment team was notified whenever they had a health crisis like a critically low (high) blood glucose level, a failing or disrupted pacemaker, and so on.

Of course, this premise isn’t limited to critical care devices like pacemakers, but can extend miscellaneous smart devices in your home – anything that (1) has an app and (2) can connect to the Internet.