Flask Blood Glucose Tracker

My oldest daughter was diagnosed with Type 1 Diabetes at the age of two. Technology has come a long way in terms of tracking blood sugar levels, but I thought I would start a Python web application to do so. I’ll be using the Flask web framework for the project and, since I’m not a marketing or product naming genius, will call the project Flask Blood Glucose Tracker. I’m certainly open to other, more catchy, names.

This is somewhat of a different post for me, in that I’ll be walking through the generation of an actual application. The application will mostly be a minimal viable product (MVP) though. It should, however, be a good tutorial on how to integrate some concepts and technologies together. As such, in this first post, I’ll cover some of the project specifications and features that I’d like to include and work on implementing them in future posts.

Application for Diabetes

Diabetics have to check their blood glucose levels frequently, typically using a blood sugar monitor. These checks involve getting a small portion of blood from a finger (or arm) prick and having the monitor test it. It then returns a measurement of the amount of glucose in the blood as a number of milligrams per deciliter (mG/dL). These readings then will be the numbers we want to record in our application.

It is also important to know if the reading is taken before or after eating and the time of day the reading was taken. Therefore, the application will need to accommodate for that as well. The readings themselves, along with the time of day and relation to meal time are all factors into the amount of insulin needs to be injected.

Throughout this, and subsequent posts, I will do my best to explain diabetes-specific terms in as user-friendly of a way as possible. I am basing much of the numbers that I use, ranges of “good and bad”, etc. on managing my daughter’s diabetes over the last 14 years and the countless doctor appointments I’ve attended. As a disclaimer, I am not a medical professional. Please check with your physician about specifics with diabetes. There is a Diabetes For Dummies book which provides a decent overview as well.

Flask Blood Glucose Tracker Application Features

There are already a lot of excellent products on the market for keeping track of one’s blood sugar levels. With that in mind, this application is going to be fairly simple to start. I would like to build it with growth in mind, however, so building a REST API into the project seems like a good idea. My basic feature list to start with is:

  • Register for the BGT site, with email confirmation.
  • Login/Logout and based on role have different access.
    • Patient to access and edit my own data.
    • Physician to get a list of all current patient records.
    • Administrator for site maintenance.
  • Input blood sugar levels with date and time of reading and indication of before or after a meal or snack.
  • Display the data in a table with averages.
  • Display the data in a chart or visual format.
  • Typical CRUD operations for the data
  • REST API to expose patient blood sugars in a secure fashion
  • Data is stored in the cloud for accessibility and ease of database maintenance.

For the reporting features highlighting high and low blood sugar levels in the report would be helpful. Since what is “good” and “bad” can change for each individual, I’ll include a field for each individual to set that.

Application Stack

I have already mentioned that this application will be built with Flask. For the data store, I will use MongoDB. To keep in line with the feature request of storing data in the cloud, MongoDB offers a Database as a Service (DBaaS) called Atlas.

I haven’t quite figured out yet where I’ll ultimately host this application, perhaps Heroku? Or maybe on my own server.

Application Libraries

When it comes to libraries, there are a lot of choices. Here’s what I’ll be using, which will also be included in a requirements.txt file.

  • Flask version 0.12.2
  • Flask-Login, 0.4.0
  • Flask-PyMongo, 0.5.1
  • Bokeh, 0.12.6
  • Jinja2, 2.9.6
  • pandas, 0.20.2

There are other libraries that will but used as well, but those are the main ones of interest.

I’m also more of a fan of Zurb Foundation than Twitter Bootstrap, so I’ll be using that for styling.

Pages and Routes

Web Pages

To start with we need a way for a user to log in, enter their personal data, enter a new blood sugar record, edit their record, and view their information in both a tabular format and then in a chart format.

We’ll need the following pages, at least to start.

  • Index
  • Registration
  • Login/Logout Page
  • Profile page, login required
  • Records page (create, read, update, delete), login required
  • Chart page, login required

For a Physician we would want to be able to:

  • Display all of their patients, login required

For an Administrator, we want to be able to

  • Have the ability to manage users (patients & physicians) but not be able to see patient medical data.
REST API Routes

From the API I want to expose the ability to securely read and write (GET and POST) data to a patient’s record. This will make it easier to, for example, write a mobile application to connect to our data. Or, with the advances in blood sugar monitors, perhaps automatically update our application with readings from a device.

Document Model

Since I will be using MongoDB to store data for this application, I’ll be leveraging the document model. This offers a lot of flexibility in how data is stored, among other benefits. I would encourage you to read my blog post on the document model if you are not familiar with it.

To start with, the basic data we want to capture and model will be as follows:

BGT Sample Document
Sample Patient Record document

In looking at this sample document, the groups field will keep track of values such as patientphysician, and admin. I have chosen to implement the postal_code and MRN values as strings instead of integers to accommodate alpha-numeric values.

Through the course of developing this application, we will see the flexibility of the document model in action. We’ll see how we can utilize some of the features from MongoDB’s aggregation pipeline to handle our data processing as well.

Wrap Up

I have outlined a nice project here which will utilize several different bits of programming. In the next few posts then, I’ll cover how to implement all of these features into an MVP application. I would definitely enjoy receiving feedback, so please leave comments below.

 


Follow me on Twitter @kenwalger to get the latest updates on my postings.

Facebooktwitterredditlinkedinmail

A review of the LoPy microcontroller

In an effort to stay current with microcontrollers, I recently picked a new MicroPython enabled device, the LoPy. Like the ever popular NodeMCU ESP8266, it is capable of utilizing many different components and gadgets. However, to LoPy comes with MicroPython installed so flashing the device isn’t necessary to write projects in Python.

The LoPy board is produced by PyCom which is based out of the United Kingdom and was released towards the end of 2016. It is more powerful and feature-rich than the NodeMCU which drives the price up over the ESP8266 boards. It also requires the use of an expansion board to build projects. Ok, requires might not be entirely accurate, strongly recommended might be better. Fortunately, the expansion board can be used with PyCom’s other products as well.

LoPy Specs

The LoPy comes with 512kB of RAM, versus 160kB for the ESP8266. It can handle up to four times as much flash memory (4MB) as well and uses the Espressif ESP32 chipset. All of that opens things up for larger IoT projects. One really cool and interesting feature with the LoPy is the addition of a LoRa radio frequency system in addition to the other radio system

This little board has three different radio systems on it.

  • LoRa
  • WiFi (802.11 b/g/n 16Mbps)
  • Bluetooth, both Bluetooth Classic and Bluetooth Low Energy (BLE)

The device accepts, and in fact, in the case of LoRa requires the use of external antennas, there are connectors for one WiFi antenna and one LoRa antenna. The use of the external antennas yields some impressive distances for operating ranges. For WiFi the range is a reported 1km and for LoRa, in perfect conditions as a network node the range is specified as 40km.

PyCom LoPy Device

It provides support for a variety of security and hash/encryption methods such as TLS/SSL. For power, it takes 3.3V – 5.5V of input and with the expansion board easily connects to power with a USB connection. Additionally, it also allows for a battery to be connected for powering the device away from a USB connected computer.

LoRa

I am going to assume that most people are familiar with WiFi and Bluetooth technologies in general terms. I will also assume that most people are not familiar with LoRa, so let’s spend a little time discussing it.

At a high level, LoRa is designed as part of a moderate range wireless network called Low Power Radio Wide Area Network (LoRaWAN). The focus of LoRaWAN is to provide IoT devices a standard and seamless communication system to communicate between IoT devices covering large areas. In a LoRaWAN network data is sent digitally from one node to a neighboring node. If that node is not the data’s final destination, it is forwarded on until the final destination is reached. This final destination is often a gateway connection to the Internet allowing for global reach.

Most of us in the developed world are used to very high speeds when it comes to network access. For example, I just tested my internet speed and had just over 48 Mbps for download speed at 6 Mbps for upload. LoRaWAN can only dream of these speeds. LoRaWAN tends to max out around 50 Kbps, yes, that’s a K there. Under 0.5 Kbps is common on the slow end. This may send chills down your leg at first glance, but really, what types of data are typically sent with an IoT device? Most applications are sending basic sensor data and not streaming video or audio.

LoPy LoRa settings

As most of us are painfully aware, there are global forces at work when it comes to management of things like radio waves. The same holds true for the frequencies on which LoRa operates.

Region Frequency in MHz
North and South America, Australia and New Zealand 915 MHz
Europe 868 MHz

You will need to configure the LoPy to utilize the proper frequency. This is accomplished through updating the firmware (a good practice anyway) with a selection of the country. Fortunately, these frequencies and devices fall under the category of low-power transmitters in the ISM band and don’t need to be licensed.

Wrap Up

The features, power requirements, and radio capabilities make the LoPy a very interesting IoT device. Especially for those that want to be able to utilize a flavor of Python to build their projects. In fact, the LoPy would be a great candidate for nodes in a mesh network. I’ll talk about the idea of a mesh network in a future post.

I hope that this brief overview of the LoPy has shown some interesting features. Perhaps it will expand the possibilities for your IoT projects. The capability to use a LoRaWAN network to cover long distance communications is particularly intriguing.


Follow me on Twitter @kenwalger to get the latest updates on my postings on MicroPython and IoT and let me know what you are building with MicroPython.

Facebooktwitterredditlinkedinmail