Continuous physical health monitoring and
classification for distress detection
Daniela Crăciun
Department of Computer Science
Babeș-Bolyai University
Cluj-Napoca, Romania
craciundaniela19@gmail.com
Abstract— This paper introduces a system which can aid in
monitoring people with mobility issues or with various health
problems. The aforementioned system offers a web-based visual
interface for the user to input data about the individual they
want to monitor. It also employs a prediction-powered service,
which uses a locally stored model trained with a random forests
algorithm to return the predicted activity level. Physical and
environmental data retrieval is done by a heart rate sensor and
movement sensor unit. The first one retrieves heart rate
measurements continuously during the day, while the second one
provides accelerometer and gyroscope data and performs a
regular check to detect if fall events occur. The data from both
sensors is synchronized by the main unit based on timestamps.
During the research of this topic, a considerable amount of data
processing has been performed on the set of information. We also
provide a comparison with similar studies that aimed to develop
a monitoring system.
Keywords—heart rate; sensor data; classification; random
forests; data processing; activity level;
I. INTRODUCTION
Supervising the daily activity of elders can help people
responsible for their care in improving their life quality,
especially when they are dealing with a limited ability to move.
The need for such an activity monitoring system is accentuated
by the decline of worldwide mortality [1], which will result in a
high number of disabled individuals with mobility issues that
require support. This type of system can also aid in monitoring
persons affected by chronic diseases such as arthritis,
neuromuscular disorders or other physical impairments.
Another issue that frequently affects old people is the risk of
falling and the long term impact this event can have on their
health. One in every three elders is estimated to fall one or
more times during the span of a single year [2]. Such an
accident might not result in immediate injury, but it can be
succeeded by a “long lie” (a period of lying on the ground
unwillingly after the fall for more than an hour) which can
induce unexpected complications such as internal bleeding or
even death [3]. Even though alarm systems which can be
manually triggered by the person falling are widely available,
many of them do not use them. Further insights reveal that they
are reluctant in being classified as at high risk for falling and
mostly have confidence in their ability to get up unassisted [4].
Consequently, an automated system that requires no interaction
with the person being monitored is ideal to keep sick, old or
disabled persons safe.
A system that aims to monitor physical activity and other
vital signs must be comfortable enough so that it can integrate
seamlessly into the daily activities of the wearer. Since physical
data tracking devices have become cheaper and more accurate
over time, they can provide some informational input about the
status of a person while still being relatively easy to obtain and
set up. Recent studies have compared consumer-level activity
monitors with research-grade devices in terms of accuracy and
validity of data. While the energy expenditure measurements
were not satisfying, the correlation between research-grade and
consumer-level gadgets heart data was high enough to be
deemed valid and can be used with moderate reliability for
predicting user status [5]. Other challenges that arise when
designing and implementing such a system are to ensure that
critical information is quickly forwarded with minimum to no
delay.
This paper proposes a possible structure and functional
specification for the previously described approach. The
system is comprised of multiple components, which will be
addressed as units in the rest of the paper. Each unit can
perform its specific tasks independently, without relying on
another unit. There are two units which provide sensor-based
data: the movement and the heart rate monitoring unit. The
main application, which provides the routing between all the
different components, awaits data from the previously
described units. It also acts as a back-end for the visual
interface used by a carer. The prediction unit is where a trained
model that classifies input resides.
It is very important to mention that the system in its current
state should be used mostly for informational purposes and not
as an actual medical diagnostic tool. The provided indications
and alerts are general recommendations based on experts’
knowledge while using devices available to the general
consumer. Also, the application should not be used to invade
someone’s privacy; the person monitored must consent to it.
This disclaimer should also be presented to the user and needs
to be read and agreed to upon registration.
The paper is organized as follows: in Section II, we present
different approaches to build a system similar to ours and how
they relate to our proposal. In Section III, a succinct theoretical
background is provided to ensure complete understanding of
the following parts. Section IV details the proposed approach,
and finally, Section VI draws the conclusions of this paper
while also outlining ideas for future work.
 II. RELATED WORK
The topic of remote monitoring for elders or individuals
with other issues who require assistance has been covered by
several papers ever since wearable devices for tracking health
metrics have become more widely spread, but most methods
that are already proposed do not offer a larger range of
information processing, most of them focusing on activity
level, heart rate or fall monitoring separately, not all of them
enclosed in a single multi-purpose system.
A method similar to the one proposed in this paper is
introduced in the article [6], which uses a comparable
architecture and is built on the same mindset: low latency and
high efficiency. One of the core differences between our system
and the one mentioned previously is the comfort aspect. We
aim to provide crucial data like fall detection and heart
irregularities, while still providing an accessible and easy way
to do so. The other system requires a chest harness which is
definitely not suitable for daily wear. This harness might prove
problematic in the case of people with breathing issues, who
may feel restricted. When a monitoring system is
uncomfortable, the wearer is much more likely to ignore the
benefits and simply remove it. Another system of similar
structure [7], running on the PAMAP2 dataset (also considered
by us in this paper) aims to detect physical activities but is not
focusing on care for elders and disabled individuals. It also
ignores the heart rate attribute, choosing to focus only on the
movement measurement because it is designed to detect human
physical activity.
Some other systems aim to provide ECG monitoring [8],
which is useful in a medical setting, but users may not always
have the required training to process and understand the offered
data. Our tool aims to offer vital information in a visual, easy
to understand format, which helps individuals (with or without
formal medical training) intervene as fast as possible in case of
emergency.
There are also some systems that try to detect falling using
different sensor data with thresholding techniques. Most of
them detect the shock received by the body on impact. For
example, in [9] accelerometer telemetry is used in different
regions of the body (at the trunk, sternum, anterior of the thigh
and midpoint of the femur) and two different experiments are
held, one with young people performing controlled falls and
one with elders while performing their daily activities,
managing to obtain a 100% accuracy with the sensor on the
trunk. The previously mentioned fall-detection system does
not include heart rate into measurements, which we integrate to
provide a wider range of details about status.
III. THEORETICAL BACKGROUND
This section provides a theoretical primer regarding the
machine learning based technique used to predict the activity
level. Firstly, the random forest algorithm is formally defined.
Then, a short technical introduction is done on IMU (inertial
measurement unit), to better understand how data is mined and
forwarded from a device which contains this type of unit.
A. Random forests
This section aims to introduce the random forest algorithm,
an ensemble approach which was first introduced in [10]. It is
described as an aggregation of decision trees in such a way that
each tree depends on the values of a random vector sampled
independently and with the same distribution for all trees in the
forest.
Ensemble methods rely on groups of weak learners to
improve performance. Each classifier is weak individually, but
when they come together they form a strong learner. Ensemble
methods are usually split into two types: averaging and
boosting methods. In averaging methods, the base principle is
to build multiple estimators and then to average out their
predictions. The random forest algorithm fits in this category.
In contrast, the boosting methods build estimators gradually,
while one of them tries to reduce the bias of the final ensemble.
In the random forest case, the weak learner is each decision
tree, also called stump. Decision trees classify input by
traversing it down from the root to some leaf node based on a
comparison between them. Each node in the tree is, in fact, a
test for the attribute of the instance which needs to be classified
[11].
Such a system is trained by using the following process: N
random samples are generated to create a subset of the data.
Then, for each node, m predictor variables are selected at
random from all the predictor variables. The one that provides
the best split, according to a defined function (usually the Gini
impurity criterion [10]), is used to do a binary split on that
node. At the next node, other m variables are chosen and the
process repeats, as seen in Figure 1.
Figure 1. Overview of a random forest
When splitting nodes, the algorithm used is
fundamental. The Gini impurity criterion only works on
categorical values and performs binary splits, that is why it is
not ideal for situations where the value to predict is numerical
or the problem is of a multi-class nature. For these cases, the
other type of split that can be used is entropy (also called
information gain).
The Gini criterion involves the selection of two random
items from a population and imposes the condition that they
must be of the same class. The probability of this is one if the
population is pure (meaning that all of its elements belong to
the same class). Conversely, if a sample is homogeneous, the
entropy is zero, since it gives the level of impurity.
B. Inertial Measurement Units
The IMU was made known in 1985 when a patent was
introduced. It is initially described as a unit which provides
three-axis acceleration and angular rate detection (using a
gyroscope) [12]. Most modern smartphones embody this type
of sensor, which is capable of providing user position, among
other measurements. Recent performance evaluation done on
innovative sensor technologies provide good results regarding
their reliability [13].
An IMU usually employs accelerometers, gyroscopes and
sometimes also magnetometers. In flight dynamics, three
principal axes are defined: pitch, roll, and yaw. The vertical
axis (yaw), is drawn from top to bottom, perpendicular on the
other two. The lateral axis (pitch), runs from left to right, while
the longitudinal axis (roll) is traced from front to back. A
detailed visualization of the concept is presented in Figure 2. It
is promptly observed that the system resembles a mathematical
three-dimensional Cartesian system, and IMU tracking is built
on the same principles [14].
Figure 2. Overview of IMU axis
IV. PROPOSED APPROACH
The system proposed revolves around a key relationship:
caregiver and care receiver. The caregiver is an individual with
an interest in keeping track of the health of another person, the
care receiver. The care receiver is assumed to be a person with
limited mobility or other illnesses, who needs constant
monitoring.
Analysis on heart rate measured in beats per minute is
becoming very popular since it is noninvasive and practical. A
difficulty it brings is identifying if the value fluctuation is
caused by physical or mental activity. A possible solution
would be taking movement sensor data into account when
trying to determine the activity level of an individual, therefore
increasing the complexity of the algorithm which performs the
processing while increasing the chance of a more accurate
prediction.
A. Architectural overview
As mentioned previously, the proposed system employs
four major components that operate individually. The main web
application provides an intuitive and easy to use interface to the
user while joining and displaying data it receives from the
other components.
The heart rate and movement sensors both send data to
the main web server, which in turn sends it to the prediction
unit and waits for a response. For optimal results, the
movement sensor needs to be securely strapped on the trunk
and the heart rate sensor needs to be properly fixed on the
surface of the skin so that both can accurately detect needed
information. The system will still function without one of the
aforementioned sensors, but will not be as informative. The
movement component can be any type of device that has the
ability to retrieve 3D magnetometer and accelerometer
measurements and is able to make HTTP calls to a specified
server. We use a mobile phone with an application designed for
this purpose. The heart monitoring component needs to be able
to keep track of heart rate in BPM (beats per minute) and the
time at which this measurement occurred. The device used by
us for this purpose is a Fitbit Charge [15] fitness band, which
sends information to a remote Fitbit server from where we
retrieve it.
As the heart rate sensor and movement sensor send
measurements autonomously, synchronization issues arise.
While one of them might continuously read and consequently
send data input, the other one may be out of order temporarily,
experiencing connection issues or have timeout periods.
Pairing them together as they come would be improper, mainly
because as delays get larger, couples of heart rate and
movement input will not accurately represent the state of a care
receiver at a given time. The solution proposed is to use a
formula with an adjustable threshold to balance the two sensor
measurement from a temporal perspective, as described by
equation (1):
|thtm|h 
where th represents the timestamp of the heart rate
measurement in seconds, tm represents the timestamp of the
movement measurement in seconds and h represents the
acceptable difference between the two. Since heart rate is
measured in beats per minute, it is assumed that a heart rate
measurement is valid for at least 60 seconds. Measurements are
stored separately in a database, and whenever a prediction is
requested the latest heart rate and movement are fetched and
compared using the above-mentioned formula. After grouping
sensor data together, other corresponding details about the
current care receiver are retrieved (which are added in the
application by the caregiver) and added to the set of
information, which will be then sent to the prediction unit.
Also, if h seconds have passed and no new heart rate
measurement is available, the caregiver will be alerted that the
information is not actual and that they need to check if the
device used for heart rate monitoring is synced with the
application server, properly placed and activated. In our case,
the Fitbit device synchronizes with the server once every 15
minutes (or faster, if synchronization is performed manually)
and the phone sensors retrieve data a few times each minute.
Regardless of the heart measurement, the prediction is still
performed (and the heart rate attribute is imputed as 0 since our
algorithm can handle sparse data).
 The unit that predicts the activity level is a web
application that exposes a single route, which awaits a JSON-
type message of a certain structure and uses a previously
trained model with a random forest algorithm using the
PAMAP2 dataset [16]. The model is stored in a static file in the
project root, making retrieval and prediction relatively easy,
without the need of performing costly operations which
increase waiting time and thus delay information delivery to
the caregiver. False positives are acceptable since at most they
require some additional interventions from the caregiver, which
cause a minimal discomfort without being threatening, while
false negatives are dangerous and should not happen.
Figure 3 describes an overview of the general architecture
of the system. It is observed that the sensor retrieval unit is
specific to our use case, but it is definitely replaceable with
other components that can conform to the specifications
imposed.
1) Feature selection
The first step in selecting attributes to use further is
deciding how suitable it is to our needs and how easily it can
be retrieved.
The PAMAP2 dataset retrieves data from three sensors
placed on the hand, trunk, and leg. While wearing many
sensors is appropriate in a research environment, it is not
convenient in daily monitoring. For that reason, we need to
determine which one of the three sensors mentioned before
provides the most accurate result and has a considerable
influence on the prediction.
A conclusion reached by studies that implement fall
detection with thresholding techniques is that the trunk is the
most suitable area of the body to place a sensor because it
yields the most accurate results, this being explicitly
mentioned in [9]. We also keep only the trunk measurements
for further training of the predictive model.
Another problem is the diversity of activity
classification provided by the dataset. Table 1 provides the
entire range of activities by their corresponding identification
in the dataset.

TABLE I. ACTIVITY DETAILING

ID Activity
0 Transition activities
Figure 3. Diagram of the system
1 Lying

2 Sitting
B. Dataset choice
The PAMAP2 dataset [16] is comprised of data retrieved 3 Standing
from 9 human subjects (one female and eight males), each 4 Walking
subject wearing three inertial measurement units and a heart
rate monitor. Each IMU measures temperature and 3D data 5 Running
from accelerometer, gyroscope, and magnetometer. Subjects 6 Cycling
wore one IMU on the dominant wrist, one on the dominant
7 Alert walking
ankle and one on the trunk. The complete dataset contains
2872532 rows of measurements, each containing 54 values. 9 Watching TV
We are using a subset of the data (from a part of the subjects)
10 Computer work
for faster training. Our subset has 942905 rows and 11
columns used for the final trained model. 11 Driving a car
This dataset was chosen mainly because the attributes it
12 Ascending stairs
contains are easy to retrieve in real life situations and do not
require special equipment. The activities it includes are 13 Descending stairs
diverse, from lying, sitting, standing, walking to running,
16 Vacuum cleaning
ascending and descending stairs. Transition activities and
activities irrelevant to our scope (as described in the following 17 Ironing
section) were discarded.
18 Folding laundry
C. Data processing
19 General house cleaning
The dataset used in our case is extensive, but it is not
feasible for usage in real life situations. Consequently, some 20 Playing soccer
analysis has been performed to select the features which
impact the final results the most. The dataset also presented a 24 Rope jumping
large amount of undefined data, which needed a method of
handling. Since we are only interested in tracking the level of
activity instead of a specific activity, we use an energy
expenditure chart to reduce the extent of classification. In [17],
a category is specified for a certain action by energy
expenditure, as seen in Table 2, based on which replacement is
done in the original dataset. For each level of activity
intensity, we use a corresponding label as seen in Table 3.
TABLE II. ACTIVITY MAPPING BY INTENSITY
Intensity level Activities
Lying, Sitting, Standing, Walking, Watching TV,
Light Computer work, Driving a car, Ironing, Folding
laundry.
Alert walking, Descending stairs, Vacuum cleaning,
Moderate
General house cleaning.
Running, Cycling, Ascending stairs, Playing soccer,
Hard
Rope jumping.
TABLE III. DATASET VALUES FOR ACTIVITY LEVEL
Intensity level Dataset value
Light 1
Moderate 2 another randomly selected value from another row, within the
Hard 3 same column. After applying these methods on the PAMAP2
Afterward, the dataset was extended with four additional
attributes: height, weight, age, and sex. These details were
extracted from the dataset documentation, which contains a
table with additional subject information. After these
adjustments, the final feature importances can be observed in
Figure 4. Since the personal details have very little
significance on the end result, they are discarded as well.
Figure 4. Feature importances
We have the following corresponding labels in Figure 4:
• accelx, accely and accelz represent the X-axis, Y-
axis and Z-axis measurements for the accelerometer;
• gyrox, gyroy and gyroz represent the X-axis, Y-axis
and Z-axis measurements for the gyroscope;
• magnetox, magnetoy, magnetoz are the X-axis, Y-
axis and Z-axis measurements for the magnetometer;
• hr represent the heart rate measurements in BPM;
• weight represents the weight in kilograms;
• height represents the height in centimeters;
• age represents age in years;
• sex is 0 for male and 1 for female.
When computing feature importance, in the case of the
random forests method, the process usually starts from a
single tree and is then applied to all the trees in the ensemble.
Each feature importance is computed as the sum of the
number of splits (across all trees) that include the feature,
proportionally to the number of total splits. The sum of all the
feature importance values should be one. For example, it could
be said that the magnetoz feature has been the basis of 14% of
all splits in the tree.
2) Data transformation
Handling missing data can be a challenge. First, the data
needs to be identified in the dataset.
A problematic attribute in the PAMAP2 dataset was the
heart rate, which was missing in 856775 rows. We need to
determine whether dropping the rows which do not contain a
value or imputing their value will provide us with a better
accuracy.
When imputing a value, many methods can be used:
using a constant value (such as zero), compute a mean or use
dataset and verifying the optimal approach is to replace every
NaN value with zeros.
D. Fall detection
Physical activity, exercise, and physical fitness are related
terms that characterize different concepts. They are often
confused with one another, even if they have distinct
definitions. Physical activity denotes general body movement
that results in energy output and is not structured and planned
with the purpose of increasing physical fitness, as opposed to
exercising [18]. Traditional treatment recommended in
hospitals is total bed-rest for a wide range of ailments, after
which patients might suffer from general weakness, delirium
and muscle atrophy. This can be avoided by ensuring that the
patient performs some therapeutic exercise tailored to the
illness level manifested while their physician or someone else
is able to monitor their well-being [19]. Safety can be ensured
by detecting a fall that may occur.
An important aspect when detecting falls is that it
should be done as fast as possible, without further processing
of the data. When additional agents for data sending and
retrieving are added, latency is increased and that is
undesirable when a situation of emergency occurs. That is
why, for the purpose of this application, we have chosen to
detect the falling directly on the data retrieving device and
create a one-way channel to announce the falling, ensuring
that this situation is quickly signaled to the end user.
The system uses a very straightforward method for
detecting the fall: calculating the total acceleration and the
rotational rate for multiple movement states and trying to fit
them between two threshold measurements [20]. The total
acceleration magnitude and the aggregate rotational rate is
obtained by using equations (2) and (3):

(2)
(3)
where ax, ay, and az, respectively ωx, ωy and ωz represent
measurements along the three axes (x, y, z), corresponding to
the sensor frame of a 3-axis accelerometer and gyroscope-
equipped on phones or other devices. Our situation requires
the detection of a fall event, with situations of misinterpreting
daily activities as falls inappropriate but acceptable and not
detecting actual falls as unacceptable.
According to [9], who performed 240 falling
experiments, the UFT (upper fall threshold) for a sensor
placed on the trunk is 3.52 and the LFT (lower fall threshold)
is 0.41. This method’s simplicity makes it ideal for situations
where limited computing power is available (in the case of
smaller sensors).
For our current system, we have developed an Android
application which mines raw sensor data and forwards it to our
main application server. To ensure that the connection between
the 2 units is performed for the required patient, a secret key is
generated by the main application. Any device (including the
mobile application mentioned before) needs to include the
secret key in their payload so that the data sent will be stored
for the right care receiver.
E. Expert rules for heart status
Heart rate tracking is important, especially if there is a prior
condition or a genetic predisposition to heart disease or other
ailments. Heart-rate can easily be categorized as normal or not
by various methods: concluding where the measurement falls
relative to lower and upper bounds by some range tables by age
[21] or using an equation to identify expected heart rate by age
and compare measurements with that [22].
A downfall for the chart methods is that the base of all
measurements is the RPR (resting pulse rate), while the second
one only measures the maximum heart rate. Our application
receives measurements during the day while resting and while
being active. Consequently, we need to combine these two
methods and compare with our activity level discovery. If the
care-receiver is performing some higher or moderate intensity
activities, we use the maximum heart rate formula to conclude
if the current heart rate is appropriate. Otherwise, if the care-
receiver is performing low-intensity activities or resting, the
heart rate gets checked by the RPR chart.
The formula proposed by H. Tanaka et al. [22] is
described in equation (4):
hrmax = 208 - 0.7 * y 
where hrmax represents the maximum heart rate and y
represents the current age of the care-receiver in years.
The ranges used by the application to report heart rate
status can be seen Table 4. This representation is a shortened
and compressed version (due to cohort and general activity not
being objects of interest in our application) of the one
developed by J. Hart [19] as a result of his studies. Another
important aspect is the correlation with the activity level. If the
positioning sensor is not connected to the application, then the
detection of the activity level is deactivated. In this case, the
threshold-based system only uses the ranges mentioned in the
table above to reach a conclusion. It will certainly not be as
accurate, but it is still helpful.
TABLE IV. HEART RATE RANGE RULES
a
Age Female Male
18 to 25 54 to 85 49 to 82
26 to 35 54 to 83 49 to 82
36 to 45 54 to 85 50 to 83
46 to 55 54 to 85 50 to 84
56 to 65 54 to 85 51 to 82
Over 65 54 to 85 50 to 80
a. correlated with activity
The system expresses expert rules that capture situations
and reply with different alerts based on the knowledge
registered into the system. The small numbers of rules and
reduced amount of specialized human knowledge make this a
minimized expert system. The rules previously mentioned
consist of defining heart ranges as thresholds based on which
heart rate status is stated.
V. EXPERIMENTS
To evaluate the performance of our trained model, we used
a subset of the PAMAP2 dataset, which was not included in the
training subset. This subset has 232776 rows and 11 columns.
Preprocessing of the data has been performed as described in
Section 4.
The experiments for this paper consist in hyperparameter
optimization, which entails the choice of parameters for the
purpose of obtaining better performance. The random forest
algorithm has the following important parameters (among
others) which support adjustments:
• n_estimators: number of trees in the forest
• max_features: the number of features to consider
when looking for the best split
• max_depth: the maximum depth of a tree
• min_samples_split: number of samples required to
split a node
We perform an exhaustive search over the parameter values
mentioned in Table 5, expecting to find the parameter pairing
that provides the best results for our problem. This will result
in 16 candidate models being built and trained (since every
parameter needs to be paired with all the others in the search
grid), then cross-validation with 3 folds is used to measure
their performance, resulting in 72 fits in total.
 TABLE V. HYPERPARAMETER VALUES algorithms are used for classification: KNN (k-nearest
n_estimators 15 20
neighbors), rotation forest and NN (neural networks) and the
results obtained are 70%, 94% and 89%, respectively. Other
max_depth None 5 papers from tangent fields have used the PAMAP2 dataset as
min_samples_split 2 3 well, with better results. In [23], BP (back-propagation) neural
max_features sqrt(n_features) log2(n_features) networks and additional data processing are used to obtain an
accuracy of 93%. A comparison between the algorithms
After the fitting, we get the first 5 pairings sorted by mentioned before and ours in terms of accuracy is presented in
accuracy as observed in Table 6. The entire fitting took 1 hour Table 7.
and 10 minutes.
TABLE VII. CLASSIFIER ALGORITHM ACCURACY COMPARISON
TABLE VI. BEST 5 PARAMETERS PAIRING BY ACCURACY
Activity classifier Accuracy
min_samples K-Nearest Neighbors 70% a
n_estimators max_depth max_features accuracy
_split
Rotation Forest 94% a
20 None 2 sqrt(n_features) 86%
Neural Networks 89% and 93% b
a
20 None 3 sqrt(n_features) 81%
10 5 3 sqrt(n_features) 79% Random Forests 91%
20 5 3 log2(n_features) 71% a. as seen in [7]
b. as seen in [23]
10 5 2 log2(n_features) 67%
VI. CONCLUSIONS AND FUTURE WORK
The highest accuracy obtained is 86% on the first row, so
Since this application was designed as a proof of concept
those are the final hyperparameter settings used further when
rather than a finite product, there are many ways in which the
building a model. We use a forest of 20 trees and set no
features provided can be extended and enhanced, or even
maximum depth of the tree, nodes being expanded until all
additional features can be easily integrated. A first step in this
leaves contains less samples than min_samples_split, which is
direction would be more tuning of the classifier in order to
two. The number of features considered for looking for a tree
obtain better accuracy.
split is the square root of the number of features. By adjusting
the function which measures the quality of the split, we arrive A massive improvement would be porting the monitoring
at a final accuracy of 91%. web panel to a mobile device. That way, it would be easier for
the caregiver to monitor on the go, rather than having to log on
The confusion matrix of the activity levels is given in
to a computer or laptop. Since this application is aimed at the
Figure 5. The labels low, medium and high represent the
elderly, trying to make the monitoring device as small as non-
activity level. We can see that the high activity level is the one
invasive as possible should be a priority. Right now, the system
that is the most challenging for our classifier to predict,
proposes a mobile phone that needs to be strapped to the waist
wrongly classifying 168 other activities.
and a fitness bracelet and both need to be worn constantly,
which might not be an option for some individuals.
For the application to have real-world applicability, it must
be extended to support multiple care-receivers. Right now, one
person can only monitor an individual. This use case, while
useful in proving the need for such an application, is not as
common in the real world. The application’s structure could
easily support such an extension, mainly because the health
monitoring panel is not tightly coupled with the care receiver.
Another helpful improvement would be providing live
notifications in case of emergency, either through web browser
notifications (supported by Chromium-based browsers) or by
push notifications on the phone. Right now the system relies on
the caregiver to perform manual synchronization for some of
the information but it would be much more helpful in the case
of extreme emergencies if this was automated.
A very convenient element of the application is the fact that
it is based on a web API (application programming interface),
making it very easy to offer as a service to the public. A
Figure 5: Confusion matrix multitude of different heart rate monitors and IMU sensors can
be easily integrated and data sent by them can be used by the
application. All that is needed is JSON-based communication
In comparison to other papers mentioned previously in between the application endpoints and the sender, which must
Section 2, we obtain comparable results. In [7], three send requests on the proper endpoint with accordingly
formatted data. For our purpose, the heart-rate was provided
through a fitness band and the positioning data was retrieved
from mobile phone sensors, but since it has a very clearly
defined API, it can use anything as a data source, as long as the
sender conforms to the standard imposed by the application.
An experimental feature would be extending the learning
model to use other data about the care-receiver as well. The
latest technology advancements made it possible to develop
non-invasive sensors that also monitor body temperature, blood
pressure, neurological activity and many other vital signs. Also,
the application could request more details about the lifestyle of
a user, to detect and provide alerts for a wider range of
ailments, like heart attacks or epileptic seizures. By providing
more complex input to the prediction algorithm, it may also
become more time-consuming. Comprehensive experiments
need to be performed, to outline a suitable input that also
proves efficient.
REFERENCES
[1] J. Oeppen and J. W. Vaupel, “Broken Limits to Life Expectancy”,
Science, vol. 296, no. 5570, pp. 1029 – 1031, 2002.
[2] J. M. Hausdorff, D. A. Rios and H. K. Edelberg, “Gait variability and
fall risk in community-living older adults: A 1-year prospective study”,
Archives of Physical Medicine and Rehabilitation, vol. 82, no. 8, pp.
1050 – 1056, 2001.
[3] S. R. Lord, C. Sherrington, H. B. Menz, “Falls in older people: risk
factors and strategies for prevention”, 2003.
[4] J. Fleming and C. Brayne. “Inability to get up after falling, subsequent
time on floor, and summoning help: prospective cohort study in people
over 90”, The BMJ, vol. 337, 2008.
[5] T. Ferguson et al., “The Validity of Consumer-Level, Activity Monitors
in Healthy Adults Worn in Free-Living Conditions: A Cross-Sectional
Study”, The International Journal of Behavioral Nutrition and Physical
Activity, vol. 12, 2015.
[6] Y. Zhang, et al., “Remote Mobile Health Monitoring System Based on
Smart Phone and Browser/Server Structure” Journal of Healthcare
Engineering, vol. 6, no. 4, pp. 717-738, 2015.
[7] A. Muhammad, and A. Kattan. “Physical Activities Monitoring Using
Wearable Acceleration Sensors Attached to the Body”, PLoS ONE, vol.
10, 2017.
[8] A. Ben Ahmed, Y. Kimezawa and A. Ben Abdallah, "Towards smart
health monitoring system for elderly people," 4th International
Conference on Awareness Science and Technology, pp. 248-253, 2012.
[9] A. K. Bourke et al., “Evaluation of a threshold-based tri-axial
accelerometer fall detection algorithm”, Gait & Posture, vol. 26, no. 2,
pp. 194 – 199, 2006.
[10] L. Breiman, “Random Forests” , Machine Learning, vol. 45, no. 1, pp. 5
– 32, 2001.
[11] T. M. Mitchell, “Machine Learning”, 1997.
[12] M. M. Morrison, Inertial Measurement Unit, 1987.
[13] G. Vassilis and H. Perakis, “Rigorous Performance Evaluation of
Smartphone GNSS/IMU Sensors for ITS Applications”, Sensors (Basel,
Switzerland), vol. 16, no. 8, 2016.
[14] A Guide To using IMU (Accelerometer and Gyroscope Devices) in
Embedded Applications, http://www.starlino.com/imu_guide.html
[15] Fitbit Charge device, https://www.fitbit.com/
[16] A. Reiss, PAMAP2 Physical Activity Monitoring Dataset,
“http://archive.ics.uci.edu/ml/datasets/PAMAP2+Physical+Activity+Mo
nitoring”, 2012.
[17] S. N. Blair, A. L. Dunn, B. H. Marcus, R. Carpenter and P. Jaret, “Active
Living Every Day”, 2011.
[18] C. J. Caspersen., K. E. Powell and G. M. Christenson. "Physical
Activity, Exercise, and Physical Fitness: Definitions and Distinctions for
Health-Related Research" Public Health Reports, vol. 100, no. 2, pp.
126-131, 1985.
[19] A. Nordon-Craft et al., “Intensive Care Unit–Acquired Weakness:
Implications for Physical Therapist Management”, Physical Therapy,
vol. 92, no. 12, pp 1494 – 1506, 2012.
[20] Q. Li, J. A. Stankovic, M. A. Hanson, A. T. Barth, J. Lach and G. Zhou,
“Accurate, Fast Fall Detection Using Gyroscopes and Accelerometer-
Derived Posture Information”, 2009 Sixth International Workshop on
Wearable and Implantable Body Sensor Networks, Berkeley, CA, 2009,
pp. 138-143.
[21] J. Hart, “Normal resting pulse rate ranges”, Journal of Nursing
Education and Practice, vol. 5, no. 8, 2015.
[22] H. Tanaka, K. D. Monahan and D. R. Seals, “Age-predicted maximal
heart rate revisited”, Journal of the American College of Cardiology,
vol. 37, no. 1, pp. 153 – 156, 2001.
[23] X. Huile, L. Jiny, H. Haibo, Z. Yi, “Wearable Sensor-Based Human
Activity Recognition Method with Multi-Features Extracted from
Hilbert-Huang Transform”, Sensors, vol 16, no. 12, 2016.