Mobile Obesity Study
ARCHIVES
MASSACHUSETTS INSTif JTE
OF TECHNOLOGY
by
AUG 2 4 2010
Hyon Lee
LIlBRARIES
S.B., M.I.T., 2009
Submitted to the Department of Electrical Engineering and Computer
Science
in partial fulfillment of the requirements for the degree of
Master of Engineering in Electrical Engineering and Computer Science
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
September 2009
@ Massachusetts
Institute of Technology 2009. All rights reserved.
'/
A uthor ............- ~~..............
Department o Electrical Engineering and Computer Science
August 19, 2009
Certified by....
Dr. Stephen S. Intille
MIT House-n Laboratory
Thesis Supervisor
Accepted by
Christopher J. Terman
Chairman, Department Committee on Graduate Theses
Mobile Obesity Study
by
Hyon Lee
Submitted to the Department of Electrical Engineering and Computer Science
on August 28, 2009, in partial fulfillment of the
requirements for the degree of
Master of Engineering in Electrical Engineering and Computer Science
Abstract
The prevalence of overweight and obesity has steadily increased over the years among
all genders, ages, racial and ethnic groups, educational levels, and smoking levels [15].
From 1960 to 2004, the prevalence of overweight increased from 44.8 to 66 percent
in U.S. adults age 20 to 74 [14]. The prevalence of obesity during this same time
period more than doubled among adults age 20 to 74 from 13.3 to 32.1 percent, with
most of this rise occurring since 1980 [14]. As these numbers increase, more people
are prone to diabetes and increased risk for congestive heart disease, high blood
pressure, osteoarthritis, dyslipoproteinemia, various cancers, and all-cause mortality
[5]. With two thirds of American adults of age 20 or older being overweight or
obese [13], it is imperative to prevent these numbers from rising any further; and,
one way is to increase the level of general physical activity [5]. The main idea of
the study is to use a mobile device (in our case, a mobile phone) to automatically
and continuously monitor physical activity and then to reinforce increases in physical
activity using positive reinforcement and operant conditioning learning theory. Prior
work in behavioral science suggests that well-timed, positive, and tailored messages
can influence behavior. This will be the first study to investigate the potential of
using automatic activity recognition using sensors to apply this theory and to measure
the impact consistent application of the theory might have on motivating behavior
changes. Although we will study physical activity, the same strategies could be used
to encourage other desired behavior changes.
Thesis Supervisor: Dr. Stephen S. Intille
Title: MIT House-n Laboratory
Acknowledgments
This project was possible because of the support, help, and guidance I have received
from many people. I acknowledge a few below, but it is by no means a complete list
of all the people who have supported and inspired me along the way.
First and foremost, I would like to thank my thesis advisor Dr. Stephen Intille
for giving me not only the opportunity to take on an exciting challenge as described
in this thesis, but also for giving me invaluable advice that I will refer to time and
time again. You have helped me grow in so many aspects that reach far outside
of my work at House-n. I would also like to thank Kent Larson for directing such
a wonderful lab where creative minds are challenged to their limits. Thank you
Anne Hunter and my academic advisor, Dr. Joel Voldman, for sparing your time to
carefully guide me through the rigorous path of MIT. A special thanks go to all of
the fellow grad students, such as Selene Mota, Aydin Oztoprak, Manu Gupta, and
Jonathan Ward, that have been there for me through the days and nights providing
me with the support and guidance needed to finish strong. Thank you, Lin Yang,
for the neat diagrams I used on the project website. My thanks extend to all of the
Finnish researchers that have worked so hard to make this project possible including
Annakaisa Hayrynen, Ilmari Oranen, Minttu Karppinen, Leo Guzman Monet, Kirsi
Turkia and many others.
Next, I thank my friends for making my time at MIT a truly memorable and
valuable experience. Thank you to Bobby Ren and Nathan Hanagami for being my
mentors as Course 6. Thank you to Delbert Joo, Chris Han, Stephen Petraeus, Jacob
Levinson, and Lawrence Chan for being supportive of my passions. Thank you Adam
McCaughan for being such a great roommate through the many years and opening my
eyes along with Zach Rich and Jacob Stultz to many new experiences. Special thanks
go to Josh Wang, who allowed for so much confusion, yet remained dependable when
I needed to print this thesis. Most of all, thank you, Richard Sinn for being next to
me not only through the many years and classes that we went through together, but
also being there for me, always, even now, in my new location. I am truly grateful
for all that you've done for me.
Finally, I want to thank my family for always pushing me to achieve the best
I can. Mother, Father, I am forever ind~ebted to you for all the sacrifices you have
made for me and my sister. Thank you. Grandfather and Grandmother, for being
the perfect role model. Last, but not least, thank you Hyonju, my favorite sister, for
being there for me, when I needed you t ie most.
Without everybody, I would be a nobody.
Contents
13
1 Introduction
1.1
P roblem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.2
Opportunity.. . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
15
17
2 Background Information
2.1
Prior work: Research on Phones . . . . . . . . . . . . . . . . . . . . .
17
2.2
Prior Work: Just-in-Time Feedback to Motivate Physical Activity . .
18
2.3
Originality of MobileHealth.. . . . .
. . . . . . . . . . . . . . . .
19
21
3 MobileHealth Application Overview
3.1
3.2
. . . . . . . . . . . . . . . ..
Application Overview..... . . . .
21
. . . . . . . . .
21
. . . . . . . . . . . . . . . .
23
M obile Platform . . . . . . . . . . . . . . . . . . . . . . . . . .
24
M ajor Components . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.2.1
Detection of Physical Activity . . . . . . . . . . . . . . . . . .
25
3.2.2
Data Logging . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.2.3
Audio Playback . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2.4
GUI..... . . . . . . . . . . . .
. . . . . . . . . . . . . . .
29
3.2.5
Communication.......... . . . . . .
3.2.6
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.7
Data Preparation for Analysis... . .
. . . . . . . . . . ..
34
3.2.8
Iterative Testing and Deployment..
. . . . . . . . . . . ..
34
3.1.1
User Experience........ . . . . . . . . .
3.1.2
Technical Challenges... . . .
3.1.3
5
. . .
. . . . . ..
29
30
4
37
Deployment
4.1
Experiment ......
1.2
Subjects ......
4.3
Current Status
37
................................
..................
...
....
.........
. . . . . . . . . . . . . . . . . . . . . . . . . . . . ...
5.2
5.3
6
39
41
5 Evaluation/Discussion
5.1
37
- - . .
41
. . . . . .
42
. . . . . ..
. . . . . .
51
. . . . . . . . . .
. . . . . .
55
5.2.1
Data Connection from abroad . . . . . . . . . . . . . . . . . .
55
5.2.2
Short Battery Life
. . . . . . . . . . . . . . . . . . . . . . . .
56
5.2.3
Not able to use keys to load program screen/menu. . . . . . .
56
5.2.4
Bad Reception
. . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.2.5
Multi-threading of accelerometer data feed . . . . . . . . . . .
57
5.2.6
Memory Card/Data Corruption.
. . . . . .
57
5.2.7
General Error Handling
. . . . . . . . . . . . . . . . . . . . .
57
. . . . . .
58
.
..................
Data ...........
5. 1.1
Evaluation of the Consistency of the Application
5.1.2
Evaluation of the Trends in Data..
Challenges . . . . . . . . . . . . . .
Recommendations.. . . . . . .
. . . . . . . ..
. . . . . . . . . . . ..
..
59
Conclusion
6.1
Future Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
6.2
Summary
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
List of Figures
3-1
MobileHealth app module and data flow chart. The solid arrows show
the exchange of physical activity data and the feedback between the
subject and the phone. The dashed arrows show the physical activity
data and other relevant data sent to the researchers for monitoring
compliance and data analysis. The dotted arrows show the path of
how the updated version of the software is loaded to the phones via
the server. The updated versions may include bug fixes and/or new
features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . ... .
3-2
Screen shot of MobileHealth app in Finnish.... . . .
3-3
Sample acceleration reading taken from MobileHealth application. . .
3-4
All graphical feedback screens in the MobileHealth application. The
22
23
26
majority of feedback is presented using audio, eliminating the need to
. . . . . . . . . . . . . . . . . . .
28
3-5
Screen shot of homepage of MobileHealth online monitoring website. .
31
3-6
Screen shot of individual page of MobileHealth online monitoring web-
remove the phone from the pocket.
site, as explained in the text . . . . . . . . . . . . . . . . . . . . . . .
33
3-7
Screen Shot of note feature in individual page. . . . . . . . . . . . . .
34
5-1
Graph comparing the average running percentage of MobileHealth app
during the Adaptation and Intervention periods. . . . . . . . . . . . .
5-2
42
Graph plotting each subject as a data point where x-coordinate is percent running app during Adaptation period and y-coordinate is during
the Intervention period.
. . . . . . . . . . . . . . . . . . . . . . . . .
43
5-3
Graph displaying the change in overall average as increasing numbers
of poorly compliant subjects are removed from the dataset. . . . . . .
..
5-4
Differential of Figure 5-3. . . . . . . . . . . . . . . . . . . . . . . .
5-5
Resulting graph of Figure 5-1, after removing the radical subject data
from the dataset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-6
46
46
Comparison graph of the average number of keypresses made by all
subjects across the two periods. . . . . . . . . . . . . . . . . . . . . .
5-9
45
Average Battery level by hour of day across all subjects for the two
p eriods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5-8
44
Comparison graph of percent of time that MobileHealth app was running across the two periods for each subject. . . . . . . . . . . . . . .
5-7
44
47
Average number of Keypresses by hour of day across the two periods
by Subject 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5-10 Average number of Keypresses by hour of day across the two periods
by Subject 31.. .......
....
.
. ....
........
.
. . . ...
48
5-11 Average number of Keypresses by hour of day across the two periods
by Subject 36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5-12 Percent of sounds that were muted by hour of day since the audio
feedback intervention was released.
. . . . . . . . . . . . . . . . . . .
50
5-13 Percent of sounds that were muted by each subject since the audio
feedback intervention was released.
. . . . . . . . . . . . . . . . . . .
50
5-14 Average and variance of the number of bouts by hour of day across the
tw o periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5-15 Average number of bouts by day of the week across the two periods.
52
5-16 Percent of time spent inbout by hour of day across the two periods.
53
5-17 Percent of time spent inbout by day of week across the two periods.
53
5-18 Average number of bouts plotted against % of time spent inbout for
each day across the two periods. . . . . . . . . . . . . . . . . . . . . .
54
5-19 Average number of t inus that the subjects went ahead of their regular
amount of physical act ivity within each hour of day since the release
of the audio feedback int ervention.
. . . . . . . . . . . . . . . . . . .
55
10
List of Tables
4.1
Timeline of the major milestones of the project. . . . . . . . . . . . .
38
12
Chapter 1
Introduction
Rising rates of obesity in the U.S. and around the world are alarming. New research
methods and health interventions might help slow this trend. In this work, a novel
health intervention for a mobile phone was developed, and the feasibility and usability
of running the system (and gathering data for research on bouts of walking) was tested
with 95 subjects in Finland for 9 months.
1.1
Problem
Obesity and overweight are commonly assessed by a person's Body Mass Index (BMI),
which is calculated by dividing the person's mass in kilograms by the square of their
height in meters [19]. BMI is categorized as underweight, normal weight, overweight
and obese. BMI's between 25 and 29.9 kg/m
2
obese is defined as a BMI exceeding 30 kg/m
are categorized as overweight, whereas
2
[16]. Among U.S. adults age 20 or
older, the percentage of overweight and obesity steadily rose from 56.0% in 1994 to
66.3% in 2004 [9].
It is common belief that one contributing factor to the increasing prevalence of
overweight and obesity is lack of sufficient physical activity [22]. In particular, the
prevalence of Americans reporting insufficient activity increased from 45.0% in 1990
to 45.9% in 1998 [8].
As sedentary behavior increases, more people are prone to
conditions linked to overweight and obesity, such as diabetes and increased risk for
congestive heart disease. high blood pressure, osteoarthritis, dyslipoproteinemia, various cancers, and all-ciuse mortality [22].
To address this issue, there have been studies on the effects of using pedometers
and their effect on the levels of physical activity [3] [10] [27]. For example. in one
study, users of pedometers increased daily steps by an average of 2491 steps versus
a control group, significantly decreasing their systolic blood pressure by 3.8mimHg.
This study and otlhers have demonstrated the short-term health benefits of using a
device that provides an objective measure of physical activity, such as a pedometer.
Overall, however, results are mixed, with other large-scale studies using pedometers,
electronic motion sensors, or accelerometers failing to lead to long-term behavior
change [22]. One problem with these devices is that they are passive, only providing
valuable information when someone looks at them, usually well after the person has
actually engaged in bouts of physical activity and when it may be difficult to engage
in additional bouts.
One way to trigger long-term behavior change may be to use immediate, or justin-time, positive and tailored feedback [25] [2] [13]. This type of intervention might be
delivered via mobile phones that use internal motion sensors to detect non-sedentary
motion, assuming the phone user carries the phone in a pocket or on the hip. The
goal of this work was to create a software system for mobile phones that can measure
the phone motion and deliver customized feedback to the phone user, where positive
reinforcement is intended to motivate additional and/or more intense bouts of walking. The system needed to be sufficiently robust to deploy with 95 users in a study in
Finland, gathering data on user walking behavior and overall use of the application.
The goal was to use this system to acquire pilot data to support development of enhanced versions of the system that might be used to measure longitudinal compliance
and efficacy.
1.2
Opportunity
Studies have shown that just-in-time positive feedback can affect behavior ciange
[25]. This project explores how the mobile phone might be used to provide just-intime information to motivate increased physical activity. In 2005, there were 233
million mobile telephone subscribers [5] in the U.S. out of 290 million residents [4].
New phones are equipped with accelerometers that can be used to detect motion
pertaining to bouts of walking if the phone is carried on the hip or in the pocket.
similar to a pedometer.
In this work an accelerometer-enabled mobile phone (5500 Sport Phone, Nokia
Corporation) was programmed to detect physical activity and provide just-in-time
positive feedback and monitor change in behavior. The system developed is conprised of four parts: an automatic software updater, a physical activity detector, a
data cleaner and statistical analyzer, and web tools for remote data collection, data
analysis, and remote study compliance monitoring and administration. In addition
to describing the system design, operation, and pilot data collected, this work also
describes challenges that others might encounter when deploying research studies on
mobile phones.
16
Chapter 2
Background Information
The mobile phone presents new opportunities for preventive healthcare [21].
This
work builds on recent efforts to gather information via mobile phones and deliver
health-related feedback. Unlike much prior work, the system built was deployed with
a relatively large number of users (n=95) and field tested for a relatively long period
of time (9 months).
2.1
Prior work: Research on Phones
As mobile phone technology becomes more sophisticated, more studies are utilizing
mobile phones in collecting data and conducting research. Because phones are carried
nearly everywhere by many people, they can be used for experience sampling as
well as ecological momentary assessment, where the device beeps on a random or
controlled schedule and prompts the phone user for self-reported information
[141.
An
extension of this idea is to use phone sensors to automatically detect a context and
trigger questions only in specific situations. This is called "Context-Aware Experience
Sampling" [14]. Sensors that might be used include a heart rate monitor and a Global
Positioning System (GPS) as well as an internal or external motion sensor, call data
logger, and other sensors.
Commercial and open source software has been developed for electronic experience sampling. The "MyExperience" project runs on Windows Mobile devices and
permits context-aware experience sampling using a variety of sensors [11]. New context awareness detection routines are being added to the software regularly [12] [15]
[17]. The emergence of mobile phone app stores has created new possibilities to easily
and widely distribute phone software that might be used for research purposes.
2.2
Prior Work: Just-in-Time Feedback to Motivate Physical Activity
Modern phones have sensors such as accelerometers that can collect physical activity
data from the user. While the phones are sometimes pre-loaded with pedometer
software (e.g., Sony Ericsson W580i), these applications do not provide continuous,
proactive feedback. Although various studies suggest that use of a traditional, hip or
pocket worn pedometer can encourage physical activity [3] [10] [27], phones that can
detect steps or bouts of movement in real-time might offer new ways to use immediate
feedback to increase the effectiveness of an intervention designed to increase physical
activity.
One recent study by Consolvo et al. explored the field of just-in-time
feedback as a mobile phone detects the physical activity of its user [6]. The UbiFit
software runs continuously in the background on a Windows Mobile phone, gathering
data from a hip-worn device called the Motion Sensing Platform (MSP). The MSP
uses an accelerometer and other sensors to detect specific physical activities, such
as walking, running, and cycling. In response to physical activity, UbiFit gives justin-time feedback visually in the form of a virtual garden that evolves as the user
attains goals throughout the week (i.e. flowers bloom and butterflies appear). The
study monitored 12 subjects in a 3-week field trial and 28 subjects in a 3-month
field experiment.
The 3-week field trial showed that the intervention successfully
encouraged physical activity. In the 3-month field experiment, the control group
that did not have the visual feedback showed a significant drop in level of physical
activity. In the past, research has suggested that just-in-time feedback can motivate
small behavior changes [25] [2] [13]. In this work, sensors built into mobile phones are
used to detect steps, eliminating the need for a cumbersome hip-mounted MSP device
or pedometer, simplifying deployment and testing with a large number of subjects.
2.3
Originality of MobileHealth
The MobileHealth software is unique in the following ways:
1. It runs on common mobile phone with no external sensors required.
2. It tracks the phone users' behavior continuously and can be easily run for many
weeks (40, in this case), offering tailored feedback based on the previous week.
3. The user interface uses only positive reinforcement. Negative reinforcement is
avoided, because the user is free to turn off the software at any time. and the user is
unlikely to tolerate negative (or non-positive, nagging) feedback for long periods.
4. The user interface consists mainly of audio feedback. In the past, there have
been studies that worked with visual positive reinforcement
[6],
but we are unaware
of prior work using positive reinforcement provided continuously and consistently via
audio, thereby removing the need for the subject to pull the phone out of his or her
pocket to see the screen, and limiting disruption of everyday activity.
5. The phone sends data back to a secure server for researchers allowing for
remote daily compliance checking, potentially lowering study administration costs
and improving data quality.
6. The software can be remotely updated and managed, further reducing study
administration costs.
20
Chapter 3
MobileHealth Application
Overview
When designing the MobileHealth software, the first step was to outline the main
functions: detecting physical activity, providing feedback to the phone user, communicating data about steps and software use to the researchers, and allowing for remote
study administration.
3.1
Application Overview
Figure 3-1 shows the different components that comprise the MobileHealth application
as well as the data flow.
3.1.1
User Experience
The MobileHealth application was designed so that the user experiences minimal
disruption to everyday life. Ideally, the user would continue living his or her daily life
- without any need to change any behavior - and the application would automatically
detect physical activity and provide appropriate audio feedback at the right moments.
As part of the minimization of disruptions, the audio feedback was designed carefully to be intuitive so that users do not have to pull their phones out to know what
..
.....................
.........
Figure 3-1: MobileHealth app module and data flow chart. The solid arrows show
the exchange of physical activity data and the feedback between the subject and the
phone. The dashed arrows show the physical activity data and other relevant data sent
to the researchers for monitoring compliance and data analysis. The dotted arrows
show the path of how the updated version of the software is loaded to the phones via
the server. The updated versions may include bug fixes and/or new features.
the audio was trying to convey. For instance, if the user is behind their daily average
of physical activity, the audio should have a hint of urgency to encourage the user
to engage in more physical activity. On the other hand, if the user is ahead of their
daily average, the audio should attempt to create a sense of accomplishment. The
number of audio cues was kept at a minimum and similar audio was used for related
messages to quicken the process of recognition and differentiation.
While the application primarily uses audio for feedback, a minimal graphical user
interface (GUI) was also implemented. The user needs to be able to mute the application for occasions when audio cues can be disruptive. Sometimes users desired
a visual reminder in case they missed or did not know how to interpret the audio
cues. Moreover, a GUI was used to provide information on a user's overall stepping
progress relative to daily history (refer to section 3.2.4). Because the users are in
Finland, the GUI was translated to Finnish. Figure 3-2 is a sample screen.
..................
..
................................
........
....
..........
Translation:
MobileHealth v. 300
Last Bout Points: 2
Total Points Today: 20
Normally,
you have 37 by now
Mute Menu
Figure 3-2: Screen shot of MobileHealth app in Finnish.
3.1.2
Technical Challenges
The greatest design challenge was the fact that the study had to be run remotely. The
technical designers were not able to meet the subjects and personally inspect phones
when a problem was reported. Subjects would be distributed over large geographic
area, and having them bring the phone to the researchers would prove difficult. The
system needed to permit remote monitoring for compliance, remote data collection,
and remote updating of the core software that implements the intervention. Robustness was another challenge to be met, in two forms. Data collected needed to be
collected continuously anytime the phone was on. Any software crashes would result
in data loss. Crashes would also result in inconsistent feedback to the users, possibly
negatively impacting the intervention and impacting subject motivation to continue
their participation in the study. The iterative nature of this project meant that there
would be imperfections in the software code or intervention design that would require updating after phones had been distributed to subjects. A system that could
automatically and remotely update the software once the bug fix had been internally
tested by the researchers was required. Finally, among the major design challenges
posed is giving meaningful, easy-to-understand audio feedback. The platform had to
be flexible and reliable enough to permit remotely changing sounds during the study
and handling repeated playback of the various audio cues.
3.1.3
Mobile Platform
At the start of the study, only two mobile phones with an integrated 3D accelerometer chip that also permitted software to be installed as background processes that
processed the accelerometer data were on the market: the Nokia 5500 Sport and the
Nokia N95. Nokia N95 was a newer phone with more sophisticated features, such as
GPS, but it cost nearly 5 times as much as the Nokia 5500 Sport. The Nokia 5500
Sport was well-known for its robustness in design, being made to endure use during
sport, harsh weather, and some water exposure. For these reasons, the 5500 Sport
was selected as the study phone. At the time of this writing, suitable phones are
available on many carriers and operating systems.
The PyS60 platform was selected, with Python as the programming language
because we had heard reports that the platform was robust and easy to use [18] [24]
[7]. In addition, the scripts could be tested without having to compile, saving a large
amount of time for the testing and debugging phase. The Nokia 5500 Sport would
directly run the Python scripts, which are essentially text files, using the PyS60 shell
provided by Nokia.
Using PyS60 on the Nokia 5500 Sport Phone had these limitations. First, the
Nokia 5500 uses relatively old hardware with low computation power, low battery
life, and small screen size. The 5500 Sport Phone has little flexibility for running a
user-friendly UI. Furthermore, the PyS60 shell does not include code to vibrate the
phone or gather accelerometer readings, so developers must rely on external modules
created by independent programmers or write their own modules. These home-brewed
modules that function properly in the short-term sometimes fail in long-term tests.
Lastly, at the end of the development phase, in order to turn a script into a standalone
application, it had to be signed through an arduous process called "Symbian Signed".
Despite some limitations, ease of development led to the selection of PyS60 on the
Nokia 5500 Sport Phone.
3.2
Major Components
As shown in Figure 3-1, the complete MobileHealth system is comprised of a phone,
a server and a local computer. The phone detects the physical activity, provides
audio and visual feedback, logs data, and communicates with the server. The server
is the main bridge between the phone and the researchers that delivers the collected
data from the phone and allows the researchers to upload an updated version of the
application for a remote update. The offline script is used to take the data sent from
the phone and to translate it into something more comprehensible to the researchers.
3.2.1
Detection of Physical Activity
To detect physical activity, or "bouts", the MobileHealth application reads three
numbers that represent the raw accelerometer reading in each of the xyz-axes. First,
to reduce noise, the raw readings of each axis are smoothed. The smoothing process
is done by taking the average of the readings from the past 0.5 seconds. To eliminate
the effects of static acceleration from gravity, the derivative of the signal is computed
by taking the difference of adjacent values. The differentiated xyz values are then
used to calculate the magnitude of the acceleration using the distance function (i.e.
s/x + y2 + z ). By using the magnitude of the derivative of the acceleration, the
orientation of the phone is ignored and only the movement of the phone is considered. To reduce the effects of minor bumps and other insignificant movements, the
acceleration value is smoothed over the window of 1 second.
Figure 3-3 shows the resulting acceleration readings. With the acceleration readings, the application then determines whether or not the person is in a bout of movement using two parameters: duration and intensity threshold. If the acceleration
reading is above the threshold for a set duration (in this case 5 seconds), the application determines that the user is currently in a bout of movement. The orange boxes
represent what the MobileHealth application determines is a physical activity, or a
"bout". Whenever a bout is detected, the information is sent to the data logger to
be compared with the subject's previous bout history.
igi
minor bump
bxes)
bouts(orage
two bouts
bouts(orage
bxes)
combIned Into one
Intense bouts
are rewarded.
-
1
0
random testing
7F-F
1
1 2 3 45
from office to entrance of lab
to elevator
waiting for elevator
to entrance of building
to food court
ah
not a bout
30
I
6:
7:
8:
9:
I.
-
.
I
6
7 89
eating
running back to the building
waiting for elevator
fast walking back to office
Figure 3-3: Sample acceleration reading taken from MobileHealth application.
3.2.2
Data Logging
Epoch data, significant events data and point data are logged.
The epoch data
includes all data that is being recorded every second. This includes the raw xyz
values, differentiated xyz values, and the final acceleration. In addition to this, the
epoch data also includes the number of samples collected since the last iteration,
whether the user pressed a button or not, and battery level. To save space on the
memory card, this time stamped information is recorded in a binary format. The
significant events data is logged purely for the purpose of debugging. Every time the
application does something, such as play a sound or muting the phone, it is recorded.
When errors are encountered, such as a subject reporting the phone software is not
running, the significant events file is checked to see if there are any similarities across
the logs.
For each activity bout that is recognized by the application, the application determines whether the bout is significant or not. In the study, a bout lasting more
than 1 minute was considered significant based on the data collected during the data
collection period before releasing the audio feedback intervention (refer to section
3.2.3). When the user earns points, these points are added to. the total number of
points for that day as well as stored in a point log. Then, the number of points for
that day is compared with the number of points earned on average by that time of
day during the past 7 days and the information is sent to the playback component.
3.2.3
Audio Playback
When the subject receives points, the data logger sends the information regarding
where the subject's points are in comparison to the previous day's total number of
points for the particular time of day. Then, the audio feedback system determines
which audio should be played. When the physical activity detection component signals the start of a new bout, the reward module starts keeping track of the length
and intensity of the bout. During the bout, audio feedback is presented once per
minute to encourage continuation of the bout. At the end of the bout, the user is
rewarded once more for the length and intensity rating of the entire bout. Rating of
the bout is by a point system based on the MET (Metabolic Equivalent) system [1].
For example, running at 5mph has a MET value of 8, which is approximately 3 times
as much work as walking at 2mph that has a MET value of 2.5. This means that the
user will be rewarded 3 times as many points as walking. Since we are interested in
"bouts", the soft walk at 2mph is set as the standard 1 point and all other perceived
activities were rewarded accordingly. Once the number of points is calculated, the information of the appropriate audio file is sent to the playback module. The playback
module first checks whether the application is muted to decide whether to play or
skip the file. If it is not muted, the module checks if a sound file is currently playing
to avoid playing two or more sounds at once. In the PyS60 platform, playing a sound
file, in the middle of the playback of another file, causes the first sound to abruptly
stop playing and immediately starts playing the second. To avoid this, instead of
immediately playing the specified sound file, the playback module stores the sound
in a buffer to be played only after the first sound file finishes playing.
Figure 3-4: All graphical feedback screens in the MobileHealth application. The
majority of feedback is presented using audio, eliminating the need to remove the
phone from the pocket.
28
3.2.4
GUI
The GUI serves three purposes: to display messages when given a reward, to mute
the application and to display information on current progress.
When the audio
playback component determines the appropriate audio file to be played, it sends the
information to the GUI to display a message that describes the audio feedback as
well as today's progress as shown in Figure 3-4 top left.
To mute the phone or see information, the user has to flip the phone twice horizontally to access the GUI. When the GUI first opens, it will display information on
today's progress as shown in Figure 3-4 top right.
By pressing the right arrow button, the user can access the week's history as
shown in Figure 3-4 bottom left and can return to the main screen by pressing the
left arrow button.
From the main screen, the user can access the mute menu by pressing the left soft
key, which is located just below the words "Mute Menu". The mute menu has a list of
options as shown in Figure 3-4 bottom right. The maximum amount of time to mute
the application is limited to 2 hours, preventing users from muting the application
indefinitely, which would defeat the purpose of the study. Once the phone is muted,
the user can go back to the Mute Menu to un-mute it, or add more minutes to be
muted.
3.2.5
Communication
The communication component takes care of the two-way communication between
the phone and the server. One way is to upload the collected data and the other is
to update the application to a new version. Before the communication component
runs, it pauses all of the other components of the application and ensures safe closing
of every file. The upload module establishes a network connection and immediately
starts transferring all of the data files to the server. After the transfer is verified,
the files are deleted from the memory card one by one. The update module searches
a specified directory on the server for an application update. If one is found, the
application downloads it and, only upon successful download, the older version is
removed.
The update module is also the first module to run when the phone is
rebooted so that it can fix any broken components by replacing the main application
components (refer to Figure 3-1) with a newer version before they are loaded.
3.2.6
Server
The server collects data from the phones, stores updated versions of the application,
and provides a summary to allow remote researchers to monitor the daily compliance
of the phones. As data files are constantly uploaded to the server from the phones,
the server periodically appends the files and organizes them into folders according to
date. In this process, some data are extracted and summarized to be displayed on a
webpage. The updated versions of the application are stored in a directory that has
the proper permission settings for the phones to download the application.
There are two web pages that provide summary data to researchers that monitor
the daily compliance of subjects using the phone: the home page and the individual
page. The home page provides a list of all of the phones and a quick-read interface
that shows if the application is running and motion data are being collected, as shown
in Figure 3-5.
First, the page divides the list of phones into four categories: Active, Semi-active,
Inactive and Test.
The active list is a list of phones that are running the latest
version of the software and have significant activity data. The semi-active list is a
list of phones that are not currently running the latest version, but have made recent
contact with the server. The inactive phones are those that have not uploaded any
data in the past 7 days. The list of test phones used by researchers at MIT and in
Finland is appended below the three sections. For each subject, six summary data
are displayed as described in the Key in Figure 3-5. The green or red dot indicates
whether the phone has made a connection with the server in the past 24 hours. The
red and green bar indicates whether there was a bout for each day in the past 7 days.
Then, between the red/green bar and the green/gray bar is the number of bouts. The
green and gray bar indicates whether any keys on the phone have been pressed in
Mobile Health Projectz
Key
UserM
NumberofBouts
CurrentVersIon
green dlot
red dot
Pinged
in last24hrs
Phone Actt Oek)
grayba
Dayswi Bots (lw)
We perCentage
I today
green bar
Active(82
S2
4
e
S
s8
12
% 264
~
5l~4
60%
0%
IIIfUIUIU
92
*
0% 264
4
37
s5
red bar
green bar
S104
47
53.~
hu~ct~e
li)
10
106
264
0% 264
264
S450%
%i3
264
SIN/
0% 264
26 4
*%-2
24
e
0%
562
51
73
.
0%
*0%
0% 26A
264
0%
264
264
0% 264
Semisctwe (1)
S28
*
Sit
s36
4
0%
Phn
264
-0%
0%
-
e0%
566
100310
e
0%
264
264
264
S 0%
S66
r1m
SMo
.
--
e
Test
591
"lyon
lii
Ii
.0%
0%
264
264l1
a0%
-
-
Stephen
A-akss
K11
264
*
e
-
-
0%
0%
0%
200341
24
100310
0%
0011
Figure 3-5: Screen shot of homepage of MobileHealth online monitoring website.
each hour for the past week. Next to it is the percentage of time that the phone was
muted that day. Finally, the version number of the application is displayed. When
the subject number is clicked, the browser is directed to the individual page, as shown
in Figure 3-6.
The individual page provides more detailed information regarding a specific subject on a specific day. At the top of the page is a calendar that links to the data from
other days.
Below the calendar is the battery graph generated from the events logs to show
the battery level for each 15-minute time slot for a given day. The height of the
orange bar indicates the battery level for the specific time slot of the day.
The bout log displays the bouts in blue. The length and intensity of the bouts
are extracted from the epoch logs (refer to section 3.2.2) that are uploaded from the
phones and are represented by the width and length of each blue bar, respectively.
The reward information is extracted from the significant events files (refer to section
3.2.2) and yellow lines indicate when the user received a reward.
Below the bout graph is list of logs for the given day. Only the available logs are
displayed as hyperlinks. Depending on the log, clicking on the link can either open
the log file or just display the contents of the file on the same page. For example, the
epoch file is binary encoded. So, the link leads to a script that decodes the binary
encoding and opens the decoded file. However, for the shell events log, the files are
small, and the researcher would generally want to see the history of the subject while
looking at the logs. Therefore, the log is just displayed at the bottom of the individual
stats page, when the link is clicked.
The notes section displays any correspondence that the researchers had with the
subject. The researchers can add more notes by clicking on the "add note" link as
shown in Figure 3-7.
The diagnosis section provides a possible solution on how issues can be resolved
if there are any.
S33: 358642011111645
Currnti Sothrare
Versoon 264
Calendar
Tew
206
Montih
lanto
larorh
4
Low
F
S
SU T W R
26 27 2129 3O01 02
60
10 11 2 t13A14 16
17 IC IQeX212723
2425262212930
31 0102 03 04 05 06
O((14A Of
0O
Septerber
AgrA
Ma
June
go"
:
July
Amgus
Arury
2009
Odoter
1,4ve~'ber
Dcermber
yeflow background
orange bar
omt
tog:
'12t0$U
U0UUM
UUr
blue bar
gray background
Noht:
2001-10-0A
We contaded
User becarse his phone has been inActhe tMoltime to talk
try again
2006-10-10
We conltadedete user slnce he phone has been sermacyfhe sfslltewslon254) -- resta otrMe phone-> sersion250
updatedsuccessirlly
Me
2006-10-23
wrh
We conladed he user sme the phone has been inadive - Sh sad hoat tshe
aways carmeste phone
her, Ihe
data connedion is on, and heephone has theverson 250
2001-10-31
Was at workwhen phone,"we agreed to call her later-- we triedto osrmatte memory card but were notable to dothat
she promsed to bMng
the phone to Elis onMorday (I1r3
2006-11-01
We contaded
was askedto foral
oe
meory card the
INuser
f reesnewas not ate totormal tecause the memory
cardwas tsed t anotrer application"
- user t0ringMe
ph1one
to oW ie tommooew
2001-11-21
Wesend a ted message tothe user since the pione has beenInacse forabout aweeb Weadkesedthe user to checkthe
data connectionard torestauithe phone juster case. the user should be cordeitng us bac ifthe dataconnecten
cannot besoundori anymatkntdton nolces appear when restarting thephone the oser was also encouraged to carr
thephone and repod as thereasons sbe would hink to cause the in*aje oNte phone -JP
2009-12-10
Weserd an e-mal to Me
user oteuing
he a new memorcard. She sil 0 itTalKorwe *tI send the card to ters a
mall -JP
2000-01-27
Theuser phoned ts andtold
that the appcatoi doesesewral ties a day -JP
a end Nte
2000,1to 20
Ptease askthe orseto restart
the phone Theprogramseermed to havedosed
C C.ilial:
PAnotr [ c
F och 1n
Ptre I
evy
aloa
Mae Log
F
MIT Hmerw
n
Figure 3-6: Screen shot of individual page of MobileHealth online monitoring website,
as explained in the text.
mail. -JP
2009-01-27
The user phoned us and told that the application closes several times a day. -JP
0 cancel note
Date: 2009-05-25
Note:
Your Name:
Add
0 "yon's Diagnosis
20089-10-20
Please ask the user to restartthe phone. The program seemed to have closed.
Figure 3-7: Screen Shot of note feature in individual page.
3.2.7
Data Preparation for Analysis
Two offline scripts were written to summarize the data for easier analysis. The first
script combines the different logs such as the epoch log and significant event logs in
to one file per day. The second script extracts and summarizes, by hour and day,
the percent of time that the application was running, average battery level, number
of times the keys were pressed on the phone, percentage of time that the application
was muted, number of bouts, percent of time that the subject was in a bout, number
of points earned, and the number of times the subject went ahead of their daily
average for the particular time of day. When the script is run, it asks for the subject
number (with the option of selecting all), the start date and end date. Then, the
script proceeds to summarize the data for the selected subjects within the time frame
outlined and outputs a set of comma-delimited text files that can be easily opened in
a spreadsheet for further analysis.
3.2.8
Iterative Testing and Deployment
Testing was first done on the developer's phones and then on phones carried by some
of the MIT researchers. When all of the components seemed to be functioning, the
V;
application was loaded onto the phones of the remote researchers in Finland. Then,
the application went through more rigorous testing. Only then, after the research
team discussed the changes, was the new version released to the subjects. However,
even with this meticulous system for testing the application, bugs were still uncovered
by the subjects after some changes and the application needed to be remotely updated
numerous times.
Two tests in particular are worth noting here. A battery life test indicated that
the high frequency of the network connection was the main source of battery drain.
A country code test was used to determine how the phone reacted to connection to a
different network, in an attempt to solve a problem that was encountered where the
phone would connect to the Internet in roaming networks and generate substantial
data fees (refer to section 5.2.1).
36
Chapter 4
Deployment
The total duration of the study is set to be one and a half years. The contract with
the subjects is one year for data collection. Six months were used for the development
of the software and analysis of the data collected from the subjects.
4.1
Experiment
Table 4.1 is a timeline that shows the major milestones of the project.
4.2
Subjects
Recruitment consisted of three parts: an online survey, information sessions, and recruitment sessions. Online survey invites were emailed to potential subjects within
the age range of 30 and 60 in Finland that were identified using the database of
Elisa's customers. Group information sessions were conducted with people expressing interest in joining the study, where questions were answered and more detailed
information was provided such as the offer of providing a free mobile phone as well as
free mobile service for one year. For those that wished to become a subject, details of
using the phones were also described, and phones were distributed. SIM cards were
mailed out later after the service contract information was processed. When recruiting subjects, each individual was given a survey based on existing surveys regarding
Table 4.1: Timeline of the major milestones of the project.
[ Week Milestone
Month
January. 2008"
February
March
April
May
June
July
August
1
.tart
of StIdv
3
Fist versioin created that records raw signals from accelerometer
4
1
Cl iation of acceleration implemented
Tst ing begiis to define what is a bout
4
I
Bowt detection implemented
Simple aidio feedback implemented
2
Testiig begins to refine bout detection
I
2
Bouit is nows well-defined
3
4
1
Server is set ip; upload/update module implemented
2
Screening questionnaire completed
3
4
1
2
3
4
1
2
3
1
2
3
Einails are sent to potential subjects to complete survey;phones are ordered
III people have filled out survey; basic monitoring system implemented on server
Phones arrive: installation of update/uploader begins; first recruitment session
Second recriitment session
Webtools for easy monitoring implemented on server
Initial testing ends; first version released to subjects
4
September
October
1
2
3
4
1
2
3
New version released to improve battery life
New version released to minimize memory usage
TC Trust Center certificate ordered to use "Symbian Open Signed Offline"
Third recruitment session
New version released to distinguish network
4
November
1
2
Recruitment finalized
First version of intervention rewards for length and intensity relative to user stats
3
December
4
1
Non-intervention version stabilized; new version released to subjects
2
3
Intervention simplified to reward only length for easier testing
4
January, 2009
1
2
3
Intervention stabilized
Intervention concept revised; relative point system implemented
4
February
I
2
Absolute point system implemented
3
4
March
April
1
2
3
4
1
2
3
Website created to describe the intervention to subjects
Intervention concept finalized and released
Intervention stabilized;new version released
4
May
1
2
3
4
Data summarized for initial analysis
physical activity [26] [23] [20] and )laced into one of five categories: extremely sedentary, somewhat sedentary, sedentary but would like to be more active, somewhat
active, and extremely active. Recruitment was prioritized on recruiting individuals
that mainly fall into the eitlher the somewhat sedentary, sedentary but would like to
be more active, and somewhat active categories.
4.3
Current Status
It has been about nine months since the subjects first received the phones and over
two and a half months since the intervention was released. With a stable version
running on the phones, we are able to experiment by changing the audio files as well
as by tweaking intervention settings, such as X, Y, and Z. With three more months left
of the contracted term, interviews will soon be conducted by researchers in Finland
to assess the effects of the intervention and to collect qualitative feedback directly
from the subjects on the perceived utility and efficacy of the software. By the end
of the study, we plan to categorize the subjects into different categories of physical
activity (i.e. sedentary vs. active) and compare this data with the interview data
collected at the beginning of the study for a more in-depth analysis of the different
types of subjects.
40
Chapter 5
Evaluation/Discussion
As outlined in section 1.3, the main goal of the MobileHealth study as presented here
was to successfully develop, deploy and test the MobileHealth application. As such,
the focus of the evaluation will primarily be on the usability and feasibility of the
system and the consistency of the data collected. Additionally, the various unexpected
challenges faced will be addressed and recommendations on future work will be given
to provide guidance for further studies that are similar to the MobileHealth project.
5.1
Data
The MobileHealth study was conducted in two phases. The first phase was to release
an application that passively logged physical activity data. Once the subjects became
familiar with the phone and sufficient amount of physical activity data was collected,
the feedback system (that will be referred to as "intervention" from here on out) was
released to explore the real and perceived impact of just-in-time positive feedback.
The following are the two time periods observed in the following subsections:
"Adaptation" = 12/5/2008 through 3/12/2009 - passive data collection software
is running consistently
"Intervention" = 3/25/2009 through 5/15/2009 - intervention software is running
consistently
5.1.1
Evaluation of the Consistency of the Application
The application running percentage indicates the percentage of time over a window
the application was actually running. For example, if the application ran for 72
seconds in an hour, in that particular hour, the running percentage is only 2%.
Average Running Percentage
by Hour
-
100
2
Adaptaion
-
Intervention
-
90
80
70
60
50
40
30
20
10
0
0 1 2 3 4 5 6 7 8 9 1011121314151617181920212223
hour
Figure 5-1: Graph comparing the average running percentage of MobileHealth app
during the Adaptation and Intervention periods.
Figure 5-1 shows the average running percentage for all the subjects averaged over
each hour of the day. We can clearly see that the software ran more consistently during
the Adaptation period at a higher rate overall. The two graphs share a common dip
at around 7 and 8am. This shows that some users may have turned their phones off
during the night and simultaneously turned them back on around the same 1-2 hour
time period.
Figure 5-2 is a direct comparison of the overall percentage of the application
running between the time interval during the Adaptation and Intervention periods.
Each data point represents a subject and the x-coordinate and y-coordinates represent
the percentage of application running during the Adaptation and Intervention periods
respectively. The dotted line represent the points in which no change occurred. The
graph clearly indicates that the majority dropped in percent running during the
Intervention period, which is also clearly shown in Figure 5-1. In addition, Figure 5-2
Percent Running App Adaptation vs. Intervention
by Subject
C
100
.5
80
0
60
a'#
fe
20
40
1A
10
-20
20
30
40
50
60
70
80
90
100
%values before release of intervention
Figure 5-2: Graph plotting each subject as a data point where x-coordinate is percent
running app during Adaptation period and y-coordinate is during the Intervention
period.
shows that the subjects in the higher percentage range had a bigger drop than the
lower range. Outliers are also visible in this graph. Some subjects actually did not
run the application at all during the study, which would be considered non-compliant,
and negatively bias the overall average. To calculate the effects of the non-compliant
subjects, Figure 5-3 shows the change in overall average as the bottom n number of
subjects are removed from the dataset, where n is the value in the x-axis.
Figure 5-3 shows that the increase in average is high when dropping the first few
subjects. This shows how much the non-compliant subjects bring down the average
of the percent running. These users can be categorized as "did not comply enough to
count as valid data." Figure 5-4 is the differential taken from the Figure 5-3.
The average across the graph for Adaptation and Intervention periods are 0.29
and 0.44 respectively with standard deviations of 0.14 and 0.11, respectively. When
considering only the slopes that come within one standard deviation from their averages, the initial peak is eliminated. Therefore, the number of subjects that are
determined as "invalid data" are the bottom 13% and 8% resepctively. After dropping the "invalid data", Figure 5-5 is the resulting graph of the percentage of time
Average Percent Running
by Subjects Dropped
-Adaptabon
-ntervenion
100
90
80
.E
C
70
S60
50
40
30
20
10
1 5 9 131721252933374145495357616569737781858993
number of least-compliant subjects removed from dataset
Figure 5-3: Graph displaying the change in overall average as increasing numbers of
poorly compliant subjects are removed from the dataset.
Differential of Avg Percent Running
by Subjects Dropped
-
Adaptation
-
teverdon
0.8
C
0.7
o
0.6
0.4
0
0.1
1 4 7 1013161922 2528313437404346495255586164
number of subjects dropped
Figure 5-4: Differential of Figure 5-3.
.
.............
that application was running.
Average Running Percentage
by Hour
-
Adaptation
--
Intevention
100
90
80
----
---
70
40
30
20
10
0
0 1 2 3 4 5 6 7 8 9 1011121314151617181920212223
hour
Figure 5-5: Resulting graph of Figure 5-1, after removing the radical subject data
from the dataset.
The change increased the overall average of the Adaptation values from 69.9%
to 76.9% and the Intervention values from 50.2% to 54.1%. The data can also be
organized by subject to see the behaviour of each individual. The following graph
shows a sample of the population to demonstrate this fact. Graphs like Figure 5-6
can be drawn for all the variables discussed in this chapter.
The average battery level was recorded every second that the application was
running. Figure 5-7 displays the average battery level throughout the day averaged
over each hour.
Figure 5-7 clearly indicates that the intervention causes a significantly larger drop
in the battery level during the day than the logging-only version. This is expected, because the intervention uses more computation power for real-time statistical analysis
as well as to play the audio files. The upward bump at the end of the day represents
the time when the subjects typically started charging their phones for the night. On
an individual level, this data became useful in providing information on the battery
itself. Four phones were reported to have come with a defective battery and those
were easily identified using this type of subject-specific graph, and the batteries were
Percent Running App
by Subject
U Adaptation U hneron
S2
54
55
S6
57
58
59
510
511
512
513 S14
Subject Number
Figure 5-6: Comparison graph of percent of time that MobileHealth app was running
across the two periods for each subject.
Average Battery Level
by Hour
-
Adaptatonw
Iteivention
100
70
60
g
50
40
0 1 2 3 4 5 6 7 8 9 1011121314151617181920212223
hour
Figure 5-7: Average Battery level by hour of day across all subjects for the two
periods.
replaced as quickly as possible.
The average numbers of key presses were calculated by recording every time the
subject presses a key on the phone, such as when making a phone call. This counts
all of the key presses, regardless of whether the application is displaying anything on
the prompt screen. Figure 5-8 shows the average number of key presses over a single
day averaged over each hour of the day.
Average Number of Keypresses
by Hour
-
Adaptation -Intervention
45
40
e
35
S30
25
6
20
.n 15
E
10
50
1
-
-
0 1 2 3 4 5 6 7 8 9 1011121314151617181920212223
hour
Figure 5-8: Comparison graph of the average number of keypresses made by all
subjects across the two periods.
Figure 5-8 shows that the phones are used most heavily during the day, which
is the expected behavior. However, this information has much more value on an
individual level. By combining the information from the individual percentage of
application running graphs (refer to Figure 5-6), the average number of bouts by
hour (refer to Figure 5-14), and the individual key press graphs (refer to Figure 58), the researchers can deduce whether the particular subject used the phone as a
primary phone (to make phone calls, etc), or just carried the study phone around to
hear the intervention sounds. The researchers can also determine if someone did not
carry the phone at all. Figure 5-9, Figure 5-10, and Figure 5-11 are a few samples of
the key press data on an individual basis.
When the intervention triggered to play a sound, some played and others were
...................
Average Number of Keypresses
by Hour for S10
-
Adaptation -ntervenion
1 2 3 4 5 6 7 8 9 101112 131415 1617181920212223 24
hour
Figure 5-9: Average number of Keypresses by hour of day across the two periods by
Subject 10.
Average Number of Keypresses
by Hour for S31
-
Adaptation --
ierveron
1 2 3 4 5 6 7 8 9 101112131415161718192021222324
hour
Figure 5-10: Average number of Keypresses by hour of day across the two periods by
Subject 31.
kmw
l
............................
-..........
Average Number of Keypresses
by Hour for S36
-
Adaptation -- Itervenbon
16
14
12
-
0
0
E4
2
0
-
-
-
1 2 3 4 5 6 7 8 9 101112131415161718192021222324
hour
Figure 5-11: Average number of Keypresses by hour of day across the two periods by
Subject 36.
muted by the user. The numbers of played sounds and muted sounds were recorded.
Figure 5-12 shows the percentage of sounds that were muted averaged across each
hour.
Figure 5-12 shows that the sounds were most muted during the day, as expected.
Figure 5-13 shows what percentage of the sounds were muted for each subject (all
subjects are listed, but the subject numbers are omitted in the interest of space). The
entire region of the graph (from 0 to 100%) represents all of the sounds triggered to
play. The shaded region on the bottom left represents the fraction of those sounds
that were muted, approximately 1.4% of the sounds for all sounds triggered to be
played for all subjects.
As described above, the collected data shows consistent data that show clear
expected trends across users, suggesting the software was running well. This data,
graphed for particular individuals, can be compared with the individual responses
from the end-of-study interviews to understand usage trends and to gather qualitative
information about how to improve the software.
............
Percent of Sounds Muted
by Hour
1.4
1.2
1
0
0.8
0.6
0.4
0.2
0
0 1 2 3 4 5 6 7 8 9 1011121314151617181920212223
hour
Figure 5-12: Percent of sounds that were muted by hour of day since the audio
feedback intervention was released.
Percent of Sounds Muted
by Subject
522
520
S97
S17
549
0
5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95100
%muted
Figure 5-13: Percent of sounds that were muted by each subject since the audio
feedback intervention was released.
---------------------------------------------------------------.
....
.............
..............
5.1.2
Evaluation of the Trends in Data
In addition to testing feasibility, another goal of the study was to investigate the
behavior change potential of the intervention. Here we show how the system could
be used to gather the type of data needed for this comparison.
The number of bouts was recorded throughout the day.
Average Number of Bouts
by Hour
d Adaptation
itervention
7
6
50
.0I
2
0 1 2 3 4 5 6 7 8 9 10 1112 13 141516 17 1819 20 2122 23
hour
Figure 5-14: Average and variance of the number of bouts by hour of day across the
two periods.
Figure 5-14 shows the average number of bouts per hour across all of the subjects
for all periods of time when software on the phones was running. The graph not only
compares the data between Adaption and Intervention periods, but the error bars
show the variance of the data across the periods. Shorter error bars indicate little
variance in general. Figure 5-15 shows the same information by day of week.
Figure 5-15 indicates that the subjects were much more active during the week
than the weekends, a result that seems reasonable Both Figure 5-14 and Figure 5-15
indicate that there was a general increase in the number of bouts after the intervention
was released, but given factors such as weather changes, it is not possible to say if
this is due to the intervention or other factors. Regardless, the data suggest that the
MobileHealth software system is sufficiently robust to collect data in future studies
to determine the impact of an intervention.
Average Number of Bouts
by Day of the Week
U Adaptation M Intervention
90
80
70
z
0
60
10
50
E
2~0
10
M
T
W
R
F
Sa
Su
day of the week
Figure 5-15: Average number of bouts by day of the week across the two periods.
The percent of time inbout was calculated by counting the number of seconds
that the user is in a bout over a specific time frame. Figure 5-16 shows the average
percent of time spent in bout for every hour of the day across subjects.
Figure 5-16 clearly indicates an increase in the lengths of bouts overall during
the intervention phase. Three sections are prominent in the "Intervention" dataset,
which seem to represent: going to work around 7-9am, lunch time around noon, and
going home from work around 3-5 pm.
Figure 5-17 shows the percent of time spent in a bout averaged for each day of
the week.
Again, Figure 5-17 shows a slight increase of length of time in bout over the
weekdays compared to the weekends, a result that is coherent with Figure 5-15.
In Figure 5-18, each data point represents a day in the study, whether it would
be before or after the release of the intervention.
Figure 5-18 clearly indicates a correlation in the length of time spent in a bout
with the number of bouts in that day, which is expected.
Figure 5-19 displays specific events that occurred as part of the intervention. The
information is validated by the similarities in the trends observed compared to the
actual physical activity data displayed above, especially in correlation with the result
........
.........................................
Percent of Time Inbout
by Hour
-
Adaptation ---
Itervention
7
6
5
S4
3
2
10
0 1 2 3 4 5 6 7 8 9 1011121314151617181920212223
hour
Figure 5-16: Percent of time spent inbout by hour of day across the two periods.
Percent of Time Inbout
by Day of the Week
U Adaptation
U nerventon
5
41
03
2
1
0 4
R
TW
Sa
Su
day of the week
Figure 5-17: Percent of time spent inbout by day of week across the two periods.
Average Number of Bouts
vs. % of Time Inbout
by Day
.
Adaptaton
* Irtervenion
7
6
5
0
0
E 3
000
00
0
2
20
40
60
80
100
average number of bouts
Figure 5-18: Average number of bouts plotted against % of time spent inbout for
each day across the two periods.
shown in Figure 5-16. It is more likely that a subject will go ahead of their average,
when there is a steep upslope in Figure 5-16. If the steep upslopes of the day happen
slightly before the average upslopes, then the subject will be "going ahead" during
those upslopes, whereas they would be "catching up" for the same upslopes, if they
were to occur slightly later than usual. Therefore, it is natural that the three peaks
in Figure 5-19 happen at the same times as the steep upslopes in Figure 5-16 and
that the biggest peak in Figure 5-19 happens at the biggest upslope in Figure 5-16,
which is around 6-7am.
Looking at the figures and data in this section, one can conclude a high correlation amongst the data and see clear trends in most. The trends can be analysed
and the phenomenon can be logically explained with our expectations from previous
knowledge about the general human behaviour, such as waking up in the morning and
going to sleep at night. This confirms the validity of the data and gives confidence in
the collection of more sophisticated data and further analysis.
..........
Number of Going Ahead
by Hour
0.1
0.09
0.08
0.07
0.06
0.05
0.04
0.03
0.02
0.01
0
0 1 2 3 4 5 6 7 8 9 1011121314151617181920212223
hour
Figure 5-19: Average number of times that the subjects went ahead of their regular
amount of physical activity within each hour of day since the release of the audio
feedback intervention.
5.2
Challenges
Throughout the development of the software, there were many challenges in both
hardware and software that had to be overcome, as described in Section 3.1.2 and
Section 3.1.3.
5.2.1
Data Connection from abroad
Over the course of the study, there were subjects that left Finland. Due to the
software's use of the data network, these subjects unintentionally incurred roaming
charges on the order of hundreds of dollars. The solution for avoiding this was to
detect the Mobile Country Code (MCC) that the network provided in each country
upon request of connection. If the subject was out of his or her own country, the
phone would run the application in offline mode and continue to collect data without
uploading it to the server. This was possible because the data size was minimized
and the memory card could store over a month's worth of data at a time.
5.2.2
Short Battery Life
One major complaint from the subjects was the short battery life. When used as a
primary phone, the battery did not last for more than a single day, even when the
application was not running. At first, when the application was running, the battery
would not last more than 12 hours. However, through controlled testing, network
connections were determined to be causing the most avoidable battery drain. By
reducing the frequency of the data uploads to twice a day and closing the connection
between uploads, battery life was increased to an average of 22 hours, which is close
to the maximum possible battery life of about 26 hours when the phone is running
without the application.
5.2.3
Not able to use keys to load program screen/menu
After testing the initial version of the intervention amongst the researchers, it was
clear that a visual prompt screen was needed. Users found an early prototype that
did not show anything on the screen to be confusing if they did not remember the
meaning of an audio prompt. A visual prompt screen was added to display messages
that explained the meaning of the sound that just played, such as "Good job, you are
now ahead of your average!" Another reason to add the screen was to be able to access
the mute menu. However, the mute menu posed a new problem - the subject needed
an easy way to pull the screen up. The typical approach is for the subject to press a
series of keys to pull up the menu screen, but, to implement this method, we needed
a key combination that was guaranteed not to be used by any other application.
Instead, we opted to detect a pattern of movement using the accelerometer readings.
The chosen pattern was to flip the phone twice. In the unlikely event that the phone
is flipped twice unintentionally, the screen could be dismissed with a single key press,
or it would go away after 15 seconds of being idle (i.e. no keys pressed).
5.2.4
Bad Reception
Compared to other phones that came out at a similar time, the Nokia 5500 has a
poorly designed antenna and can provide poor reception. To deal with inconsistelt
connectivity issues, file sizes of data to be transferred to the server were minimized.
Large files were also split into smaller pieces so some data could be transferred in
short bursts. If the network connectivity was poor, the software did not attempt to
send any data and skipped the upload or update, retrying 30 minutes later.
5.2.5
Multi-threading of accelerometer data feed
To use the accelerometer on the Nokia 5500, an external Python module called pvextaccel was imported. The behavior of this module was unpredictable. Sampling rate
was inconsistent, fluctuating from 15Hz to 40Hz. In addition, the module could instantiate many threads, creating file-handling problems, since two threads would try
to write data to the same file at the same time. Using process locks it was possible
to get the module to return accelerometer samples reliably at 10 samples per second
and avoid file conflicts that would otherwise crash the software.
5.2.6
Memory Card/Data Corruption
There were quite a few defective memory cards given to subjects in the experiment.
The Nokia 5500 came with a 32MB microSD card and some of them could not be
detected, while others could be written to but caused read errors. These memory
cards were replaced. There were a few cases where the memory cards would function
properly initially, then would stop working. Formatting the cards and restarting the
software solved these issues.
5.2.7
General Error Handling
For each file I/O operation, exception handling was implemented for opening the file,
then for reading/writing the file, and also for closing the file. Sometimes an error
would occur while closing the file and would not allow for proper opening of the
same file, resulting in a file lock that would later crash the application. Extensive file
exception handling was critical to achieving smooth operation of the software.
5.3
Recommendations
For future, remotely-monitored mobile phone studies that are similar to MobileHealth,
in addition to being prepared for the challenges described in the previous section,
researchers should be aware of the following.
Visualization/summary tools: Prepare to develop tools that can help the visualization of the data and the communication among researchers. With the various
kinds of data collected, one can easily find him/herself repeating steps to generate
visualizations and/or summary of data as it is being collected. Identify these steps
at an early stage and make sure to include the development of such visualization and
summary tools in the overall timeline.
Communication with subjects: Subjects need a way to communicate with the
researchers. With the availability of the Internet, it is recommended that a webpage or a wiki be set up for the subjects to be able to receive information, updates,
and possibly even correspond with the researchers. Having this channel set up is
critical because good communication will increase subject tolerance as problems are
encountered, minimizing subject disenrollment.
Create an exhaustive troubleshooting manual: When dealing with real-time data
collection involving various instruments and components, it is important to respond
quickly to problems. Not all researchers on the project team will have the same type
of technical knowledge regarding the software, so materials must be developed such
that multiple researchers can respond to inquiries in a timely manner.
Chapter 6
Conclusion
In this document, we have described the technical development of the MobileHealth
application. The data presented clearly shows the tool functions, and throughout the
experiment we have demonstrated that the software can be remotely updated and
maintained. The system design and challenges documented here may guide others
interested in developing software for mobile phones intended to implement and study
just-in-time positive feedback.
6.1
Future Work
We have demonstrated proof-of-concept of running an international study that collects
continuous real-time data from 95 subjects over a period of 9 months using common
mobile phones that automatically detect bouts of physical activity. Mobile phones
now have a wider range of sensors such as GPS, cameras, and even heart rate monitors.
Coupling the advanced hardware with a more flexible, development-friendly platforms
such as Google Android, Microsoft Windows Mobile and Apple iPhone OS 3.0, future
studies can collect highly detailed and elaborate data for better control and analysis of
the numerous variables involved in continuous data collection. In addition, the larger
screens, touch screens, and higher-quality audio feedback of these newer devices afford
better opportunities to create user-friendly and intuitive interfaces that might better
encourage just-in-time behavior change.
In this study, we collected acceleration data from a 3D accelerometer inside a mobile phone. The signal was aggregated into activity bouts. However, it is also possible
to analyze raw data and detect specific physical activities, such as steps or even various postures and modes of ambulation. This type of detailed physical activity data
on type, intensity, duration, and (perhaps using GPS) location of physical activity
would expand the type of intervention strategies the phone might use to encourage
behavior change. These are areas for future work.
In this study, subjects were recruited in a traditional manner and then enrolled in
the study. It is now possible to upload applications to so-called "app stores" where
thousands or even hundreds of thousands of people might freely download them. This
creates exciting new research opportunities if the software and data can be remotely
updated and managed, as in this study. This type of study raises many interesting
technical and experimental challenges and is another area for future work.
6.2
Summary
As mobile phones become more sophisticated in hardware as well as software, it is
possible to collect and convey more detailed information without the need for external
sensors or devices. The MobileHealth application demonstrated the ability to collect
highly detailed (1dataset/sec) acceleration data using only the hardware of the mobile
phone. In addition, utilizing the data communication capabilities of the modern
mobile phone network and services, the application provided the detailed data in realtime to be remotely monitored by researchers. Finally, with this non-invasive method,
the MobileHealth application was sufficiently robust to remotely collect the highly
detailed data about physical activity from 95 subjects at a reasonable compliance level
over a period of 9 months. Data analyzed to date show the promise of performing this
type of remotely-administered study on mobile phones with large numbers of subjects.
This is a new way of doing research, which will become increasingly powerful as mobile
technology improves, influencing an increasing number of people every day. When
targeted and administered properly, such methods can play a major role in addressing
national health issues such as obesity.
62
Bibliography
[1] Ainsworth. The compendium of physical activities tracking guide. Prevention
Research Center, Norman J. Arnold School of Public Health, University of South
Carolina,January 2002.
[2] H. Beckman, S. Hawley, and T. Bishop. Application of theory-based health
behavior change techniques to the prevention of obesity, in children in nursing.
Journal of Pediatric,41(4):266-275, 2006.
[3] Dena M. Bravata, Crystal Smith-Spangler, Vandana Sundaram, BA Allison
L. Gienger, Nancy Lin, Robyn Lewis, Christopher D. Stave, Ingram Olkin, and
John R. Sirard. Using pedometers to increase physical activity and improve
health. JAMA, 298(19), 2007.
[4] U.S. Census Bureau. National Population Estimates. May 2008. http://www.
census.gov/.
[5] CIA. The World Fact Book. May 2008.
publications/the-world-factbook/.
https://www.cia.gov/library/
[6] Sunny Consolvo, David W. McDonald, Tammy Toscos, Mike Chen, Jon E.
Froehlich, Beverly Harrison, Predrag Klasnja, Anthony LaMarca, Louis
LeGrand, Ryan Libby, Ian Smith, and James A. Landay. Activity sensing in
the wild: A field trial of ubifit garden. Conference on Human Factors in Computing Systems, 2008.
[7] Cyke64. Everything on pys60. May 2009. http: //www.mobilenin. com/pys60/
menu.htm.
[8] Center for Disease Control and Prevention. Physical Activity Trends. May 2008.
http: //www. cdc.gov/mmwR/preview/mmwrhtml/mm5009a3.htm.
[9] Center for Disease Control and Prevention. Prevalence of Overweight and Obesity Among Adults. May 2008. http://www.cdc.gov/nchs/products/pubs/
pubd/hestats/overweight/overwght-adult_03.htm.
[10] Stephen Freed and David Joffe. Diabetes in control. May 2008. http: //www.
diabetesincontrol.com/studies/step.shtml.
[11] J. Froehlich, M. Chen, S. Consolvo, B. Harrison, and J. Landay. Sensors and
surveys: Collecting qualitative and quantitative data on human attitudes, behaviors, and activities via mobile phones. New Paradigms in Using Computers
(NPUC), 7 2007.
[12] Jon Froehlich, Tawanna Dillahunt, Predrag Klasnja, Jennifer Mankoff, Sunny
Consolvo, Beverly Harrison, and James A. Landay. Ubigreen: Investigating a
mobile tool for tracking and supporting green transportation habits. Conference
on Human Factors in Computing Systems, 2009.
[13] Andrea Carlson Gielen and David Sleet. Application of behavior-change theories and methods to injury prevention. Oxford Journals Epidemiologic Reviews,
25(1):65-76, 2003.
[14] S. S. Intille, J. Rondoni, C. Kukla, I. Anacona, and L. Bao. A context-aware
experience sampling tool. Proceedings of CHI '03 Extended Abstracts on Human
Factors in Computing Systems, pages 972-973, 2003.
[15] Jonathan Lester, Phil Hurvitz, Rohit Chaudhri, Carl Hartung, and Gaetano
Borriello. Mobilesense - sensing modes of transportation in studies of the built
environment. International Workshop on Urban, Community, and Social Applications of Networked Sensing Systems - UrbanSense08, 2008.
[16] National Heart Lung and Blood Institute.
BMI.
May 2008. http: //www.
nhlbisupport . com/bmi/.
[17] M. Morris and F. Guilak. Mobile heart health: Project highlight. Pervasive
Computing, IEEE, 8(2):57-61, 2009.
[18] Nokia. Nokia forum. May 2009. http: //www. forum. nokia. com/.
[19] World Health Organization. Obesity and Overweight. May 2008. http: //www.
who.int/dietphysicalactivity/publications/facts/obesity/en/.
[20] The original PAR-Q was developed by the British Columbia Ministry of Health.
It has been revised by an Expert Advisory Committee of the Canadian Society
for Exercise Physiology chaired by Dr. N. Gledhill. Par-q. 2002.
[21] K. Patrick, W. G. Griswold, F. Raab, and S. S. Intille. Health and the mobile
phone. American Journal of Preventive Medicine, 35:177-181, 2008.
[22] Physical Activity and Health. A Report of the Surgeon General 1996, May 2008.
http://www.surgeongeneral.gov/library/reports.htm.
[23] M. Richardson. Validation of the stanford 7-day recall to assess habitual physical
activity. Annals of Epidemiology, 11(2):145-153, 2001.
[24] Jurgen Scheible. Pys60 tutorial.
pys60/menu.htm.
May 2009.
http://www.mobilenin.com/
[25] Stuart Silverman and Ellen Kimmel. The Influence of Immediate Feedback on
the Behavior of Teachers-In-Training. 1972.
[26] Ruth E. Taylor-Piliae, Linda C. Norton, William L. Haskell, Mohammed H.
Mahbouda, Joan M. Fair, Carlos Iribarren, Mark A. Hlatky, Alan S. Go,
and Stephen P. Fortmann. Validation of a new brief physical activity survey
among men and women aged 60-69 years. American Journal of Epidemiology,
164(6):598-606, 2006.
[27] Catrine Tudor-Locke. Taking steps toward increased physical activity: Using
pedometers to measure and motivate. Research Digest, (17), 2002.