Partilhar via

Using IoT for Enhanced Glucose Monitoring

  • Artigo

Using IoT for Enhanced Glucose Monitoring 

by Josh Holmes, Partner Catalyst Team

Customer Background

Medilync was founded with the goal of revolutionizing the way diabetes is managed and treated in a value-based care landscape. In the value-based care landscape, a deep understanding of the patient and the ability to make recommendations about lifestyle choices are crucial to long-term success.

The Problem

Medilync creates an all-in-one telehealth device, called Insulync. Composed of a glucose meter and insulin pen reader, Insulync enables doctors with the ability to interact with patients in a more impactful way, leveraging near-real time analysis of data feeds on blood sugar levels, insulin dosage, pulse, and blood pressure. Simultaneously, data collected via the device will be combined with meal plan data from partners such as MyFitness Pal and exercise information. All of this data is analyzed using machine learning to help understand and identify the best care options for a patient.

 With the sensitivity of the personal data that is captured with the Medilync smart glucometer, there are a number of challenges.

  1. How to register and identify the devices as known devices and belonging to a given patient.
  2. How to securely and reliably send data to the cloud at scale.
  3.  How to send commands and configuration to the device itself in a secure way.

With privacy concerns even more important when dealing with the personal information coming from the Medilync devices, solving these challenges are essential to the success of Medilync.  

 

Overview of the Solution

In January 2015, Medilync developers spent several days on site at Microsoft with developers from the Technology Evangelism and Development (TED) team working to find a solution to these challenges. The solution to these three challenges comes in the form an open source project called Nitrogen (https://nitrogen.io). Nitrogen is a set of IoT components that leverage Azure and its premium services such as Azure Event Hubs, while providing security, scale and reliability, similar to the Azure IoT suite.

 

The smart glucometer that Medilync has created runs an embedded Linux implementation called OpenWRT which is capable of running node.js. Nitrogen has a small node.js agent that runs on the device to handle registration, authentication and communications with the server side.

 

On the server side, Nitrogen provides 4 major components.

Registry

  • This component manages the central credential store for all of the principals in the system. Each device, user and application are considered principals and has credentials and a set of permissions on other principals in the system. These permissions can include Impersonation (impersonating another principal), sending messages and receiving messages.

Ingestion

  • This component manages the ingestion of telemetry data. It pushes data into Azure Event Hubs. See below for further details.

Consumption

  • This component handles the outbound communications with the devices from the server side. This leverages Service Bus to do reliable messages back to the device including mail boxing of messages for semi-connected devices such as the battery operated glucometer.

Frontdoor 

  • This final component simply unifies and handles the REST front end and transfers data to and from the services. 

 

 

For information on how to get started with Nitrogen, including full walk-throughs and tutorials, visit https://nitrogen.io.

 

Azure Event Hubs are very high scale queues and buffers for the ingestion of telemetry data. Each Azure Event Hub is capable of handling up to one gigabyte of data per second and can then optionally hold that data up to 30 days while the consumers of that data process it.  Each Event Hub can support up to 30 separate consumers, all which are all processing at their own speed.

 

By default, Azure Stream Analytics can consume data directly from Azure Event Hubs. Azure Stream Analytics processes data in near real-time and can perform actions based on pre-defined rules. This allows a SQL like query language over the top of real time streams and join that with existing data to look for clustering and anomalies.

 

 

In addition, Medilync uses HDInsights to do processing of historical data for additional insights. Azure Event Hub can handle up to 30 consumers at one time so an additional consumer was used to pull data and store it in HDFS so that HDInsights could get to it. HDInsights is a PaaS (Platform as a Service) implementation of Hadoop. The output from the HDInsights processing is stored in MongoDB database which feeds dashboards and long term reports since. MongoDB was used because they had an existing infrastructure and codebase for their dashboards and reports already up and running. Additionally, Medilync uses Azure Mobile Services to notify mobile apps that changes or updates are available based on this data processing.

Code Artifacts and examples

HDInsight: https://azure.microsoft.com/en-us/documentation/services/hdinsight/

Nitrogen: https://nitrogen.io/  

Azure ML: https://azure.microsoft.com/en-us/documentation/services/machine-learning/

Event Hub: https://azure.microsoft.com/en-us/documentation/services/service-bus/

Opportunities for Reuse

While the code and the specific algorithms that Medilync created for their project is proprietary, the architecture described in this case study can be used in other scenarios in which private data is collected from IoT devices, and then combined with other data and analyzed.  In addition, Nitrogen.io framework offers several examples that can be applied to a range of scenarios that use IoT devices.

 

Josh Holmes is a passionate soul who gets his kicks solving problems with deep fried awesomeness. He is the Director of Architecture in the Partner Catalyst Team.