AGIL - Active Glucose Insulin Control System
Interface Design Report
Daniel Hewlett
dhewlett@wam.umd.edu
Michael Wires
mwires@wam.umd.edu
December 7, 2004
Table of Contents
Abstract .......................................................................................................................... - 3 Credits ............................................................................................................................ - 3 Introduction ................................................................................................................... - 4 Diabetes – Background ............................................................................................... - 4 Insulin Delivery .......................................................................................................... - 5 Blood Glucose Monitoring ......................................................................................... - 5 Related Work .............................................................................................................. - 6 Presentation of Design .................................................................................................. - 7 Transition Diagram ..................................................................................................... - 9 High Fidelity Screens ................................................................................................ - 10 Report on Development Process ................................................................................ - 25 Task Examples .......................................................................................................... - 25 System Requirements................................................................................................ - 27 Hardware Requirements........................................................................................ - 27 Software Requirements ......................................................................................... - 27 Network Requirements ......................................................................................... - 27 Low Fidelity Prototype ............................................................................................. - 28 High Fidelity Prototype............................................................................................. - 29 Usability Test ............................................................................................................ - 29 Subjects ..................................................................................................................... - 31 Subject 1................................................................................................................ - 31 Subject 2................................................................................................................ - 31 Subject 3................................................................................................................ - 32 Subject 4................................................................................................................ - 32 Subject 5................................................................................................................ - 32 Subject 6................................................................................................................ - 33 Subject 7................................................................................................................ - 33 Subject 8................................................................................................................ - 33 Test Results ............................................................................................................... - 34 Problems ................................................................................................................... - 34 Conclusions .................................................................................................................. - 36 Acknowledgements ..................................................................................................... - 37 References .................................................................................................................... - 38 Appendix 1 – Index of Figures ................................................................................... - 40 -
-2-
Abstract
Traditionally, diabetics have relied on a combination of finger-pricking blood
sugar meters and insulin injections to control their blood sugar levels. Recent studies
have demonstrated the effectiveness of two new technologies in controlling blood sugar
levels: the insulin pump and continuous glucose monitoring. The insulin pump allows the
user to program insulin delivery, which is done through a hidden needle inserted in the
body. Continuous glucose monitoring prevents any fluctuations in blood sugar levels
from going unnoticed. Soon, blood sugar measurements will be taken through the needle
already used by the insulin pump, combining these technologies. Once this occurs, the
interface and functionality of the current insulin pumps will be unable to take full
advantage of the possibilities available.
The AGIL Control System is designed specifically to take advantage of this new
integrated system. It provides insulin delivery, blood sugar management, record keeping,
programmable insulin pump control, and emergency notification, all on a PocketPC
device.
Credits
Daniel Hewlett and Michael Wires
 Initial low fidelity concept and prototype design.
 User needs introduction and task examples.
 References and Task list.
 Pre and Post Test Questionnaires.
 Usability testing.
 High fidelity prototype design and initial code setup for entire program.
 Revisions and slide show presentation.
Daniel Hewlett
 Proposal and System requirements.
 Second prototype design document.
 Bulk of programming for “Home Screen” and all screens linked from “Home
Screen.”
 Interface Design Report – Introduction, Presentation of Design, Conclusions
Michael Wires
 Reference annotations.
 Prototype tutorial.
 Usability test report.
 Bulk of programming for setup process.
 Portfolio compilation.
 Website design.
 Interface Design Report – Report on Development Process, miscellaneous areas,
and compilation.
-3-
Introduction
Diabetes – Background
Diabetes affects more than 177 million people worldwide, leaving those affected
dependent on external methods of controlling the amount of glucose in their blood.
Maintaining an acceptable level of blood glucose is essential for both short-term and
long-term health. If levels become too high, a condition called hyperglycemia, the
individual may become light-headed and feel ill. If levels become too low, called
hypoglycemia, the individual may suffer from a lack of alertness, or even lose
consciousness. In the long term, however, the consequences of greatly fluctuating blood
glucose levels are even more serious, including damage to the nervous system, heart, and
kidneys.
However, when blood sugar levels are kept within an acceptable range, these
negative effects can be greatly ameliorated or even avoided altogether. Studies show a
strong correlation between poor blood glucose management and these negative side
effects; but the opposite is true as well. Essentially, the more blood glucose levels stay
within a healthy range, the smaller the chance of negative side effects becomes. There are
many factors that influence glucose levels in the human body, including diet, exercise,
and sleep. The key to effective diabetes care, then, is to provide the means to a lifestyle
that allows all these factors to be kept under control, and where treatment methods are as
unobtrusive as possible.
In people without diabetes, glucose levels are controlled by the pancreas, through
the production of a chemical called insulin. Insulin allows the body’s cells to absorb
glucose from the bloodstream, keeping the cells nourished and regulating the level of
glucose in the bloodstream. In people with diabetes, the pancreas does not produce the
proper amount of insulin needed to keep glucose levels within the proper range. Without
insulin production, glucose accumulates in the bloodstream to dangerous levels, and cells
cannot get the energy they need to function properly. Thus, many require some form of
supplementary insulin delivery.
While treatment plans for diabetes vary from one individual to the next, there are
three types of diabetes that require different treatment. The first is type 1 diabetes, which
was formerly known as juvenile diabetes. While it accounts for only about 5-10% of
known diabetes cases within the United States, individuals with type 1 diabetes are the
most likely to require constant glucose monitoring and to be dependant on insulin
injections, and so are the most likely users of our system. This is because type 1 diabetes
is caused by an (total) inability to produce insulin. Since all insulin in the body must then
be delivered, the responsibility rests on the individual to do the job their body’s job.
Individuals with type 1 diabetes must monitor their diets closely, and respond
appropriately to actions that affect blood glucose levels.
Type 2 diabetes is much more common than type 1 diabetes, accounting for 9095% of known diabetes cases within the United States. It occurs when insulin production
is insufficient, or when the body’s cells develop a resistance to insulin. Since some cases
of type 2 diabetes can be managed through diet control, exercise, and some medications,
a lower percentage of type 2 diabetics will need our system.
-4-
Gestational diabetes is a condition developed during pregnancy where the mother
is not able to produce enough insulin to accommodate for the changing needs of her
body. It affects approximately 4% of pregnant women. Gestational diabetes is dangerous
to both the mother and the unborn infant, as high glucose levels can also affect the
growth of the fetus through its sensitive and critical maturation. Gestational diabetes
requires careful monitoring of glucose levels and insulin delivery, so mothers with this
condition can benefit from using our system.
Effective diabetes treatment is multi-faceted, often including a regulated diet,
regular exercise, and an avoidance of harmful habits such as drinking and smoking, in
addition to blood sugar monitoring and insulin delivery. However, our system focuses on
the delivery of insulin and the monitoring of blood glucose levels.
Insulin Delivery
Two fundamental types of insulin dosing are employed in the treatment of
diabetes: a dose of fast-acting insulin, called a bolus, and discrete or continuous doses of
slower-acting insulin. The bolus is delivered to offset an action that would raise blood
sugar levels quickly, usually eating a meal. Its effects are visible quickly, and the timing
of the delivery is important. There are two methods of controlling blood sugar over a
longer period of time. The first is a single large dose of insulin that acts slowly over time,
such as Lantus. The second is through a continuous delivery of insulin in small quantities,
at a rate called the basal rate.
There are many methods currently available to deliver insulin. Perhaps the most
common and traditional is through injections. This method is simple, and allows the user
to be in full control of how much insulin they deliver and when. The main disadvantage
is that all insulin deliveries are discrete events, and continuous or near-continuous insulin
delivery is not possible. Its effects can be simulated with insulin that acts slowly over
time, such as the Lantus mentioned above. Users also generally calculate or simply
estimate the amount of insulin they need in a given dose without assistance.
However, studies have shown that a newer method, called the insulin pump, can
provide a level of control beyond that achievable with standard injections. The insulin
pump is a pager-sized device that contains a reservoir of insulin. A small tube connects
the pump to the body. It can deliver insulin in two ways. The first, in one large dose, is
used for meals and is essentially the same as the normal injection, except it is physically
administered by the pump, not the user. The advantage of the pump lies in a second
delivery method: a small, slow dose called a basal rate. This basal delivery more closely
mirrors the action of the human pancreas, and so controls glucose levels better in the time
between bolus doses. These devices usually support multiple basal rates, and the ability
to compute bolus doses through a pre-programmed formula.
Blood Glucose Monitoring
The prevalent form of blood glucose measurement is through a system of fingerpricking, test strips, and electronic measuring devices. A pen-like device pricks the finger
of the user, allowing them to collect a small blood sample using a test strip. This strip is
-5-
then inserted into a small measuring device and a reading is taken. The devices often
record the results in the form of a long list, or else a log book may be used.
More sophisticated approaches to this problem are nearly available. Continuous
glucose monitoring was once a cumbersome and expensive proposition, and so was only
used in critical cases, such as hospitalized patients. Now, technological advances have
made these devices not much larger than conventional glucose monitoring devices. The
potential benefits of continuous monitoring devices are considerable. Glucose levels may
fluctuate greatly between readings, and there is no way of telling this directly without
continuous monitoring.
Related Work
The most common current way for a user to control an insulin pump is through a
low-res, monochrome screen, with only a few buttons, such as a directional pad, OK, and
Cancel. Some devices feature a small pager-like device that communicates wirelessly
with the pump itself, though the basic interface is unchanged. Continuous blood sugar
monitoring is possible today, but is not common. The traditional method of fingerpricking to gain blood samples for testing devices is still prevalent. However, building
monitoring into the pump itself appears to be a near-future reality (see Figure 1), as such
devices are already beginning to enter clinical trials.
Automated glucose control by the pump, which would
essentially make it an autonomous artificial pancreas,
appears to be farther away, and is not a consideration of
our design.
While no PDA-based system with the capabilities
of our design exists, other PDA-based systems for blood
sugar management do exist and serve as the primary
competition for our design. The recently discontinued
TheraSense FreeStyle Tracker was a Palm-based hardware
Figure 1 - MiniMed's
vision of a combined
and software combination that supported glucose
insulin pump and
measurement and logging, as well as some viewing of
continuous glucose
charts and graphs of data. This product was similar to ours
monitoring system.
in that it incorporates glucose monitoring directly, but it is
not continuous and does not interact directly with a glucose delivery system.
Academic Studies
Research has proven the advantages of both continuous glucose monitoring and
the insulin delivery methods used in the insulin pump. A 2003 study by Chico, et al
determined that continuous glucose monitoring systems were able to detect
hypoglycemias, or episodes of low blood sugar, that went undetected in diabetics using
traditional, or capillary, glucose measuring techniques. In type 1 diabetics, continuous
monitoring was able to detect unrecognized hypoglycemias in 62.5% of those studied.
Subjects used the same kinds of insulin delivery (Chico, 2003). This study demonstrates
that continuous glucose monitoring can reveal import features that capillary glucose
-6-
monitoring cannot. Our interface seeks to capitalize on this fact by making the data
gathered by the continuous glucose monitor readily available and clear to the user.
Perhaps a more striking result is that achieved in a recent study about the efficacy
of the insulin pump, specifically one from MiniMed corp, compared to that of multiple,
daily injections. This Yale study, by Doyle, et al, found that users of the insulin pump
were much more likely to achieve consistently acceptable glucose levels, as measured by
the A1c hemoglobin test. Six times as many insulin pump users achieved the acceptable
level than did users of Lantus, described above. This result shows the large potential that
exists for improving glucose levels with the insulin pump. Our design seeks to expose
this capability to the user in a simple and effective manner, further encouraging user
involvement in the care process.
Presentation of Design
Our design consists of an integrated insulin pump and continuous glucose
monitor. This design allows total blood sugar control with a single device. With the
ability to continuously monitor insulin, users are able to monitor their own health to an
extent not commonly available today. This produces the opportunity for the system to
demonstrate a very high level of responsiveness, leading to more engaging user
interaction. Since the ability to deliver insulin is built into the device as well, the user can
respond quickly to any problematic situations that arise, before they become dangerous.
For the device platform, we chose the PocketPC, because it has features that allow
us to build advanced functionality into the design. It is a small, portable device, and so is
reasonable for users to carry with them at almost all the time, a fundamental requirement
for the device. It features a 3.5” or 3.8” color screen, which enables the display of
meaningful information more easily, such as charts and graphs. It has the ability to
produce sounds and sometimes vibrate, two features essential to the notification system.
Finally, it supports a range of wireless communications, meaning it can send messages
and medical information to doctors or emergency personnel, phone these interested
parties, and also communicate wirelessly with the pump itself, encouraging further user
interaction with the device.
The main goal of our design was to provide an interface direct enough to make
the user feel in control of their own health, simple enough to make frequent interactions
consume minimal time and stylus presses, and powerful enough to deal with the full array
of situations users will encounter in their lives. Diabetics lead full and rich lives, and this
device would be a near constant part of them, being used at every meal, waking up and
going to sleep, and whenever physical activity levels change. Some diabetics, such as
former Baltimore Orioles pitcher Jason Johnson, a long-time proponent and user of the
insulin pump, have even become professional athletes.
To maintain internal locus of control, our design avoids automation and judgment
of the user. It does not work as an artificial pancreas, dynamically calculating insulin
delivery rates in a way that would be inaccessible to the user. The user determines when
to deliver bolus insulin and how much to deliver, exposing the simple calculations needed
to compute this value so the user knows exactly why the calculated amount is being
delivered. For basal rates, the user sets the current rate and must specify whether to use
-7-
the only automatic rate change available in the design, the switch from morning rate to
the normal waking rate.
During setup, the user and their doctor specify exactly how the device should
respond to a variety potentially dangerous situations, leaving no surprises when such a
situation arises. When blood sugar levels leave the target range specified by the user, the
device presents the relevant numbers to the user and suggests possible courses of action.
This means that the device allows the user to make an informed decision based on
information provided by the user and the facts of the current situation, rather than having
to trust the machine’s problem solving abilities. There are no judgmental messages such
as “You need to monitor your levels more closely,” but rather simple visualizations that
make evident the user’s success in keeping their levels where they want them to be.
Finally, our design allows for both the intuitive level of interaction needed for
early users and the faster but less self-evident expert interactions. Expert features and
shortcuts are important in this device because users will do the exact same few tasks
(such as eating a meal) every day, more than once a day. For this reason, we have
incorporated one-finger navigation into the two most commonly used screens, the bolus
dose (Eat a Meal) and basal rate (Change Schedule). This feature is explained more in the
tutorial/help subsection at the end of this section.
-8-
Transition Diagram
Yellow: Setup, Green: Main Functions, Red: Advanced Functions
View Messages
Begin
Send Message
Personal Info
View Levels
Advanced
Doctor’s Info
View History
Schedules
Add Schedule
Device Status
Sleeping
Schedule
Emergency Call
Bolus Formula
Preferences
Levels
Eat Meal
Responses 1
Main
Change Schedule
Responses 2
Sleep
Confirm
Figure 2 - Transition Diagram
-9-
High Fidelity Screens
General Device Features and Main Screen
Figure 3 - Main Screen
The simple LCD screen above the main screen shows the user’s current glucose
level. This display remains on even when the main screen is turned off, so that the most
important monitoring information is immediately visible at all times. This also means that
the user can access this information at any screen of the interface, so that the user will not
need to switch screens just to obtain this piece of information.
In developing our design, we felt it was important to actually use the interface on
a real PocketPC, so that we understand and take advantage of aspects of the device
design. This was part of our inspiration for the one-touch designs. While complexity is
- 10 -
often measured in stylus presses, this approach leaves out some important factors: the
removal and replacement of the stylus take time, and even the simplest text input is
complicated by the cramped on-screen keyboard, which is a fixed part of the system. The
text input methods on the device are all prone to error (the keyboard because of small
keys, the text recognition systems because of inaccuracy). Since the interactions on the
main screen are all intended to be quick interactions that begin and end with the device
off, the natural consequence of all of these factors is the following principles:
1. Make all interaction possible either with the directional-pad or finger.
2. Make data entry and selection possible without using the stylus. For numeric
data, this meant using spinner controls which can be changed with the d-pad.
For other data, selection from a combo box or list box is used.
These principles for the main programs mean that the user never has to even
remove the stylus for these tasks. It also gave rise to a clear distinction between novice
interaction and expert interaction.
This screen shows the three functions of the interface that will potentially need to be
used on a daily basis: Eat a Meal, Change Schedule and Go to Sleep. Each of these
buttons corresponds to an action that the user wants to perform, so their purpose is clear.
These buttons are designed to be reliably pressed with a finger or thumb, so they are large
and far apart. All of the functions linked to on this page can be navigated without using
the stylus, so it is important that this screen be navigable without it as well. The
‘Advanced’ tab at the bottom switches to the advanced feature set. For the other screens
we will only show the actual device screen, because the device layout remains constant.
Begin
Description
This screen simply ensures that the user is in
consultation with their doctor during setup, so
they will be able to obtain any necessary medical
information.
Figure 4 - Setup Screen
- 11 -
Setup: Personal Info
Description
This screen records the users personal
information, so that if an emergency alert is ever
necessary, this information can be transmitted
automatically to medical personnel. It also
enables it to be included in general messages to
doctors.
Figure 5 - Personal Information Setup
Screen
Setup: Doctor’s Info
Description
This screen records the doctor’s information, so
that the user does not need to enter the doctor’s
email address and phone number when
attempting to contact them.
Figure 6 - Doctor's Information Setup
Screen
- 12 -
Setup: Bolus Formula
Description
This screen allows the user to input their bolus
formula, which is used to calculate the amount of
insulin needed in a bolus based on the grams of
carbohydrates eaten. Since the possible values
are small for each number, not more than 10, we
choose to use combo boxes instead of spinners.
Figure 7 - Bolus Formula Setup Screen
Setup: Basal Rates
Description
This screen displays the list of schedules, or
basal rates, the user has added, and allows them
to modify that list. Entering the schedules in this
way enables the rapid selection of a basal rate by
its associated name later on.
Figure 8 - Basal Insulin Setup Screen
- 13 -
Setup: Add Schedule
Figure 9 - Basal Insulin Setup Screen
Figure 10 - Basal Insulin Setup Screen
Description
These screens allow the user to name each schedule, and enter a corresponding
basal rate. On the sleeping schedule screen, the name defaults to “Sleeping.” The second
screen is treated as a step in the setup process to emphasize the unique status of the
sleeping schedule, but the respective buttons have essentially the same effect as they do
on the first screen.
- 14 -
Setup: Levels
Description
On this screen, the user enters the glucose levels
the device will use to determine if an alert is
necessary. The colored regions correspond to the
colored regions in the graph screen. We
considered using a pair of double-box sliders for
this screen, but the device does not support that
component, and we would have had to
implement one from scratch. This would
probably be worthwhile in a larger project, but
not within the constraints we are under.
Figure 11 - Blood Sugar Levels Setup
Screen
Setup: Responses
Figure 12 - Responses(1) Setup Screen
Figure 13 - Responses(2) Setup Screen
- 15 -
Description
These screens allow the user to configure exactly how the device will respond when
glucose levels leave the target or tolerable range. We used checkboxes because all of the
options (except do nothing) can be enabled for a single event. The combo box is used to
specify a time delay before the actions are taken.
Confirmation
Description
This screen simply presents a confirmation
prompt to the user, letting them know they have
completed the multi-part setup.
Figure 14 - Confirmation Screen
- 16 -
Eat a Meal
Figure 15 - Eat a Meal Screen
Description
This screen is accessed from the main screen, and contains all of the information
and functionality needed to deliver a bolus dose of insulin when food is eaten. The user
only has to enter the amount of carbohydrates in the meal, and the system uses the ratio
entered during setup to determine and display the appropriate insulin dose.
The information on the screen is presented in order of importance to the user.
First, the amount of carbohydrates in the meal, the only numerical value the user has to
modify. This is the only value the user has to “get right” on this screen. Reducing insulin
delivery to this one number should make this screen cause less anxiety in users. Second,
the insulin dose to be delivered is displayed and updated whenever the carbohydrate
amount is changed. For users wanting to very the correctness of the dose, this and the
third piece of data, the bolus formula, should be all that is needed to understand where the
dose amount came from.
This screen is one of the screens designed to be usable without the stylus, because
eating a meal is such a frequent task.
1. Set the carbohydrate amount (Directional pad) – When the user enters the
screen, the focus is set in the spinner control containing the amount of
carbohydrates to be eaten. The user can change this number using the
directional pad, up or down (the system prevents this number from going
negative).
2. Set the meal type (Directional pad) – When the number is correct, pressing the
d-pad in, which is the action button on the PocketPC, visibly moves the focus
to the meal type combo box. Here the user can choose the meal type also
- 17 -
using the d-pad. However, pressing the d-pad in will not deliver the insulin
dose. This is a deliberate error-prevention mechanism. We do not want users
to accidentally press the d-pad in too many times and deliver the wrong dose.
3. Press Deliver (Thumb) – Therefore, the user must actually press the Deliver
button, which means consciously switching input methods to the thumb. After
this is done, a confirmation dialog appears.
4. Confirm (Directional pad) – Because the OK button is automatically selected,
pressing the d-pad will press it and deliver the dose of insulin, returning the
user to the main screen.
Change Schedule
Description
This screen is accessed from the main screen and
allows the user to change their basal insulin
delivery rate. Rather than directly entering the
rate, users select from a list of names for
schedules they entered with their doctor during
setup. When the user selects a new schedule, the
new basal rate, together with the old one, is
displayed at the top of the screen.
Figure 16 - Change My Schedule Screen
- 18 -
Advanced Features
Description
All of the advanced functions can be accessed
from this screen. It is not designed for finger
operation like the main screen is.
Figure 17 - Advanced Features Screen
View Levels
Description
This screen presents the user with various views
of their glucose levels over time, including
month, week, and day. The colored regions
correspond to the values set in the levels screen
of setup. The combo box opens into a date
picker. In a final version, the graph should be
continuous, but this version served our purposes
for testing.
Figure 18 - View My Levels Screen
- 19 -
Send Message
Description
The message sending screen opens with the
doctor’s email address already filled-in, so the
user only has to be concerned with the message
they are writing. The attach graph button links to
the “View My Levels” screen, where the user
can select a graph to attach to the current
message.
Figure 19 - Send a Message Screen
Emergency Call
Description
This screen provides three ways to call for help
in an emergency: the doctor’s emergency
number, provided during setup, a standard
emergency number (911), and the option of
typing in any other number if necessary.
Figure 20 - Emergency Call Screen
- 20 -
Notification
Description
This screen appears when glucose levels rise
above the target maximum. It appears regardless
of what other alerts were enabled in the
responses setup. It presents the information
relevant to the situation clearly, and then
suggests two courses of action to the user. If
neither course is desirable, the user can choose to
ignore the alert and seek to remedy the problem
some other way.
Figure 21 - Notification Screen
Tutorial
First Time User
The first time the unit is powered on and the software is run, the user must set
certain parameters, as well enter personal information. It is expected that this will be
done with the help of the user’s physician. In the case of a minor, the parents would also
be involved. The first screen shown when AGIL runs is an introductory screen, with the
message Click to Begin. Once the user clicks, they will enter an eight-step setup program
that is detailed here.
1 – Personal Information
This screen is where the user enters data about themselves, including: First Name,
Last Name, Birth Date, and Diabetes Type. The first two fields are filled out using the
onscreen keyboard, and the Birth Date and Diabetes Type fields are filled out using a
sequence of combo boxes. When finished, the user can select Next to continue (this is
true for all screens during setup.) From this screen on until the setup is complete, the
user will also always have the option of selecting Previous to return to the previous
screen.
2 – Doctor’s Information
- 21 -
This screen is where the user enters data about their doctor. There are five pieces
of information that must be entered: First Name, Last Name, Email Address, Office
Phone, and Emergency Phone. These fields are all filled out with the onscreen keyboard.
3 – Basal Insulin
On this screen, Basal Insulin(1) the user defines different delivery schedules
which can be activated throughout their day. The user starts by selecting Add New to
create the first schedule. A new screen appears, prompting the user for the Schedule
Name and Rate. When done, the user selects Ok, and the screen returns to the list of
schedules. The user then has the option of selecting Add New to create more schedules,
selecting Edit to modify previously created schedules, or Delete to remove schedules.
The user must create at least one schedule before they may continue.
Once they select Next, the user is shown the Basal Insulin(2) screen. Here the
user sets the name of the schedule they will use while sleeping, and the corresponding
rate.
4 – Daily Schedule
Here the user selects which schedule they want to use as their default. If the user
created more than one schedule, they also have the option of choosing to use a different
schedule when they first wake up in the morning. If they do so, they also set how long
they want this schedule to be in affect before switching to the default schedule.
5 – Bolus Formula
On this screen, the user enters the ratio that will be necessary for the software to
later calculate Bolus dosages for the user. Later, the user will be able to enter the amount
of carbohydrates in the meal they are consuming, and the software will use this data
along with a formula to calculate the correct amount of insulin to deliver.
6 – Blood Sugar Levels
At this step, the user must enter blood-glucose values that will correspond to the
status light (see the next section). There are four necessary values: max and min “target”
values, and max and min “tolerable” values.
7 – Responses(1)
On this screen, the user selects what action they want AGIL to take when their
blood sugar level leaves the Target range defined on the previous screen. If they choose
anything other than “Do Nothing,” they must also select a time delay for the appropriate
responses.
8 – Responses(2)
- 22 -
On this screen, the user selects what action they want AGIL to take when their
blood sugar level leaves the Tolerable range defined in step six. If they choose anything
other than “Do Nothing,” they must also select a time delay for the appropriate responses.
Confirmation
Once the user has completed the eight steps of setup, they are asked to confirm
that the data they entered throughout the setup process is correct. If they select Done,
their information is saved, and they are taken to the Home Screen.
Status Pod
A device will plug into the top of the Pocket Pc that will display the current
Blood-Glucose level, alongside a general status light. If the user’s blood-sugar level is
within the target range that they have set, the light will be green. This allows the user to
simply glance at the unit to tell them quickly if there is a problem. If the light is green,
they need not even look at the actual number if they don’t want to. The light will turn
yellow when the user is in their tolerable range. If the user is outside their tolerable
range, the light will be red. The unit will respond in different ways to these various light
changes depending on the preferences of the user.
The other main purpose of the Status Pod is to allow the Pocket PC to be powered
down to keep from wasting batteries. The Status Unit will run on its own power supply,
and being that its display is a simple LCD screen and LED light, will consume power at a
much slower rate then if the entire Pocket PC was on. The Status Unit in conjunction
with the Glucose Pump will continue to deliver insulin at the current basal rate while the
main unit is off.
Home Screen
The Home screen is by default where users will start when they power on the unit.
From the Home screen, the user can select from two tabs: Main and Advanced. The
Main tab contains the following options:



Eat A Meal
Change My Schedule
Go to Sleep
The Advanced tab contains the following options:







Deliver Corrective Dose (Not Implemented)
View My Levels
Device Status (Not Implemented)
Send Message
View Messages (Not Implemented)
Make Emergency Call
Adjust Preferences (Not Implemented)
- 23 -
Eat a Meal
First, the user enters the carbohydrate count of the food they are consuming using
a spinner. The screen shows the user’s bolus calculation ratio at the bottom of the screen,
and dynamically updates the actual insulin amount that will be injected as the user sets
the spinner. Then, the user selects what meal they will be eating from a drop down box.
The selections are: Other, Breakfast, Lunch, or Dinner. The user can then select Deliver,
and must then confirm the amount of the injection. If they select to Confirm, the insulin
is delivered through the insulin pump. This entire screen can be manipulated with one
finger. At any time, the user can Cancel to navigate back to the Home screen, as they can
on any of the following screens.
Change My Schedule
This screen displays the current basal schedule name and rate in a list box, along
with all the other schedules the user has setup. Changing the schedule is done by
selecting a new schedule, then clicking Change.
Go To Sleep
Selecting this button causes the unit to switch between your current delivery
schedule and your sleeping schedule. A message appears letting you know the unit is in
Sleep mode, and displays a button to click to return to Waking mode.
View My Levels
On this screen, the user selects a date, and then from a combo box: Day, Week, or
Month. The appropriate graph is then shown, displaying the user’s past blood sugar
levels. A button at the bottom of the screen can be used to attach this data to an email,
which can then be sent to the user’s doctor.
Send a Message
On this screen, the user can send their doctor a simple email, which can include
text and/or graphs. A “To” field is shown, already filled out with the doctors email
address, but which can be modified if necessary. The user can then fill out the subject
and message box with the onscreen keyboard, or by writing freehand with the stylus
using the PocketPC’s transcriber. They can also select the Attach Graph button, which
takes them directly to the View My Levels screen where they can select a graph to attach.
Finally, the user can select Send or Cancel.
Make an Emergency Call
Here the user can select from two buttons: Call Doctor, or Call 911. There is also
a field they can fill out to manually call a number not listed.
- 24 -
Notification System
If a notification appears, the user has the option of delivering a corrective dose,
changing their schedule, or ignoring the warning.
Report on Development Process
The first stage of the development process was to find out exactly what the
current systems on the market offered, and to research what users would really want and
need in an advanced diabetes management system. What we found was that nothing like
AGIL currently existed on the market, and we could not find any plans available publicly
that showed that something like AGIL was even being developed. This was good in the
respect that we wanted to create something innovative, but it did not give us much to go
on in terms of development ideas.
What we did was create a list of possible tasks that we envisioned AGIL being
used for. We specifically chose tasks that highlighted features of AGIL we wanted to
implement, but which were not features of currently existing products. From this, we
were able to determine the system requirements that would be necessary to implement
such a product.
Task Examples
1.) A new user sets up his insulin delivery schedule.
John, a teenage high school student visits his physician with his parents. Up until
recently, he has used insulin injections to control his blood sugar level. He is just starting
to use a full time glucose pump in conjunction with the AGIL Software, and wants to set
up two initial presets for basal insulin delivery: one for school days, and one for
weekends. John and the physician together enter key parameters, specific to John’s blood
sugar needs, and create the two delivery programs. John and his parents are shown how
to make minor adjustments to the presets if necessary.
Discussion: This task is very important, but occurs infrequently. Over long periods of
time, the presets might need adjustment, but the hope is that this will not happen very
often, and that it automates the process of insulin delivery to some extent. The user will
most likely need help with this step, as the entire process will be brand new to them.
2.) A user delivers a dose of insulin before a meal.
Stacy, a middle-aged woman, sits down for lunch. She starts the AGIL Software and
checks to see if she already has a preset programmed for the meal she is about to eat. She
finds that she has not set one up yet, and does not really have the time to do so at the
moment. Instead, she enters the amount of carbohydrates she is about to ingest, and the
AGIL Software calculates the amount of insulin necessary to balance out the meal. After
- 25 -
reviewing the amount that the software suggests, she accepts, and a bolus of insulin is
injected through the glucose pump. This data is recorded for her.
Discussion: This task will most likely be one of the most frequent performed by the user,
and one of the most important. The only piece of data the user must have is the
carbohydrate count of their meal.
3.) A user checks his blood sugar level.
Joe takes a break between classes to check his blood sugar level. From the numerical
data, he sees that it is currently slightly low, although not low enough for the software to
signal an alarm. To give himself an overall idea of when it started to drop, he looks at the
day’s level chart. He finds that his blood sugar dipped after his last meal, and concludes
that he may have taken too much insulin in his last bolus dose. He decides to flag the
current reading as an important one for later review.
Discussion: This task is not as frequent as the others are, but still of moderate
importance. Graphs make it easier to see where a user’s levels have been, and where they
currently are.
4.) User sends data to doctor for analysis.
Stephanie delivers repeated insulin doses, but her high blood sugar level remains
unaffected. Attempts to adjust her basal rate and deliver a corrective bolus have proved
ineffective, so she decides to contact her doctor. While speaking with her on the phone,
the physician requests a record of Stephanie’s sugar levels for the entire day. To avoid
any potential errors in manually reading the data over the phone, Stephanie has the AGIL
Software email her doctor in plain text all the readings for the day. The physician is able
to review the accurate data before Stephanie even enters the doctor’s office.
Discussion: This task is important, yet infrequent. The ability to transfer a large amount
of data to a doctor in an accurate way could be very helpful in a situation where the user
is unable to stabilize their blood sugar level themselves.
5.) User adjusts their insulin delivery for an exercise routine.
Kyle decides to make an unscheduled stop at his gym for a quick workout. He picks out
a treadmill, and then realizes he should adjust his basal insulin delivery rate so that his
insulin levels do not drop too low during his exercise. Using the AGIL Software, he
chooses a delivery rate corresponding to moderate exercise, and then enters the amount of
time he plans to run. He initiates the delivery program, and then starts to use the
treadmill.
Discussion: This task is of moderate importance, and will occur at varying frequencies
depending on the specific user’s lifestyle. Someone who exercises at a consistent rate
- 26 -
and on the same days of the week every week could factor that in to their initial presets
(see task 1). Unscheduled exercise or physical activity however would require a task like
this one.
6.) User checks a patient’s information at a nursing home.
Mary is asleep, and it is time for her sugar levels to be checked. A nurse walks into her
room, and runs the AGIL Software on the PDA already located in the room. The nurse
checks Mary’s current level against the data on her chart, and sees that it is right where it
is supposed to be. Mary does not even need to be woken up.
Discussion: This task is of minor importance, but shows the convenience the software
can provide. Frequency would depend on the user and their needs. A child could be
monitored by its parents in a similar way.
System Requirements
Hardware Requirements
Required
 PocketPC 2002 or later – A modern, color Personal Digital Assistant
(PDA). Unit must be fully functional with the ability to vibrate.
 A device added onto the PocketPC to enable it to communicate with the
insulin pump
o This device should also display the latest blood sugar level
constantly independent of the main device screen, so that the
PDA’s batteries are not needlessly wasted just to see one number
 Insulin Pump, capable of communicating wirelessly with the PDA.
Optional
 Cellular phone capabilities.
Software Requirements
Required
 .NET Compact Framework
 AGIL Software
Network Requirements

Wireless internet capabilities, either through Wi-Fi or Bluetooth.
- 27 -
Low Fidelity Prototype
From the task examples and system requirements, we were able to develop a low
fidelity prototype. We hand drew approximately 95% of AGIL’s screens, keeping in
mind what we wanted the system to be capable of. A few of these original drawings are
shown below; the rest are available in AGIL’s design portfolio.
Figure 22 - Basal Insulin Prototype Screen
Figure 23 - Eat a Meal Prototype Screen
Figure 24 - Glucose Levels Prototype Screen
Figure 25 - Levels Prototype Screen
- 28 -
It was our original intention to create two completely different hand drawn
prototype designs. After designing the first prototype however, we decided it would be
better to do an unofficial review with a diabetic to get some suggestions for changes and
improvements. These suggestions were than incorporated into a short design document
for a second prototype. Although the second low fidelity prototype was never actually
drawn, many of the concepts we had for it were combined with our drawings to build the
final high fidelity prototype.
High Fidelity Prototype
The high fidelity prototype was developed in Visual Basic .NET 2003, using the
low fidelity prototype as a guide. As the system was built, it was clear that some changes
were necessary to increase functionality, and to make AGIL easier to use on the small
screen of the PocketPC. While some of AGIL’s screens largely resemble the low fidelity
drawings, many had to be altered.
AGIL’s code was developed in two parts. In one, the setup process was created.
The setup process is where users tailor the system to their specific needs. This only
needs to be done by a user one time, but it is still extremely important. The data that is
entered controls all aspects of how AGIL functions later on, so we felt it was necessary to
make the process as clear and easy as possible. In addition, the setup process would be
any user’s first contact with AGIL, and we wanted to make sure it did not scare anyone
by being bloated or overly complicated. The setup screens were designed with all these
issues in mind.
The second part of AGIL’s code development was implementing the actual
functionality of the system, so that users could complete the tasks that AGIL was
designed to handle. This consisted of developing the home screen, and all of it’s linked
screens, where users would spend the majority of their time.
Once the high fidelity prototype was created, the usability test was initiated.
Usability Test
Our usability test was conducted using a high fidelity prototype of the AGIL
software, on actual PocketPC units. This was done so that the test conditions would
mimic real world conditions as closely as possible. It was also important to us that we
see how users would respond to a PocketPC device, since it was our impression that most
of AGIL’s target audience had most likely never used one. That assumption turned out to
be correct.
The tasks used for the test are listed below. They are modified versions of the
tasks listed under Task Examples, changed so that they all cover events a user might
encounter in a single day (except for the first task of setting up the system, which a user
would only need to complete once.)
1. Your doctor has provided you with some parameters for setting up the AGIL Control
System. Setup the device using these parameters:
- 29 -
Personal Information
If you do not have diabetes: Choose Type 1
Doctor Information
Name: Bob Johnson
Email: bjohnson@doc.com
Office Phone: 410-555-1234
Emergency Phone: 410-555-4321
Waking Schedules
You’ll need to create four schedules. The names and rates for each one
are listed below.
Normal
.2
Exercise .25
Elevated .4
Morning .55
Sleeping Schedule
Sleeping Rate Schedule is .4
Daily Schedule
Default schedule is Normal, Use your morning schedule in the morning
for 1 hour.
Blood Sugar levels
Tolerable Max.: 150
Target Max: 132
Target Min: 81
Tolerable Min: 45
Responses
When you’re blood sugar level leaves the target range, you don’t need the
unit to issue any type of warning.
When you’re blood sugar level leaves the tolerable range, you should have
it quickly warn you with an audible alarm.
2. You are about to eat a meal containing a total of 36 grams of carbohydrates. Deliver the
appropriate amount of insulin.
3. You have been inactive most of the day, but now you want to engage in some light
exercise. Change the basal insulin delivery rate (schedule) to one appropriate for this
level of activity.
4. Your doctor has requested a graph of your glucose levels during the week of October 18.
Send him this information along with a message saying what it is.
- 30 -
5. Keep the device in your pocket or lap, out of sight, for 2 minutes and respond to any
alerts that it generates in whatever way you feel appropriate. The experimenter will notify
you when this time has passed.
Subjects
When choosing test subjects, we felt it was more important to cover a wide area of our
target audience, than it was to necessarily test many diabetics. One of the most important
features of the AGIL system is that it is designed for a huge target audience. As stated
earlier, anyone who is capable of testing their own blood sugar and delivering insulin
shots is a candidate for AGIL. This means we needed to test users male and female
ranging in age from teenagers to the elderly, and most important, with varying degrees of
experience with PocketPC’s and technology in general. It is very plausible that new
users of the AGIL system may actually be using a computer for the first time.
With this in mind, we sought to have at least 25% of our subjects be diabetic, and
made the other 75% as diverse as possible with regard to the factors mentioned above.
Below are some details about each of our test subjects. What is written below
focuses on the pretest for each user, as well as various comments made and actions taken
during the test.
Subject 1
The first subject tested was a 21-year-old female, non-diabetic. She had never
used a PDA of any type before participating in this test, and rated her comfort level as
low as our pre-test allowed. She needed a small amount of help with the basic
functionality of the PocketPC (namely how to activate the keyboard for text entry).
On the first setup screen (doctors information), she started to enter her own
personal information and did not realize her mistake until getting to the text boxes for
Emergency Phone. Other than that, the test went very smoothly. All the tasks given to
her were completed quickly and more than once she seemed surprised that she had
already finished a task.
Subject 2
Subject 2 was an 82-year-old female with Type 1 Diabetes, which she has had for
2 years. She had no experience with a PDA, and commented verbally that she was not
comfortable using a computer of any kind. In the past, she had used oral medication and
injections to control her diabetes.
The setup process for subject 2 went very slow. Like subject 1, she needed help
with the basic functionality of the PDA, and attempted to fill out her own information on
the Doctor’s Information screen. She had trouble with the small characters on the onscreen keyboard. She seemed comfortable with the terminology used throughout AGIL’s
interface.
After getting through the setup, the rest of the test went fairly well. The tasks
were completed quickly, accept during the fourth task where a fatal bug occurred. It was
necessary to correct this before other users were tested. The only other problem occurred
- 31 -
when the fifth task (a semi-random event) occurred before the subject had read the
directions for the fifth task.
This subjects only other complaint was that some font sizes were too small.
Subject 3
The third subject tested was a 56-year-old male, non-diabetic. He had no
experience with a PDA, but had been using a desktop computer for about 5 years.
This subject encountered some of the same problems as the first two users. As in
the last two subjects, he entered his own information on the doctor’s information screen,
and needed help using the onscreen keyboard. He also needed help with some of the
diabetes terminology throughout the test. Another problem he had was that he did not
know what to do during the last task where the user is asked to respond to a notification
screen. That task took longer than the others did since he spent some time studying the
screen, trying to understand what action he was supposed to take. A very small
modification was made to the instruction sheet after this subject’s test, so that it was a
little clearer that we were testing the device and not the user.
Subject 4
The fourth test subject was a 58-year-old male, non-diabetic. What made him
substantially different from subject 3 was that he stated he had a great deal of experience
with a PocketPC, and that his occupation was a pharmacist.
Because of his experience not only with PocketPC’s, but also with the
terminology involved with diabetes, subject 4’s test went faster than any before it. As
with all the others, subject 4 did attempt to enter his personal information on the doctor’s
information screen, which by this point we had to come to expect. Other than that, he
had absolutely no problems. He seemed enthusiastic about the system after the test, and
stated he had not seen anything similar to it.
He did have some suggestions, one of which was to implement an alternative (or
user definable) color scheme. Until this point, we had not directly dealt with the issue of
color blindness. In addition, subject 4 informed us that users with glaucoma would have
a significantly hard time with the blue scheme we had selected.
Subject 5
The fifth subject tested was a 17 year old female, who has lived with diabetes for
over two years. She rated her PocketPC comfort level as five out of seven. During the
test, the subject made several comments about features they would like to see
implemented, and changes they thought that should be made. These included:



User wanted different response settings for glucose level going high or low.
User noted there were too many possible numbers in the ratio setting.
User thought that the insulin dose precision was unrealistic.
- 32 -
Like everyone before, she entered her own information first instead of the
doctor’s. She also attempted to enter her entire name in one field. During the test, the
program crashed because of a bug in the basal rate spinner.
Subject 6
Subject 6 was a 14-year-old female, non-diabetic. This subject stated in her pretest that she had monthly PocketPC experience. This test went smoothly, although the
user did enter her personal information on the doctor’s information screen. Other errors
that occurred:



User added her sleeping schedule to the waking schedules section during setup.
User did not choose the correct day in the graph task.
Finally, the user accidentally skipped the response screen during the final task.
During the test, it was noted that the user had some trouble with opening and
closing the on-screen keyboard, a problem that could be remedied by having the
keyboard open and close automatically when necessary. This user did not complete the
final task because she accidentally closed the response screen by clicking Ignore before
reading everything on screen.
Subject 7
The seventh subject was a 50-year-old female, non-diabetic with no PocketPC
experience. This subject was the first one to correctly fill out the first screen, although
she did attempt to enter her first and last name into a single field.
There were some minor problems with this user’s test. She was confused by the
concept of naming schedules, and during the fourth task, did not choose the correct graph
date. This user also noted that she wanted to be able to use the TAB key on the on-screen
keyboard to move from field to field. Finally, this subject took a longer period of time to
locate the Advanced tab on the Home screen then other users did.
Subject 8
The last subject tested was a 60-year-old male, non-diabetic. Although he stated
that he had monthly experience with a PocketPC, he still rated his comfort level at 2 out
of 7. This subject had numerous problems throughout the test, some of which were seen
with other subjects. They are listed here:




Entered first and last name in one field.
Had problems with onscreen keyboard, and finding the @ character.
Did not choose correct graph date in fourth task.
Was confused because rates do not show up on schedule list view, only schedule
names do.
- 33 -
Test Results
Overall, we were happy with the results of the usability test, as well as the
feedback we received from the post-test. We now have a clear picture of what people
liked and disliked about the system, and what needs to be fixed. Below are the averaged
results for each question on the posttest (on 7-point scales).
1. Overall, how would you rate the AGIL system?
6
2. How would you rate the overall aesthetics of the system?
5.5
3. How easy was it to navigate the system?
6
4. How reasonable was the amount of time needed to complete the tasks?
6
5. How easy was it to read the text in the system?
6.5
6. How easy was it to understand the terms used in the system?
5
7. How consistent were the terms used in the system?
4.75
8. How complete was the set of functions available in the system?
5
9. How intuitive was data entry in the system?
5.5
10. After participating in this test, how likely are you to use a system like this one?
5.5
Problems
Below is an itemized list of common problems we encountered during the
usability test, and possible solutions for each. Each problem is rated on importance and
effort required to fix the problem. Both are rated on a five-point scale, where 5 is most
important and highest effort.

The notification system has a flaw, in that if the user happens to be clicking
around the screen when it appears, they could accidentally ignore it, or take an
action that they do not mean to. A solution for this would be to have the buttons
disabled for a very small amount of time when the notification occurs, so that
users do not inadvertently select something too quickly. Another solution would
be to have an intermediate screen, where the user is warned that a notification is
occurring. This screen could be shown for a few seconds, and then the actual
notification could displau. (This problem was fixed in the final prototype.)
o Importance: 5
o Effort: 2
- 34 -

Users tended to fill out their personal information on the first screen, “Doctor’s
Information.” An easy and obvious fix for this problem is to flip-flop the
Doctor’s Information screen with the Personal Information screen. Even though
the setup process is only completed one time, the frequency of this problem shows
that it is an important one to fix. (This problem was fixed in the final
prototype.)
o Importance: 5
o Effort: 1

Older users commented that some text was too small. There would need to be
very significant changes made to some areas of the system to accommodate
larger, or adjustable font sizes.
o Importance: 4
o Effort: 5

Users had a hard time finding the icon to activate the on-screen keyboard. A
simple message on the introduction screen should fix this problem.
o Importance: 4
o Effort: 1

A method needs to be created for users to have more control over the color
scheme of the system, specifically to help users with glaucoma. This is an option
that could be added to the preferences area.
o Importance: 3
o Effort: 4

Some users (especially older ones) found the on-screen keyboard difficult to use.
The one we used for AGIL is a built-in feature of the PocketPC. It might be
necessary for a custom keyboard to be created in the future, which is created with
older users in mind. Another solution would be to provide instructions to the user
on how to use the PocketPC’s built in transcriber, which would let them write full
screen in their own handwriting, instead of using the keyboard.
o Importance: 3
o Effort: 4

Some users felt opening and closing the on-screen keyboard manually was
cumbersome. This could be remedied by having the keyboard open automatically
when a user enters a field that requires text entry, and close when they leave the
field.
o Importance: 3
o Effort: 3

One user wanted to be able to use the Tab key to move between fields. This
functionality could be added, and in the process, it might be wise to map one of
the buttons on front of the actual PocketPC to the Tab key. This way the user
- 35 -
could use their primary hand to “type” while the secondary hand holds the unit
and tabs between fields.
o Importance: 3
o Effort: 3

Some users were confused by the Target response and Tolerable response screens;
they had trouble understanding what the difference was at first glance. An easy
fix for this would be to highlight in some way, or underline the words Target and
Tolerable, so that they stand out. This would help the user recognize that the two
screens are in fact different. (This problem was fixed in the final prototype.)
o Importance: 3
o Effort: 1

One user requested a way to set responses, not based on target and tolerable
ranges, but whether the blood sugar level went high or low. The Response setup
screens could be modified to accommodate this.
o Importance: 2
o Effort: 2

Attaching a graph was a little complicated for the users. They were unsure if they
should go to Send a Message, or View My Levels first. We made it possible for
them to do it either way, which makes the problem of little importance.
o Importance: 1
o Effort: 3

Some users attempted to enter their entire name into the one field. This problem
could be solved by creating shorter name fields. (This problem was fixed in the
final prototype.)
o Importance: 1
o Effort: 1
Conclusions
Though we developed a design that addresses the main needs our users identified,
there is still substantial work to be done on a variety of fronts before our system can
become reality. Technological progress in the fields of blood glucose monitoring and
insulin delivery is ongoing, and devices that integrate these capabilities in the way we
envision should be available in the near future. The challenge is to equip these devices
with interfaces that not only minimize errors and support simple, highly efficient
interaction, but also make users feel in control of their health, and respond seamlessly to
a wide variety of users and situations.
A misjudgment that we initially made, and that other PDA-based solutions seem
to make, is that people with diabetes want to be frequently presented with an arsenal of
information about their health. Designs that put tasks such as viewing charts or delivery
histories and consulting on-line resources on the same priority as the basic tasks of
- 36 -
delivering insulin, and checking glucose levels did not connect to the priorities of the
users we consulted. These simple tasks are done several times a day, every day of the
user’s life. People who are used to monitoring their blood sugar generally like the idea of
having these features available, but do not need to be confronted with them every time
they use the device.
We feel our design has demonstrated the effectiveness of this return to simplicity
in the majority of user interactions, while still preserving the ability to perform more
complex tasks. The most compelling of these interactions is the ability to view
visualizations of various factors that can affect blood sugar management. The device
would already be recording information about insulin deliveries, glucose levels, and
indirectly, meal times, sleeping habits, and periods when the pump is removed.
Collecting this information in an unobtrusive manner was a focus of our design, as all of
this data is collected as a result of some action taken in the interface. Possible useful
visualizations we did not design include:
 Tracking glucose levels for each schedule, to determine whether the amount
of insulin is correct, or was underestimated or overestimated.
 Cross-cutting days to view only levels at waking up or going to sleep, for
example.
 Methods of identifying outliers and analyzing them, as these may help aid the
user in modifying potentially harmful items, such as foods that contain more
carbohydrates than normal.
By using a PocketPC-based design, we were able to add color to graphs and make
provide some means of manipulating them. However, a great deal of work still needs to
be done on visualizing this data on such a small screen. An important step is to identify
the data and the views that are important to users vs doctors. While patients are
increasing knowledgeable about their own care and diabetics implement the bulk of their
treatment themselves, a team of medical professionals can still utilize data in ways that
users cannot. This means that including these special visualizations on the device should
be strongly questioned, because we have already seen that users do not want to be
burdened or confused by information they can not or do not want to use.
Acknowledgements
We would like to thank Dr. Shneiderman for his help and comments throughout
the development process.
We would also like to thank the people that took the time to help us test the AGIL
system, and for their suggestions and patience. This has been a great experience, and you
helped us create a piece of software we are proud of.
- 37 -
References
(All web sites current as of October 1, 2004)
About Diabetes. Diabetes Mall.
http://www.diabetesnet.com/diabetes_information/diabetes_types.php
Alternative Insulin Delivery Systems. American Diabetes Association.
http://www.diabetes.org/for-parents-and-kids/diabetes-care/alternative-insulin.jsp
Chico, Ana, et al. “The Continuous Glucose Monitoring System...” Diabetes Care 26
(2003): 1153-1157.
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=retrieve&db=pubmed&list_
uids=12663589&dopt=Abstract
Diabetes Pilot. Digital Altitudes.
http://www.diabetespilot.com/index.php
Doyle, Elizabeth, et al. “A Randomized, Prospective Trial Comparing the Efficacy of
Continuous Subcutaneous Insulin Infusion With Multiple Daily Injections Using Insulin
Glargine.” Diabetes Care 27 (2004): 1554-1558.
http://care.diabetesjournals.org/cgi/content/abstract/27/7/1554
Guardian Continuous Glucose Monitoring System. Medtronic MiniMed.
http://www.minimed.com/patientfam/pf_ipt_guardian_overview.shtml
http://www.minimed.com/patientfam/pf_ipt_ptov_whygoodcontrol.shtml
Hemminger, M. and Chase I., University of Maryland. Current Diabetes-Monitoring
Systems.
http://www.cs.umd.edu/hcil/soh/ws_meddevice.htm
Insulin Delivery. Life Clinic.
http://www.lifeclinic.com/focus/diabetes/supply_syringes.asp
Kaufman, FR, et al. “Use of Insulin Pump Therapy at Nighttime Only For Children 7-10
Years of Age With Type 1 Diabetes.” Diabetes Care 23.5 (2000): 579-582.
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=retrieve&db=pubmed&list_
uids=10834412&dopt=Abstract
Meigs, James B, et al. “A Controlled Trial of Web-Based Diabetes Disease
Management.” Diabetes Care 26 (2003): 750-757.
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=retrieve&db=pubmed&list_
uids=12610033&dopt=Abstract
- 38 -
The Pumpoz Project.
http://www.pumpoz.com
TheraSense. FreeStyle Tracker.
http://www.therasense.com
UTS Diabetes Palm Software. Universal Tracking System.
http://www.utracksys.com/plugins/diabetes/
- 39 -
Appendix 1 – Index of Figures
Figure 1 - Minimed’s Vision........................................................................................... - 6 Figure 2 - Transition Diagram ........................................................................................ - 9 Figure 3 - Main Screen ................................................................................................. - 10 Figure 4 - Setup Screen ................................................................................................. - 11 Figure 5 - Personal Information Setup Screen .............................................................. - 12 Figure 6 - Doctor's Information Setup Screen .............................................................. - 12 Figure 7 - Bolus Formula Setup Screen ........................................................................ - 13 Figure 8 - Basal Insulin Setup Screen ........................................................................... - 13 Figure 9 - Basal Insulin Setup Screen ........................................................................... - 14 Figure 10 - Basal Insulin Setup Screen ......................................................................... - 14 Figure 11 - Blood Sugar Levels Setup Screen .............................................................. - 15 Figure 12 - Responses(1) Setup Screen ........................................................................ - 15 Figure 13 - Responses(2) Setup Screen ........................................................................ - 15 Figure 16 - Confirmation Screen .................................................................................. - 16 Figure 17 - Eat a Meal Screen....................................................................................... - 17 Figure 18 - Change My Schedule Screen ..................................................................... - 18 Figure 19 - Advanced Features Screen ......................................................................... - 19 Figure 20 - View My Levels Screen ............................................................................. - 19 Figure 21 - Send a Message Screen .............................................................................. - 20 Figure 22 - Emergency Call Screen .............................................................................. - 20 Figure 23 - Notification Screen..................................................................................... - 21 Figure 24 - Basal Insulin Prototype Screen .................................................................. - 28 Figure 25 - Eat a Meal Prototype Screen ...................................................................... - 28 Figure 26 - Glucose Levels Prototype Screen............................................................... - 28 Figure 27 - Levels Prototype Screen ............................................................................. - 28 -
- 40 -