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

oller

Nisar Malek

2,3

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

Keywords:

mHealth, Telehealth, Data Monitoring, Wearable Data, Patient-reported Outcomes.

Abstract:

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 ﬁrst study.

1 INTRODUCTION

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-speciﬁc

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 ﬂexible and case-speciﬁc 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

urttemberg

(Germany) initialized this project to develop a tele-

health system for PM, that enables individual conﬁgu-

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

613

eters in the oncological setting. Effects concerning

human life by monitoring health data and resulting

diagnosis must be identiﬁed and secured.

In order to provide ﬂexibility, 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.

2 RELATED WORK

With the availability of 2.5G and 3G mobile telecom-

munications networks in the ﬁrst years of the 21st

century, bandwidth was sufﬁcient 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 ﬁeld 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 sufﬁcient (Tu-

rakhia et al., 2019; Raja et al., 2019). In contrast

to current comparable home care solutions using spe-

ciﬁc medical devices, the bwHealthApp also applies

consumer wearables. They are cost efﬁcient 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

inﬂuences, 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.

3 APPROACH

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, conﬁg-

urability, and ﬂexibility. For a more speciﬁc system

presentation, inﬂuential factors and boundary condi-

tions were deﬁned. 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 speciﬁc data extraction.

https://oncorelief.eu/

HEALTHINF 2021 - 14th International Conference on Health Informatics

614

3.2 Functional and Qualitative

Requirements

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 ﬁndings to detect unusual

changes within the patients’ individual proﬁle during

their stay at home.

To support the main goal of keeping a patient in

his regular environment, data collection must be ﬂex-

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 speciﬁc 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 deﬁned 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-

ﬂine 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 ﬂex-

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 speciﬁcations, leading to the Cosi-

nuss One

as the sensor of choice for initial develop-

ment and testing.

4 USE CASE SCENARIOS

4.1 Patient Registration and

Authentication

The ﬁrst 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

identiﬁcation during operation.

4.2 Measurement Conﬁguration and

Evaluation

For the measurement conﬁguration, the physician se-

lects a set of vital parameters and/or questionnaires

from a catalog, deﬁning sampling rates for each el-

ement. The conﬁguration 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 conﬁgured data

is collected, it can be reviewed by the physician. The

corresponding web application offers a selection of

tools for visualization and data ﬁltering.

4.3 Device Initialization and Data

Collection

After a patient has been registered, authenticated, and

corresponding measurements are conﬁgured by the

physician, the smartphone application and used wear-

ables must be initialized. If the medical question does

https://www.cosinuss.com/en/products/one/

bwHealthApp: A Software System to Support Personalized Medicine by Individual Monitoring of Vital Parameters of Outpatients

615

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 conﬁgured

health care parameters are covered by which con-

nected device. Missing components trigger notiﬁca-

tions and request feedback. In parallel, conﬁgured

questionnaires are downloaded automatically. Sen-

sor parameters are sampled and questionnaires are

displayed automatically in accordance with the con-

ﬁgured 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.

5 SYSTEM ARCHITECTURE

AND FUNCTIONALITY

The project’s three essential systems are summarized

in ﬁgure 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.

/patients

Research

Application

/patients

KIS / HIS

/patients

Custom Physician

Frontend

/patients

Wearables

Smartphone

Patient App

Backend

Server

Bluetooth

R >R >

Physician

Application

(Browser)

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 conﬁgured

vital parameters and searches for appropriate sensors

to connect to. After the connection has been con-

ﬁrmed, the sensor manager establishes the BLE con-

nection and provides a handler for each sensor. A spe-

ciﬁc 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 conﬁgured 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 conﬁgured 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 ﬁlled in. Currently, data

is only held in RAM temporarily in support of data

economy. An ofﬂine mode temporarily moving data

from RAM to app may be introduced in the future.

5.2 Web Server and Physician

Application

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

Sensor

Handler n

Sensor

Handler 1

Sensor Manager

Measurement

Scheduler

Data Manager

Measurement

Module

Questionnaire

Module

GUI

User

App

Storage

Questionnaire

Scheduler

Network

Backend

Server

...

Figure 2: Smartphone application overview.

HEALTHINF 2021 - 14th International Conference on Health Informatics

616

Backend Server

Handler

Patient

Handler

Measurement

Case Handler

Questionnaire

Handler

Data

Handler

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 deﬁned. 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 ﬁgure

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 ﬁrst

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

/practitioners/login/patients

Patient

Handler

Other

Handlers

Practitioner

Handler

Gateway

Controller

Database

Manager

Parsing

Service

Other Systems

Central

Authentication

Service

Other Systems

(e.g. HIS)

External

systems

internal

subsystems

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

ﬂexible replacement of such subsystems as well as ex-

tensibility with additional components. The internal

and speciﬁc subsystems of the project cover the ad-

ministration of management data such as user identi-

ties, registered devices, and individual parameter con-

ﬁgurations, 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 notiﬁcations.

The server application is designed with inter-

operability in mind, speciﬁcally 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

617

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 ﬁrst 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 (speciﬁcally medi-

cal outcomes) can be provided to external subsystems

for learning of predictors, ensuing automated alerting,

and currently unspeciﬁed research applications. All

while maintaining the patient’s data ownership.

6 UI AND USER PROCESSES

6.1 Patient Registration and

Authentication

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 veriﬁcation.

6.2 Device Initialization and

Conﬁguration

Physicians can create a conﬁguration 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 ﬁgure 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 conﬁguration 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 (ﬁgure 6, left

side). For connected devices, the app automatically

checks whether the conﬁgured features are available.

6.3 Data Collection and Evaluation

If a conﬁguration has been downloaded, data collec-

tion is started directly after sensor initialization. The

newest interpreted value gets shown in the applica-

tion (see ﬁgure 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

618

Figure 8: Graphical data evaluation.

played immediately. If the app is in the background, a

notiﬁcation 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 ﬁlter 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 (ﬁgure 8).

7 CRITICAL ANALYSIS

Integrated and clinically approved solutions for spe-

ciﬁc 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 sufﬁces 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-justiﬁed doubts

and criticism. One major key aspect here is user con-

sent, an internationally recognized problem, mostly

with national-speciﬁc 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.

8 CONCLUSION

A ﬁnal 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 ﬁrst 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 sufﬁce to show the prac-

ticability of such an application.

A ﬁrst 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

619

implementation, but in detail the number of clicks

needed to fulﬁll the tasks has to be reduced.

One driving factor throughout implementation

was to aim for genericity. This contributed to the ben-

eﬁt of the current system being applicable in a wide

array of use cases. While desirable for developing

our application, some of the valued ﬂexibility 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 ﬁrst measure of toning down ﬂexibility 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 conﬂict

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 ﬁeld. In a subsequent

study the usability and overall practicability of the

presented approach will be examined.

ACKNOWLEDGEMENTS

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-

terests.

REFERENCES

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. http://med.stanford.edu/news/all-

news/2017/01/wearable-sensors-can-tell-when-you-

are-getting-sick.html.

Friedenreich, C., Neilson, H., Farris, M., and Courneya,

K. (2016). Physical activity and cancer outcomes:

A precision medicine approach. Clin Cancer Res.,

22(16):4766–75.

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.,

7(17):417.

Statista (2019). Forecast wearables unit shipments

worldwide from 2014 to 2023 (in millions).

https://www.statista.com/statistics/437871/wearables-

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

620