Informatics in Medicine Unlocked 10 (2018) 27–44

Contents lists available at ScienceDirect

Informatics in Medicine Unlocked

journal homepage: www.elsevier.com/locate/imu

Mobile health architecture for obesity management using sensory and

social data
Saad Harous a, Mohamed El Menshawy b, Mohamed Adel Serhani a, *, Abdelghani Benharref c
a
College of Information Technology, United Arab Emirates University, United Arab Emirates
b
Concordia Institute for Information Systems Engineering, Concordia University, Canada
c
Faculty of Engineering and Information Sciences, University of Wollongong in Dubai, United Arab Emirates

A R T I C L E I N F O A B S T R A C T

Keywords: One of the principal causes of several chronic diseases (e.g., diabetes, high cholesterol, and hypertension) is the
Mobile health obesity epidemic in high and middle income countries. Obesity also leads to an increasingly negative effect on
Obesity public health resources. Therefore, obesity and overweight have to be monitored to mitigate and prevent the
Monitoring potential risks generated from the threat of related diseases and from reducing productivity experienced by
Prevention businesses. A mobile-health monitoring system includes sensing, transmitting, storing, processing, and analyzing
Data mining
intensive, continuous, and heterogeneous medical data. However, current approaches are standalone mobile
Sentiment analysis
applications, augmented mobile applications, or mobile health systems. These approaches only consider simple
Social community
Sensors activities (assess, detect, or control obesity) and rely on a mobile phone to perform complex processing operations
on the collected data. Such complex operations need (1) efficient data mining techniques, (2) more memory
consumption and processing time, and (3) long life mobile battery. In this work, we develop a new comprehensive
mobile architecture for tackling the challenging issues of obesity control, monitoring, and prevention. We
introduce a set of business requirements considering stakeholders, sensor devices, and architecture requirements
to meet our architecture's objectives. Our architecture system can also help individuals track food intake, lifestyle,
calories intake, calories consumption, and exercise activities. We analyze the data collected from continuous
monitoring using non-invasive sensors, in addition to the data collected from social communities created to
propagate awareness and share appropriate information about the obesity problem and its solution. We develop
data mining algorithms and sentiment analysis algorithms and generate intelligent suggestions, warnings, and
recommendations to control and mitigate the risk of obesity and its related diseases. We develop schemes for
reducing data and saving energy, which minimize the amount of network traffic within the community of sensors.
Moreover, we totally implement our architecture system as a collection of Web services organized by the mod-
el–view–controller design pattern to write, retrieve, and access data to and from the cloud storage firebase. We
finally evaluate the efficacy and scalability of the implemented system using a comprehensive cloud database
including entered data, calculated data, sensory data, and social data of 50 underweight, overweight, normal, and
obese volunteer subjects. The obtained results show our architecture's objectives are fulfilled.

1. Introduction
With respect to the World Health Organization, overweight and
obesity chronic diseases are delineated as “abnormal or excessive fat
accumulation that may impair health” [1]. The popularity of obesity has
reached the degree of a global epidemic. In fact, around 1.4 billion adults
were overweight and 0.5 billion adult persons were obese worldwide in
2008 [1]. The incidence of obesity has increased twice in the period
1980–2008 [1]. While obesity was associated with high-income coun-
tries, it is nowadays very common in both low-income nations and
middle-income nations. The annual health survey in the England in 2012
reported that a quarter of adults were approximately obese [2]. The
studied data in the National Health and Nutrition Examination Survey
(2009–2010) within the United States indicate that more than 2 in 3
adults were either overweight people or obese people and about
one-third of children and teenagers aged 6 to 19 were either overweight

* Corresponding author.
E-mail addresses: harous@uaeu.ac.ae (S. Harous), m_elme@encs.concordia.ca, m.elmenshawy.mohamed@gmail.com (M. El Menshawy), serhanim@uaeu.ac.ae (M.A. Serhani),
abdelgha@uow.edu.au (A. Benharref).

https://doi.org/10.1016/j.imu.2017.12.005
Received 25 September 2017; Received in revised form 3 December 2017; Accepted 5 December 2017
Available online 7 December 2017
2352-9148/© 2017 Published by Elsevier Ltd. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).
S. Harous et al.
people or obese people [3]. There are 2.8 million persons dying per year
as a consequence of overweight disease or obese disease [1]. The report
of the Government's Foresight Program states that above than half of the
UK adult persons could be obese ones by 2050 [4].
Overweight and obesity is related to more deaths worldwide than
underweight [1]: 65% the inhabitance of the world live in high and
middle income countries wherein overweight and obesity diseases cause
to die more people than underweight disease. Specifically, 44% of dia-
betes and 23% of ischemic heart disease as well as 7–41% of particular
cancers are related to obesity and overweight diseases. Obesity has an
increasing impact on public health resources [5]. In the UK, the NHS
costs related to overweight and obesity will be twice to £10 billion each
year by 2050, and the indirect costs to community and business (e.g.,
reduced productivity experienced by businesses) are estimated to reach
£49.9 billion per year [4]. In 2012, the United States Centers for Disease
Control and Prevention expected that obesity might reach 42% and might
cost $500 billion by 2030 [6].
In 2012, the Health Authority Abu Dhabi published a report revealing
that people living in the United Arab Emirates (UAE) have high rates of
chronic diseases [7]. In particular, 33% and 38% of the male and female
population have a chronic obesity disease respectively. Obese persons are
more probably to have high cholesterol level, high blood pressure, high
lipids, cardiovascular diseases, hypertension, and type-2 diabetes. This
will have an impact on life-threatening comorbidities and a burden on
health care expenses and resources. For example, the UAE categorizes as
the fifth most obese nation in the world [8] where male adults consume
around 2500 calories and female adults around 2000 calories per day.
Adults in the UAE and Qatar have been found to consume over 3000
calories per day, almost 20% above the worldwide average. The UAE
Ministry of Health had warned that most children would be obese and
44.5% of women could become obese in the next three years with less
physical activities. These rates will increase further without major life-
style changes. Although causes of obesity on a broad scale are complex,
Butland et al. [4] defined four determinants of obesity control and
treatment (a) the level of primary appetite control, (b) the force of dietary
habits, (c) the level of physical activity, and (d) the level of psychological
ambivalence. At the level of the individual person, weight gain results
primarily from excess calories resulting from the consumption of more
calories than those required and burned out of metabolic activities and
physical activity. Moreover, combining television viewing, snacking
during watching television, and computer screening time has been
obviously linked with high Body Mass Index (BMI) beside adiposity in
children ([9,10]). In summary, one of the principal causes of several
chronic diseases is the obesity epidemic in high and middle income
countries and obesity leads to an increasingly negative effect on public
health resources. Therefore, obesity and overweight have to be
controlled by losing weight and monitored to mitigate and prevent the
potential risks generated from the threat of related diseases and from
reducing productivity experienced by businesses.
1.1. Mobile health systems and current challenges
Many health-care centers have emerged in modern and developing
countries to improve health-care services and optimize medical re-
sources. The core of all these centers is the investment in modern In-
formation and Communication Technology (ICT) infrastructures to
connect directly hospitals, clinics, and healthcare organizations to make
the exchange of medical data possible. Most US health-care industries,
research, and development agencies (e.g., NIH and NRC) have engaged in
transforming healthcare ecosystems from hospital-centered to patient-
centered and actively involving patients in the process of monitoring
and accessing their health portfolios. To fight obesity, overweight, and
chronic diseases, there is a major shift in the literature towards electronic
healthcare services, which keep patients informed about their health
conditions and continuously advise them with best lifestyle practices
([11,12]). With this major shift, electronic health (e-Health) and mobile
28
Informatics in Medicine Unlocked 10 (2018) 27–44
health (m-Health) systems have been introduced to monitor, detect,
control, and prevent obesity. Such systems devote to mitigate the po-
tential risks generated from the threat of related diseases. Indeed, e-
Health is a significant and emerging domain that combines medical
informatics and public health disciplines. It refers to health-care services
and a repository of medical information in an electronic form that can be
delivered to patients over the Internet and its associated technologies
[13]. This repository allows physicians and doctors to access medical
information easily without asking patients directly [14,15]. M-Health
systems extend typical e-Health systems with a set of new promises and
benefits to patients as follows:
1. Mobile devices (e.g., smartphones, tablets, and wireless sensors) are
used widely throughout different age groups in obese populations and
provide a cost-effective platform to implement easy-to-use healthy
programs [16,17].
2. Required data might be gathered in a real-time and secure way and
meanwhile feedback can automatically and rapidly be delivered
following obese patient's measurements and activities, anytime and
anywhere [18].
3. Health and reliable telemedicine applications, interfaces, and mobile
devices can readily be tailored and personalized to receive, for
example, text messages about a weight loss management and calories
intake and consumption to control obesity.
4. Patients/users can obtain and track information that enables them to
self-monitor and access progress weight loss reports and provides
them with the resources required to begin and/or maintain healthy
behavior changes.
5. M-Health devices can visually display feedbacks, physicians' recom-
mendations on appealing screens, and introduce exciting and enter-
taining games to make obese patients experience enjoyable. Such
devices also overcome geographical and organizational barriers and
do not disturb the obese patient's normal lifestyle activities.
6. M-Health systems can leverage existing social networks of obese
peoples or establish new social networks to promote lifestyle changes.
Using social networks is one of five strategies employed in the mobile-
phone health treatments as shown in Ref. [19] as follows “1) tracking
health information, 2) involving the healthcare team, 3) leveraging
social influences, 4) increasing accessibility of medical health infor-
mation, and 5) utilizing entertainment.”
As we will show in Section 3, the current m-Health approaches range
from standalone mobile applications, mobile applications augmented
with some capabilities to mobile health systems. However, these ap-
proaches are very few and not suitable because they provide a simple and
partial solution to the obesity problem; for example, healthy diet pro-
grams alone cannot lead to weight loss. A combination of diet programs
and physical activities with a strong spirit, motivation, proper guidelines
to control the daily food intake, and behavior therapy is the most effec-
tive solution [20,21]. The success of this combination requires imple-
menting a self-monitoring system [22] that reports clearly and easily the
progress of the diet programs and produces awareness and appropriate
recommendation to the users. Also, a combination self-monitoring,
feedback, social support, structured program, and the personally
tailored program would facilitate weight loss [23].
Using m-Health systems to monitor, prevent, and control obesity and
overweight raises many challenging issues ranging from sensing, trans-
mitting, and storing intensive, continuous, and heterogeneous data.
Other challenging issues include, but not limited to, energy harvesting of
sensors and mobile devices, intermittent network connection, pre/post-
processing of collected data, seamless access to data, analysis, visuali-
zation and personalization of collected data, integration of various
technologies, and assessing trade-offs between all of these issues com-
bined together. Challenging issues linked to analyzing and visualizing big
data are not suitably addressed. For data analytics, the challenges remain
in extracting medically useful information from an array of biomedical
S. Harous et al.
time series. This process encompasses advanced data mining algorithms
and tools for data analysis that consider continuous and heterogeneous
data streams. With regard to visualization of customized data, the chal-
lenge resides in the flow of data that is massive and continuous, which
makes current techniques for data visualization not adequate to cope
with high diversity, rate, and dynamicity of data. Adaptive visualization
techniques might be utilized to summarize the data in a meaningful,
consistent, and useful manner. These techniques include on-demand
visualization, optimized and personalized display, Web-centric, and
summarized data representations. Other challenges related to obesity
community creation and management include, but not limited to, dy-
namic management of the social communities as members can join and
leave anytime, influence dissemination and maximization, awareness
propagation, an appropriate share of information, access rights, and data
privacy assurance.
2. Motivations and proposed approach
Comprehensive and preventive measures are desperately required to
control and monitor the spread of the obesity epidemic, while healthcare
systems should be organized depending on locally derived data to pro-
vide adequate and affordable care to the increasing groups of overweight
and obese people. Specifically, we aim to address the following research
questions:

How to develop a new and comprehensive mobile architecture and its
requirements to tackle the above challenges of obesity control,
monitoring, and prevention? This architecture system should help
individuals track food intake, lifestyle, calories intake, calories con-
sumption, and exercise activities. Based on the preparation and
analysis activity of the data collected from continuous monitoring
non-invasive sensors using advanced data mining algorithms, the
architecture system generates intelligent suggestions, warnings, and
recommendations to control and lower the risk of obesity and over-
weight. Access is given to the patients' medical doctor to have an
overall view of the patient history.

How to collect statistic information to be used by health adminis-
trators to have a clear and evident picture of the health condition of
the population and might help in making appropriate and intelligent
decisions?

How to develop local and global social communities to be a center-
stone medium in an overweight and obesity prevention and treat-
ment? In our approach, local social communities are created for local
chatting sessions instead of global social communities using the
Twitter accounts in specific situations/cases, such as the network
connectivity is not available, some patients refuse to discuss their
cases on global communities, and getting faster and direct suggestions
from physicians and nutritionists. These communities will include
people, their families and friends, physicians, and anyone who might
need help from the communities or who can offer positive help to the
communities' members. Also, how to analyze the opinions of com-
munities' members to make appropriate and intelligent decisions?
How to implement our architecture system as a group of Web services
and lightweight communication protocols to support interoperability and
multiple platforms? In the proposed obesity monitoring system, “intel-
ligent and appropriate decisions” refer to decisions suggested and taken
after analyzing and mining previous and current data, which is not
usually available or not at this scale of details, and comes from various
sources. Decisions are based on long-term monitoring data and contin-
uous monitoring from physicians, nutritionists, and community mem-
bers. Continuous gathering data and relaying it as soon as available and
needed within the community represents a competitive advantage that is
not available for traditional obesity controls where the patients have to
report to a hospital or nutritionist to provide data and get feedback.
The rest of the paper is organized as follows. In Section 3, we review
29
Informatics in Medicine Unlocked 10 (2018) 27–44
Fig. 1. Taxonomy of current obesity approaches.
and evaluate the current mobile health architectures and systems pro-
posed to monitor, control, detect, and prevent obesity. We present our
fundamental contributions to tackle such challenging issues in the same
section. In Section 4, the design and description of our mobile architec-
ture system are presented. In Section 5, we introduce our schemes for
reducing data and saving energy and study how to intelligently minimize
the amount of network traffic within the community of sensors. Given
that, we proceed to describe how we implemented our architecture
system as a collection of Web services to write, retrieve, and access data
to and from the cloud storage Firebase in Section 6. We evaluate the
efficacy and scalability of the implemented system using a comprehen-
sive cloud database including entered data, calculated data, sensory data,
and social cloud data of underweight, overweight, normal, and obese
volunteer subjects. Section 7 discusses the performance of the whole
architecture system. Section 8 concludes the paper and identifies the
direction for future work.
3. Related work
Hereafter, we review current approaches, identify key challenges, and
present our contribution. Before that, as described in Fig. 1, we classify
current approaches for obesity monitoring, control, and prevention into
three wide classes: Standalone mobile applications, augmented mobile
applications, and mobile health systems.
3.1. Standalone mobile applications
With the progress in mobile technologies, the adoption of mobile
devices to support obesity problem has evolved from short messages
(SMS), multimedia message services (MMS) to real standalone mobile
applications with calculation, alerting, and tracking capabilities (see
Fig. 2). In general, m-Health systems based on SMS and MMS for obesity
interventions are better than paper-and-pencil approaches as shown in
Refs. [24–27].
Among standalone mobile applications, there are several health
Android applications developed for mobile devices and can freely be
downloaded or purchased at minimum charge. MyFitnessPal,1 Calorie
Counter,2 Cardio Trainer,3 and Weight Watcher Diary4 are some exam-
ples of these applications. They are dietary assessment tools with a simple
and objective goal that is managing weight loss. These applications
complement each other with different functional requirements without
having a suggestion for a healthy diet plan. For example, MyFitnessPal
and Calorie Counter are similar in keeping track of the food intake and
Calorie Counter provides a possibility to input the physical activities.
Lee and Bakken in Ref. [25] developed a prototype of the personal
digital assistant decision-support system depend on clinical practice
guidelines for managing the obesity problem. In Ref. [28], the authors
developed a mobile application that enables users to self-monitor calorie
balance using diet programs (calorie consumption) and physical activ-
ities (calorie expenditure) in a real time. This application is a so-called
Patient-Centered Assessment and Counseling Mobile Energy Balance
(PmEB). The client side of PmEB uses Web services to register and
1
https://www.myfitnesspal.com/.
2
https://www.caloriecount.com/.
3
https://play.google.com/store/apps/details?id¼com.wsl.CardioTrainer&hl¼en.
4
https://play.google.com/store/apps/details?id¼com.canofsleep.wwdiary&hl¼en.
S. Harous et al.
Fig. 2. Current trends of mobile applications for weight loss management [22].
personalize the application and enables users to directly interact with the
PmEB system. The server side of PmEB sends updated caloric reminders
to the user, stores food intake and activity information, and keeps the
user's calorie consumption up to date. Its feasibility study is evaluated
using 15 clinically overweight participants.
Patrick et al. in Ref. [29] developed and evaluated an intervention
system based on text messages to aid a patient to lose or keep weight
within a four-month period. Such a service incorporates personalized text
messages (SMS and MMS) sent up to five-time instances per day along
with short monthly telephone calls out of a technical health counselor.
The obtained results depicted that 92% of participating patients would
advise this intervention system for controlling weight to their friends and
families. In addition, they argued that text message services could be a
good product line to provide weight loss within obese adults.
Rodrigues et al. in Ref. [30] proposed a mobile application named
SapoFit to govern obesity diseases and physical activities. The applica-
tion is indeed a daily diet diary where the user records the meals eaten in
the day to monitor in a real-time the calories are eaten by the user, and
the calories burned when the physical activity is carried out. The authors
evaluated the performance of SapoFit using various operating software
systems (Android and iPhone OS) and its usability with real users. A
self-monitoring tool designed in Ref. [31] using the Hadoop and Map-
Reduce framework that allows individuals to track their calorie of food
intakes and exercise levels, and also produces recommendations using
predictive models to reduce their risks of obesity. However, we are not
able to evaluate this approach as experimental results of using the pro-
posed tools are missing.
The authors in Ref. [22] reviewed current capabilities of mobile ap-
plications with respect to the weight loss management (see Fig. 2) and
concluded that standalone mobile applications do not support a
comprehensive proposal to solve the obesity problem effectively. From
our perspective, end-to-end activities ranging from obesity awareness to
monitoring and prevention should be developed. Moreover, the critical
review published in Ref. [32] has shown that mobile diet applications
“are not very effective for prolonged use.”
3.2. Augmented mobile applications
In the literature, some approaches have proposed to extend stand-
alone mobile applications discussed in Section 3.1 with external intelli-
gent wearable sensors beside built-in sensors to improve mobile phones'
capabilities and extend their applications as well as motivate persons
toward better health [33]. Among these approaches, Zhu et al. in
Ref. [34] introduced a system, which employs a mobile phone with an
embedded camera sensor, network connectivity, and image analysis al-
gorithms to accurately record daily foods and nutrients intake per a meal.
The objective is to use the visualization capability along with the stored
database to compare and record food intake. The acquired food images
are employed to approximate the mount of foods and nutrients depleted.
30
Informatics in Medicine Unlocked 10 (2018) 27–44
Khalil and Glal in Ref. [35] proposed a step counter application called
StepUp that uses a built-in sensor of mobile phones to count automati-
cally the number of the user's walked steps. The essential goal is to
provide the user with the possibility to measure the mount of its physical
activities per a day and to establish a good healthy competition that
serves as an origin of positive suggestions. Moreover, the StepUp mobile
application intends to improve the user's awareness about why physical
activities are important and simplify their integration into daily life. Jang
et al. in Ref. [36] presented a waist circumference measurable belt with a
5 mm resolution to determine if someone has the potential possibility for
overweight/obesity. Specifically, their system consists of magnets and
magnetoresistive sensors to measure the waist circumference. The au-
thors also developed an algorithm to distinguish the belt moving direc-
tion. In Ref. [37], a cooperative mobile application for serious games
called StarsRace is developed to enable obese persons from different ages
to play outdoors. StarsRace comprises three main perspectives. In the
therapist perspective, the therapist is able to register and monitor pa-
tients (players) and create matches along with giving recommendations.
The player perspective is indeed a mobile software application that al-
lows players to obtain instructions and to play the selected match. ECG
sensors are connected via Bluetooth to the StarsRace mobile application.
The service view is responsible for connecting, sending, receiving, and
manipulating health-care data.
The aforementioned standalone and augmented mobile approaches
[15,23,29–32,34–36] are designed as client-server architectures. These
architectures lead to system management problems, scalability, and
performance. The third class of systems in Section 3.3 aims to address
such challenging problems by proposing a multi-tier client-server archi-
tecture that separates processes (i.e., presentation, data management,
application processing, and database) to be executed on different servers
(processors).
3.3. Mobile health systems
A Body Area Network (BAN) (or Wireless Body Area Network
(WBAN) or Body Sensor Network (BSN)) can be defined as a network of
electronic devices termed sensors inside vicinity the human body or over
the human body within fixed positions. These sensors have limited power
and processing capabilities. They can make interaction with other sen-
sors and with a central node. These body sensors measure movement,
physiological data, position, etc. They also dispense medication, and
supply imaging required for poor sighted people, etc. The central node
can be a mobile smartphone, personal digital assistant (PDA), or a house
central hub. The principal goals of this network can be manifold:
Analyzing and monitoring vital signals, health monitoring (e.g., in the
hospital), and self-assessment (e.g., in sports). From our perspective,
because the central node can be a small and portable mobile device and
such networks enable patients to enjoy mobility and lifestyle, we
consider the BAN, WBAN, and BSN networks as important approaches to
S. Harous et al.
design and implement m-Health systems discussed in Section 1 (the third
class in our classification).
Among the BAN, WBAN, and BSN-based approaches, the authors
developed a WBAN network called KNOWME to detect [38] and to assess
[39] pediatric obesity using heart rate electrocardiograph monitor and
accelerometer geospatial data. The network architecture is three tiers.
The sensor tier is responsible for collecting data from heterogeneous
wearable sensors. Such sensors are coupled to the mobile phone acting as
a base station with data transmission and processing capabilities. The
second tier is a web server which receives data and carries out the
authentication process and data cleaning and scrubbing. The Web server
encrypts and transmits data to the final tier that serves as a back-end
database server. The authors experimentally analyzed data for different
key states (lying down, sitting, standing, walking and running) and
proposed a detection strategy.
The authors in Ref. [40] proposed a WBAN network architecture for
monitoring obesity diseases. The architecture consists of software and
hardware models. The hardware is four iMote2 sensors to monitor the
body motion. The sensor points are attached to hands and feet and a
computing device (e.g. a smartphone or small personal computer) acts as
a server. The sensor points are connected using a star network topology.
The software model includes the BMI calculator, personalized calories
calculator, calories adder object class, calories consumption object class,
and suggestion object class. In fact, BMI is an adequate measurement of
extra body weight and regarded as a reliable and suitable indicator of
personal weight status [1]. BMI can be estimated using the measurements
of weight and height as follows:
Weight in kilograms
Height squared in meters
Table 1 shows the standard classification of BMI [1]. For example,
when a person has BMI of 30 or more, he/she is considered to be obese.
3.4. Current limitations and contributions
In summary, all the aforementioned approaches suffer from three
main limitations (1) they only consider simple activity (assess, detect, or
control obesity), (2) they depend on a mobile phone to perform complex
processing operations on the collected data. These complex operations
need (a) efficient data mining/machine learning algorithms, which are
completely missing, (b) more memory usage and processing time, and (c)
long life mobile battery, and (3) although they used multitier client-
server architecture to replace client-server architectures, the new archi-
tecture limits the flexibility of system designers in which they have to
determine what service should be integrated firmly in each layer. De-
signers should also provide some means to servers to be replicated when
more customers are added into the system to meet scalability. While our
proposed architecture is a multi-tier one and provides a comprehensive
obesity solution, it designs the system solution as a set of interacting
services without attempting to distribute these services into layers in the
system. Each service or a set of related services is implemented using a
separate component/object. Such components provide a set of services
that might be called by other components. Therefore, designers should
focus on how to provide application functionality only in terms of ser-
vices and collection of services and how to provide these services by
using a set of distributed intelligent components.
A summary of our architecture's contributions and novelties that
addressed these limitations are portrayed as follows:
Table 1
The classes of BMI.
BMI(kg/m2) <18.5 18.5–24.9 25.0–29.9
Classification Under-weight Normal range Over-weight
Informatics in Medicine Unlocked 10 (2018) 27–44
1. Data and service integration: We develop a comprehensive architec-
ture for monitoring, controlling, preventing, and detecting obesity
that implements every entity as a service (e.g., Data as a Service
(DaaS)) without distributing these services into layers. This service
can write, retrieve, and access data to and/from cloud storage (e.g.,
Firebase) and can integrate seamlessly different obesity processes
using standard protocols that support interoperability.
2. Data visualization: Visualization involves the implementation of
different visualization profiles (e.g., physicians and patients),
customized and personalized display, device display adaptation, and
real-time data visualization.
3. Important features: We make use of a Tiny Web server, a small device
that plays the role of intermediator and has twofold objectives (1)
handling intelligently some data pre-processing on behalf of the
mobile device, which leads to energy saving of the mobile device and
minimizes its processing activities, and (2) reducing intelligently data
communicated between sensors and mobile devices. Our imple-
mentation is targeted only the Android platform.
4. Minimizing network traffic: This is realized through the data reduc-
tion scheme that delegates some pre-processing and filtering activ-
ities to the Tiny Web server. This significantly reduces data transfer
and leads to considerable network traffic minimization.
5. Data mining: We develop a set of algorithms in MATLAB to mine the
ECG signal data of obese people and to detect the ECG intervals and
peaks. Based on these mining results, physicians can make intelligent
and appropriate decisions.
6. Adaptability and scalability: Our architecture system ensures funda-
mental performance requirements (adaptability and scalability). With
regard to the adaptability requirement, we suggest energy and
resource-aware mobile-based monitoring that considers, for example,
network availability, battery drainage, mobile's CPU, and memory
availability. It also guarantees scalability property by supporting a
rising number of users, requests, and a number of services, thanks to
the use of cloud infrastructure and services.
7. High availability: To enhance the availability of our proposal, we use
various wireless technologies (e.g., Bluetooth, Wi-Fi, and 3G/4G). We
also use the cloud resources to ensure high availability. As soon as the
obese patient gets connected, the whole obesity solution is available
on the fly. When a patient is not able to connect, offline obesity
process resumes, and data is sent as soon as a connection is available.
8. Social communities: Creating local and global social communities for
obesity awareness, relevant information and treatment, and best
practices dissemination. We also implemented an algorithm to (1)
extract the most common aspects of the obesity entity, (2) extract the
sentiment words, (3) produce the sentiment database, and (4) classify
this database opinions into positive and negative opinions. Based on
these sentiment results, intelligent and appropriate decisions can
make.
It is to be noted that all complex computations are performed at
servers.
4. Mobile health architecture for obesity control, monitoring,
and prevention (MA4OCMP) description
Our MA4OCMP architecture provides a comprehensive proposal to
manage and monitor obesity data collected from continuous monitoring
sensors and social communities. Then, it applies data mining algorithms
30–34.9 35–39.9 40
Class I (Mild obesity) Class II (Moderate obesity) Class III (Morbid obesity)
31
S. Harous et al. Informatics in Medicine Unlocked 10 (2018) 27–44

and sentiment analysis algorithms to generate practical and intelligent
suggestions and recommendations. We also develop efficient schemes for
reducing data and saving energy that minimize the amount of generated
traffic and allow long-life monitoring. Moreover, exploring the cloud and
Web services capabilities will gain in space, time, and efficiency. All these
features add an asset to the system domain and advance the research in
this vital domain. Particularly, our architecture system comprises of a set
of modules, each one of which carries on a set of functionalities and
services.
Fig. 3 illustrates clearly the framework structure and the main com-
ponents of each module. These modules particularly include data sour-
ces, interfaces, data manipulation, and infrastructures. MA4OCMP
integrates different modern technologies and solutions at all level from
low-level infrastructure to high-level services and applications. The rest
of this section describes our modules along with their main roles and
responsibilities within the architecture.
1. Data Source: Data is collected from two main sources: social net-
works and sensors. Sensing devices are automatically incorporated
within the obese environment to continuously measure vital data
(e.g., posture/activity, weight, cholesterol, blood pressure, and blood
sugar) of diseases correlated with the obesity disease. Sensing tech-
nologies used to monitor these parameters include an automated
scale sensor, a cholesterol sensor, and a pedometer sensor. These
sensing devices have an interface (APIs) that allows accessing the
collected data. Based on the collected data, some other data can be
calculated (e.g., BMI and calories). However, data collected from
social networks includes sharing obesity information, awareness,
recommendations, and experiences among interesting people.
Different types of data are stored in the database server.
It is worthy mentioning that the two silos in the proposed architecture
characterize two important aspects: Security and quality of service
management (see Fig. 3). These properties should be supported at all
levels of the proposed architecture, i.e., they are held in the aforemen-
tioned four modules. Technically, security is a significant feature in the
architecture and should be supported by every single module of the
proposed solution. Protecting data collection, storage, communication,
and manipulation by applications and services is very crucial since we
deal primarily with private and very sensitive patients' health data. On
the other hand, the quality of service management involves the man-
agement of processes effectively from the lowest level modules on
differently used infrastructures to the highest-level modules on how data
is collected.
5. Monitoring scheme and sensors communication
5.1. Service model
The obesity community is closed one in the sense that interested
patients, physicians, and other members cannot freely join and or leave
the community. In fact, the community is administered by the hospital
information system administrator who first adds one or a few physicians
who will later manage membership in the community. Physicians can
then add their patients and other physicians to the community. Other
members willing to join have to make a request to the physicians. After
verifications, the membership requests can be denied or accepted, in
which case the member will be added.
Official communication between members of the social community
must happen within the community. The use of other means of
communication (e.g., social channels: Twitter and WhatsApp) are not

Fig. 3. MA4OCMP architecture components.

2. Interfaces: The architecture encompasses four interfaces. Remote Monitoring Systems are used to supervise and administer the overall monitoring activities including collected data,
released recommendations, and undertaken emergencies interventions. Physician Interface is utilized by the physician to initiate, view, and terminate monitoring as well as proposing
some recommendations (e.g., change medication dose). Emergency Response Interface is in charge of initializing an emergency reply after a severe situation happens to a patient under
monitoring, such intervention includes ambulance intervention. However, Nutritionist Interface is used by a nutritionist to suggest to the patient under monitoring food intake and
provide lifestyle habits. The system can also automatically notify physicians and/or nutritionists whenever a serious situation is detected providing the supportive data and evidence via
their interfaces.
3. Data Processing, Analytics, and Visualization: Collected data both from sensors and from social networks require some pre-processing. Social data is unstructured, and it requires to
be transformed/translated into a structured data to be ready for analysis. After data pre-processing, diverse data mining and analytics techniques can be employed to the data collected
from monitoring and from social communities. Because data is continuous, advanced analytics techniques might be employed to cope with data streams and generate insights, patterns,
and evidenced predictions. Moreover, to have a better view and interpretation of the data, we develop a module for the adaptive visualization process. More precisely, this module
visualizes statistics, history, and even predict the evolution and attenuation of the obesity problem.
4. Infrastructures: This module provides the necessary infrastructure that supports other modules of the architecture. It provides storage technologies as well as processing technologies,
such as cloud data centers, Hadoop, MapReduce, and HBase. Because we are working with large volume data streams, the integration of these technologies will support high scalability,
availability, and processing efficiency.

32
S. Harous et al. Informatics in Medicine Unlocked 10 (2018) 27–44

considered official and falls outside of the jurisdiction of the obesity
community. In this regard, the monitoring application running on pa-
tient's smartphone and the control application running at the physician
and nutritionist side represent a one-stop environment for all commu-
nication. Physician and nutritionists play an essential role in the moni-
toring process. Physicians can initiate or terminate monitoring activities
while nutritionists suggest food intake and provide lifestyle habits that
are of interest to a specific patient along with the whole social commu-
nity. During the monitoring period, the role of patients is limited to
wearing sensors and making sure they are connected to the monitoring
application running on their smartphones.
provided the available resources and the availability of internet
connection.
Energy Saving: By delegating some pre-processing activities to the
TWS device, this will remove some burden from the mobile devices that
were supposed to process the data. This will also lead to mobile device
energy saving. The device's energy is also saved by reducing the data
transmission to and from the mobile device.
The above intelligent schemes are applied to different modules of the
proposed architecture including data collection, data reduction, ana-
lytics, and visualization.
5.3. Sensors communication

5.2. Schemes A community of sensors as the one we described above can generate a
considerable amount of network traffic if the exchanged data are not
Fig. 4 describes the monitoring scheme we have developed. It tech- reduced to an appropriate minimum level. Therefore, it is very crucial to
nically involves (1) data reduction, and (2) energy saving. We have study the amount of network traffic introduced by communication within
incorporated a lightweight processing device called Tiny Web Server the community and then to minimize it. Indeed, the network traffic in the
(TWS). It is, in fact, an HTTP server implementing basic GET and POST community of sensors is generated as a result of the following three ac-
requests as well as handling dynamic content generation. The TWS de- tivities (1) sensory data, (2) practitioners' messages, and (3) intra-
vice is able to filter data, handle some processing, and relay data to a members’ messages.
mobile device and/or back-end server. It can also implement some simple
filtering techniques and host Web services to retrieve sensory data. Our 5.3.1. Sensory data
scheme considers two scenarios: Home/office based monitoring and These sensory data are collected by various attached body sensors and
mobile-based monitoring. In the home monitoring, the sensor is inter- used by community members as dictated by their physicians. The
faced with the TWS device, which is itself accessed by a back-end server collected data need to be routed towards a central back-end server for
via a group of Web services. However, in the mobile monitoring, the TWS more analysis and processing. So far, the community expects the use of
device is interfaced with sensors but accessed from a mobile device using the body sensors listed in Table 2.
a group of Web services. In the following, we depict how data reduction is A message containing a sensory data should have the following in-
fulfilled and how mobile energy is saved. formation (Fig. 5):
Data Reduction: The TWS device reduces the processing burden
from the mobile device and back-end server by filtering sensory readings
using an embedded simple filtering algorithm, and transmitting only
Table 2
relevant and non-redundant data. For mobile-based monitoring data Supported sensors and their frequencies.
reduction is done through partial data transmission (only relevant data is
Vital sign Sensor Frequency (minimum required)
send), this practice might reduce significantly the data transmitted that
can reach 40% data reduction in some situations (e.g., blood pressure Blood BP sensor 3 times/day
pressure
sensing, blood sugar sensing, and weight scale sensing) based on a set of
Blood sugar BS sensor 3 times/day
experiments we have conducted. For example, during normal physical Heart rate HR sensor 3 times/day, half an hour each, 1 reading/second
activities, the blood pressure is not expected to significantly vary to Weight Weight Once a day
require transmission of all blood pressure readings. Once a new reading is sensor
not in line with previous readings, it is transmitted. However, in the Physical Pedometer Once a day, minimum of half an hour each, twice a
activity minute
home or office monitoring, a full data is delivered to the back-end server

Fig. 4. Energy saving and data reduction using TWS.

33
S. Harous et al. Informatics in Medicine Unlocked 10 (2018) 27–44

Fig. 5. Sensory message format. Fig. 6. Practitioner's message format.

Message ID: Identifies what type of message and data this one is
carrying,

Sensor ID: Identifies the sensor source of the reading,
Fig. 7. Intra-member's message format.

Timestamp: Identifies the date and the time at which the reading was
taken, and

Value: The reading's value.
members can send the same messages as practitioners (see Table 3)
In terms of size, the message ID and the sensor ID can be represented except “Take medication” message. The format of the intra-member's
each by a single byte. The timestamp holds a year (requires 2 bytes), a message is shown in Fig. 7.
month (requires 1 byte), a day (requires 1 byte), hour (requires 1 byte), In terms of traffic, the overhead of intra-member message can be
minute (requires 1 byte), and second (requires 1byte). The value of the estimated as follows:
reading itself could be represented by three bytes, two bytes to represent  
the natural number, and one to represent the decimal part. That is, a 1 1
TrafficðMemberÞ ¼ 3 þ 3 þ 3 þ þ *9 þ 9 þ 165
single message, at the application level, consists of a stream of 12 bytes. 7 7
Every day, the typical generated traffic from sensory data could be
Let's consider a scenario of the total network traffic generated for one
computed by using the following equation as follows:
patient when half of community members (i.e., 50%) are active and each
TrafficðsensorsÞ ¼ TrafficðBPÞ þ TrafficðBSÞ þ TrafficðHRÞ one sends m messages on average during a specific day. If n denotes the
number of members in the community, the total daily traffic can be
By substituting the number of messages and the size of messages, the expressed as:
expression of daily generated traffic could be written as follows:
Traffic(Total) ¼ Traffic(Sensors) þ 2 * Traffic(Practitioner) þ n * 50/100 * m *
TrafficðSensorsÞ ¼ 3*12 þ 3*12 þ 3*30*60*12 þ 12 þ 12 þ 23012 Traffic(Member)
Therefore, the total is as follows: Where Traffic(Sensors) is as discussed above, 2 * Traffic(Practitioner)
refers to the traffic generated by a physician and a nutritionist, n is the
TrafficðSensorsÞ  64 Kbytes
number of members, 50/100 reflects half of the members are active, m
the number of messages per member, and Traffic (Member) is the over-
5.3.2. Pactitioners' messages
load generated by one message from a member. To avoid excessive in-
Practitioners (i.e. physicians and nutritionists) send and receive a
jections of messages by a specific member or a group of members, the
certain number of messages to and from their patients. So far, the com-
administrators of the community can ban such members from sending
munity supports the messages depicted in Table 3:
messages or even kick participated members out of the community. Fig. 8
The generic message is a placeholder in which a practitioner can send
illustrates how the network traffics in Kbytes evolve with the increasing
any textual description for the patient to take a specific action or to notify
number of members from 100 to 1000 where each member sends an
him/her a particular event. The maximum size of this generic message
average of 50 messages per day, there are two practitioners, and all the
can be fairly estimated to be 165 bytes, similar to the standard size of
sensors are stated as in Table 2.
SMS and a bit bigger than a tweet-size (140 bytes). A practitioner can
We can observe from Fig. 8 that the network traffic generated by
send multiple messages if the message is large and cannot be contained in
sensing activities and practitioner's messages is very minimal (see the
one generic message. Other messages in Table 3, however, can be
first two small columns where n ¼ 100). According to the above calcu-
recognized by sending a message along with a special code in the
lation, the increment of the total network traffic is very minimal. Yet,
Message-ID field of the message and with an empty “Optional message”
both the network traffic and total network traffic get a little bit high when
field (refer to Fig. 6). This makes the daily traffic generated by practi-
the community size consists of 1000 members. However, we don't expect
tioners' messages to be expressed as follows:
a patient to receive messages from 500 members in one day. Moreover, a
  patient is likely to receive messages from around 100 members in other
1 1
TrafficðPractitionerÞ ¼ 3 þ 3 þ 3 þ þ *9 þ 9 þ 165 communities during one day. Receiving more messages from more users
7 7
in addition to other social media where the patient is a registered
member of them might become overwhelming to the patient and some
5.3.3. Intra-members’ messages
important messages from our community messages may get overlooked.
One of the principal objectives of the community is to have a positive
synergy between members. This synergy is reflected through the ex-
6. Implementations and experimental results
change of encouragements and positive messages. Non-practitioner

To prove the feasibility and effectiveness of our MA4OCMP archi-

Table 3 tecture, we implemented its components and their interactions with a
Practitioners' messages. reference to obesity and overweight diseases monitoring. We developed a
Message Frequency (Average)
working proof-of-concept that we introduced to tackle the appeared
challenging issues during the implementation phase. Since we follow the
Go exercise 3 times/day
test-first principle, a standard and famous one in agile extreme pro-
Eat less sugar 3 times/day
Eat less fat 3 times/day gramming methods, we test each mobile application separately with real
Take medication 3 times/day data taken from real patients through an incremental method. At the end
Consult physician Once a week of every increment, we present our mobile application implementation to
Consult nutritionist Once a week
users and take their feedbacks. After validating our mobile applications,
Generic message Once a day

34
S. Harous et al.
Fig. 8. The network traffic of sensors, practitioners, and members.
Fig. 9. Test-bed configuration.
we test the system as a whole with real data that focus specifically on the
communications and interfaces between mobile applications. Then, we
present the system implementation to users and take their feedback/
comments and address them. Finally, we test the system including the
different mobile applications again using a template including some
interesting and technical questions, which are answered by some users
after training them. We believe that passing all these tests and consid-
ering all feedbacks give us an evidence and trust in our implementations
and support our conclusions. Moreover, our applications start with initial
values/defaults, but users can change them as they are desire and other
values are dynamic based on the calculations, mining results, sentiment
analysis, and intelligent suggestions. Before that, we begin with config-
uring our employed test-bed.
6.1. Test-bed
Fig. 9 shows the test-bed that we employed to implement our
MA4OCMP architecture. The proposed configuration makes data and
processes transparent to all involved entities. In fact, our implementation
provides the separation of responsibilities using three-tier servers orga-
nized by the model–view–controller design pattern. Specifically, all
collected data (e.g., entered, calculated, sensed, and social data) are
stored in a cloud database (Server #2 in Fig. 9). All accesses to the data
are done via Web services/cloud services, which are deployed on the
35
Informatics in Medicine Unlocked 10 (2018) 27–44
application server (Server #1 in Fig. 9). Data analytics are performed on a
separate server (Server #3 in Fig. 9) in which different processing and
analysis software tools (e.g., MATLAB) are deployed. For scalability
purposes, these servers can be made redundant through physical and/or
virtual appliances. The description of the main technologies, tools, de-
vices, platforms, sensors, and database that we have used to implement
and test our architecture system is given in the following subsections.
6.2. Systems and platforms

Servers: Intel CoreTM i7-3770K CPU @ 3.40 GHz with Turbo Boast,
32 GB of DDR3 RAM, 1 TB hard drive, and 64-bit operating system.

Web services: We implemented a group of Web services to write and
retrieve data to and from the cloud storage Firebase.

JSON (JavaScript Object Notation): It is a lightweight format for data
representation used to retrieve data from sensors to the mobile device
and from the later to a back-end server.

MATLAB: It provides toolboxes to prepare and mine ECG data, detect
ECG intervals, and visualize the analyzed results.

Tweepy: A Python library to access the Twitter API along with a set of
features.

NLTK (Natural language Toolkit): It is a Python free library needed for
sentimental analysis and natural language processing (NLP),
S. Harous et al. Informatics in Medicine Unlocked 10 (2018) 27–44

classification, tokenization, stemming, tagging, parsing, semantic Table 4

reasoning, and wrappers for NLP libraries. A fragment of calories consumption cloud database.

Food Quantity Calories

6.3. Vital sign sensors Apple 1 small (4 oz.) 80
Banana 1 medium (6 oz.) 101

ECG sensors: We used Zephyr Bioharness35. This sensor contains an Grape Each 2
Mango 1 (8 oz.) 135
electronics module that is joined firmly a chest strap. It measures,
Orange 1 (4 oz.) 71
stores, and delivers vital signal data, such as ECG, heart rate, respi- Peach 1 (6 oz.) 38
ration rate, and body orientation and activity. Pineapple 1 cup 80

Pedometer sensors: We used an Android mobile device that has a Strawberry 1 cup 53
Watermelon 1 cup 45
built-in pedometer.

Weight scale sensor: We used WeightTel6 a telemedical body weight
monitoring and management system. Table 5

Blood pressure sensor: We used Zephyr HxM heart Rate. The interface description of implemented Web Services.

Blood sugar sensor: We used iBGStar® Blood Glucose Meter.7 It is a Operation signature Description
precise meter, which gives plasma equivalent readings and requires a
Patient related interfaces These interfaces return
small droplet of blood (0.5 μL). It uses test strips which require no
getPatientList() information about patients
coding and it is integrated with an iPhone or iPod.
getPatientDetailsByPid(int PID) stored in a Firebase database.

getPatientsByGender(String Gender) Data could be retrieved by

getPatientsByAge(int AgeFrom, int AgeTo) filtering methods, specifically
6.4. Mobile devices
either by patient ID, age, or
gender.

Samsung Galaxy Grand Prime with 5-inch screen size. ECG signals related to the DaaS services These interfaces return all ECG

Samsung Galaxy Nexus 5 with 480 dpi screen size.
getECGSignalList signals or specific ECG signal for

getECGSignalListByEID(int EID) specific constraints, for example,

getECGSignalListOfPatient(int PID) per patient, per period between
6.5. Database
getECGSignalListsByDate(int PID, date specified dates. JSON is utilized
DateFrom, dateDateTo) to encode and interchange data.
We developed a dedicated cloud storage database to store all kinds of
getLastReadingbyPID(int PID)
Calories intake and consumption related to the These interfaces return foods
data of 50 subjects over three months: 10 underweight subjects, 10
DaaS services intake per day or per week,
normal subjects, 10 overweight subjects, and 20 obese subjects. Such
getFoodInTakeListByDay(int PID) calories intake per day or per
subjects are a volunteer from different places and they signed a consent to
getFoodInTakeListByWeek(int PID) week, given patient ID and list of
collaborate with us. The ages of these subjects are ranging from 18 years
getCaloriesInTakeListByDay(int PID, List food names, and calories
to 55 years, as they mentioned. This composite dataset is continuously FoodNames) consumed per a particular

getCalorieInTakeListByWeek(int PID, List physical activity or per a list of
updated whenever new data is collected, calculated or entered by the
FoodNames) activity names, given patient ID
user. It records data collected from the social communities and any pieces
getCaloriesConsumptionListByActivity(int and the list of activities. JSON is
of advice and recommendations issued for all users. It also keeps tracks of PID, String ActivityName) utilized to encode and
knowledge and best practices on monitoring, controlling, and preventing
getCaloriesConsumptionListofAllActivities(int interchange data.
PID, List ActivityNames)
obesity. Table 4 shows a fragment of calories consumption cloud data-
Social extracted data related to the DaaS services After creating a Twitter's
base (for more information, consult the 2015–2020 Dietary Guidelines
searchForTweets(int count, String patientKey, account, the first interface
for Americans [41]): String patientSecret) searches Twitter for tweets using

getPreferredWordsList(DB tweetEntities) specific keywords such as the

getSentimentAnalysis(List of extracted words) count keyword parameter,
6.6. Implementing architecture components
which constrains the number of
returned results in batches, given
Here, we describe fully the main architecture components we have the patient credentials (key and
implemented. These components include the Visualization as a Service secret). The second interface
(VaaS), Data as a Service (DaaS) module, four mobile applications, and a takes the database of tweet
entities and returns the list of
group of Web services/cloud services. extracted words. The third
interface takes this list and
6.6.1. The VaaS module classifies it into positive
The VaaS module is implemented to cope with different aspects sentiment and negative
sentiment.
including diversity of the content to be visualized, device screen size, and
customization based on profiles (e.g., physician and nutritionist). Since
data is streamed continuously from different sources (e.g., sensors) some previous readings. All these features have been implemented within the
adaptive and interactive data visualization techniques can be applied. four mobile application's interfaces, which we describe in the coming
Such techniques include incremental visualization, data fusion, data sub-sections.
stratification, and zoom-in and zoom-out features. Furthermore, design
principals were adopted to display summarized and real-time data using 6.6.2. The DaaS module
figures, 3D graphs, and tables whenever possible. Automatic visualiza- We implemented a group of Web services to aid the DaaS module in
tion adaptation to the mobile screen size of different users was also saving, retrieving, and accessing data to and from the Firebase8. The
implemented. In addition, visualization is customized depending on the Firebase is a real-time backend database that supports several features,
user's profile, for instance, physician interface includes more detailed such as encryption, authentication, and cloud data storage. For example,
information and a possibility to expand for more detailed data such as the Firebase uses the HTTPs communication protocol that supports
bidirectional communications encryption between a client and server.
5
https://www.zephyranywhere.com.
6
http://extern.bodytel.com/weighttel_en.html.
7 8
http://www.diabetes.co.uk/blood-glucose-meters/sanofi-aventis-ibgstar.html. https://firebase.google.com/.

36
S. Harous et al. Informatics in Medicine Unlocked 10 (2018) 27–44

Such services are installed and deployed on Server #1 to enable autho- patients' real data. For example, Fig. 10 shows the BMI calculation result
rized applications not only to collect and calculate data but also to access of the patient called Amira where her weight is 121 Kg and her height is
and retrieve the current as well as the past ECG data through a seamless 1.73 m. The mobile application in Ref. [30] and the WBSN framework in
method using the set of interfaces depicted in Table 5. To highly support Ref. [40] have a module responsible for calculating and displaying the
scalability and availability of data, and to benefit from the cloud storage BMI calculation.
and processing resources, we have deployed our servers in a cloud data Fig. 11 reports the results of calculating the calories of each food
center . intake and the total calories intaken per day for the patient named
Hossam Ahmed based on the request of his doctor/physician during their
6.6.3. Patient application chatting session. The WBSN framework in Ref. [40] displays only the
total calories (not for each food intake) without showing how these
The patient application essentially focuses on data entered, data calculations are made. Since our calculations are based on the
calculated, data retrieved from sensors, data collected from the social 2015–2020 dietary guidelines for Americans [41], a patient only needs to
communities, food intake entered, and information presentation (e.g., know the quantity/amount of foods intake (e.g., cup, medium, small,
calories intake and consumption and active physical activity and its etc.) per a meal. These measurements are easy for patients to report. All
calorie consumption). Specifically, mobile health systems do not provide the patient the possibility to chat

The application starts with the registration page that enables a pa- with their physicians.
tient, physician, and nutritionist to register the first time by entering Moreover, Fig. 12 reports the results of computing the physical ac-
some personal information, name, email, mobile number, etc. This tivities of the patient named Tarek Ali based on the computed total cal-
information is saved in their profiles in the database server (Server ories along with the possibility to change the assigned physical activities
#2). and their intensity and duration. All previous mobile health systems

When the application is opened, an image of the patient's gender is [29–31] reviewed and discussed in the literature do not have these
represented graphically in the background with a pink color for fe- capabilities.
male and a green color for a male.

After the patient has successfully logged in, he/she is asked to enter 6.6.5. Physician application
data (height, gender, and age) and his/her weight is sensed by the The physician application is mainly responsible for (1) presenting
weight sensor. ECG readings in a graph view, (2) presenting the mining of ECG signals,

The application proceeds to calculate automatically BMI and display (3) calculating calories, (4) producing intelligent suggestions, (5) dis-
its class (underweight, normal, overweight, or obesity classes) along playing weight loss chart, and (6) presenting habits that should be
with a horizontal bar graph reflecting the intensity of BMI. All these changed. Specifically.
data are transmitted stored in the cloud database server (Server #2).

If the physician and nutritionist are offline, they will check their
The physician application calculates calories taken per day with the
received data and notifications later. They can also make chatting help of the firebase cloud calories database.
sessions with the patient if needed.
It sends the results to the nutritionist application and sends the

The physician application alerts the patient, displays ideal weight for intelligent suggestions to the patient for calories taken and calories to
the patient, and suggests taking blood pressure (BP) and blood sugar be consumed.
(BS).
It then triggers the start of recording ECG signals.

Having the BP and BS values, the patient application sends them to
the database server (Server #2). These values can afterward be read, These functions are collected and displayed inside the navigation
updated, or deleted. block with an intuitive name and appropriate design. The detailed

Based on the physician's suggestion, the patient application starts to description of each item is introduced below.
collect daily foods intake.

The patient application also enables the patient to record the physical 6.6.5.1. Calculating calories interface. This item is divided into two tabs/
activities [42] using the pedometer sensor, select different kinds of sections as follows:
activities/exercises and their intensities, and observes the burnt
number of calories based on the exercises duration. 1. Calculating the basal metabolic rate (BMR9).

For man, BMR ¼ 10 * weight(kilogram) þ 6.25 * height(centim-
The following (see Table 6) is the cloud database fragment of physical eter) - 5 * age(year) þ 5
activities and their hourly calorie burning rates (for more information,
For woman, BMR ¼ 10 * weight(kilogram) þ 6.25 * height(-
see Physical Activity Guidelines for Americans [43]). centimeter) - 5 * age(year) - 161
2. Calculating the ideal weight (IW).
6.6.4. Experimental results and comparisons
We follow the World Health Organization (WHO) where the
As we mentioned, we follow the test-first principle. Therefore, we healthy BMI range is: 18.5 to 25 for both man and woman.
start with testing each mobile application. Specifically, we experimen-
tally tested all capabilities of the patient application using different 6.6.5.2. Mining and reading ECG interface. The graph view plots the ECG
readings coming from every sensing point on a 2- dimensional plan
Table 6
wherein the X-axis is the time and the Y-axis is the amplitude of the
Cloud database of physical activities and the related calories burning rates. signal. When the patient application finished recording ECG signals, it
sends them to Server # 3 for the data analysis purposes. Before discussing
Activity (1 h) 125 lbs person 155 lbs person 185 lbs person
this analysis, we present the relationship between obesity and ECG ab-
Walk 240 300 360 normalities. It is known that obesity is related to a several varieties of
Kayaking 300 370 440
Swimming 360 440 530
ECG abnormalities including alterations in cardiac morphology which
Tennis 420 520 620
Running 480 600 710
Bicycling 480 600 710 9
BMR is the amount of energy you require when you are just resting. Depending on the
Basketball 480 600 710
amount of physical exercise you do, you can multiply the basal metabolic rate by a specific
Soccer 480 600 710
number to determine calorie needs.

37
S. Harous et al.
Fig. 10. From left to right, the login interface, the patient profile, activities of the patient application, and BMI calculator interface.
Fig. 11. From left to right interfaces: The chatting session, the input of the foods intake, and their calories.
may cause a sudden death [44–46]. From Ref. [47], the key ECG ab-
normalities that occur with disproportionately high frequencies in obese
persons can be defined by the following rules:

The leftward shift in the P, QRS, and T wave axes: Leftward move-
ment of the mean P wave, QRS, and T wave axes from their rightward
location. This is reversible with significant weight loss. Moreover, the
axis deviation is uncommon in persons with unproblematic obesity.

Several changes in the P wave duration and morphology: There exists
a significant difference within left atrial morphology between
morbidly obese patients and healthy persons. For example, the P-
terminal force in lead V1 is  - 0.04 mm per second within morbidly
obese/overweight patients. The P-wave duration in lead II is noted
>110 ms within morbidly obese/overweight patients. In Refs.
[44,45], the authors noted a substantial decrease in P-terminal force
with significant weight loss.

Low QRS voltage: The low QRS voltage is  5 mm within the standard
leads and 10 mm within the standard precordial leads. In Refs.
[44,45], it is reported a substantial reduction in the frequency of low
38
Informatics in Medicine Unlocked 10 (2018) 27–44
QRS voltage from 13% to 2% due to a significant weight loss within
morbidly obese/overweight patients.

T-wave flattening in the inferior and lateral leads: A substantial
weight loss is related to reversal or marked reduction of T-wave
flattening within morbidly obese/overweight patients as noted in
Refs. [44,45]. In other terms, reversible T-wave flattening in the
inferior and lateral leads is normally observed in morbid obesity.

Lengthening of the QT interval: It is proven that obesity is related to
“delayed ventricular repolarization”, i.e., it is associated with the
prolongation of the adjusted QT interval or QT interval duration.
We implemented in MATLAB a mining algorithm to identify and
cluster ECG signals using the standard KNN algorithm where K ¼ 4 into
four classes representing the QT interval, the T interval, the P interval,
and the QRS interval. Then, the algorithm proceeds to compare the ob-
tained classes with the normal ones (QT ¼ 10 small boxes ¼ 0.4 s, T ¼ 2.5
small boxes ¼ 0.1 s, P ¼ 2.5 small boxes ¼ 0.1 s, QRS ¼ 2.5 small
boxes ¼ 0.1 s) and then applies some fixed interpretation rules taken
from Ref. [40] to identify the relationship between ECG abnormalities
that would adjust based on individual patients and obese patients. All
S. Harous et al.
Fig. 12. The physical activities and their choices.
these computations are carried on the data analytic server (Server # 3).
Finally, the obtained mining results are visualized in the physician mo-
bile application to help physicians in altering patients to record their
measures and making appropriate decisions, such as scheduling plans for
physical activities or recommending not to perform any physical activ-
ities according to the heart conditions of patients.
6.6.5.3. Intelligent suggestions interface. This interface is divided into two
sections as follows:
1. If the person does not suffer from heart diseases and according to
Cal2Lo, the physician can advise some:

Solutions, for example, to lose 1 pound or 0.5 kg per week, you
need to reduce 500 calories from your daily menu.

Suggestions:
Fig. 13. From left to right, all activities of the physician application, BMR, ideal weight, losing weight tabs, and weight loss chart and intelligent suggestions.
39
Informatics in Medicine Unlocked 10 (2018) 27–44
a. Try to not lower your calorie intake by more than 1000 calories
per day.
b. Try to lower your calorie intake gradually.
c. Try to keep your degree of fiber intake as well as balance your
other nutritional needs.
2. If the person does have some heart diseases and according to the
analysis of ECG signal, the physician can suggest appropriate plan
including medications, performing physical activities (see Fig. 12).
6.6.5.4. Weight loss chart interface. This interface calculates the number
of calories that should be reduced in order to maintain the ideal weight as
follows:

Cal2IW (calories to maintain the ideal weight) is equal to BMR.

CalIN (calories intake) is equal to the total summation of calories
intake per day.
S. Harous et al. Informatics in Medicine Unlocked 10 (2018) 27–44

Cal2Lo (calories to reduce) is equal ¼ CalIN – Cal2IW

Based on this calculation, we draw the weight loss chart that tracks
the amount of progress the patient is making every week within the
predetermined period. The design of this chart is illustrated in Fig. 13,
wherein the goal weight is the calculated ideal weight.

6.6.5.5. Habits to change interface. This interface displays some bad

habits that the physician needs to convey to patients as follows (see [48]
for other bad habits and more information):

One bad habit that many users share is the spending of much time in
the front of the screen (a computer screen, a television screen, or a
phone screen). Reducing time in viewing screens is a definite way to
burn more calories.

Snacking while watching the screen is a very probable method to gain
weight.

Make sure the size of portions in your daily meals is not too big.

You can eat healthy foods, but when you eat overmuch of them, the
chances of gaining weight are considerable.

6.6.6. Experimental results and comparisons

We experimentally tested all capabilities of the physician application
using different patients' data. For example, Fig. 13 reports the results of
drawing the weight loss chart of a patient named Tarek based on the
calculations of the BMR and ideal weight. In this figure, the X- and Y-
values are intelligently and dynamically calculated with respect to the
patient's weight, ideal weight, loss plan, and the screen size. Moreover,
the figure shows the solutions of the physician suggestions to Tarek: 49 h
physical activities such that Tarek has to perform 3.5 h per week for 14
weeks. Examples of these physical activities (e.g., walk, and football) are
determined through a chatting session between Tarek and his physician.
For the comparison purpose, all these capabilities are missing in current
mobile health systems.
6.6.7. Nutritionist application
Based on the patient application updated data and calculated calories
through the physician application, the nutritionist application is mainly
responsible for (1) producing intelligent suggestions, and (2) losing
weight sensibly. As in the physician application, these responsibilities are
Fig. 15. A local social community.
collected and displayed in a navigation bar with an intuitive name and
appropriate design. The detailed design description of each item is
introduced below.
6.6.7.1. Intelligent suggestions interface. In this interface, the nutritionist
reviews BMR, BMI, current weight, ideal weight, calories to consume,
and weight loss plan recommended by the physician, suggests a healthy
food plan as a notification to the patient that maintain the ideal weight,
and opens a chatting session with the patient if needed (see Fig. 14).
Moreover, when you longer chomp your food, the greater a number of
calories you absorb (see Ref. [41] for more information).

Fig. 14. From left to right, all activities of the nutritionist application, reviewing calories intake, chatting with the patient, and sending a healthy food plan to the patient as a notification.

40
S. Harous et al.
Table 7
Calories per gram of common food components.
Food Elements Calorie per gram
Fat 8.8
Proteins 4.1
Carbohydrates 4.1
Fiber 1.9
Ethanol (drinking alcohol) 6.9
Organic acids 3.1
Polyols (sugar alcohols, sweeteners) 2.4

Foods that need more efforts to chomp (e.g., fruit, whole grains, and
vegetables) cause your body combust more calories. Such calories are
needed to digest these foods and maintain you feeling fulfilled longer.

Some other foods increase calorie burning such as coffee. This is not
merely for the caffeine it included but also for other elements it
included.

Certain spices (e.g., cinnamon, chilies, and ginger) can help to burn
calories.

Recently, scientists have detected that it exists a difference positively
in weight loss or gain with a reference to the amount of the consumed
calories, not only the quantity. For example, it exists a significant
difference within exhausting 500 calories from carrots than
consuming 500 calories of popcorn—although you consumed the
same quality of energy, the 500 calories of the popcorn make you
fatter.

A healthy diet program irrespective of quantities keeps you thinner.
For example, the best diet program is to tuck within each meal five
fruits and five vegetables.
Table 7 shows the calories for each gram for common food elements
[41].
6.6.7.2. Losing weight sensibly interface. A proper weight for your size is
essentially a healthy condition. However, it will not be healthy when you
cut down too sharply on calories, do too much activity/exercise without
eating properly, or take other extreme measures. Weight should always
be gradually lost.
6.6.8. Experimental results and comparisons
As we did above, we experimentally tested all capabilities of the
nutritionist application using different patients' data. For example,
Fig. 14 reports the suggested results of the nutritionist to the patient
named Hossam Ahmed regarding consuming 1000 calories from his
foods intake per week within a period of 5 weeks based on the calculation
of BMR, BMI, current weight, ideal weight, calories consumption, and
weight loss plan. To the best of the authors' knowledge, the current
mobile health systems introduced in the literature did not consider these
capabilities.
6.6.9. Social community application
The social community application supports obese people with rele-
vant awareness and preventive information, allows them to share their
experiences and best practices, and posts their advice in the social obesity
community. It also enables the patient to post, like, comment, and to
acquire several benefits from the community members. To implement
this application, we developed:

A local social community wherein all chatting sessions between
members are saved in the cloud storage firebase for the locality
purpose (see Fig. 15).

A global social community such that all participating people must
have a Twitter account for globally sharing information, awareness,
recommendations, and experiences among interesting people over
the world.
41
Informatics in Medicine Unlocked 10 (2018) 27–44
The global social community is mainly responsible for (1) searching
and posting tweets, (2) calculating the number of followers, and (3)
presenting the sentiment analysis. As in the above applications, these
responsibilities are collected and displayed in a navigation bar with an
intuitive name and appropriate design. The detailed description of each
item is introduced below.
6.6.9.1. Searching and posting tweets interface. Every patient, nutritionist,
and physician must have a Twitter account. This account enables par-
ticipants in our system to make a Twitter chat. Generally speaking, the
Twitter chat is two types: Chat host and chat participant. A Twitter chat is
a group of Twitter users that meet at a pre-defined time to share and
discuss interests using a designated hashtag (#) in every contributed
tweet. The user can ask questions to prompt replies from participants and
to encourage interaction amongst the group. The expected problem is
that what we will do when we cannot find a chat that we are looking for.
To address this challenging issue.

We started our own one, i.e., we adopted a local host chat and defined
a clear and simple hashtag and then registered it on Twubs10. Our aim
is to provide a place wherein people can learn more about our obesity
topics.

We posted the time zone in each tweet so that anyone around the
world can join. Given that, we used the Tweetchat,11 a powerful
Twitter tool, to communicate and answer to tweets quickly.

When you are connected to your Twitter account, you can keep up
with fast Twitter chats because it modifies and refreshes in a real
time.
From the implementation perspective, we used a tweepy Python li-
brary to search for tweet entities and post tweets. However, every pa-
tient, nutritionist, and physician should create a Twitter API using a
Twitter account. The tweepy library uses the OAuth protocol to provide
authorized access to the Twitter API. It needs the consumer key, the
consumer secret, the access token, and the access token secret (refer to
Table 4): api ¼ tweepy.API(auth). The API class supports access to all
Twitter API RESTful techniques including the search method.
6.6.9.2. Calculating the number of followers interface. To create the user
object with a twitter argument, we used the following method:
user ¼ api.get_user('twitter'). This object contains the required data as
well as some methods that can be used to get the username and followers
count user.followers_count. We also get the followers' names with a
method called user.friends().
6.6.9.3. Sentiment analysis interface. Since our patients can discuss,
share, and exchange experiences, advises, and recommendations by
making use of a real-time chatting, a vast amount of opinionated data is
generated. Of course, opinions are central to all human activities as they
are fundamental influencers of human behaviors. Meanwhile, we need to
make a decision and we want to know and consider other's opinions. We
also need to analyze these opinions; therefore, we conduct an automated
sentiment analysis (it is also so-called opinion mining).
6.6.10. Experimental results and comparisons
We experimentally tested all capabilities of the social community
application. Specifically, with respect to the aspect-based opinion sum-
mary approach,12 we performed the following activities at Server #3.

We firstly searched tweets entities and extracted the most common
aspects of the obesity entity, such as (i) the use of wearable sensors,
10
Available at: http://www.twubs.com/.
11
Available at: http://www.tweetchat.com.
12
In this approach, the opinion target is decamped into entity and its aspects.
S. Harous et al. Informatics in Medicine Unlocked 10 (2018) 27–44

Table 8 Table 9
An aspect-based opinion summary. Comparison between the response times of the Firebase and Restful services.

Obesity aspect Sentiment Numbers Results Average response times

Wearable sensors Positive 1000 80% Firebase services Restful services

Negative 200 20%
ECG data with 5 s duration 50.100s 52.250s
Same kind of Foods Positive 600 42%
ECG data with 10 s duration 64.440s 67.130s
Negative 800 58%
ECG data with 15 s duration 81.227s 85.248s
Anti-obesity medicine Positive 400 66%
ECG data with 20 s duration 92.245s 96.368s
Negative 200 34%
Physical activity (Walk) Positive 1100 78.6%
Negative 300 21.4%
Table 10
Physical activity (Running) Positive 450 60%
Questions in our survey.
Negative 300 40%
Question Description

Q1 Is the platform of the mobile applications attractive?

Q2 Are the mobile applications easy to use?
(ii) the adoption of the same kind of foods for a certain period, (iii) the Q3 Is the environment of the mobile applications user-friendly and intuitive?
use of anti-obesity medicine, and (iv) the recommended physical Q4 Are the navigation options clear and consistent?
Q5 Are text blocks compacting and useful?
activity. Q6 Are fonts clear to read from the mobile screen?

We secondly extracted the sentiment words (or opinion words), Q7 Is the feedback and reply time of the mobile applications fast enough?
which are utilized commonly to express either positive or negative Q8 Is the mobile application patient helpful for physical activity and food
sentiment for these aspects. Examples of such words are great, good, intake choice and control?
Q9 Do the mobile applications aid to understand the challenging problem of
excellent, amazing, terrible/horrible, bad, worst, etc.
obesity?

We thirdly listed such words and their sentiment classes to produce
the sentiment database stored at Server #2. We divided this database
with the ratio of 9: 1 for the set of training data and the set of testing
data, respectively. That is, we adopted the leave-one-out cross-vali-
dation. We classified this list using the Naïve Bayes classifier and
finally tested the classifier.

Notice that the sentiment classification is indeed a text classification

problem and most of the above activities are accomplished with the
assistance of the NLTK Python free library.13 According to the experi-
mental results shown in Table 8, we found that (1) 80% of the obese
people are positive toward wearable sensors, (2) 42% of the obese people
are positive toward the same kind of foods, (3) 66% of the obese people
are positive toward using the anti-obesity medicine, (4) 78.6% of the
obese people are positive toward walking activity, and (5) 40% of the
obese people are positive toward running activity. The obtained results
are sent to the physician and nutritionist applications to take the
appropriate decisions such as reducing the duration of the running ac-
tivity. To the best of our knowledge, the current mobile health systems
reviewed in the literature do not support these capabilities.
7. Discussing the performance of the whole architecture system
Because the number of current mobile health architecture systems are
very few and since our architecture advances the state of the art, we add
another section to discuss the validation of our implementations. To do
that we use the test-first principle that tests all mobile applications and
the whole system with the real cloud database of 50 subjects and real
devices mentioned earlier in all the performed experiments. The
behavior of all our mobile applications performed very well wherein the
difference between actual outputs and computed outputs is negligible
(very close to zero). These experiments enabled various debugging op-
erations to verify all behaviors of the architecture system.
7.1. Performance evaluation
A comparison between the response times of the Firebase and Restful
services responsible for parsing, transmitting, and storing ECG signal
data in Server #2 with different durations was performed, provided that
the network is available. The response time results are described in
Table 9. Although the differences in the average response time values are
Fig. 16. Results of users' review and survey.
small, our firebase Web services are faster. This results from the fact that
the connection was made directly in JSON without polling. The socket
connection and the cloud capabilities offer higher flexibility, security,
and availability for all mobile applications.
7.2. User evaluation
A total of 100 users answered the survey, we have developed, to
evaluate features of the application including, for instance, the interface
conviviality, availability, and ease of use. These users are volunteer
employed in different places and they signed a consent to collaborate
with us. The users used the system for some time to test it and become
familiar with it. After the experiment, they completed the survey. Our
designed questions are described in Table 10.
As in Ref. [30], we used the Likert scale14 to answer our questions
with strongly agree, agree, tend to agree, undecided, tend to disagree,
disagree, and strongly disagree.
In Fig. 16, it can be observed that the majority of users strongly agree
with (1) our platform has an attractive design, (2) the environment is
user friendly and intuitive, (3) navigation choices are clear and consis-
tent, (4) our texts are written in minimalist style, (5) adopted fonts are
clear to read from the mobile screen, and (6) the mobile applications help
understand the obesity problem. A large percentage of volunteer users
think that our platform is very readily to employ and our mobile appli-
cations are helpful for choosing and controlling physical activity and food
intake. Moreover, in all the remaining questions, the volunteer users gave

14
For more information, you can see this documentation at: https://en.wikipedia.org/
13
Available at: http://www.nltk.org/. wiki/Likert_scale.

42
S. Harous et al.
a positive response. However, roughly half of the volunteer users were
unhappy with the mobile applications response times. As in Ref. [30], our
argument is that the response time depends on local applications func-
tionalities, such as database testing, network availability, Web server
connections, and mobile screen sizes.
8. Conclusion
The developed new and comprehensive mobile health architecture
for effectively monitor, control, and prevent overweight and obesity
epidemic and related chronic diseases and its developed business re-
quirements are the main contributions of the present manuscript. Other
silent architecture contributions are to (1) help individuals track food
intake, lifestyle, calories intake, calories consumption, and exercise ac-
tivities, (2) analyze the data collected from continuous non-invasive
sensors and local and global social communities created to propagate
awareness and share appropriate information using data mining algo-
rithms and sentiment analysis algorithms, (3) generate suggestions,
warnings, and recommendations to control and lower the risk of obesity,
(4) develop schemes for reducing data and saving energy, and (5)
minimize the amount of network traffic within the community of sensors.
Another main contribution is the full implementation of the developed
architecture system as a collection of Web services using new technolo-
gies (e.g., standard communication protocols and cloud storage Fire-
base). Our implementation is also validated using exhaustive tests with a
real-time cloud database of 50 subjects and with real devices in all the
performed experiments. The experimental results showed that 80% of the
obese people have a positive opinion about the wearable sensors. The
response time of the developed Firebase cloud services is faster than the
one provided by the Restful services. Finally, we developed a survey to
evaluate a qualitative aspect of the mobile applications. The results re-
ported that the majority of users strongly agree that (1) our platform has
an attractive design, (2) the environment is user friendly and intuitive,
(3) navigation choices are clear and consistent, (4) our text areas are
written in minimalist style, (5) adopted fonts are clear to read from the
mobile screen, and (6) the mobile applications help understand the
challenging issues of obesity and overweight disease.
For immediate future work, we plan to develop a compression algo-
rithm to compress collected data and ECG signal data before transmitting
to the back-end server in order to reduce response time and increase
network transfer speeds. We also plan to consider the portability
requirement and investigate deeply the relation between this require-
ment and other requirements achieved in our architecture, implement an
image analysis algorithm to identify foods intake and their quality and
quantity, and extend the intelligent suggestions of nutritionists with the
percentages of macro-nutrient when a patient will cook the meal by
himself/herself. Moreover, we plan to analyze and compute the time
complexity and the space complexity of the developed data mining al-
gorithms and sentiment analysis algorithms. Moreover, we plan to
formally specify our business requirements and model our architecture
system using, for example, finite state machines. Given that, we can
formally verify the soundness of the modeled system against specified
requirements with the aim to detect, repair, and delete design errors
before proceeding to the post-development phases, such as the imple-
mentation phase, to reduce the development costs.
Acknowledgement
This research work was supported by the UAEU/UPAR Grant Number
31T066.
Appendix A. Supplementary data
Supplementary data related to this article can be found at https://doi.
org/10.1016/j.imu.2017.12.005.
43
Informatics in Medicine Unlocked 10 (2018) 27–44
References
[1] World Health Organization. 10 facts on obesity. Available from:. 2014. http://
www.who.int/features/factfiles/obesity/en/ [Accessed 2017].
[2] Health and Social Care Information Centre. Health survey for England. Available
from:. 2002. http://www.hscic.gov.uk/catalogue/PUB13218/HSE2012-Sum-bklet.
pdf [Accessed 2017].
[3] USA, National Institute of Diabetes and Digestive and Kidney Diseases, Overweight
and obesity statistics, 2009–2010. Available from: https://www.niddk.nih.gov/
health-information/health-statistics/Pages/overweight-obesity-statistics.aspx.
[Accessed 2017].
[4] Butland B, Jebb S, Kopelman P, McPherson K, Thomas S, Mardell J. Tackling
obesities: future choices-project report. Department of Innovation Universities and
Skills; 2007.
[5] McCormick B, Stone I. Economic costs of obesity and the case for government
intervention. Obes Rev 2007;8(s1):161–4.
[6] Available from: USA, Centers for disease control and prevention, weight of the
nation. Press Briefing; 2012. https://www.cdc.gov/media/releases/2012/t0507_
weight_nation.html [Accessed 2017].
[7] Available from: UAE, Health authority Abu Dhabi. 2017. http://www.haad.ae/
haad/tabid/228/Default.aspx [Accessed 2017].
[8] Walpole SC, Prieto-Merino D, Edwards P, Cleland J, Stevens G, Roberts I. The
weight of nations: an estimation of adult human biomass. BMC Public Health 2012;
12(1):1–6.
[9] Andersen RE, Crespo C, Bartlett SJ, Pratt M. Relationship of physical activity and
television watching with body weight and level of fatness among children: results
from the Third National Health and Nutrition Examination Survey. JAMA 1998;
279(12):938–42.
[10] Anderson SE, Whitaker RC. Household routines and obesity in US preschool-aged
children. Am Acad Pediatr 2010;125(3):420–8.
[11] Maddalena Fiordelli NDPJS. Mapping m-health research: a decade of evolution.
Med Internet Res 2013;15(5). pp. e95–e95.
[12] Free C, Phillips G, Watson L, Galli L, Felix L, Edwards P, et al. The effectiveness of
mobile-health technologies to improve health care service delivery processes: a
systematic review and meta-analysis. PLoS Med 2013;10:1–26.
[13] Webb TL, Joseph J, Yardley L, Michie S. Using the internet to promote health
behavior change: a systematic review and meta-analysis of the impact of theoretical
basis, use of behavior change techniques, and mode of delivery on efficacy. Med
Internet Res 2010;12(1). pp. e4–e4.
[14] Kim D, Jung Y, Toh Kar-Ann, Son B, Jaihie K. An empirical study on iris recognition
in a mobile phone. Expert Syst Appl 2016;54:328–39.
[15] EL-Menshawy M, Benharref A, Serhani Mohamed. An Automatic mobile-health
based approach for EEG epileptic seizures detection. Expert Syst Appl 2015;42(20):
7157–74.
[16] Burke LE, Styn MA, Sereika S, Ewing LJ. Using m-Health technology to enhance
self-monitoring for weight loss: a randomized trial. Prev Med 2012;43(1):20–6.
[17] Burke LE, Warziski M, Starrett Terry, Choo J, Music E, Stark S, et al. Self-monitoring
dietary intake: current and future practices. J Ren Nutr 2005;15(3):281–90.
[18] Cheong S-N, Ling H-C, Teh P-L. Secure encrypted steganography graphical
password scheme for near field communication smartphone access control system.
Expert Syst Appl 2014;41(7):3561–8.
[19] Klasnja P, Pratt W. Healthcare in the pocket: mapping the space of mobile-phone
health interventions. J Biomed Inf 2012;45(1):184–98.
[20] Wu T, Gao X, Chen M, Dam R v. Long-term effectiveness of diet-plus-exercise
interventions vs. diet-only interventions for weight loss: a meta-analysis. Obes Rev
2009;10(3):313–23.
[21] Curioni C, Lourenço PM. Long-term weight loss after diet and exercise: a systematic
review. Int J Obes 2005;29(10):1168–74.
[22] Yusof AF, Iahad N. Review on online and mobile weight loss management system
for overcoming obesity. In: Proceedings of the international conference on
computer & information science (ICCIS); 2012. p. 198–203.
[23] Khaylis A, Yiaslas T, Bergstrom J, Gore-Felton C. A review of efficacious technology-
based weight-loss interventions: five key components. Telemed J E-Health 2010;
16(9):931–8.
[24] Woolford SJ, Clark SJ, Strecher VJ, Resnicow K. Tailored mobile phone text
messages as an adjunct to obesity treatment for adolescents. J Telemed Telecare
2010;16(8):458–61.
[25] Leea Nam-Ju, Bakkena S. Development of a prototype personal digital assistant-
decision support system for the management of adult obesity. Int J Med Inf 2007;
76:S281–92.
[26] Carter MC, Burley VJ, Nykjaer C, Cade JE. Adherence to a smartphone application
for weight loss compared to website and paper diary. Med Internet Res 2013;15(4).
pp. e32–e32.
[27] Acharya SD, Elci OU, Sereika SM, Styn MA, Burke LE. Using a personal digital
assistant for self-monitoring influences diet quality in comparison to a standard
paper record among overweight/obese adults. Am Diet Assoc 2011;111:583–8.
[28] Available from: USA, center for disease control, overweight & obesity. 2011. http://
www.cdc.gov/obesity/index.html [Accessed 2017].
[29] Patrick K, Raab F, Adams MA, Dillon L, Zabinski M, Rock CL, et al. A text message-
based intervention for weight loss: randomized controlled trial. Med Internet Res
2009;11(1):e1.
[30] Rodrigues JJPC, Lopes IMC, Silva BMC, Torre I d L. A new mobile ubiquitous
computing application to control obesity: SapoFit. Inf Health Soc Care 2013;38(1):
37–53.
[31] Govindarajan R, Madan S, Shetty A. Hadoop-based obesity monitoring system.
Technical Report. San Jose State University; 2011.
S. Harous et al.
[32] Yusof AF, Iahad NA, Omar AH. Critical approaches in the design of a mobile phone
diet application for prolong use. Int J Innov Comput 2013;3(2):28–36.
[33] Patel MS, Asch DA, Volpp KG. Wearable devices as facilitators, not drivers, of health
behavior change. J Am Med Assoc 2015;313(5):459–60.
[34] Zhu F, Bosch M, Woo I, Kim S, Boushey CJ, Ebert DS, et al. The use of mobile
devices in aiding dietary assessment and evaluation. IEEE J Sel Top Signal Process
2010;4(4):756–66.
[35] Khalil A, Glal S. StepUp: a step counter mobile application to promote healthy
lifestyle. In: Proceedings of the international conference on the current trends in
information Technology (CTIT); 2009. p. 1–5. Dubai, United Arab Emirates.
[36] Jang Y, Shin S, Kim S. A basic study for automatic waist circumference
measurement using magnet with waist belt to assist obese management in daily life.
In: Proceedings of the 30th annual international conference of the IEEE engineering
in medicine and biology society; 2008. p. 2333–6.
[37] AL-Qurishi MS, Mostafa MA, Alrakhami MS, Alamri AM. StarsRace: a mobile
collaborative serious game for obesity. In: Proceedings of the IEEE international
conference on multimedia and expo workshops (ICMEW); 2014. p. 1–5.
[38] Annavaram M, Medvidovic N, Mitra U, Spruijt-Metz D. Multimodal sensing for
pediatric obesity applications. In: Proceedings of the international workshop on
Urban, community and social applications of networked sensing systems; 2008.
p. 21–5.
[39] Lee S, Annavaram M, Thatte G, Spruijt-Metz D. Sensing for obesity: KNOWME
implementation and lessons for an architect. In: Proceedings of the workshop on
44
Informatics in Medicine Unlocked 10 (2018) 27–44
biomedicine in computing: systems, architectures, and circuits (BiC2009); 2009.
p. 1–4.
[40] Alrajeh N, Lloret J, Canovas A. A framework for obesity control using a wireless
body sensor network. Int J Distrib Sens Netw 2014:1–6.
[41] 2015-2020 Dietary Guidelines for Americans. Available from: https://health.gov/
dietaryguidelines/2015/guidelines/message/. [Accessed 2017].
[42] Sanchez-Valdes D, Trivino G. Linguistic and emotional feedback for self-tracking
physical activity. Expert Syst Appl 2015;42(24):9574–86.
[43] Physical Activity Guidelines. Available from: www.health.gov/paguidelines.
[Accessed 2017].
[44] Alpert M, Terry B, Cohen M, Fan TM, Painter J, Massey C. The electrocardiogram in
morbid obesity. Am J Cardiol 2000;85:908–10.
[45] Alpert M, Terry B, Hamm C, Fan TM, Cohen M, Massey C, et al. Effect of weight loss
on the ECG of normotensive morbidly obese patients. Chest J 2001;119(2):507–10.
[46] Lavie CJ, Amodeo C, Ventura HO, Messerli FH. Left atrial abnormalities indicating
diastolic left ventricular dysfunction in cardiopathy of obesity. Chest J 1987;92:
1042–6.
[47] Diagnostic in obesity comorbidities: obesity and the electrocardiogram. J Obes Rev
2005;6:275–81.
[48] Y. Kato, T. Suzuki, K. Kobayashi and Y. Nakauchi, Comparison of dietary
information logging methods for obesity prevention system, in Proceedings of the
IEEE/SICE international symposium on system integration, Japan, December 16-18,
2012.