Introducing GlucoFit: An Assistive Technology forMonitoring and Managing Diabetes

Bryan Gislason, Christopher McKnight, Brianna Potvin, Sean Stuart, Juan Zepeda,‡Jens Weber, and Haytham ElMiligi

Faculty of Engineering

University of Victoria

Victoria, BC, Canada

Email: {bgislaso, christopher.mcknight395, brianna.potvin, stwsman, jubosz}@gmail.com

Abstract—This paper introduces GlucoFit, an application de-signed for diabetics to help them manage and monitor theirblood sugar (glucose) level. It allows users to input their bloodglucose readings and insulin injections. With the use of theexercise information from FitBit, an exercise monitoring device,GlucoFit also provides suggestions for exercise goals to increasethe user’s physical activity. The GlucoFit server and web clientwere developed using the Django web framework and Python.The application Tastypie was used to create the GlucoFit RESTAPI. In addition to the web client, a mobile application wasdeveloped for the iPhone, allowing users to record and reviewblood glucose and insulin injection data and monitor fitnessgoals.1

I. INTRODUCTION

In recent years, the North American lifestyle has become

increasingly sedentary. As a result, there has been a rise in

obesity rates and the diagnosis of type 2 diabetes. Increasing

daily exercise and eating healthy food can help reduce the

side effects of diabetes and improve overall health. Making

these healthy life changes can be foreign and difficult for

someone who has previously lived an inactive lifestyle. To

address this problem, we are introducing GlucoFit, a prototype

web service that is designed to help newly diagnosed and

already diagnosed diabetics transition to a healthy and active

lifestyle while monitoring and managing their diabetes. The

GlucoFit application utilizes the FitBit Ultra device, which is

an exercise-monitoring sensor. This portable device is clipped

onto a user’s clothing and then tracks their number of steps,

distance, and calories burnt over the course of the day. This

information is then wirelessly uploaded to the FitBit server. By

using the FitBit API we are able to retrieve this information

and use it to suggest exercise goals to the user. These suggested

exercise goals are dynamically generated by the user and

are dependent on a user’s exercise history. By analyzing a

user’s FitBit data, daily and weekly goal suggestions can be

generated to increase a user’s activity in neglected areas. After

using GlucoFit, a user should start getting into the habit of

integrating exercise into their daily lives.

This paper is organized as follows. Section II highlights

similar work. Section III explains the technologies used to

develop the GlucoFit application. Section IV discusses the

1‡ First 5 authors listed in alphabetic order, equally contributed to the work.

system design and implementation. Section V covers the

mobile application development. Section VI shows the per-

formance evaluation of the developed application and lists the

limitations. Finally, we draw our conclusion and propose few

ideas for future work in Section VII.

II. BACKGROUND RESEARCH

Managing diabetes can be very challenging. Therefore, soft-

ware developers proposed various mobile-application solutions

for monitoring and managing blood glucose to help reduce

the side effects of diabetes and improve overall health. For

example, an agent-based pervasive healthcare system (PHS)

was developed to support pregnant women with Gestational

Diabetes Mellitus (GDM) [1]. Another example is develop-

ing a platform to support the monitoring, management, and

treatment of patients with type 1 diabetes mellitus (T1DM)

[2], [3]. For integrated E-health platforms, a mobile feedback

system was developed to improve self-care and compliance

of diabetes mellitus patients [4]. For more examples, readers

can refer to a review of mobile terminal-based applications for

self-management of patients with diabetes in reference [5].

There are also a few products on the market today that

incorporate what GlucoFit is trying to attempt. The iPhone

application, Bant [6], is the new leader in blood glucose

management software. It is a social application that allows

users to log glucose reading with ”one touch”. The application

integrates social media to help connect diabetics and create

a diabetic community. The newer blood glucose meters on

the market like the OneTouch VerioIQ [7] identifies patterns

and sends the user notifications. Another example is Bayer’s

Countour USB [8], which allows users to store readings

on the device then connect to a computer and upload the

readings to the user’s GlucoFacts profile. One thing that is

lacking amongst these products is incorporating exercise and

fitness as a way to help manage glucose levels. Research has

shown that small amounts of low intensity exercise can help

diabetics naturally manage their blood glucose levels [9]. On

the other hand, it is also important for diabetics to make sure

that their blood glucose level is at a safe level before high

intensity exercise as they could become hyper or hypoglycemic

[10]. People who have been diagnosed with diabetes due to

obesity may not know how to easily transition into an active

2012 Seventh International Conference on Broadband, Wireless Computing, Communication and Applications

978-0-7695-4842-5/12 $26.00 © 2012 IEEE

DOI 10.1109/BWCCA.2012.74

414

and healthy lifestyle that could help them manage both their

diabetes and weight.

III. TECHNOLOGIES

This section discusses the technologies used to develop the

GlucoFit application.

A. Python/Django/Tastypie

The majority of the GlucoFit application was written in

Python using the Django web framework. Tastypie, an addi-

tional Django application, was used to easily create the REST

API. This language and framework were chosen due to ease

of development and developer experience.

B. Heroku

Heroku [11] is a cloud based application platform that

allows for the easy deployment of scalable applications.

Choosing to deploy GlucoFit on Heroku allowed for quick

deployment of the application on multiple servers for no cost.

C. FitBit

One of the key technologies used in the GlucoFit application

is FitBit [12]. FitBit Ultra is a small portable monitor that

contains a 3D accelerometer and has the ability to track

distance travelled, steps taken, stairs climbed, and calories

burnt. This information is available through their API after

users have authenticated our app with their service. Although

FitBit has some goal tracking and achievements associated

with their service, they rely on the user to set the goals

based on total number of stairs climbed or other exercise that

they want to complete a day. To separate ourselves from this

service, we plan to dynamically suggest goals based on a user’s

historical FitBit information.

D. iOS

The mobile front end of the GlucoFit service was developed

in objective-C on Apple’s iOS platform. The decision to

develop the application on the iPhone was mostly due to

the availability of iOS devices and previous development

experience. Out of all the mobile platforms currently on the

market, iOS has one of the largest app markets and has a

fairly large user base. Users don’t necessarily need access to

an iPhone as new iPod touches support newer version of the

iOS.

IV. SYSTEM DESIGN AND IMPLEMENTATION

A. Features and System Overview

There are three key features in GlucoFit: 1) blood glucose

and insulin tracking, 2) integrating exercise information from

FitBit, and 3) an exercise suggestion engine. Figure 1 illus-

trates the overall system architecture. The core functionality

of GlucoFit is accessed through two different clients, a web-

interface and an iPhone application. Both these clients com-

municate with the central GlucoFit server. The server stores

a user’s blood glucose, insulin injections, and current goals.

The server also provides the point of contact to the FitBit API

when requesting a user’s exercise information. The following

subsections will describe the design and implementation of the

server, suggestion engine, web client, and mobile application.

Fig. 1. GlucoFit System Overview.

B. Server

The GlucoFit server was designed and implemented to

contain four key elements:

1) Models, as required by the Django framework.

2) REST API, implemented using Tastypie.

3) Views, generally for providing user front ends.

4) Authentication mechanisms, which are technically im-

plemented as views and which make heavy use of the

oauth2 Python package [13]

These four components combine to satisfy the requirements

placed on the server, and Figure 2 represents the interactions

between the different server components.

Fig. 2. Server Architecture.

The models are implemented as defined by the Django

framework. These classes essentially serve as wrappers to

database tables. They can be queried, modified, updated, and

415

so on, and serve as the data backbone of the application. Six

different models were used:

• GlucoseRecord; used to store a user’s glucose history.

• InsulinRecord; used to store a user’s insulin history.

• Suggestion; used to store suggestions in the system.

• Goal; used to store a user’s goals.

• Profile; used to hold information about a user not stored

in the user table, including tokens involved in the Open

Authentication handshakes.

• User; a Django implemented model used for authentica-

tion and authorization.

These six structures define the data required to support our

application.

1) REST API: The REST API was built on top of the

models using a Python/Django framework called Tastypie [14].

This framework greatly aided the development of a REST

API and in fact only resulted in the creation of wrapper

classes for each of the models, that serve as the operands

inside the Tastypie framework. This made the implementation

of the API very quick, once the behavior of the framework

was determined. The Tastypie framework also allows for

authorization and authentication classes to be defined allowing

for the customization of access granted to users. The views

are simply the server side components of the user front end.

It should be noted, however, that these views make use of the

authentication structures discussed in the following subsection.

2) Authentication: Authentication within the Glucofit sys-

tem is implemented using the Open Authentication (OAuth)

protocol [15] and the oauth2 framework. FitBit provides this

service to allow other applications, such as our Glucofit

system, to use their login information as the users’ credentials

to log into Glucofit. The authentication process involved is

not covered here as it is strictly a standard procedure and is

not inside the scope of this paper, other than to state that

FitBit provides a suitable API to allow for the use of the

OAuth protocol to log users into the Glucofit system. The

current implementation for a mobile client requires that the

client already has an account and has logged in on the mobile

device. Once logged in, the user can view their token on a

specific URL (specifically rooturl/token). This token can then

be input into the application and the token and the user’s ID

can be piggy-backed onto any requests made by the phone

client to the Glucofit server. This token and username pair

will then be used for authorization and authentication of the

client. Clearly, there are issues with this implementation, and

it certainly stands as one of the biggest flaws in the security

of user data. The authentication structure, once set up with a

logged-in user, is then used as a gateway to contact FitBit.

Using the authenticated client structure provided as part of

the oauth2 framework, it is possible for GlucoFit servers to

contact and request user information from FitBit servers. We

plan to improve the level of security of the data in our future

work.

C. Web Client

The intention of the GlucoFit’s web application front end

is to provide users with an easy-to-use interface to the system

that allows them to view and enter blood glucose and insulin

injection data. It was decided that to do this the best approach

was to create a web site consisting of four core pages,

each serving their own purpose. The home page immediately

provides users with information that is considered the most

relevant to them. This information is displayed in a large

format, which is allowed since the information presented is

limited to the users’ latest glucose and Insulin readings and

the quantity of goals they have achieved. If users require

access to insulin and glucose records other than the latest ones,

they may visit the history page. The home page also presents

warnings to the user if there are warnings to be presented.

Figure 3 illustrates the home page presenting a warning for

a high glucose level.

Fig. 3. Web Client High Glucose Warning.

1) Logging Glucose and Insulin Information: The data

entry page allows users to input their glucose readings, or the

amount of insulin taken at a certain time. The page presents

users with separate forms for each of the aforementioned data

types. Users are also allowed to specify the date and time of

the reading. For specifying dates, the site displays a calendar

view similar to those found in travel sites and as shown in

Figure 4. This is the only way in which the site allows users

to input dates as doing so eliminates date formatting problems.

The values of all other fields are verified by the Django

back-end (e.g. letters are not allowed numbers are expected,

and numbers fall within an expected range) before storing to

the application’s database. When users submit data, they are

informed if they are inputting invalid data, and whether or not

the data was successfully stored.

2) Activity and History Pages: The Activity View page

allows users to view activity data that has been stored on their

FitBit accounts. This data is presented on a day-by-day basis,

for which users must specify the dates for which they wish to

see activity records. For each activity recorded for that day,

the page displays the amount of calories which were burned,

the distance covered, and the duration of the activity.

The History page allows users to review readings they have

416

Fig. 4. GlucoFit Web Client Data Entry.

input into the system other than the latest ones presented by

the home page. It is divided into two similar subpages, with

little variation in format and differing in the information they

present. Specifically the purpose of one subpage is to present

a history of the users’ insulin records and the purpose of the

other is to present a history of the users’ glucose records. The

format of the page for a user’s insulin and glucose records is

shown in Figure 5.

Fig. 5. GlucoFit Web Client Glucose History.

V. MOBILE APPLICATION

The mobile application was developed for iOS 5.1 for the

iPhone. In addition to the iOS 5.1 SDK, the open source

SBJSON library [16] was used for parsing the JSON requests

from the GlucoFit RestAPI. The overall design of the mobile

application is simple and mostly consists of navigation and

handling of the JSON requests to the server. The mobile ap-

plication consisted of five main views: home, glucose readings,

insulin injection, goals, and settings. There are two additional

views on the glucose and insulin page for entering a glucose

reading or insulin injection.

A. Summary View

Once the application has been loaded the user is presented

with the Home view, as shown in Figure 6. This view makes

a few API requests to the server and presents the user with a

summary of their information stored on the GlucoFit server.

The latest blood glucose and insulin readings are displayed,

as well as a calculation of their current A1C% value and the

number of goals they have completed. On the bottom of the

screen they can see their current goals in progress.

Fig. 6. Mobile Application Home View (L) and Goals (R).

B. Glucose and Insulin Views

The glucose and insulin views are based off the same

structure in order to ensure that the interface and feedback is

consistent across the application. When a user selects either the

Glucose or Insulin tab located at the bottom of the application

they will be taken to the views in Figure 7. The initial screen

makes a simple JSON request to the GlucoFit API to retrieve

the last 20 glucose or insulin records. Once the information

has been received, the application parses the information and

displays it in the text field. The benefit to displaying the history

in this text field is that the text can be selected and copied to

an email or word processor on the iPhone. There is a refresh

button on the right side of the bottom tool bar, which will

refresh the text field with the latest records from GlucoFit.

When a user wants to log a blood glucose reading or an

insulin injection they need to tap the (+) button in the top

right corner. This will bring up the Add Glucose Readingor Add Insulin Injection views as seen in Figure 8. For the

Add Glucose Reading the user will be able to input their

blood glucose reading, a label associated with reading (Before

Lunch, After Lunch, After Fast, etc.), and the date and time

the reading was taken. For the Add Insulin Injection the user

can enter the amount of insulin they injected, the type of it

(fast acting, slow acting), and the date-time they administered

417

Fig. 7. Insulin and Glucose Record View.

the injection. The user can also set a reminder to retake their

blood glucose reading to make sure their body is properly

adjusting to the intake of food or insulin.

Fig. 8. Insulin and Glucose Add Record View.

After all the necessary information has been entered into

the fields, the information is sent via JSON request back to

the GlucoFit Server when the button Add Reading or AddInsulin Injection is tapped. After the information has been

successfully sent to the server an alert will appear on the

screen informing the user of its success, as seen in Figure 9.

If the user wants to enter in another reading or injection they

have previously forgotten, they can change the field values and

proceed as usual.

At this stage of the GlucoFit application, the Goals view

is fairly simple as it only displays the active goals as well as

listing the goals that have been completed. If development

were to continue on the mobile application, the ability to

manage goals and see the current progress of them will need

to be added.

Fig. 9. Insulin and Glucose Success Feedback.

VI. PERFORMANCE EVALUATION

After performing an experimental testing, we noticed a few

key technical issues that need to be resolved in order for the

system to meet the security and usability standards we hope

to achieve.

A. FitBit API Maximum Requests

Currently, the checking of current goals requires seven calls

to FitBit each, to retrieve exercise data for each day of the

week preceding the goal end date. This can quickly add up

to a lot of API calls. FitBit currently has a rate limit of 150

calls per hour per user, which could be a problem if the user

frequently refreshes the home page. The exercise information

is not currently saved to GlucoFit locally, since users can log

data for previous days any local data may be obsolete. It is

not also efficient to store data both on FitBit and GlucoFit.

The number of calls could be reduced in the future by only

checking exercise data from the previous week, and saving it

to check against each current goal. Another option would be

subscribing to changes in user data, instead of polling FitBit.

B. Mobile Interface

Although the mobile interface is usable at this point there

are a few improvements that could be made to the way

information is displayed on the phone. For example, for the

glucose view of the application, the information received from

the server is printed to a text box similar to a comma separated

value file. Printing the results to the textbox was a quick fix

for the memory issues that were occurring when attempting

to use a dynamic UITableViewController. If development was

to continue on the mobile application, the glucose and insulin

history pages should be changed so they use the UITableView-Controller as it would clean up the interface and make the

usability similar to other iPhone applications. Changing to the

UITableViewController would also allow for manipulation of

individual glucose readings or insulin injections. In addition,

on the logging screens for both insulin and glucose there

is some lag associated with bringing up the individual data

418

pickers. Removing this lag either by changing the triggering

touch condition or by moving to custom sub-views instead

of custom alert views would improve the response and user

experience. The error handling should also be improved and

provide the user with accurate information of where the appli-

cation failed. Because our implementation does not store any

information on the phone itself, it relies heavily upon a strong

and stable Internet connection. Currently, the application when

loading the history will print that a connection could not be

established to the GlucoFit server. All these errors should be

made consistent through the use of UIAlert popups.

C. Phone Authentication and Server Security

Currently there are a few known issues in the server

application. The first and most crucial of these is the current

state of the mobile app authentication process. This issue

would need to be addressed if work on the system were to

be continued. Another, much less severe issue, is the current

use of a view to act as part of the REST API used by the

mobile application to get a user’s activity data. Essentially,

the current implementations of the activity-based API calls

simply interact with a view on the server side, not a class that

is part of the REST API proper. This is done because the view

is capable of making a REST API request to FitBit on behalf

of the user, whereas the Tastypie API is not. This process,

however, should be rewritten to either use the Glucofit REST

API proper or to contact FitBit directly, bypassing Glucofit

servers altogether.

VII. CONCLUSION AND FUTURE WORK

A prototype of GlucoFit was developed to help patients

manage and monitor their blood glucose level. Much work

remains in order to make this prototype consumer-ready,

but it did provide a platform to learn the complexities in

development and security required for an application in the

medical field. As obesity and diabetes rates rise, it is important

that people have tools that can help them manage their

condition and give them steps towards living a healthy and

active lifestyle and GlucoFit is a step in this direction.

Although the technical aspects of the project proved to be

a success, GlucoFit is still in the early stages of development

and there are few key features that still need to integrated.

One of the most important features that need to be added

is the ability to visualize users’ glucose, insulin, and exer-

cise information. Providing graphical representation of this

information will allow users to identify trends amongst their

glucose and exercise information. Having these visualization

will help illustrate the effects that exercise has on their blood

glucose levels. Having good interactive visualization could be

a valuable tool in increasing the usability and marketability

of GlucoFit. The last feature that needs to be implemented

is exporting a users glucose and insulin records, either by

emailing or saving the results to a file locally. This feature

would allow users to quickly prepare their past blood glucose

readings when they have their next doctors/nurse check-up.

One of our future plans is to get experts’ knowledge

incorporated into the system. The system currently contains

basic suggestions based on our knowledge and should not be

used for actual health purposes. A set of domain experts’

knowledge should be integrated into the system. Doctor’s

would provide the necessary information for warnings on

blood glucose levels and when it is safe to suggest exercise

goals and to what intensity. Physical therapist and fitness

trainers could also be consulted to help provide information

on the proper increments in the exercise suggestion, to slowly

build up the user’s physical fitness. The most important experts

that should be consulted are diabetics. They deal with living

with diabetes everyday and are the end-user for which the

system has been designed. If GlucoFit fits their requirements

of monitoring their diabetes and they are positive about the

exercise suggestions, then the final version of GlucoFit will

probably have a dedicated user base.

REFERENCES

[1] S. Bromuri, M. Schumacher, K. Stathis, and J. Ruiz, “Monitoring gesta-tional diabetes mellitus with cognitive agents and agent environments,”in 2011 IEEE/WIC/ACM International Conference on Web Intelligenceand Intelligent Agent Technology (WI-IAT), vol. 2, aug. 2011, pp. 409–414.

[2] S. Mougiakakou, C. Bartsocas, E. Bozas, N. Chaniotakis, D. Iliopoulou,I. Kouris, S. Pavlopoulos, A. Prountzou, M. Skevofilakas, A. Tsoukalis,K. Varotsis, A. Vazeou, K. Zarkogianni, and K. Nikita, “Smartdiab: Acommunication and information technology approach for the intelligentmonitoring, management and follow-up of type 1 diabetes patients,”Information Technology in Biomedicine, IEEE Transactions on, vol. 14,no. 3, pp. 622 –633, may 2010.

[3] S. Mougiakakou, I. Kouris, D. Iliopoulou, A. Vazeou, and D. Koutsouris,“Mobile technology to empower people with diabetes mellitus: Designand development of a mobile application,” in 9th International Confer-ence on Information Technology and Applications in Biomedicine, nov.2009, pp. 1 –4.

[4] A. Fioravanti, G. Fico, M. Arredondo, and J. Leuteritz, “A mobilefeedback system for integrated e-health platforms to improve self-care and compliance of diabetes mellitus patients,” in 2011 AnnualInternational Conference of the IEEE Engineering in Medicine andBiology Society, 30 2011-sept. 3 2011, pp. 3550 –3553.

[5] N. Tatara, E. Arsand, H. Nilsen, and G. Hartvigsen, “A review ofmobile terminal-based applications for self-management of patients withdiabetes,” in International Conference on eHealth, Telemedicine, andSocial Medicine, feb. 2009, pp. 166 –175.

[6] Bant. (2012) A diabetes app for the epatient. [Online]. Available:http://www.bantapp.com/

[7] OneTouch. (2012) Onetouch verio iq - overview. [Online]. Available:http://www.onetouch.ca/verioiq

[8] Bayer. (2012) Bayer’s contour usb meter. [Online]. Available:http://www.bayercontourusb.ca/

[9] C. Laino. (2012) Exercise after meals helps control blood sugar.[Online]. Available: http://www.medicinenet.com/script/main/art.asp?articlekey=146310

[10] R. Weil. (2012) Managing your blood glucose during exercise.[Online]. Available: http://www.bd.com/us/diabetes/page.aspx?cat=7001&id=7516

[11] Heroku. (2012) Heroku — cloud application platform. [Online].Available: http://www.heroku.com/

[12] Fitbit. (2012) Fitbit. [Online]. Available: http://www.fitbit.com/home[13] Simplegeo. (2012) python-oauth2. [Online]. Available: https://github.

com/simplegeo/python-oauth2[14] C. S. Daniel Lindsley and M. Croydon. (2012) Welcome to tastypie.

[Online]. Available: http://django-tastypie.readthedocs.org/en/latest/[15] O. Community. (2012) Oauth. [Online]. Available: http://oauth.net/[16] SBJSON. (2012) Sbjson (previously known as json-framework).

[Online]. Available: http://stig.github.com/json-framework/

419