bwHealthApp: A Software System to Support Personalized Medicine by
Individual Monitoring of Vital Parameters of Outpatients
Philip Storz
, Sandra Wickner
, Benjamin Batt
, Johannes Schuh
, Denise Junger
, Yvonne M
Nisar Malek
and Christian Thies
School of Informatics, Reutlingen University, Reutlingen, Germany
Center for Personalized Medicine, University of T
ubingen, T
ubingen, Germany
Internal Medicine I, University Hospital T
ubingen, T
ubingen, Germany
mHealth, Telehealth, Data Monitoring, Wearable Data, Patient-reported Outcomes.
Continuous monitoring of individual vital parameters can provide information for the assessment of one’s
health and indications of medical problems in the context of personalized medicine. Correlations between
parameters and health issues are to be evaluated. As one project in this topic area, a telemedicine platform is
implemented to gather data of outpatients via wearables and accumulate them for physicians and researchers to
review. This work extracts requirements, draws use case scenarios, and shows the current system architecture
consisting of a patient application, a physician application with a web server, and a backend server application.
In further work, the prototype will assist to develop a vendor-free and open monitoring solution. A conclusion
on functionality and usability will be evaluated in an imminent first study.
Personalized medicine (PM) focuses on the person
themselves, their characteristics, and needs, ideally
supported by enriching existing patient information
with continuously collected health data. There are in-
dications of the medical potential of such non-specific
health monitoring (Dusheck, 2017).
The increasing use of wearables with an unman-
ageable variety of sensors leads to self-assessments
and a new type of appropriate medical consultations.
To prove medical evidence and to enable a systematic
approach, a large-scale evaluation in a real clinical en-
vironment is necessary, which requires a suitable and
freely adaptable software system for data processing.
Understanding patterns of vital signs and diseases
is an emerging application for large data analysis and
machine learning. Continuous monitoring of vari-
ous health data using case studies, including medi-
cal outcomes, is the basis for supporting diagnosis for
precision medicine. A solution is needed that com-
bines flexible and case-specific sensor composition
with the interpretation of medical data in a clinical
care environment. This additional data can be used to
supplement the current diagnosis, therapy planning,
monitoring of the patient’s condition, clinical evalua-
tion, and research. Further, the actually needed type,
quality, and quantity of vital data and for monitor-
ing relevant patient-reported outcomes (PROs) as well
as their correlation with pathophysiological processes
are current objects of research (Dusheck, 2017; Dias
and Cunha., 2018; Ohri et al., 2017).
To realize such a solution, the ministry of social
affairs and integration state of Baden-W
(Germany) initialized this project to develop a tele-
health system for PM, that enables individual configu-
ration for body area networks (BAN) for eligible med-
ical use cases. Tools for data recording by arbitrary,
commercially available sensors as well as examina-
tion and validation are provided alongside interfaces
to systems for automated data analysis, alarming, or
deep learning for predictors. The principal applica-
tion underlying this work is the monitoring of patients
undergoing chemotherapy treatment in medical onco-
logical daycare units. Here, continuous monitoring of
vital parameters can support the detection of critical
situations or overall changes in the patient’s condition
(Ohri et al., 2017).
Medical partners of the bwHealthApp project are
the Center for Personalized Medicine (CPM) and the
Clinic of Internal Medicine of the university hospi-
tal of T
ubingen, Germany, with its daycare units. An
upcoming, cooperative clinical trial shall determine
which sensors are useful for monitoring health param-
Storz, P., Wickner, S., Batt, B., Schuh, J., Junger, D., Möller, Y., Malek, N. and Thies, C.
bwHealthApp: A Software System to Support Personalized Medicine by Individual Monitoring of Vital Parameters of Outpatients.
DOI: 10.5220/0010324106130620
In Proceedings of the 14th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2021) - Volume 5: HEALTHINF, pages 613-620
ISBN: 978-989-758-490-9
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
eters in the oncological setting. Effects concerning
human life by monitoring health data and resulting
diagnosis must be identified and secured.
In order to provide flexibility, the platform is de-
veloped in an open form, so that sensors from differ-
ent vendors can be used. This work presents the re-
quirements analysis and the implemented prototype.
With the availability of 2.5G and 3G mobile telecom-
munications networks in the first years of the 21st
century, bandwidth was sufficient to examine the ap-
plicability of decentralized individual vital data cap-
turing from BAN for patient monitoring (van Halteren
et al., 2004), and has since been an ongoing field of
research for individual health assessment. With the
constant growth of the wearable market, consumer
devices for various vital parameters became widely
spread (Dias and Cunha., 2018; Statista, 2019). Their
suitability for medical purposes is currently evaluated.
Preliminiary results indicate that the quality for some
parameters (e.g. heart rate) is partly sufficient (Tu-
rakhia et al., 2019; Raja et al., 2019). In contrast
to current comparable home care solutions using spe-
cific medical devices, the bwHealthApp also applies
consumer wearables. They are cost efficient and part
of an increasing number of peoples’ everyday life,
which is expected to ensure a sustainable coverage
of monitoring time and manageable need for support.
The trade-off between usability and data quality is to
be evaluated.
For PM, the long-term collection of data from am-
bulatory patients in their home environments provides
information about the progress of a disease that would
not be available during short hospital stays. For in-
stance, in the case of chemoradiotherapy, the analysis
of activity data by a step counter between the weekly
visits in daycare may help to avoid hospitalization
(Ohri et al., 2017). An advantage of the bwHealthApp
is the continuous transfer of data to the central server
for closer monitoring and quicker response times.
By long-term monitoring, further, yet unknown
correlations between vital parameters, environmental
influences, and progress of a disease may be uncov-
ered. For cancer treatment, several correlations be-
tween parameters and patient outcomes have been ex-
amined (Friedenreich et al., 2016; Guo et al., 2015).
Until now no operational integrated mobile health so-
lution is known to the authors which makes sensor
data from oncological outpatients’ everyday life avail-
able for clinical routine. Here the bwHealthApp sup-
ports the emerging concept of integrating routine data
and clinical research, as applied in PM (Vogenberg
et al., 2010). The system further allows for adaptive
variation of vital parameters to be monitored.
Making vital data available requires connectivity
and sensors which are manageable by patients with-
out a technical background, as well as tools that al-
low physicians to check the data during a regular pa-
tient visit. For this purpose home care monitoring
provides practical solutions for nearly two decades
(Lin et al., 2007). This experience, existing tools and
concepts are used to establish the bwHealtApp soft-
ware. Counteracting cancer is one of the current main
challenges in medicine. There are international ef-
forts taken to make use of digital possibilities, such
as the new ONCORELIEF project
funded within the
EU H2020 framework since 2020. The novelty of the
bwHealthApp is the application of well established
remote patient monitoring approaches for oncological
treatment adapted to PM.
The aim of the project stage presented is to establish
an initial prototype accepted by physicians and pa-
tients within the domain of chemotherapy.
3.1 Design Process
First, principal use case scenarios considering the rou-
tine operation of the system were obtained by in-
terviews and workshops with the CPM stakeholders,
identifying important functional and quality require-
ments regarding changeability, extendibility, config-
urability, and flexibility. For a more specific system
presentation, influential factors and boundary condi-
tions were defined. The concrete architecture, con-
sisting of a smartphone application for patients’ use, a
backend server application for storing and exchanging
data, and a frontend web application for physicians,
was developed and implemented. The open-source
paradigm is applied to enable sustainability and avoid
dead ends by closed-shops. As characteristic for PM,
the boundaries between patient care and research are
blurred. For individual data examination, the collec-
tion, organization, processing, and visualization of
raw data are fundamental requirements. High-level
analysis and machine learning have not yet been inte-
grated, except the data model and service architecture,
allowing for specific data extraction.
HEALTHINF 2021 - 14th International Conference on Health Informatics
3.2 Functional and Qualitative
The core task of the bwHealthApp is the centralized
recording of individual health data from decentral-
ized data sources and to provide attending physicians
with a possibility to analyze and correlate different vi-
tal parameters, PROs, and findings to detect unusual
changes within the patients’ individual profile during
their stay at home.
To support the main goal of keeping a patient in
his regular environment, data collection must be flex-
ible and need to avoid interference with daily life
wherever possible. Thus, easily available and user-
friendly wearables should be prioritized for integra-
tion. Wearables should be combined individually con-
cerning medically required parameters and indepen-
dent of specific vendors. For personal involvement of
the patients, an appropriate compliance considering
the application of the tools can be assumed.
All data the patient wants to provide should be re-
trievable for the treating physicians. Although con-
tinuous data collection would be ideal in the medical
setting, the patients have sovereignty of their data and
can terminate the data monitoring. The whole system
should be generic, modular, integrative and open.
3.3 Aspects of Realization
The bwHealthApp is a new digital health care applica-
tion, which is not fully covered by German legislation
since medical data is collected and processed beyond
an a priori defined medical question. Therefore, it can
currently only be applied in clinical trials.
The performance of smartphone and server pro-
cessors must be considered, as well as technical limi-
tations, such as battery lifetime, memory, or network
connectivity, and different versions of mobile oper-
ating systems. Other relevant factors are handling of-
fline and online modes, and essential external systems
needed for the running system.
Concerning the evolving requirements regarding
sensors, vital parameters, and medical questions,
an agile development approach, as well as DevOps
paradigms, have been adopted. The principal com-
ponents are developed for open source and frame-
work availability, giving importance to versioning and
monitoring of patches and security issues. The over-
all risk of dying frameworks and components has to
be matched by a modular architecture, which in turn
affects deployment pipelines.
The Bluetooth low energy (BLE) protocol, being
the current de facto standard for consumer wearables,
is used to set up the BAN. BLE still being under de-
velopment leads to frequent changes in the applied
frameworks of the android platform, requiring a flex-
ible and modular design of the smartphone app. The
implementation of the BLE protocol stack has to be
monitored by the android developers, and resulting
version limits for android will exclude smartphones
with older OS installations.
Further, sensors cannot be integrated if vendors do
not provide their specifications, leading to the Cosi-
nuss One
as the sensor of choice for initial develop-
ment and testing.
4.1 Patient Registration and
The first step for using the bwHealthApp in treatment
is the patient registration and authentication. Patients
are registered by an attending physician in the medical
daycare unit. After registration, the authentication of
the patient takes place via QR code scans, linking the
patient’s personal information with the smartphone to
be used as the BAN gateway. This makes the patient,
their monitoring cases, and medical data as associa-
ble as possible. The smartphone is further used for
identification during operation.
4.2 Measurement Configuration and
For the measurement configuration, the physician se-
lects a set of vital parameters and/or questionnaires
from a catalog, defining sampling rates for each el-
ement. The configuration is then persisted on the
server and transferred to the patient’s smartphone.
Physicians can also create individual questionnaires
and add them to the catalog. After the configured data
is collected, it can be reviewed by the physician. The
corresponding web application offers a selection of
tools for visualization and data filtering.
4.3 Device Initialization and Data
After a patient has been registered, authenticated, and
corresponding measurements are configured by the
physician, the smartphone application and used wear-
ables must be initialized. If the medical question does
bwHealthApp: A Software System to Support Personalized Medicine by Individual Monitoring of Vital Parameters of Outpatients
not need uniform devices, patients can use any pre-
ferred wearable that is supported by the system.
When launched, the smartphone app scans for
available devices in the environment and connects to
selected wearables. The app scans which configured
health care parameters are covered by which con-
nected device. Missing components trigger notifica-
tions and request feedback. In parallel, configured
questionnaires are downloaded automatically. Sen-
sor parameters are sampled and questionnaires are
displayed automatically in accordance with the con-
figured sampling rate and are persisted on the back-
end server. After initialization, a dashboard offers an
overview of the sampling process. The user can de-
cide if and when they want data to be recorded.
4.4 Connectivity and Operation
During data collection, further functionalities are
needed to handle broken connections, error feedback,
and reconnects. These have to be individually realized
by each client application. In contrast to the current,
more supervised monitoring approaches (e.g. Holter
monitor), this will need to be evaluated with respect
to clinical viability. A fundamental challenge will
be general usability for people with limited capabil-
ity to operate the smartphone app. Further, processes
need to be implemented to guarantee data synchronic-
ity across all sub-systems.
The project’s three essential systems are summarized
in figure 1. Note that wearables, smartphone, and pa-
tient app are part of the system for patients, while both
web server and physician application are part of the
system of physicians. External systems are excluded
by the horizontal swim lane divider. All three compo-
nents are required for the entire application to func-
tion as intended, yet each individual system should be
replaceable, serving the modularity desired for open-
source software.
Custom Physician
Patient App
R >R >
Web Server
Figure 1: System architecture overview.
5.1 Wearables and Patient Application
Wearables represent external sensor systems for data
collection and are combined into a BAN, for which
the smartphone app acts as a data integration system
with sensor management, data management, and user
interaction. Figure 2 shows the basic architecture of
the smartphone application.
The measurement scheduler extracts configured
vital parameters and searches for appropriate sensors
to connect to. After the connection has been con-
firmed, the sensor manager establishes the BLE con-
nection and provides a handler for each sensor. A spe-
cific GATT service (e.g. heart rate) is assigned to each
sensor. The handler extracts the desired value, inter-
prets the raw data according to the GATT implemen-
tation, and transfers it to the data manager component
in the configured interval. Error messages and invalid
values are handled here. The measurement module
regularly pools the current values for display. This
is the only implementation of polling, all other data
changes are using the observer pattern. Accordingly,
the questionnaire scheduler handles the download and
timely display of configured questionnaires.
Data is not streamed to the server. Instead, sensor
data is buffered into packets and transmitted at regular
intervals. PROs on the other hand are submitted after
the questionnaire has been filled in. Currently, data
is only held in RAM temporarily in support of data
economy. An offline mode temporarily moving data
from RAM to app may be introduced in the future.
5.2 Web Server and Physician
The web server, as seen in Figure 3, serves as an in-
terface between the backend server and the physician
application. It establishes a one-way connection to the
Wearable 1 Wearable n
Sensor Sensor
Handler n
Handler 1
Sensor Manager
Data Manager
Figure 2: Smartphone application overview.
HEALTHINF 2021 - 14th International Conference on Health Informatics
Backend Server
Case Handler
Parsing Service
Parsing Service
Frontend Components
Web Server
Web Client
REST Communication
Figure 3: Web application overview.
backend server and forwards all client requests via a
REST interface. The web server hosts the physician
application and provides it with static resources. For
each incoming client request, the server forwards it
to a separate handler, where the route to the back-
end server is defined. The returning request is then
received by the same handler and forwarded to the
client. If requests take too long or cause errors, time-
outs and error handling are available.
Purpose of the physician application is the man-
agement of monitoring cases. The system provides
visualization of individual health data and is used for
manual evaluation during consultations. The current
lack of medical guidelines on the use of individual
monitoring in PM marks the current system bound-
ary. Data visualization is processed in the browser,
without any external services.
The frontend is divided into functional compo-
nents, providing tools for patient registration and au-
thentication, monitoring case creation, view and edit-
ing, and most prominently data evaluation. For the
latter, data from sensors and PROs can be viewed as
raw data and rendered into a graphical representation,
as well as exported for integration into external tools.
5.3 Backend Server Application
The server application functions as both a gateway
for the aforementioned client applications and a con-
troller managing subsystems, as is shown in figure
4, providing REST-like interfaces for client systems.
Access to resources and corresponding operations is
limited, as per usual, by provided URLs and their cor-
responding HTTP-methods, thereby offering a first
layer of (role-based) access control. With respect to
system evolution and interoperability, data is trans-
mitted to and from the server application in JavaScript
Object Notation (JSON).
Data security of both incoming and outgoing mes-
sages will be ensured by encoded communication pro-
tocols (e.g. HTTPS) and established authentication
Patient-App Physician-App
REST-like interface
Other Systems
Other Systems
(e.g. HIS)
Figure 4: Server application overview.
mechanisms (e.g. X.509). Those messages are then
forwarded to the receiving handler, where they are
dispatched to the appropriate internal (e.g. database
management) or external (e.g. central authentication
service) subsystems, if given authorization require-
ments are met. Communication with external sub-
systems may require the use or provision of medical
standard interfaces (e.g. HL7, DICOM) to allow for a
flexible replacement of such subsystems as well as ex-
tensibility with additional components. The internal
and specific subsystems of the project cover the ad-
ministration of management data such as user identi-
ties, registered devices, and individual parameter con-
figurations, as well as run-time data such as assigned
sensors and measured values or PROs. External sub-
systems will include a centralized authentication ser-
vice, which is currently under development, and may
be extended by further systems for data visualization,
diagnosis support, and messaging for notifications.
The server application is designed with inter-
operability in mind, specifically concerning exter-
nal applications for clinical information processing
such as hospital information systems (HIS) or tumor
boards. It’s also supposed to serve as a data source
for research applications like machine learning, or
evidence-based medicine.
5.4 Persistence and Data Management
Persistence and data management are fundamental
tasks within the project, handled by an internal sub-
system of the server application. Central to the persis-
tence are monitoring cases, which encases a patient,
treating physicians, and an array of related data.
As a server application subsystem, the database
cannot be accessed directly, but only via appropri-
ate REST routes. By this means, the previously
mentioned role-based access control provided by the
bwHealthApp: A Software System to Support Personalized Medicine by Individual Monitoring of Vital Parameters of Outpatients
Figure 5: Questionnaire creation.
REST interface is extended to the database. Further-
more, access control within the database is to be ex-
tended by discretionary access control (DAC), intro-
ducing the concepts of data ownership and individu-
ally governed access control to personal data.
In a first step, the introduction of DAC will al-
low both patients and physicians to consult further
physicians, and in monitoring cases involving sev-
eral physicians, for each of them to access and review
the patient’s data. Later on, data (specifically medi-
cal outcomes) can be provided to external subsystems
for learning of predictors, ensuing automated alerting,
and currently unspecified research applications. All
while maintaining the patient’s data ownership.
6.1 Patient Registration and
The physician registers the patient in the web applica-
tion with personal information. After the information
is sent to the server, the physician is forwarded to the
authentication page. Upon receiving a new patient,
the server will generate an authentication code, which
is then sent to the physician’s client as a response to
the creating request. The patient can enter said code
(as QR code) into their mobile app for verification.
6.2 Device Initialization and
Physicians can create a configuration containing vi-
tal parameters and questionnaires. Measurements pa-
rameters consist of the type and sampling interval.
Questionnaires can be created from existing templates
or from the editor shown in figure 5. A questionnaire
consists of at least one item: a question, a grouping of
further items, or a display text. Each questionnaire
Figure 6: Device initialisation & data collection.
has a sampling interval, too. A measurement case
consists of any combination of questionnaires and vi-
tal parameters. After the configuration is saved, it is
loaded onto the patient’s smartphone.
To measure vital parameters, wearables must be
connected to the application. The user can search for
and connect to available BLE wearables (figure 6, left
side). For connected devices, the app automatically
checks whether the configured features are available.
6.3 Data Collection and Evaluation
If a configuration has been downloaded, data collec-
tion is started directly after sensor initialization. The
newest interpreted value gets shown in the applica-
tion (see figure 6, right side). In this case, the pa-
rameters heart rate (HR) and temperature (TEMP) are
queried and for each of these parameters, a device is
connected (green dot). Missing features will be visu-
alized by a red dot instead. Polling times are auto-
matically set for scheduling the PROs. When the app
is opened in the foreground, the questionnaire is dis-
Figure 7: Tabular data evaluation.
HEALTHINF 2021 - 14th International Conference on Health Informatics
Figure 8: Graphical data evaluation.
played immediately. If the app is in the background, a
notification is created that allows the user to open the
questionnaire. The user can always decide whether
he wants data to be recorded or not. By default, data
is recorded in the background once the app is opened
in the foreground or background. However, when the
user closes the task, this process is terminated. This
means that the user has the data sovereignty and can
determine at any time whether or not data is recorded.
The data that gets saved to the backend server can
be evaluated in the physician’s client application. The
physician can filter the data by the associated case, the
vital parameters and questionnaires included, or the
time period in which the data was collected. Figure 7
shows the raw data evaluation as tables. Additionally,
a graphical evaluation is available for all vital parame-
ters and some selected questionnaire items (figure 8).
Integrated and clinically approved solutions for spe-
cific vital parameters are only available for certain
medical use cases and diagnoses. In contrast to these
restricted monitoring applications, the depicted ap-
proach needs to combine changeable and case depen-
dent sensor composition with medical data interpreta-
tion. The presented data integration solution was de-
veloped to enable the clinical validation of this open
approach in the clinical environment. The designed
system architecture depicts a vendor-free and open
solution consisting of a centralized server and de-
centralized BAN gateway applications, demonstrating
the feasibility of collecting wearable data independent
of the used sensors and supported value types. In re-
ality, however, independence from vendors and com-
patibility with any sensor are mutually exclusive, due
to closed shops built by most sensor manufacturers.
Additionally, the wider the array of supported sen-
sors, the more critical the question of sensor data reli-
ability and precision becomes. The naive approach
to this problem would be to argue that even if the
data produced is lacking precision, simply having a
lot more data presents value in itself. While there
may be some truth to that, this argument won’t hold
up once incorrect data leads physicians to false diag-
noses, especially considering false negatives. Many
sensors accumulate additional data, such as skin con-
tact, that could be used to narrow down the precision
of measurements, e.g. the better the skin contact, the
more reliable the corresponding measurement. If or in
what capacity this suffices to counterbalance the risk
of incorrect data will require own research. However,
the presented platform will be available to assist in
such research, providing a framework by which nec-
essary tests can be supported.
Next to the reliability of data, privacy and secu-
rity are ever-present topics for well-justified doubts
and criticism. One major key aspect here is user con-
sent, an internationally recognized problem, mostly
with national-specific implications. Bolstered by Ger-
man federal minister of health Jens Spahn, the Euro-
pean General Data Protection Regulation, and many
big players from both IT and medical contexts, data
ownership, and sovereignty, as well as the infamous
’transparent citizen’, have been recent topics of con-
troversy in Germany. While some criticize the general
idea of data collection without immediate cause, oth-
ers argue for such data to be of high medical necessity.
It is clear that in addition to technical concepts, robust
and adequate solutions for various legal questions will
be required.
A final conclusion cannot yet be drawn but should be
available after testing the application in a real-world
scenario, i.e. with actual patients and physicians in a
real treatment situation. In an imminent first study, we
will evaluate operations, user acceptance, and sensor
connection stability according to the chemotherapy
use case. Initial vital parameters are general physi-
cal activity (e.g. step-count), weight and body fat per-
centage, cardiac values (heart rate, blood pressure),
and body temperature. In addition, an UV sensor and
skin conductance measurement will be made avail-
able. Until now our advances suffice to show the prac-
ticability of such an application.
A first small non representative user-study with
physicians indicates a general approval of the pilot
bwHealthApp: A Software System to Support Personalized Medicine by Individual Monitoring of Vital Parameters of Outpatients
implementation, but in detail the number of clicks
needed to fulfill the tasks has to be reduced.
One driving factor throughout implementation
was to aim for genericity. This contributed to the ben-
efit of the current system being applicable in a wide
array of use cases. While desirable for developing
our application, some of the valued flexibility needs
to be toned down to enter a testing phase. Especially
considering that such a generic approach gives way
to plenty related problems, such as volatility of stan-
dards or frameworks, or the closed shop mentality of
many wearable device distributors.
A first measure of toning down flexibility will be
to settle for a selection of vital data points relevant
to the use case of oncology, selecting appropriate sen-
sor types for measuring said data points, and choosing
devices that offer the required services. The selection
of appropriate sensors, or rather devices, presents a
somewhat harder challenge. In addition to technical
requirements, user acceptance is crucial for the suc-
cess of both testing and operation of the project, in-
cluding factors such as comfort, ease of use, aesthet-
ics, or even brand loyalty.
As expected in the current stage of development,
some additional questions remain open, and some de-
cisions may be overthrown in the future. For exam-
ple, the mobile application for patients currently stops
sending data once the user closes the application on
their phone. While this is an easy way to give control
to the patient, this design decision may deviate from
the user’s assumption of the app, or create a conflict
between the wish to keep the list of opened applica-
tions tidy while still passively sending out data. There
are several alternate approaches, each of which needs
to be checked with user compliance. While the func-
tionality and basic structure of the bwHealthApp is
clear and functioning it is not evaluated if and how
the system is accepted in the field. In a subsequent
study the usability and overall practicability of the
presented approach will be examined.
This project is funded by the ministry of social affairs
and integration, state Baden-W
urttemberg, Germany.
The authors declare that they have no competing in-
Dias, D. and Cunha., J. P. S. (2018). Wearable health de-
vices - vital sign monitoring, systems and technolo-
gies. Sensors, 18(8):2414.
Dusheck, J. (2017). Wearable sensors can tell when you
are getting sick.
Friedenreich, C., Neilson, H., Farris, M., and Courneya,
K. (2016). Physical activity and cancer outcomes:
A precision medicine approach. Clin Cancer Res.,
Guo, Y., Koshy, S., Hui, D., Palmer, J., Shin, K., Bozkurt,
M., and SW, Y. (2015). Prognostic value of heart rate
variability in patients with cancer. J Clin Neurophys-
iol., 32(6):516–20.
Lin, C.-H., Young, S.-T., and Kuo, T.-S. (2007). A remote
data access architecture for home-monitoring health-
care applications. Medical Engineering & Physics,
29(2):199 – 204.
Ohri, N., Kabarriti, R., Bodner, W. R., Mehta, K., Shankar,
V., Halmos, B., Haigentz, M., B. Rapkin, C. G.,
Kalnicki, S., and Garg, M. (2017). Continuous activ-
ity monitoring during concurrent chemoradiotherapy.
International journal of radiation oncology, biology,
physics, 97(5):1061–65.
Raja, J. M., Elsakr, C., Roman, S., Cave, B., Pour-Ghaz,
I., Nanda, A., Maturana, M., and Khouzam, R. N.
(2019). Apple watch, wearables, and heart rhythm:
where do we stand? Annals of translational medicine.,
Statista (2019). Forecast wearables unit shipments
worldwide from 2014 to 2023 (in millions).
worldwide-shipments/ (Accessed: 2020-12-15).
Turakhia, M., Desai, M., Hedlin, H., Rajmane, A., Talati,
N., Ferris, T., Desai, S., Nag, D., Patel, M., Kowey, P.,
Rumsfeld, J., Russo, A., Hills, M., Granger, C., Ma-
haffey, K., and Perez, M. (2019). Rationale and design
of a large-scale, app-based study to identify cardiac ar-
rhythmias using a smartwatch: The apple heart study.
American Heart Journal., 32(6):66–75.
van Halteren, A., Bults, R., Wac, K., Konstantas, D., Widya,
I., Dokovsky, N., Koprinkov, G., Jones, V., and Her-
zog, R. (2004). Mobile patient monitoring: The mo-
bihealth system. Journal on Information Technology
in Healthcare, 2(5):365–373.
Vogenberg, F. R., Isaacson Barash, C., and Pursel, M.
(2010). Personalized medicine: part 1: evolu-
tion and development into theranostics. P & T :
a peer-reviewed journal for formulary management,
35(10):560 – 576.
HEALTHINF 2021 - 14th International Conference on Health Informatics