Universität Ulm | 89069 Ulm | Germany Faculty of
Engineering, Computer
Science and Psychology
Institute of Medical Sys-
tems Biology
Developing a medical software to
enhance patient participation
Master’s thesis at Ulm University
Submitted by:
Michael Schrempp
Reviewer:
Prof. Dr. Hans A. Kestler
Prof. Dr. Manfred Reichert
Supervisor:
Dr. Johannes Schobel
2020
Version from March 12, 2020
c
2020 Michael Schrempp
This work is licensed under the Creative Commons. Attribution-NonCommercial-ShareAlike 3.0
License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/de/
or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California,
94105, USA. It is attributed to Manthana Chaiwong, licensed under CC BY 3.0
https://creativecommons.org/licenses/by/3.0/, strongicon, licensed under CC BY 3.0
https://creativecommons.org/licenses/by/3.0/, PICOL, licensed under CC BY-SA 3.0
https://creativecommons.org/licenses/by-sa/3.0/, Cuong Kieu Thi Kim, licensed under CC BY 3.0
https://creativecommons.org/licenses/by/3.0/, Laura Reen, licensed under CC BY-NC 3.0
https://creativecommons.org/licenses/by-nc/3.0/ Marczewski, A, licensed under CC BY-NC-ND
4.0 https://creativecommons.org/licenses/by-nc-nd/4.0/
Composition: PDF-L
A
T
EX 2ε
Abstract
Mental health disorder is a frequent issue among cancer patients. It is estimated that in
about 30% of cancer patients, psychological issues are undetected. Psychooncology is a
subdomain of psychology, which studies cancer related psychological issues and, hence,
develop appropriate treatments. With the help of screening instruments like the Distress
Thermometer, patients are rated according to their mental state. The result of the
screening indicates, whether a patient needs psychological treatment or not. However,
in most medical facilities this screening is processed using paper-based questionnaires,
which complicates the treatment. This thesis aims for enhancing the screening process
as well as the overall psychological treatment with a newly developed mobile application
Feelback.
The mentioned application uses patient participation principles by applying the latter.
Patients shall feel more involved in the psychological treatment process. This results
in patients that take a more active role in making decisions related to their treatment.
Moreover, sophisticated gamification concepts guarantee long-term motivated users.
From the medical facility’s point of view, screened patients are evaluated in an automated
manner, which, in term, saves time and money. In addition, Feelback makes it easier
to document psychological treatments. At the current state of development, further
steps should focus on user acceptance testing, in order to verify, whether the mentioned
concepts work as intended.
iii
Acknowledgment
I would like to thank all persons who supported me during this master’s thesis.
Special thanks go to my supervisor Dr. Johannes Schobel for your valuable ideas,
feedback and your patient advices.
I would like to kindly thank all proofreaders for correcting this thesis, which helped a lot.
I would like to thank my family for your continuous support and inspiration.
Also, I want to thank the development team of SurveyJS for a pleasant cooperation.
v
Contents
1 Introduction 1
1.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Fundamentals 5
2.1 Patient Participation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 eHealth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Gamification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Psychooncology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 Distress Thermometer . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Basic Terms in Context of Feelback . . . . . . . . . . . . . . . . . . . . . . 11
3 Concept 13
3.1 Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 As-Is Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 To-Be Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 User Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1 Sequence Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Gamification 29
4.1 Conception of Gamification . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Gamification for Elderly People . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Gamification Concept for Feelback . . . . . . . . . . . . . . . . . . . . . . 32
5 Implementation 35
5.1 Ionic Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Additional JavaScript Frameworks . . . . . . . . . . . . . . . . . . . . . . 38
5.3 Native Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.4 Mockup Backend System . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
vii
Contents
5.5 Tabs and Routing Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.6 Generic Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.7 Reactive Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.8 Presentation of the Mobile Application . . . . . . . . . . . . . . . . . . . . 48
6 Related Work 59
6.1 Narrow Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1.1 Pain Squad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1.2 Pit-a-Pat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2 Wider Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7 Discussion 65
8 Conclusion 69
8.1 Further Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A QR Code Card 75
viii
1
Introduction
Patients suffering from cancer often also suffer from mental distress and other psycholog-
ical issues. In many cases, this is often not properly detected [
1
] [
2
] [
3
]. In most medical
facilities, the process for screening mental distress is often performed in a paper-based
fashion, which involves several drawbacks for patients and practitioners. From patients’
point of view, this means, that they cannot immediately see the results nor the answers
of screenings. Because of this, patients get their screening result at a much later point in
time, which makes the process for both, patient and practitioners, time-consuming. Fur-
thermore, filling out paper-based questionnaires is often error-prone and time consuming
and is perceived as inconvenient [
4
]. From practitioners’ point of view, the evaluation of
screenings is a resource consuming process, as there are technical hurdles. In terms of
archiving health data, there are certain law regulations e.g. the legal retention period.
The legal text §630f Bürgerliches Gesetzbuch [German Civil Code] requires that, for
certain health data, a retention period of 10 years must be complied
1
. Archiving those
paper-based health data takes up large space and is costly. Only with high expense, for
the medical facility it is possible to view and analyze these archived data. Furthermore,
the medical facility as a whole is hardly able to make assertions about cancer patients
which are treated from psychological issues. To put in detail: Medical facilities try to
guarantee, that they screen patients with a subsequent psychological treatment by a
rate of 100%. With the use of paper-based screenings, these intentions are difficult to
prove by externals.
From a more technical point of view, paper-based questionnaires can only be evaluated
with high expense, in order to treat patients according to the results of the screening. In
1https://www.gesetze-im-internet.de/bgb/__630f.html last accessed: 2020-03-03
1
1 Introduction
most medical facilities, the filled out questionnaire is scanned so it can be processed by
the HIS. Additionally, practitioners manually add metadata to the questionnaire so it can
be evaluated by different parties. With this approach, more problems arise when other
medical facilities want to access this data, because of the inconsistent way in handling
data. Furthermore, making statistical statements (e.g. how many patients have been
treated psychologically) is difficult, because there is no metadata from paper-based
documents. Also, the communication with the Hospital Information System (HIS) and the
paper-based screenings is impaired. This may be crucial when the treatment process
involves more than one party, since such processes require more consultation and hence
data exchange which is requested from the HIS.
With the easy access to smartphones, it is with a low amount of resources possible to
perform such screening processes in a digital manner. Patients fill out the Distress Ther-
mometer on their own smartphones or use a provided one from the medical facility and
can subsequently see their screening result on the device. The filled out questionnaire
can be analyzed with a clear and easy to use polar chart. Line charts show how often
patients fill out questionnaires, since this mobile application can also be used as a way of
tracking the psychological course. But not only patients profit from this. From the medical
facility’s point of view, such digital process with smartphones and the corresponding
infrastructure within the HIS leads to better internal communication. On the one hand,
the infrastructure which consists of the HIS and the presented Feelback system can
communicate in an automated manner and on the other hand, practitioners who want to
operate with the system can easier access the data. Also, with this new process, the
medical facility is capable of documenting the treatment of patients in a digital manner.
This means that the previously mentioned law regulations can be met with lower costs
which saves space, time and money. Furthermore, patients feel more involved in the
psychological treatment process, because they see their screenings and can evaluate
themselves at any time, which enhances the treatment. In addition, with this newly
developed application Feelback, patients are motivated in using the application in the
long run, because various gamification concepts are utilized. The concept of levels and
a reward system are part of it.
2
1.1 Structure
1.1 Structure
The further structure of this thesis is as follows. Chapter 2 describes basic concepts like
patient participation, eHealth, gamification and the field of psychooncology are explained,
in order to provide profound background. In Chapter 3, the current As-Is and the future
To-Be process of the overall system is illustrated. Furthermore, this chapter also contains
the most important user stories of Feelback, which means that the most common actions
of users are listed. The overall technical architecture as well as sequence diagrams
describe the system in a more technical manner. Finally, mockups which are made
in Figma are presented with screenshots. Chapter 4 explains the use of gamification
frameworks as well as the gamification concepts within Feelback. In Chapter 5, important
implementation aspects are discussed in details. These include, for example, native
plugins or routing structure. Also, the concept of reactive forms in Angular are presented.
Finally, the mobile application is presented via screenshots. Chapter 6 discusses related
work in the context of this thesis. In Chapter 7, limitations of the presented thesis are
stated, while Chapter 8 summarizes the thesis and discusses further work.
3
2
Fundamentals
In this chapter important terms like patient participation as well as other terms are
defined in order to provide a profound background. Furthermore, basic concepts of
related topics in patient participation are described. Finally, there are several terms like
patient or participant used in a specific manner. In order to provide clarification, these
terms are also defined.
2.1 Patient Participation
The term patient participation is widely used, however there exists no unique definition
in literature [
5
]. Also, there are several synonyms for it like patient empowerment,patient
engagement,patient and public involvement or patient involvement. In the medical
context, these terms are used interchangeable. This thesis uses the term patient
participation, because it is most commonly used.
Speaking of patient participation, the European Patients’ Forum (EPF) provides a
widespread definition in [
6
]. It is described as a process of helping people get con-
trol of their situation or issue by increasing their knowledge. This newly gathered
knowledge helps the patient taking a more active role in meaningful decision making.
The EPF states that this kind of knowledge is experiential knowledge that comes from a
frequent contact with the healthcare system. Depending on how much experience the
patient has, he/she can influence the medical treatment.
In Figure 2.1 a patient with little experience starts from complaining and goes through
giving information, listening and responding, consulting and advising to full participation.
5
2 Fundamentals
Figure 2.1: Continuum of Patient Influence [7]
Experience-based co-design is a design process of accessing the users experience to
improve patient participation and so the medical treatment [7].
2.2 eHealth
The described concept of patient participation can be enhanced in different ways. In a
simple scenario where a physician treats a patient, the physician could inform the patient
about his/her disease and the related treatment in an understandable way. This scenario
is normally applied in most clinics. It improves patient participation, because the patient
is in a better situation when deciding about his/her treatment if the decision process is
distributed. In a distributed decision process, the practitioner as well as the patient can
decide which treatment is the best suitable for both sides [6].
In a more technical scenario, electronic devices like smartphones, tablets or computers
can also improve patient participation. For example, the patient increases his/her
knowledge due to the usage of an electronic application or searching related databases.
The utilization of such devices in the field of medicine is called electronic health or short
eHealth.
Eysenbach defines eHealth as a way to improve healthcare by providing information with
the usage of the Internet and other related technologies. He also states that the term is
used in the interdisciplinary fields of medical informatics, public health and business [
8
].
6
2.3 Gamification
2.3 Gamification
Gamification is an important concept in the context of eHealth to improve patient partici-
pation. One purpose of applying such techniques is long-term motivation of users of an
electronic application.
Deterding, Khaled, Nacke and Dixon established a widespread definition that is most
commonly accepted. According to Deterding et al. (2011), "Gamification is the use
of game design elements in non-game contexts." (p. 12-15). Moreover, the authors
distinguish between serious games and gamification. A serious game is a complete
game that has a different purpose than entertaining. Deterding et al. state that this
purpose is perceived subjective, because the purpose of a game can be for each
individual a different one [
9
]. From a game designer’s perspective, e.g. a puzzle game
could be designed for enjoying the creativity, whereas a certain player could perceive
the game objective as training for memorization.
Gamification not only helps motivating the users. Depending on how the gamification
aspects are designed, one can achieve different purposes. When, for example an
application designer wants to achieve that a questionnaire is filled out on a regular basis,
then the gamification aspect of the application should reward the players when they do
so. With this in mind, every use case can be represented in gamification aspects.
Gamification concepts have various domains in eHealth. Sardi, Idri and Fernandez-
Aleman made a systematic review where they reviewed the domain of gamification in
eHealth by investigating 46 papers. Most often, gamification is applied in treating chronic
diseases like cancer, Alzheimer’s disease, stroke, obesity and diabetes. The second
most often domain is physical activity. Next, mental health and hygiene are the least
common domains for gamification [10].
Also, the authors of [
10
] investigated the advantage of gamification in eHealth. Most
papers state, that gamification sustains users’ engagement with the application. Also,
gamification fosters a positive emotional state and self-esteem. In 14 papers, users
feel motivated in changing health behaviors. Making the application more entertaining
and easy to use led in most papers to a better user experience, especially for children
7
2 Fundamentals
and the elderly. 20 of the examined papers state, that gamification enhances intrinsic
and extrinsic motivation. Lastly, physical activities are perceived as less exhausting and
social game mechanics were perceived to be appealing [10].
2.4 Psychooncology
The application of concepts like patient participation, eHealth or gamification are man-
ifold. One scenario, which is also the running example of this work, is in the field of
psychooncology.
Psychooncology, as the name indicates, is a subdomain of oncology. Oncology is the
discipline of treating cancer. Speaking of psychooncology, it came up in the 1970’s. In
1975, a working group called The Psychosocial Collaborative Oncology Group found
out, that 47% of investigated cancer patients suffer from psychological illnesses like
depression, anxiety, and delirium. Most often it was adjustment disorder [11].
In the 21th century, research took several steps forward and so psychooncology was
established in different fields: research to lower the cancer risk, research for early
detection of cancer, treating sequelae of cancer, controlling psychological symptoms like
anxiety, depression or pain in a cancer treatment and handle palliative or end-of-life care
[11].
A key component for quantifying psychological symptoms are screening instruments.
This is a special kind of questionnaire, which is used to screen a patient by question-
ing him/her [
12
]. There are different instruments for screening a patient like Distress
Thermometer [
13
], Hospital Anxiety And Depression Scale [
14
], Hornheider Screening
Instrument [
15
], Fragebogen Zur Belastung Von Krebskranken [
16
], Psychoonkologische
Basisdokumentation [17] and numerous others [18].
The first of the listed questionnaire is used in this work.
8
2.4 Psychooncology
2.4.1 Distress Thermometer
Figure 2.2 depicts the Distress Thermometer. The questionnaire comprises two parts.
The upper part is a 11-point range Distress Thermometer scale, whereas the lower
part comprises a problem list of 34 questions. The National Comprehensive Cancer
Network states, that a score of five and higher of the thermometer indicate a distressed
cancer patient. According to the National Comprehensive Cancer Network, the problem
list says, which service should be applied to the patient. Practical and psychosocial
problems should be tackled by social workers, emotional and psychological by mental
health services and spiritual problems by pastoral counselors [13].
Several studies validated the cutoff score of Distress Thermometer like [
19
]. Jacobsen
et al. found out, that a cutoff score of four is the optimal trade off between sensitivity and
specificity, in order to screen a patient. For this, Jacobsen et al. investigated 380 patients
in five different medical facilities. This finding is in line with the National Comprehensive
Cancer Network [19].
The methodology of screening patients with a screening instrument, in order to decide if
a patient is mentally distressed leads in some studies to controversy like in [
20
]. They
question, whether an untreated psychological disease can be found with screening
instruments in an oncological setting [20].
9
2.5 Basic Terms in Context of Feelback
2.5 Basic Terms in Context of Feelback
In the following Table 2.1, all relevant terms in the context of this work are described.
This ensures clarity in using the corresponding terms.
Term Description
Patient
A patient is a participant in the Feelback study, whereas not
only a patient in the strict sense is meant. Also, relatives or
acquaintances of the patient can participate in the Feelback study.
Practitioner
A Practitioner is a member of the clinical staff, where member can
be the practicing physician or the creator of the medical study.
User
A User is the person who interacts with the application. This
could either be a patient or a practitioner.
Screening
A method for detecting psychological conspicuousness, utilizing
self assessment questionnaires.
Questionnaire
In the psychooncological context, a questionnaire (or survey) is
a screening instrument, which is used to quantify psychological
symptoms.
Application
An electronic application (or short app) is software that runs on
electronic devices like smartphones, tables or computers, in order
to meet a certain purpose.
Feelback
The name of the project, which has its application in the field of
psychooncology. Screening instruments are utilized in order to
quantify psychological symptoms.
Table 2.1: Basic Terms
11
3
Concept
In the following section, an application scenario is provided. It explains the technical
system and the integration into a clinical environment. Furthermore, user stories explain,
what a user shall accomplish by using the newly developed application. Afterwards,
the overall system architecture is depicted, described and essential user stories of the
overall system are visualized in sequence diagrams. Lastly, mockups show how the
application could look like.
3.1 Application Scenario
In this section, clinical as well as technical aspects of an overall application are inves-
tigated. Furthermore, special focus is put on the integration of the technical part into
the clinic’s everyday life. For this purpose, the As-Is as well as the To-Be processes are
investigated. Finally, the advantages of the new process in presented.
3.1.1 As-Is Process
Figure 3.1 depicts the current process in medical facilities. Starting at number (1),
the patient is at his/her cancer treatment in a clinic, hospital or other medical facilities.
Because cancer disease and its treatment often lead to psychological and mental issues
(cf. Chapter 2.4) at number (2) medical staff hands out various screening instruments
like the Distress Thermometer.
Screening a patient helps to identify if the person suffers from a psychological illness.
The Distress Thermometer is heterogeneous in this As-Is process, which means, that
13
3 Concept
Figure 3.1: As-Is Application Scenario
a medical facility can adapt the screening instrument if required. For example, some
clinics use a modified questionnaire containing an extra checkbox to find out, whether
the patient explicitly requests a psychological treatment whereas other clinics adapt
the screening instrument otherwise. For instance, the field for religious concerns is
sometimes combined into a single question. This makes comparing screenings and
their results from different medical facilities impossible. Furthermore, the screening
instrument is paper-based, which implies several other disadvantages in regards to
automated evaluation and accessibility for other parties.
When the patient fills out the questionnaire (3), the document is scanned and saved in
the Hospital Information System (HIS) of the medical facility. Because the document
is now just a digital picture, additional information for automated evaluation is required.
This is often manually handled by medical stuff. In terms of evaluation, this process is
also heterogeneous, which means that clinic A, for example, can rate a patient to be
physically distressed when the distress value is grater than five, whereas clinic B can
14
3.1 Application Scenario
classify a patient to be physically distressed, if a patient checks more than six optional
stress factors.
If the result of evaluation is positive (indicating that the patient is probably distressed),
the psychologist gets notified (4). In case the psychologist is located in the same medical
facility and uses the same HIS, he/she receives the scanned screening. This may also
be a manual process. In case the psychologist is located in another medical facility,
he/she must manually consult the other facility, in order to receive the required screening.
The same problem arises, when the psychologist finishes the treatment. The generated
reports of the psychological treatment are important for the patient’s record, but only
with high expense, these reports (5) appear in the patient’s record.
Finally, communication between different facilities is also problematic. For this, there
are several use cases, for instance, when a patient receives a treatment in clinic A and
thereafter one in clinic B.Clinic B needs for this the patient record including psychological
screenings. For this use case, the exchange of data is with a high probability just
manually possible. The situation becomes worse when for example clinic A archives
their screenings only in conventional folders.
3.1.2 To-Be Process
The process is described in Figure 3.2 (1), namely when the patient is treated at the
medical facility. There, the patient is asked if he/she wants to participate in the study
Feelback, in order to do a digital Distress Thermometer screening.
If the patient agrees, the practitioner hands over a card as indicated at number (2). The
card has a Quick Response (QR) Code printed on it for authenticating the patient. Also,
the medical staff notes on an e.g. sheet of paper, which patient received which card.
More information on this approach is provided in Figure 3.4.
At number (3) of Figure 3.2 there are two possible branches. The first branch, indicated
with an orange color, uses the smartphone of the study for filling out the Distress
Thermometer questionnaire.
15
3 Concept
Figure 3.2: To-Be Application Scenario
At number (4) the practitioner scans the QR Code of the patient, so the practitioner is
allowed to collect his/her data. In the following situation, the practitioner interviews the
patient, guided by the questionnaire. The orange path is chosen, if, for example, the
patient feels uncomfortable in using smartphones or if he/she is incapable of properly
using such devices.
The second branch, indicated with a green color, uses the smartphone of the patient. At
number (6) to (7) the patient scans his/her QR Code in order to authenticate himself/her-
self to the system. Now the patient fills out a questionnaire on his/her own. This branch
is typically chosen, if the patient has an affinity for technology and owns a smartphone.
An advantage of it is, that the practitioner could proceed to his/her work. Also, the
smartphones of the clinic are not blocked for other patients.
Comparing the As-Is process with the To-Be process with respect to the automated
processing and evaluation of the Distress Thermometer, it can be seen that this process
can be fully automated. The required data exchange is possible, because in medical
16
3.2 User Stories
facilities psychologists and physicians can communicate with a consistent and persistent
data storage in a server. Furthermore, rules for evaluation can now be managed in
a single location, which increases consistency. Also, clinic-to-clinic communication is
easier to achieve, because each participant of Feelback can communicate with other
participants with a central server infrastructure.
In this To-Be process, it is also important that the questionnaires are filled out on a
regular basis. Note that a simple notification, which serves as a reminder, is not enough,
because this concept does not motivate users. Here, gamification concepts may help to
motivate users filling out questionnaires on a regular basis (e.g. weekly). Furthermore,
these concepts help to achieve different purposes, like collecting meaningful data (data
that has a significance in psychooncology).
3.2 User Stories
This section lists important user stories of the Feelback project. In agile software
development, user stories are general software requirements expressed in everyday
language. Use-cases are also a way expressing theses requirements, but they are more
detailed [21].
User Stories as a practitioner:
1. As a practitioner I want to follow an invitation, so I can use the Feelback system.
2.
As a practitioner I want to login with my email address and password in order to
use the functionality of the system.
3. As a practitioner I might forget my password.
4. As a practitioner I want to personalize my application by choosing a color theme.
5.
As a practitioner I want to change my personal data: name, email address, profile
picture and password.
6. As a practitioner I want to have an overview of patients I’m currently treating.
7. As a practitioner I want to select a patient, in order to see his/her screening data.
17
3 Concept
8. As a practitioner I want to see a single screening of a patient.
9.
As a practitioner I want to be able to alter a screening’s date, in order to correct the
date.
10. As a practitioner I want to start a new screening for a patient.
11. As a practitioner I want to add new patients I’m currently treating.
12.
As a practitioner I want to request a screening which was not previously assigned
to me.
User Stories as a system administrator:
1.
As an admin I want to create n (e.g. n = 1000) users. For each user a card with a
printed QR Code on it shell be generated.
2. As an admin I want to invite practitioners to the system.
3.
As an admin I do not want to save medical data, in order to comply to the data
protection regulations.
4.
As an admin I want to save only a pseudonym for the patient, so I do not share
any personal data.
5.
As an admin I want to separately manage the login database from the regular
database, in order to comply to the data protection regulations.
User Stories of a patient
1.
As a patient I want to get access to the system with either a QR Code on a card or
manually via pseudonym and password.
2. As a patient I might forget my password.
3. As a patient I want to change my password.
4. As a patient I want to accept or reject requests for my screening data.
5. As a patient I want to assign a new practitioner to my account.
18
3.3 Architecture
Figure 3.3: Technical Architecture
3.3 Architecture
From a more technical point of view, Figure 3.3 depicts the architecture of the new
process. Starting from bottom-up, there are two main services. First, Keycloak
1
is an
identity provider as well as an access management tool. An identity provider authenti-
cates users to access the overall system. Other parties of the architecture can consult
Keycloak via the Application Programming Interface (API) whether the user is the user
that he/she pretends to be. Keycloak also handles access management, which means,
that Keycloak checks, whether a specific user is allowed to call a specific action.
Second, on the bottom right there is a NestJS
2
service, handling requests for the general
database via its own API. In NestJS, one can write typescript code for running all kinds
1https://www.keycloak.org/ last accessed: 2020-01-22
2https://nestjs.com/ last accessed: 2020-01-22
19
3 Concept
of server software. In this architecture, the NestJS service also communicates with the
Keycloak service, in order to authenticate users backend-wise.
Next, the software that runs on a user’s device is presented. For this, a framework called
Ionic
3
was used. Ionic is a platform independent framework, build with Stencil.js
4
web
components. A web component is encapsulated web code that is compiled to reusable
components. This generic approach of Ionic has several advantages. For example,
programmers can choose, whether they want to use Angular
5
, React
6
or Vue
7
as code
base. An additional step is required to run the web code on a device. If iOS or Android
is the desired platform, Apache Cordova
8
or capacitor
9
is required, in order to generate
native code, but this process is automated. Also, Electron Apps
10
for Windows, macOS
and Linux as well as Progressive Web App (PWA) are supported.
3.3.1 Sequence Diagrams
In this section, the most important user stories of the system as a whole, are presented.
Figure 3.4 shows the registration process of Feelback. A patient is at the medical facility
for his/her cancer treatment. There, the patient is asked if he/she wants to proceed with
a digital psychooncological screening. For this, patients need a card with an QR Code
on it, so the patients can login. These cards are usually prepared prior to the registration,
so there is a specific contingent cards for patients that are participating in this process.
When the patient has his/her card, he/she can log in by scanning the QR Code. Now the
patient is able to perform a psychooncological screening.
Figure 3.5 depicts the evaluation process. A patient performs a screening using the
mobile app on their own. After that, the data is transferred back to the Feelback backend,
where it is saved in the database. When later in the process a practitioner wants to know,
3https://ionicframework.com/ last accessed: 2020-01-22
4https://stenciljs.com/ last accessed: 2020-01-22
5https://angular.io/ last accessed: 2020-01-22
6https://reactjs.org/ last accessed: 2020-01-22
7https://vuejs.org/ last accessed: 2020-01-22
8https://cordova.apache.org/ last accessed: 2020-01-22
9https://capacitor.ionicframework.com/ last accessed: 2020-01-22
10https://www.electronjs.org/ last accessed: 2020-01-22
20
3.3 Architecture
Figure 3.4: Registration for Feelback
whether a patient has symptoms for distress, he/she can request the patient’s data. The
patient is notified, asking him/her to accept or reject the request. If the patient accepts
the request, the practitioner receives the data and can evaluate it in an automatic way.
Furthermore, the evaluation process is standardized, because the rules for evaluation
are defined in the backend. This guarantees the same evaluation results for all parties.
In case of a positive outcome, indicating that the patient shows symptoms for a distress,
he/she is transferred to a psychological for a consultation.
As one can see, Figure 3.6 builds upon Figure 3.5. It depicts how different parties (like
practitioner and psychologist) can access a patient’s screenings. It is also important to
note, that the parties are not necessary located in the same medical facility for accessing
data. Especially in scenarios, where patients visit different facilities like hospitals, general
practitioners or cancer counselling services, this approach offers huge benefits.
21
3 Concept
Figure 3.5: Evaluation of a Screening
Figure 3.6: Different Parties Request Screenings
22
3.4 Mockups
3.4 Mockups
The following mockups demonstrate how the application might look like. The software
which was used to create the mockups is called Figma11. For this thesis it was chosen,
because in Figma it is possible to design not only mockups, but also prototypes.
On the upper left side of Figure 3.7 the welcome screen of the application can be
seen. From here it is possible to login with either the QR Code card or manually with
pseudonym and password. The upper right side shows the screen, when a user wants
to log in via card and so with the QR Code. The screen on the lower left side shows how
the manual login with pseudonym and password could look like. When a user clicks on
Forgot password?, he/she gets redirected to the lower right side of Figure 3.7 where
he/she can request a new password.
Figure 3.8 shows the mockup for the screenings of a patient. As soon as the patient
logs in, this screen is shown. On top of the screen there is a tab bar showing the most
important functions for a patient, namely My Screenings,Permissions and Profile. For
each screening there is a title, describing the name of the screening, a subtitle describing
the name of the filled out questionnaire and a date which describes the date when the
questionnaire was filled out, is shown. Also, there is a green Floating Action Button
(FAB).
When the user clicks on the FAB he/she will be redirected to Figure 3.9 where he/she can
choose which questionnaire to fill out. On the bottom of each questionnaire a progress
bar is shown, indicating the current progress of the respecting questionnaire. When a
user fills out a questionnaire, the progress bar increases until it is filled. Reaching the
end, a collectable item is assigned to the user. This gamification concept supplements
the general level system of a patient. In the last questionnaire in Figure 3.9 an alternative
gamification concept is shown where a multiplier is depicted. By filling out questionnaires
continuously, the multiplier is increased. Both concepts have their reason for existence
and can be used to motivate users over a longer period of time.
11https://www.figma.com/ last accessed: 2020-01-22
23
3 Concept
Figure 3.7:
Mockups for Welcome, QR Code Scan, Manual Login and Forgot Password
24
3.4 Mockups
Figure 3.8: My Screenings Mockup
Figure 3.9: New Screening Mockup
In Figure 3.10 the user has an overview of pending permissions. If a practitioner requests
a screening of a patient, these requests are shown here. For each request the title of
the screening, the name of the questionnaire, which practitioner wants to access the
screening and the date of the request is shown. The patient can decide if he/she wants
to allow the request or reject it. Furthermore, the patient can view the answers of the
requested questionnaire.
Figure 3.11 shows the last tab for the patient. Here, the patient can see his/her
pseudonym, current level, collected badges and radio buttons for theme selection.
Figure 3.12 shows a sample questionnaire with different kinds of question types. The
question types are a slider, radio buttons for single selection, check boxes for multiple
choice, a yes no switch and a free text input. In Figure 3.13 a filled out questionnaire is
depicted.
As one can see in Figure 3.14, this is the start screen for a practitioner. In this mockup,
all for the current logged in practitioner, patients are listed. In addition, all important
25
3 Concept
Figure 3.10: Permissions Mockup Figure 3.11: Profile Mockup
areas for a practitioner are presented in three tabs, namely My Patients,All Patients and
Profile.
Mockup 3.15 depicts the second tab for a practitioner, where all available patients are
listed. In this mockup, grey buttons indicate already assigned patients, whereas green
buttons indicate patients that can be assigned to a practitioner.
In Figure 3.16 one can see screenings of a specific patient. Each screening has a
screening title, a questionnaire name, a date when the questionnaire was filled out,
and a status describing whether a practitioner can access the screening. The green
check icon indicates, that the practitioner can access this screening. A green plus
button indicates, that a practitioner can request access to a patient’s screening. The last
screening has a grey button, indicating that the patient rejected the request. With the
green FAB button, the practitioner can create a new screening for the patient, if he/she
is allowed by the patient. This is done by scanning the QR Code.
Figure 3.17 shows the mockup dialog when a practitioner clicks on a green button, trying
to add a patient to their list of patients.
26
3.4 Mockups
Figure 3.12: Questionnaire Mockup Figure 3.13: Answers Mockup
Figure 3.14: My Patients Mockup Figure 3.15: All Patients Mockup
27
3 Concept
Figure 3.16: Screenings Of a Patient
Figure 3.17: Add Patient Mockup
28
4
Gamification
This chapter describes basic gamification concepts and how they may be applied in
the context of the Feelback application. Furthermore, common challenges illustrate
what should be circumvented when designing gamification concepts for an application.
Next, special focus is put on gamification for elderly people and if it is necessary to
adjust common game mechanics to them. Finally, the gamification concept developed
for Feelback is presented.
4.1 Conception of Gamification
When designing gamification aspects for an application, it is vital to have an overview of
the existing game mechanics.
Sardi, Idri and Fernandez-Aleman made a systematic review [
10
] where they investigated
game mechanics described in 46 papers. They found out, that in 93% of the investigated
applications, an automated feedback system with collectible rewards like badges and
points was applied. Furthermore, social interaction was observed in most approaches.
Leaderboards for competing with other users and instant messaging within the application
are two common examples for social interaction. Also, the integration of social networks
like Twitter or Facebook was applied for socializing between users [10].
Another game mechanic described are progress bars, which help visualizing the progress
of current activities or tasks and keep track about it. Challenges and quests were
applied for various purposes. Trophies, ribbons, medals and badges were used to
reward completing tasks or users for leveling-up. Finally, sound effects for notifications,
29
4 Gamification
congratulatory messages and videos were also applied as common game mechanics
[10].
What is also important are the challenges of previous approaches. Avoiding these pitfalls
results in better gamification experience.
The authors of [
10
] also investigated these effects. Various investigated papers of [
10
]
state, that it is difficult to motivate users in the long term. Some application designers
bypass this effect by constantly adding new gamification content to the application. For
example, designers could extend existing game mechanics e.g. adding new badges to
existing ones or add complete new concepts to the application. Furthermore, diverse
papers state, that a lack of customization of gamification concepts often leads to an
effect, where users do not see the purpose of gamification.
The next problem which is mentioned in [
10
] is, that not every gamification concept
is suitable for all ages. Also, cheating, the usage of only one game mechanic and
irrelevant rewards are also pitfalls. Two papers state, that when health professionals are
not involved in the process of designing gamification, the concept is rated with a lower
credibility [10].
4.2 Gamification for Elderly People
Most cancer diseases have a linear relationship between incidence and age [
22
]. With
this in mind, special focus is put on gamification concepts specially designed for elderly
people. In the following it is examined, whether elderly people need adjusted game
mechanics.
De Vette, Tabak, Dekker-van Weering and Vollenbroek-Hutten found out, that no gam-
ification framework has a special focus on elderly people [
23
]. An investigated paper
of [
23
] states, that the most challenging issue is the unfamiliarity of seniors with game
elements like points, levels and badges. However, other sources of [
23
] state, that
gamification for elderly people has huge potential, because it decreases the fear and
frustration of using modern technology, if gamification aspects are carefully designed
[23].
30
4.2 Gamification for Elderly People
Figure 4.1: Marczewski’s Player Type Model [24]
In order to answer the question, whether elderly people need adjusted game mechanics,
a player taxonomy is presented. In this theory, players are classified into groups. This
is a common approach in game industry, since it gives insights into players’ behavior.
There are various models, however, this thesis uses Marczewski’s player type model, as
it is commonly used and can be applied in gamification settings [24].
Figure 4.1 describes each player type in an edge. Players that want to disrupt the system
in order to achieve positive or negative changes are Disruptors.Free Spirits are players
that are motivated by autonomy, in order to explore and create content. Achievers are
motivated by mastery, so they can train skills and overcome challenges. Players do what
the system wants them to do, in order to gain rewards. A Socialiser is motivated by
relatedness. This means that they want to connect to other players. A Philanthropist is
motivated by purpose, meaning that this player wants to do something good to others or
help them. They do not expect that they will ever be rewarded [24].
In the examined player taxonomy of De Vette et al. [
23
] as well as Marczewski’s taxonomy
[
24
], they both describe an individual personality regardless of their age. Nevertheless,
this field requires more research, because firstly a literature search for elderly people
and gamification framework does not return any results [
23
] and secondly there are
contradictory statements, e.g. elderly people need adjusted game mechanics [
23
],
whereas others state, that this is regardless of age [25].
31
4 Gamification
4.3 Gamification Concept for Feelback
In the following, the gamification concept for Feelback in presented. The concept
comprises general levels for a patient or a practitioner, collectable stars, a multiplier and
collectable badges.
Starting with levels, an easy to follow mathematical function was chosen, because this
enables the usage of infinite levels.
f(x) = 0.001 ∗x2(4.1)
The Function 4.1 describes, how much experience a user needs for a correspond-
ing level.
X
represents Experience Points (XP) and
f(x)
the corresponding level. A
quadratic function with a coefficient of
0.001
was chosen, because the increase of the
function is moderate. When for example a questionnaire rewards the user with ten XP,
approximately three questionnaires are needed for the first level. Four for level two, five
for level three and so on.
Table 4.1 illustrates, how much experience a user needs for the first few levels.
Level Experience Range Required Experience for next level
1 [0-30] 31 XP
2 [31-74] 44 XP
3 [75-128] 54 XP
4 [129-191] 63 XP
5 [192-262] 70 XP
Table 4.1: Required Experience For The First Few Levels
Next, the collectable stars are presented. The stars are utilized to reward users when
they fill out a certain questionnaire (cf. Figure 3.9). Stars (or other arbitrary collectable
items) complement the general level approach and motivate users in different ways.
The following mathematical equation 4.2 describes the process of gaining stars.
g(x) = 40 (4.2)
32
4.3 Gamification Concept for Feelback
This Function 4.2 describes, how much XP a user needs for gaining a star per question-
naire. A linear function with zero slope was chosen, as this collectable item should be
easy to gain. It is a kind of a gap filler when the user does not level up. A constant of 40
was chosen, so normally the user gains levels and stars alternatingly.
Table 4.2 illustrates the first few numbers of stars. Especially at the experience range
fields, one can see the alternating effect.
Level Experience Range Required Experience for next level
1 [0-39] 40 XP
2 [40-79] 40 XP
3 [80-119] 40 XP
4 [120-159] 40 XP
5 [160-199] 40 XP
Table 4.2: Required Experience For The First Few Stars
In terms of experience, a patient gains ten XP per filled out questionnaire for the level
and the star counter. If the questionnaire takes longer than usual, he/she may get an
increased number of experience points (e.g. 20 XP). Also, a practitioner receives ten
XP for level and star when he/she fills out a questionnaire for a patient. Additionally,
practitioners are rewarded with 20 XP when they treat a patient.
The concept of the multiplier works as follows: It starts by 1.0 per patient and practitioner
and increases by 0.1 when an action resulting in experience was achieved. The multiplier
decreases to 1.0, if the patient or the practitioner did not gain any experience within one
week.
Badges also represent some kind of collectable item. Patients and practitioners are able
to collect six different badges. There are additional five level per badge, resulting in a
total of 60 different rewards. This helps to keep the number of total badges low, which
results in a better user experience. Users see their badges in their profile like one can
see in Figure 3.11.
The first badge Total Experience Points is illustrated by the second column of Table 4.3,
showing the reward for total experience points. This badge is collectable by patients and
practitioners. The second badge Reaching a Level is illustrated by the third column of
33
4 Gamification
Required
Level Experience Level Amount questionnaires Multiplier Amount questionnaires on time Amount Stars Treated patients
1 100 5 7 2.0 3 5 3
2 250 10 20 3.0 7 15 7
3 500 20 45 4.0 13 30 13
4 1000 40 85 5.0 21 50 21
5 2000 80 175 6.0 32 100 32
Table 4.3: The Badge System of Feelback
Table 4.3. It is collectable by patients and practitioners. The third badge Amount of Filled
Out Questionnaires is shown in Table 4.3 fourth column. It is also collectable by patients
and practitioners. The fourth badge High Multiplier is shown in Table 4.3 fifth column
and it is collectable by patients and practitioners. The fifth badge Amount of Filled Out
Questionnaires on Time is only collectable by the patient. For this, the patient must start
to fill out a questionnaire within five minutes. This approach helps to collect significant
psychological data. Table 4.3 column 6 illustrates the badge. The sixth badge Total
Amount of Stars is again collectable by patients and practitioners. Table 4.3 column 7
shows this badge. Last badge Amount of Treated Patients is a badge for practitioners.
In the Feelback application, there will be a checkbox where a practitioner can note, that
a patient is treated, shown in Table 4.3 column 8.
As one can see in the different badge level tables, when a user gains a specific badge at
a certain time, other badges do not overlap. Next badges are typically gained during the
next user interaction. With this technique, almost every action of a user triggers some
kind of reward.
It is also possible to integrate hidden badges. This is a special kind of badge that is only
shown to users, when the user already fulfilled its objective. This concept triggers users
to seek for hidden achievements within the application, resulting in long term motivation.
34
5
Implementation
This section presents a small overview of some important concepts introduced by Ionic,
including the grid system, CSS and routing. After that, two utilized JavaScript frameworks
(SurveyJS and Chart.js) used within the Feelback project are demonstrated. Also, the
native plugin (PhoneGap Plugin BarcodeScanner) that communicates with the hardware
API is presented. During development, there was a need for a functioning backend
system. In order to be able to develop the mobile application independently, a mockup
backend was developed and will be declared (Chapter 5.4). Next, the overall tabs and
routing structure of patients and practitioners in Feelback is presented. In the Feelback
Ionic project, a concept of generic components was used for specific parts of the app.
This is presented in Chapter 5.6. Furthermore, reactive forms instead of template-driven
forms were used. This approach is stated in Chapter 5.7. Last, the mobile application
itself is shown in Chapter 5.8.
5.1 Ionic Framework
For this thesis as mentioned in Chapter 3.3, Angular was chosen as the code base within
the Ionic framework. In Angular, developers can write web code in Hypertext Markup
Language (HTML) and Typescript
1
. As usual, CSS is used for styling. The widespread
concepts of Angular e.g. modules, components, services, service injection, templates,
directives, data bindings and others are also applicable in Ionic.
Ionic itself is a collection of web components, that are build by StencilJS. Programming
in Ionic basically means to access these bundled web components using Angular. The
1https://www.typescriptlang.org/ last accessed: 2020-02-19
35
5 Implementation
Figure 5.1: Example Responsive Grid of Ionic
mentioned web components of Ionic are a powerful tool in developing web code, because
these components adept themselves according to the operating platform. This means
that these web components look different for each platform, imitating a native application.
Furthermore, there are other convenience functions e.g. the color adaptation of the
component. This means, that when developers decide to take e.g. a dark background
for the component, the text color automatically changes to white, providing a look and
feel for the application.
Also, Ionic’s web components are highly scalable with regard to display sizes. By
utilizing Ionic’s grid, developers can constrain the components in relation to size, without
constraining the scalability of the component. Figure 5.1 depicts such a grid of Ionic.
As one can see, there are seven rows and two to four columns per row. In general, the
default grid system of ionic has a size of twelve, which means a total width of 100%. The
mentioned grid system is similar to other frameworks like Bootstrap
2
, where developers
also build their user-interfaces upon grid systems. Looking at the first row of Figure 5.1,
2https://getbootstrap.com/ last accessed: 2020-02-20
36
5.1 Ionic Framework
this means that the two columns have a size of six, achieving that each column takes up
50% of the total row width. In addition, it is possible to constrain the size of a column by
the size of a display. This can be achieved by writing Size-md="8", meaning that this
column takes up a size of eight, for displays of medium size and larger. Reasons why
one should use such constrains are manifold. Some components, for example, do not
look appropriate when they are stretched too wide, especially on large displays. The
resolution of the display required to be categorized as e.g. medium or large is provided in
the Ionic documentation. This concept is called Breakpoints and can also be customized
by using CSS variables.
Ionic uses a special extension for CSS which is called Sass
3
.Sass has several ad-
vantaged compared to plain CSS. For example, Sass has concepts of variables and
developers can write cleaner code, by utilizing the cascading structure of CSS as well as
several other advantages.
What’s more special about Ionic is the usage of Angular’s routing module in terms of
transitions. Mobile applications typically have a kind of transition, indicating that the
current view was changed to a new one. For these transitions, most often a slide effect
is used, indicating that a view is either pushed to the graphical view stack or popped
from the latter. Websites do not have such transitions, and so Angular does not have
transitions in the router module either. This is where Ionic’s NavController is applied
by calling push(),pop() or navigateRoot(). This NavController utilizes Angular’s router
module internally, in order to perform a view change. Additionally, the NavController
builds up this mentioned view stack and automatically manages back buttons for users,
if they want to navigate backwards. An important aspect of the navigateRoot() method
is, that previous views on the view stack will be deleted, meaning that no back button on
top of a view is presented to users.
3https://sass-lang.com/ last accessed: 2020-02-19
37
5 Implementation
5.2 Additional JavaScript Frameworks
In the Ionic Feelback project, several additional JavaScript frameworks were used. This
section presents two of them, namely SurveyJS4and Chart.js5.
SurveyJS is a framework for dealing with digital questionnaires. There is a module for
creating a questionnaire, a model for displaying highly responsive questionnaires in
someones own application and several services for analyzing the results of the ques-
tionnaire. In terms of the Creator module, this is an application where the questionnaire
can be configured and finally graphically represented. The Creator can either run in
someones own application or can be used by the online application on the website of
the project.
Configuring the questionnaire is possible by drag & drop, which can be done by non-
developers. Third party JavaScript frameworks like noUiSlider
6
can also be used by
dragging & dropping the element into the questionnaire. The website contains a list
of all supported third party frameworks. As a result of configuring the questionnaire in
the Creator module, a JSON file is outputted, where the structure of a questionnaire is
described.
Listing 5.1 depicts an example questionnaire structure of a single radio group with two
radio buttons.
1{
2" pages " :[ {
3"name" :" page1",
4" elements " :[ {
5" type " :" radiogroup " ,
6"name" :"question1",
7" t i t l e " :" Please i n d i c a t e i f Depression has been a problem f o r
you in the past week i n c l u d i n g today . " ,
8" choices " :[ {
9" value " :"item1",
10 " t e x t " :"YES"
4https://surveyjs.io/ last accessed: 2020-02-19
5https://www.chartjs.org/ last accessed: 2020-02-19
6https://refreshless.com/nouislider/ last accessed: 2020-02-19
38
5.2 Additional JavaScript Frameworks
11 },
12 {
13 " value " :"item2",
14 " t e x t " :"NO"
15 }
16 ]
17 } ]
18 } ]
19 }
Listing 5.1: JSON Radio Button Example from the Distress Thermometer
Figure 5.2 shows the result of the radio button example, which can directly be inspected
in the Creator.
Figure 5.2:
Graphical Result of the Radio Button Example from the Distress Thermome-
ter
In the Feelback project, the NestJS service sends the JSON file of the questionnaire
directly to the Ionic mobile application, without using the infrastructure provided by Sur-
veyJS. This has multiple advantages, e.g. that the filled out questionnaire is directly sent
back to the NestJS service, where it can be evaluated in a custom manner. Moreover,
there is no dependency of a third party server infrastructure, increasing the reliability of
Feelback.
Next, the integration of Chart.js into the Ionic Feelback project is presented. Chart.js is
a JavaScript framework for displaying highly responsive charts. Although there are many
supported types of charts, the realized mobile application currently only makes use of
39
5 Implementation
line and polar charts. A line chart is used for visualizing a chronological sequence of
filled out questionnaires. This is a gamification concept for user motivation.
Polar charts are used for analyzing results of a questionnaire. In the Distress Ther-
mometer, there are five groups within the problem list, namely practical problems, family
problems, emotional problems, spiritual concerns and physical problems. For each
group, a part of the circle is drawn with respect to the total checked problems in the
questionnaire. Moreover, the scoring is normalized, because the number of problems
differ for each group. Figure 5.3 is an example evaluation, using a polar chart of Chart.js.
Figure 5.3: Questionnaire evaluation by means of a polar chart
The integration of Chart.js into Ionic is achieved with HTML Canvas elements. Canvas el-
ements are multimedia elements for all kinds of graphics and drawings. In the TypeScript
controller, developers can access these canvas elements by using Angular’s ViewChild
decorator.
40
5.3 Native Plugins
5.3 Native Plugins
Ionic supports feature-rich native plugins which can be integrated in applications by
developers. There is a distinction between Community and Premier plugins. Premier
plugins are developed by the Ionic team and are charged, whereas Community plugins
are a collection of open source software for Cordova. Native plugin means that the
software is dedicated to a specific platform, however a plugin can support multiple
platforms like Android, iOS and Windows. These plugins often communicate with
dedicated hardware of the device, like the camera, microphone or location sensors like
GPS.
For this thesis, a plugin for scanning QR Codes was used. It is called PhoneGap Plugin
BarcodeScanner and can scan several code types like QR Code, bar code and 14 others.
Supported platforms are Android, iOS, Windows and diverse browsers. Because this
plugin is integrated with Cordova, only Android and iOS are supported in Feelback.
Integrating native plugins into an Ionic project works as follows: First, developers
must add the plugin to cordova by calling
ionic cordova plugin add phonegap-
plugin-barcodescanner
. Next, a package manager of developers choice like npm
needs to add the source code to the project by calling
npm install @ionic-native-
/barcode-scanner
. Last, BarCodeScanner must be imported into the providers array
of the root app module.
1this . barcodeScanner . scan ( ) . then ( barcodeData => {
2console . log (’Barcode data’ , barcodeData ) ;
3} ) . catch ( e r r => {
4console . log (’Error’ , e r r ) ;
5} ) ;
Listing 5.2: BarcodeScanner Example
Listing 5.2 shows how to use the bar code scanner. By calling
barcodeScanner
.scan()
, the camera of the device is activated and ready to scan QR Codes. Within the
asynchronous callback at Line 2, the data of the QR Code can be used for further steps.
In the Ionic project, user credentials for patients are decoded for the authentication
41
5 Implementation
process, which are then sent to Keycloak afterwards. If something goes wrong, errors
can be caught within the asynchronous error callback (Lines 3 to 5).
5.4 Mockup Backend System
During development, there was a need for a functioning backend system, however at this
time the NestJS service did not exist. Therefore, a mock backend system was developed
by using a Node.js7server.
Within the Node.js server, a Typescript framework called faker.js
8
was used for generating
realistic data. Faker.js has functions for generating all kinds of fake data grouped by
addresses, commerce, company, databases, dates, finance and others. Additionally, a
location can be set for generating location specific data, which increases the realism of
the data. Also, randomness can be added by calling e.g.
random.number()
to receive
a random number. For Feelback,faker.js was used for generating fake users, patients,
practitioners, screenings and pending permissions.
1{
2" users " :[
3{. . . },{. . . },{. . . }
4]," screenings " :[
5{. . . },{. . . },{. . . }
6]
7}
Listing 5.3: JSON Server database
The fake data was utilized by another TypeScript framework called JSON Server
9
.
This framework automatically generates a Representational State Transfer (REST) API,
depending on a file database. This database is represented by a JSON file called db.json,
where routes and the corresponding objects are stored. Listing 5.3 is an example db.json
file, where users and screenings have three example objects. JSON Server automatically
7https://nodejs.org/en/ last accessed: 2020-02-19
8https://github.com/marak/Faker.js/ last accessed: 2020-02-19
9https://github.com/typicode/json-server last accessed: 2020-02-19
42
5.4 Mockup Backend System
generates two routes (/users and /screenings), addressed by auto generated GET, POST,
PUT, PATH and DELETE methods.
For full flexibility, an ordinary Node.js server was utilized, in order to provide cus-
tom API routes that extend the autogenerated routes of JSON Server. The auto-
matically generated routes by JSON Server can be integrated into Node.js by calling
server.use(jsonServer.bodyParser)
. An example of such a custom route is the
mockup authentication process. During development, the Feelback frontend needed an
authentication service, which returned fake tokens for patients and practitioners.
1server . post (’/auth/login’ , ( req , res ) => {
2l e t pseudonymOrEmail = req . body [ ’pseudonymOrEmail’ ] ;
3
4i f ( pseudonymOrEmail===’patient’ ) {
5res . stat u s (200) . jsonp ( {
6token : "token" ,
7r o l e : "patient"
8} ) ;
9}else i f ( pseudonymOrEmail===’practitioner’ ) {
10 res . stat u s (200) . jsonp ( {
11 token : "token" ,
12 r o l e : "practitioner"
13 } ) ;
14 } . . .
15 } ) ;
Listing 5.4: Node.js Mockup authentication
Listing 5.4 shows a very simple mockup authentication for the POST route /auth/login.
Depending on the field
pseudonymOrEmail
which is in the POST body, the Node.js
service authenticates a user as a patient or a practitioner by sending the status code 200.
With this technique, the frontend can show patient views for the patients and practitioner
views for the practitioners.
43
5 Implementation
5.5 Tabs and Routing Structure
In mobile applications, there are typically two basic approaches how a user navigates
within the application, in order to reach the functionality of the app. First, there is a menu
(or side menu), which can typically be activated by clicking a hamburger button. After
clicking, the menu slides from left or right into the view, containing all navigation items
that are available for the user. Second, there is the concept of tabs, which shows all its
content to the user. These tabs can also be divided into special tabs that show similar
content within a specific domain of the app and also hide themselves when users leave
the domain. The other variant shows the overall structure of the app constantly. Both,
side menus and tabs, have their advantages, however in Feelback constant tabs were
chosen, because constantly showing all available content of the app enhances user’s
orientation, especially when most users are elderly people.
Side menus are represented by Ionic’s ion-menu and tabs by ion-tabs and the corre-
sponding routing on it. In the Feelback project, patients and practitioners have their own
ion-tab, showing My Screenings,Permissions and Profile for patients and My Patients
and Profile for practitioners.
1{
2path : ’tabs2’ ,
3component : TabsPractitionerPage ,
4canActivate : [ AuthGuardService ] ,
5data : { ro les : Role . P r a c t i t i o n e r } ,
6c h i l d r e n : [
7{
8path : ’my-patient’ ,
9c h i l d r e n : [
10 {
11 path : ’’ ,
12 loadChildren : ’./../my-patient/my-patient.module#
,→MyPatientPageModule’
13 } ,
14 . . .
Listing 5.5: Routing for practitioners tabs
44
5.6 Generic Components
Listing 5.5 shows exemplary the routing of practitioners for such tab. When loading the
tab My Patients (Line 8 to 13), the module MyPatientPageModule is lazy loaded (Line
12) into the tab module. Lazy loading means, that the required module is only loaded
if it needs to. This technique dramatically improves performance in terms of load time
and application response. Additionally, the tabs for practitioners are protected with an
authentication guard (Line 4). This service checks, whether a user is authorized as a
practitioner and can, therefore, access the tab.
5.6 Generic Components
By default, Ionic generates its components (or pages) in separate modules, containing
the routing, controller, view, styling and unit testing, providing their functionality only for
the module itself. However, it is also possible to write custom Angular modules that
can provide functionality to other pages. With this approach, developers can generate
generic modules.
Listing 5.6 shows, that components which provide functionality to other components are
listed in the exports section. Also, it is vital to import the IonicModule (Line 8) when the
components within the generic module want to use Ionic’s components.
1@NgModule ( {
2de cl a ra ti o ns : [
3PermissionPatientComponent ,
4. . .
5] ,
6imports : [
7CommonModule,
8IonicModule
9] ,
10 exports : [
11 PermissionPatientComponent ,
12 . . .
13 ]
14 } )
Listing 5.6: Generic Angular Module
45
5 Implementation
When developers want to access e.g.
PermissionPatientComponent
, they can do
so by importing the whole generic module. This approach of generic components has
several advantages like great flexibility in the way of coding, which means that developers
are able to program just one generic component which can then be utilized in the whole
application.
Figure 5.4 shows the graphical representation of the
PermissionPatientComponent
component. Ionic’s ion-card component was used, which represents a card
10
. Input
parameters like titles and names can be set by utilizing the Angular decorator
@Input()
.
Setting these input parameters is done by standard input binding.
Figure 5.4: Generic Component Example
5.7 Reactive Forms
In Angular and therefore in the Feelback Ionic project, there are two basic types of forms,
namely reactive forms and template-driven forms. With both techniques, developers
can achieve the same result, whereas both have their advantages. In the Feelback
project, reactive forms were chosen, because of the following advantages compared to
template-driven forms.
Reactive forms are easier to unit test, because in an automated test, developers can
query and set its values by simply calling
form.value
. With template-driven forms,
this can only be achieved indirectly using the
@ViewChild()
decorator. Also, building
10https://material.io/components/cards/ last accessed: 2020-02-19
46
5.7 Reactive Forms
a reactive form mainly takes place in the controller of a component, whereas template-
driven forms are built in the view. Shifting the logic of a form to its controller is a clear
way of coding, since it enhances the idea of encapsulating logic of a component into
its controller. Finally, form validation can be programmed within the controller, because
this is the place where the form was built, increasing the clarity of code. Drawbacks of
reactive forms, as stated by developers, are that building and managing such forms feel
less intuitive, compared to template-driven forms. For this, Angular offers the FormBuilder
class for an easier building process, which can be seen in Listing 5.7.
Listing 5.7 demonstrates a reactive form, containing two FormControls.
Fb
is the previous
mentioned FormBuilder, which makes it easier to build FormGroups, FormControls and
FormArrays.
Fb.group
creates a FormGroup which is a container for FormControls like
pseudonymOrEmail
. A FormControl is a container for saving the value and state of an
input. The first argument in Listing 5.7 Line 2 of the square bracket is the default value
of the input, whereas the second argument defines validators for the input. Developers
can also define custom validators or asynchronous validators, for example, a validator in
the registration process, when at first a database lookup is processed, checking if the
entered username is already in use.
1loginForm = this . fb . group ( {
2pseudonymOrEmail : [ ’’ , V al i da to rs . re quired ] ,
3password : [ ’’ , V a li da to rs . required ]
4} ) ;
Listing 5.7: Reactive Login Form
Connecting the reactive form
loginForm
with the view is possible by the input binding
formGroup
, which is demonstrated in Listing 5.8. FormControls can be connected (see
Line 2) with the usage of formControlName binding.
1<form [formGroup ]=" loginForm " (ngSubmit )=" l o g i n ( ) " >
2<ion−input formControlName= " pseudonymOrEmail " type= " t e x t " >
3</ion−input>
4</form>
Listing 5.8: Reactive Login Form View
47
5 Implementation
5.8 Presentation of the Mobile Application
This section presents the user-interface of the developed application by showing screen-
shots of it. First, the patient’s domain is presented followed by the practitioner’s domain.
Figure 5.5a shows the welcome screen for a patient and a practitioner. Using the upper
button SCAN CARD users can login via QR Code, whereas with the lower button LOGIN
the login is performed manually via pseudonym and password.
Figure 5.5b depicts the manual login screen. In the screenshot a pseudonym was already
entered, but the password is missing. This is annotated with red color. By clicking on
LOGIN, the patient or the practitioner is redirected to the corresponding start screen.
FORGOT PASSWORD? redirects to a form, where users can enter their pseudonym or
email address.
(a) Welcome Screen (b) Login Screen
Figure 5.5: Welcome and Login Screen
48
5.8 Presentation of the Mobile Application
Figure 5.6: My Screenings View
Figure 5.6 shows the start screen of a patient. In tab My Screenings, the patient sees
previous screenings (Screening 1 to 4 in Figure 5.6). He/she can access them by clicking
the corresponding card. Furthermore, one particular screening can be analyzed by
clicking the green analyze button. An overall analysis is also possible, by clicking on the
white analyze icon on the top right corner. With the FAB button, a user can fill out new
screenings. The tabs Permissions and Profile are shown in Figure 5.13 and 5.14.
49
5 Implementation
(a) upper part (b) lower part
Figure 5.7: Screening 1
When users click on a single screening, Figure 5.7 is shown to the patient. In this
Figure, the Distress Thermometer questionnaire is used for visualization, showing that
the user entered 3.00 in the thermometer and several other values at the problem list.
The thermometer is visualized via a vertical slider that goes from bottom to top and is
also extended via the labels Extreme distress and No distress.
50
5.8 Presentation of the Mobile Application
Figure 5.8: Single Screening Analysis
Figure 5.9: Multiple Screening Analysis
Figure 5.8 depicts the screen, when a user clicks on the green analyse button within the
card on his/her start screen. Either by swiping or by clicking the arrow buttons, users
can analyse different screenings. Figure 5.9 shows overall analysis over every screening
using two different line charts. The upper line chart analyses the screening regarding
the group of the problem list, whereas the lower line chart shows the total amount of
filled out questionnaires.
51
5 Implementation
Figure 5.10: All Questionnaires
Figure 5.10 shows an overview of all available questionnaires of the system. This view is
shown, when users click on the FAB of Figure 5.6. For each questionnaire, a progress bar
is shown to users, where the current progress is depicted. This is a gamification concept,
where users can collect stars. By clicking on a questionnaire, users are redirected to
Figure 5.11a, where they can fill out the questionnaire.
52
5.8 Presentation of the Mobile Application
(a) Filling out a questionnaire (b) Missing answers
Figure 5.11: New Screening of Feelback
Figure 5.11 shows the user-interface for filling out a questionnaire. On Figure 5.11a
users can fill out the questionnaire and can save it with a save FAB button. Figure 5.11b
shows what happens when a user forgets to fill out a required field.
53
5 Implementation
(a) Questionnaire Completed 1 (b) Questionnaire Completed 2
Figure 5.12: Questionnaire Completed
Figure 5.12a shows the user-interface after a screening was completed. After five
seconds, the patient is redirected to Figure 5.12b where he/she is rewarded with XP. By
clicking on CONTINUE, patients and practitioners are redirected to the start screen.
54
5.8 Presentation of the Mobile Application
Figure 5.13: Permissions View
Figure 5.13 shows the second tab for patients, where pending permissions are shown to
the patient, when a practitioner requests access to a screening. The patient can either
allow or reject the request. Also, he/she can click on VIEW ANSWERS, in order to see
his/her answers, so the patient makes sure, that this is the right screening. The red
number next to the icon (99) indicates, that there are requests pending.
55
5 Implementation
(a) Profile 1 (b) Profile 2
Figure 5.14: Profile View
Figure 5.14 depicts the third and last tab for patients. Practitioners have the same profile
view, but on the second tab. In this profile section, users see their pseudonym, current
level, current points, multiplier and collected badges. Also, users can change the theme
of the app by clicking the corresponding color. Figure 5.14b shows the popover view for
changing the password and logout functionality when a user clicks on the gear icon.
56
5.8 Presentation of the Mobile Application
(a) My Patients tab (b) All Patients
Figure 5.15: Patients View
Figure 5.15 shows the start screen for practitioners, which lists all patients that are
currently assigned to the logged in practitioner. By clicking on the white add icon, the
practitioner is redirected to Figure 5.15b where all patients of the system are listed.
Patients who are already assigned to the practitioner are depicted with a greyed out plus
button and patients who can be assigned are depicted with a green plus button.
57
5 Implementation
(a) Detailed Patient View 1 (b) Detailed Patient View 2
Figure 5.16: Detailed Patient View
Figure 5.16 depicts the detail view of a patient when practitioners click on the correspond-
ing patient. Each screening is listed as a card, showing its title, questionnaire name,
access status and date of creation. The access status can either be Access granted
indicated with a green check icon, rejected indicated with a greyed out mail button and
ready for request, indicated with a green mail button. If a practitioner clicks on this green
mail button, a request is sent to the patient, containing a message, that this practitioner
wants to access this screening. A screening that can be accessed (first card in Figure
5.16a, namely Screening 1) is depicted in Figure 5.16a. By clicking the green add FAB
button, the practitioner makes a new screening for the patient by scanning the QR Code.
58
6
Related Work
In context of the Feelback project, related work is manifold. However, in this chapter
related topics are restricted to work containing self assessment questionnaires in various
scientific fields. Furthermore, related work that deals with mobile application in the
context of cancer and psychological illnesses is also considered.
6.1 Narrow Related Work
In the following, related work is divided into narrow and wider related work. Work that
utilizes similar approaches and is thematically related to this work is classified as narrow,
whereas wider related work is thematically related.
6.1.1 Pain Squad
Pain Squad is a mobile application developed by Stinson et al. to assess the pain level
of patients during cancer treatment. According to the authors, assessing pain is the
first vital step for managing pain. If pain is badly managed, it may result in anxiety and
distress and may develop psychological issues [26] in the long-term.
Most commonly, pain assessment is done by paper-based questionnaires. This has
several drawbacks like this technique often leads to inaccuracies, because questionnaires
are possibly not filled out during painful episodes. Reconstructing such events is biased.
Furthermore, patients tend to hoarding (back filling) questionnaires, which also lead
to inaccuracies [
26
]. In order to provide a way in which patients can digitally manage
59
6 Related Work
their pain level, Pain Squad enables patients to keep a diary for pain. In this application,
users play a fictitious law enforcement officer, in order to hunt down pain. With every
diary entry, users get closer to this goal [26].
One gamification concept in Pain Squad is the whole law enforcement theme of the app,
imitating a video game. Furthermore, the authors developed a ranking system in which
users can level up by filling out three reports (i.e., diary entries). The users are notified,
reminding them to keep the diary. The timing of the notifications can also be configured
in the options of the application. Another gamification concept that was implemented
are the video clips of law enforcement officers, acting as members of the squad. This
is sometimes used as promotion for the next rank or just as a reward. Also, users can
collect badges and medals, which are shown at a specific domain of the app (see Figure
6.1), where users also can play again the video clips [26].
Figure 6.1: Pain Squad [26]
Figure 6.1 shows the reward system in which ranks, badges, medals and videos are
presented. In the right part of Figure 6.1 a video is shown for rewarding the patient.
In order to provide a good user acceptance, it is vital that users can relate the gamification
aspect of the application to assessing pain. Stinson et al. had a theme Gum Shoe at
60
6.1 Narrow Related Work
first, but this could not be related to pain assessment, because it was unclear to users.
This negative user experience led to a new development, which resulted in the officer
theme, leading to an overall higher user acceptance [26].
Feelback and Pain Squad have several concepts in common. For example, several
gamification concepts like the reward system are used for motivating users. Also, self
assessment questionnaires enhance the medical treatment because of the higher patient
participation. In addition, the medical context of both applications is very similar, which
probably indicates, that concepts like self assessment questionnaires and gamification
can be applied in the field of cancer treatment. Several other studies like [
27
] indicate,
that this assertion is most probably true.
As previously mentioned, Pain Squad uses a theme, which is present in the entire user
interface, whereas Feelback uses its gamification concepts in a more subtle way. This
design principle is due to the fact, that the targeted average patient’s age of Pain Squad
is younger than in Feelback. Also, user acceptance of these gamification in Feelback
must be evaluated in further studies.
6.1.2 Pit-a-Pat
Among cancer patients, depression is a widespread accompanying illness which is only
detected by approximately 30% of the patients. This has several reasons like the lack of
time of clinical staff or patients feel not comfortable and reluctant with their mental state
[4].
In order to enhance the detection rate for depression among cancer patients, doctors
recommend to keep a daily diary, however this paper-based approach is error-prone,
because patients often reconstruct entries. Furthermore, for patients it is inconvenient to
keep a paper-based diary. For this purpose, Kim et al. developed an iOS and Android
application called Pit-a-Pat, in which patients can assess their mental health rating on a
daily basis. In the beginning of the study, patients fill out a demographic questionnaire
which questions age, educational attainment, marital status and occupation. After that,
patients can fill out the daily questionnaire on a self assessment basis [4].
61
6 Related Work
Figure 6.2: Pit-a-Pat: daily diary assessment [4]
Figure 6.2 shows the daily questionnaire which consist of sleep satisfaction, mood and
anxiety. This questionnaire checks whether the patient suffers from sleep disturbance
which is an indicator for mild depression. Quality of sleep and anxiety level were dis-
played as a distress thermometer with face emoticons. Everyday at nine am and six
pm, users receive notifications, which serve as a reminder to fill out the daily question-
naire. For result validation of the study, users were notified to fill out the Patient Health
Questionnaire-9 (PHQ-9) every two weeks.
In total, 78 patients participated in the study over a period of 48 weeks. The main
purpose was to investigate, whether it is possible to screen patients for depression,
using a digital application, which is completely based on self assessments. The authors
of [
4
] found out, that the self assessment approach is validated with a high accuracy
of depression screening. This validation was achieved by a calculation in which it is
assumed that PHQ-9 reported the correct screening.
In early 2013, Min et al. did a feasibility study for the Pit-a-Pat application and found out
that the overall compliance rate is 45%, which is higher compared to studies that do not
use such mobile applications [28].
Figure 6.3 depicts the compliance rate over 91 days, showing that there is a constant
decrease. The authors of [
28
] state, that this effect may results from patients that simply
62
6.2 Wider Related Work
Figure 6.3: Changes in compliance over time [28]
forget the notification. Additionally, it is noted that there are no gamification concepts in
Pit-a-Pat, compared to Feelback.
However, it is noteworthy that user interface elements, like the distress thermometer, are
used in a more playful way compared to Feelback. This difference is possibly justified
with cultural differences between Europe and Asia, because Pit-a-Pat is mainly applied
in South Korea.
6.2 Wider Related Work
Other related work that use questionnaires for self assessment in mobile applications
are [
27
] [
29
] [
30
] [
31
] [
32
]. However, the objectives of the mentioned publications are
manifold. The authors of [
27
] answer the question, whether it is possible to assess
the psychological state of patients by utilizing the application Mindful Moods. Again,
the application uses a subset of the PHQ-9 questionnaire. The objective of [
29
] is to
determine, whether users of the mobile application Health Monitor, are willing to go to
health care professionals when the application detects high depression symptoms. The
authors of [
30
] use self assessment mechanics to find out, whether it is possible to use
self-monitoring applications for enhancing the well-being of the users. In TrackYour-
Tinnitus they developed a mobile application for assessing the fluctuations of tinnitus
during daily routines. In addition, the microphone of a smartphone detects a loudness
value when filling out questionnaires [
32
]. In [
31
] they try to detect emotional changes
63
6 Related Work
during the day, by using self assessment techniques. In Feelback, such techniques
are utilized, in order to screen for psychological distress among patients suffering from
cancer. Several studies like [
29
] show, that mobile applications are a valid approach for
this.
Findings of the mentioned articles that are worth mentioning are, for example, that a
digital subset of the PHQ-9 questionnaire is as accurate as the paper-based. Further-
more, patients with suicidal ideation can be better detected compared to the traditional
paper-based approach [
27
]. BinDhim et al. showed, that approximately 38% patients
with high depressive symptoms consult a health care professional, if the mobile appli-
cation detects high depressive symptoms [
29
]. The authors of [
30
] found out, that it is
possible to decrease patients’ depressive and anxious emotional state and increase
their well-being by using self assessment questionnaires. However, this effect was just
detected among patients that are rated as clinically depressed at time of the baseline
assessment [
30
]. Pryss et al. showed exemplary for a patient, that the assessed tinnitus
loudness fluctuated the most in quiet environments, whereas the tinnitus was perceived
in a lower level when the environment was louder. Also, the perceived tinnitus loudness
was depicted over time and it showed, that for this individual patient the loudness value
increased over the day reaching its maximum at night [32].
Several publications like [
27
] indicate, that self assessment using questionnaires is a valid
way of screening, diagnosing and monitoring patients. Also, such mobile applications
are used for a method which is called Experience sampling method. In this method,
users keep a diary for assessing symptoms on a daily basis.
64
7
Discussion
In this chapter, general limitations as well as alternative approaches are presented.
Moreover, fundamental concepts like gamification for elderly people are discussed.
As already mentioned in Chapter 5.3, Ionic provides Community and Premier plugins.
Community plugins are a collection of open source software for Cordova, maintained
by the community, whereas Premier plugins are maintained by the Ionic core team.
During development, the mobile application required functionality for scanning QR
Codes. The first search within the ionic homepage for an appropriate plugin resulted
in the open source project QR Scanner
1
. However, with the introduction of Swift 5
2
in
March 2019, there were severe changes, which broke the native compilation process of
QR Scanner. This example demonstrates the underlying problem of poor maintained
third party software. Developers should always keep in mind that with the release of
breaking major releases, the third party software must be updated to this release as well.
What is also often a problem of these third party software is the missing or incomplete
documentation, which leads to ambiguities in using the API resulting in bugs.
Another limitation which should be mentioned, are the short development cycles of Ionic.
Frontend frameworks, especially in web technology, tend to change very frequently.
Since Ionic is a framework in this domain, there are new major releases roughly every
six months which lead to breaking changes. This means, in order to maintain an Ionic
project, high development costs are to be expected. During writing this thesis, the new
Ionic version 5.0.0 was released, which should be considered as the next development
1https://ionicframework.com/docs/native/qr-scanner last accessed: 2020-02-20
2https://swift.org/blog/swift-5-released/ last accessed: 2020-02-20
65
7 Discussion
step, since the current used version is 4.11.10. The migration process
3
from major
version 4.X to 5.0 could probably take some time, because there are breaking changes
in APIs for various components. Since the underlying major version of Angular also
changes (from 8 to 9), this also comes with changes for someone’s own project as well
as in third party software. Used third party software could be build with major version 8,
which would probably break the software as a whole.
In Chapter 5.2, the usage of the JavaScript framework SurveyJS was introduced. This
usage involves several limitations to the Feelback project. SurveyJS supports all types
of questions like single choice questions or multiple choice questions, but only supports
about 15 custom widgets like the previously mentioned noUiSlider. Additionally, the
integration of these widget’s API is in some cases poorly managed like it was here
the case. In case of the noUiSlider, special features like sliding from right to left could
not be integrated into SurveyJS. Since SurveyJS/widgets
4
is an open source project,
developers can overcome this problem by extending the source code. This was done in
Feelback
5
, so the noUiSlider can be used as a Distress Thermometer in the correspond-
ing questionnaire, in order to map the paper-based Distress Thermometer (see Figure
2.2). Note that developers which use SurveyJS are always restricted to the supported
widgets. Moreover, when extending the source code of SurveyJS/widgets, developers
are always dependent on staff of SurveyJS that accept the pull requests on GitHub.
Of course, this hurdle can be overcome by writing a custom questionnaire framework,
but this approach consumes many resources, in order to provide as many features as
SurveyJS has. Furthermore, the integration of third party JavaScript frameworks into
someone’s own project increases the dependency to other software, which involves
limitations to the project. For example, the project, which uses the third party software is
dependent on the maintenance of the third party software. As one can see in the previ-
ous paragraph dealing with the QR Scanner, this is often a pitfall for software projects. If
the maintenance of a third party software has stopped, developers should consider to
use another framework. This process is always resource consuming and probably could
3https://github.com/ionic-team/ionic/blob/master/BREAKING.md
last accessed: 2020-
02-21
4https://github.com/surveyjs/widgets last accessed: 2020-02-20
5https://github.com/surveyjs/widgets/pull/156 last accessed: 2020-02-28
66
lower the quality of the software project, since the new third party framework has e.g.
different functionality or even a different user interface.
Another limitation of this work was that there was no backend available during develop-
ment. In order to develop the frontend independently, the backend was simulated using
a mockup component (Chapter 5.4). This approach has limitations, for example, when
the real backend is deployed, the mobile application must possibly be adapted to the
new backend. Also, it is required that the entire functionality of the mobile application is
tested when such critical software part changes. For this, the existing unit tests should
indicate, whether the real backend acts in an expected or unexpected manner.
As described in Chapter 4.2, several gamification frameworks do not consider elder
people in their conception [
23
]. Most probably, this is due to fact, that the target group for
gaming in mobile applications are younger persons. However, when developing concepts
for long term motivating patients in mobile eHealth applications, elderly people are the
largest target group. Because of this fact, special focus should be put on those people.
In several gamification frameworks like in [
24
], players are classified into specific player
types. This classification describes players with their personality, regardless of their age.
Furthermore, it can be expected that all humans have a certain play instinct, which is
also independent of age. For certain video games like Counter Strike, there are groups
of elderly people playing together in clans. They call themselves Silver Gamers, playing
on several tournaments all over the world
6
. However, in this field further research is
required, to examining gaming techniques for elderly people.
Finally, the change of the current process in a medical facility should also be considered.
As described in Chapter 3.1, the current process of screening patients with subsequent
psychological consultation is mostly paper-based. In order to digitalize this process,
several steps are necessary to restructure the hospital’s internal work-flow. For example,
the HIS current used must be extended, in order to communicate with Feelback. Further-
more, medical staff like practitioners or people who are directors of studies must be able
to operate with smartphones, in order to explain critical features of the application, if the
patient requests this help.
6https://www.arte.tv/de/videos/086138-021-A/re-silver-gamers/
last accessed: 2020-
02-21
67
8
Conclusion
The objective of this thesis was to develop a medical, mobile application with principles
of patient participation, gamification and self assessment questionnaires. Such concepts
will enhance the screening process and, therefore, result in a better overall psychological
treatment of patients. The application field of this software is in a medical setting, where
a) cancer patients are screened for psychological issues and b) practitioners of different
parties access these screenings, in order to treat the patient.
This goal was reached with the help of the mentioned techniques. Patient participation
enhances the medical treatment process, because patients take a more active role in
decision making processes. This leads to a better overall treatment. Moreover, the
developed application enhances the medical screening process by digitalizing the latter.
With this approach, results can be evaluated in an automated manner. Furthermore,
the communication between patients, practitioners and other participating parties, like
psychologists is enhanced.
This medical application fulfills a patient centralized approach. Whenever practitioners
want to access data from patients, the patient has to permit access to this person. This
technique increases trust in the system, which most likely result in proper data of the
self assessment questionnaires.
Furthermore, this thesis describes the current As-Is process and what is needed for the
To-Be process. Within this thesis, the integration of the mobile application into the To-Be
process is described. This enhances the communication of the participating parties by
using a dedicated application.
69
8 Conclusion
Concepts for long term motivation like gamification enhance user experience on the one
side and the generated data from the self assessment questionnaires on the other side,
because the study dropout rate is low.
Finally, this thesis describes the user interface of Feelback, which contains all the
previously mentioned principles.
8.1 Further Research
In order to run this application in a productive environment, several tests are necessary.
First, End to End testing frameworks like Cypress
1
should be utilized for writing such
automated tests. For this, Cypress seems to be a profound framework, because it is an
All-in-One solution and furthermore provides constant results of tests [33].
In a next step, the technical aspects of the mobile application should be tested by
humans (e.g. beta testers). Special focus should be put on different environments
like iOS, Android and various browsers. Furthermore, several display sizes should be
evaluated by using different devices like smartphones or tables.
The next step is to evaluate the overall user acceptance of the application. The design
of the user interface and clarity of routing should be evaluated. Additionally, it is vital to
evaluate, whether the gamification concepts of Feelback work as expected. This can
be checked with large scale acceptance testing. Here, special focus should be put on
elderly people and whether these gamification concepts motivate them.
It is also important to test the mobile application again when the development of the final
backend system is completed. This is due to the fact, that migrating from the mockup
backend to the real backend will require certain adaptations.
Finally, the entire system which is integrated in a medical facility should also be eval-
uated in a further work. Within this test, special focus should be put on the seamless
communication between Feelback and existing HIS.
1https://www.cypress.io/ last accessed: 2020-03-03
70
Bibliography
[1]
Maguire, P.: Improving the detection of psychiatric problems in cancer patients.
Social science & medicine (1985)
[2]
Zabora, J., BrintzenhofeSzoc, K., Curbow, B., Hooker, C., Piantadosi, S.: The
prevalence of psychological distress by cancer site. Psycho-Oncology: Journal of
the Psychological, Social and Behavioral Dimensions of Cancer 10 (2001) 19–28
[3]
Stark, D., Kiely, M., Smith, A., Velikova, G., House, A., Selby, P.: Anxiety disorders
in cancer patients: their nature, associations, and relation to quality of life. Journal
of clinical oncology 20 (2002) 3137–3148
[4]
Kim, J., Lim, S., Min, Y.H., Shin, Y.W., Lee, B., Sohn, G., Jung, K.H., Lee, J.H., Son,
B.H., Ahn, S.H., et al.: Depression screening using daily mental-health ratings from
a smartphone application for breast cancer patients. Journal of medical Internet
research 18 (2016) e216
[5]
Moser, A., Steckelberg, A., et al.: Patient participation-what is it? Zeitschrift für
Evidenz, Fortbildung und Qualitat im Gesundheitswesen 110 (2016) 12–15
[6]
EPF: Epf background brief: Patient empowerment.
https://www.eu-patient.
eu/globalassets/campaign-patient-empowerment/epf_briefing_
patientempowerment_2015.pdf (2015) last accessed: 2020-01-17.
[7]
Bate, P., Robert, G.: Experience-based design: from redesigning the system
around the patient to co-designing services with the patient. BMJ quality & safety
15 (2006) 307–310
[8]
Eysenbach, G.: What is e-health? Journal of medical Internet research
3
(2001)
e20
[9]
Deterding, S., Khaled, R., Nacke, L.E., Dixon, D.: Gamification: Toward a definition.
In: CHI 2011 gamification workshop proceedings. Volume 12., Vancouver BC,
Canada (2011)
71
Bibliography
[10]
Sardi, L., Idri, A., Fernández-Alemán, J.L.: A systematic review of gamification in
e-health. Journal of biomedical informatics 71 (2017) 31–48
[11]
Holland, J.C.: History of psycho-oncology: overcoming attitudinal and conceptual
barriers. Psychosomatic medicine 64 (2002) 206–221
[12]
Gundlach, H.: What is a psychological instrument. Psychology’s territories:
Historical and contemporary perspectives from different disciplines (2007) 195–224
[13]
Network, N.C.C., et al.: Distress management. clinical practice guidelines. Journal
of the National Comprehensive Cancer Network: JNCCN 1(2003) 344
[14]
Zigmond, A.S., Snaith, R.P.: The hospital anxiety and depression scale. Acta
psychiatrica scandinavica 67 (1983) 361–370
[15]
Rumpold, G., Augustin, M., Zschocke, I., Strittmatter, G., Söllner, W.: Die Validität
des Hornheider Fragebogens zur psychosozialen Unterstützung bei Tumorpatienten.
PPmP-Psychotherapie
·
Psychosomatik
·
Medizinische Psychologie
51
(2001) 25–33
[16]
Herschbach, P., Marten-Mittag, B., Henrich, G.: Revision und psychometrische
Prüfung des Fragebogen zur Belastung von Krebskranken (FBK-R23). Zeitschrift
für Medizinische Psychologie 12 (2003) 69–76
[17]
Herschbach, P.: Behandlungsbedarf in der Psychoonkologie. Der Onkologe
12
(2006) 41–47
[18]
Herschbach, P., Weis, J.: Screeningverfahren in der Psychoonkologie.
Testinstrumente zur Identifikation betreuungsbedürftiger Krebspatienten. Berlin:
Deutsche Krebsgesellschaft (2008)
[19]
Jacobsen, P.B., Donovan, K.A., Trask, P.C., Fleishman, S.B., Zabora, J., Baker, F.,
Holland, J.C.: Screening for psychologic distress in ambulatory cancer patients: a
multicenter evaluation of the distress thermometer. Cancer
103
(2005) 1494–1502
[20]
Coyne, J.C., Palmer, S.C., Shapiro, P.J., Thompson, R., DeMichele, A.: Distress,
psychiatric morbidity, and prescriptions for psychotropic medication in a breast
cancer waiting room sample. General hospital psychiatry 26 (2004) 121–128
72
Bibliography
[21]
Cockburn, A.: Structuring use cases with goals. Journal of Object-Oriented
Programming 10 (1997) 56–62
[22]
Pike, M.C., Krailo, M., Henderson, B., Casagrande, J., Hoel, D.: ‘Hormonal’ risk
factors, ‘breast tissue age’ and the age-incidence of breast cancer. Nature
303
(1983) 767–770
[23]
de Vette, F., Tabak, M., Dekker-van Weering, M., Vollenbroek-Hutten, M.: Engaging
elderly people in telemedicine through gamification. JMIR serious games
3
(2015)
e9
[24]
Marczewski, A.: User types. Even Ninja Monkeys Like to Play: Gamification, Game
Thinking and Motivational Design 1(2015) 65–80
[25]
Primack, B.A., Carroll, M.V., McNamara, M., Klem, M.L., King, B., Rich, M., Chan,
C.W., Nayak, S.: Role of video games in improving health-related outcomes: a
systematic review. American journal of preventive medicine 42 (2012) 630–638
[26]
Stinson, J.N., Jibb, L.A., Nguyen, C., Nathan, P.C., Maloney, A.M., Dupuis, L.L.,
Gerstle, J.T., Alman, B., Hopyan, S., Strahlendorf, C., et al.: Development and
testing of a multidimensional iphone pain assessment application for adolescents
with cancer. Journal of medical Internet research 15 (2013) e51
[27]
Torous, J., Staples, P., Shanahan, M., Lin, C., Peck, P., Keshavan, M., Onnela,
J.P.: Utilizing a personal smartphone custom app to assess the patient health
questionnaire-9 (phq-9) depressive symptoms in patients with major depressive
disorder. Journal of medical Internet research mental health 2(2015) e8
[28]
Min, Y.H., Lee, J.W., Shin, Y.W., Jo, M.W., Sohn, G., Lee, J.H., Lee, G., Jung, K.H.,
Sung, J., Ko, B.S., et al.: Daily collection of self-reporting sleep disturbance data via
a smartphone app in breast cancer patients receiving chemotherapy: a feasibility
study. Journal of medical Internet research 16 (2014) e135
[29]
BinDhim, N.F., Alanazi, E.M., Aljadhey, H., Basyouni, M.H., Kowalski, S.R., Pont,
L.G., Shaman, A.M., Trevena, L., Alhawassi, T.M.: Does a mobile phone depression-
screening app motivate mobile phone users with high depressive symptoms to seek
73
Bibliography
a health care professional’s help? Journal of medical Internet research
18
(2016)
e156
[30]
Bakker, D., Rickard, N.: Engagement in mobile phone app for self-monitoring of
emotional wellbeing predicts changes in mental health: Moodprism. Journal of
affective disorders 227 (2018) 432–442
[31]
Rickard, N., Arjmand, H.A., Bakker, D., Seabrook, E.: Development of a mobile
phone app to support self-monitoring of emotional well-being: a mental health
digital innovation. Journal of medical Internet research mental health
3
(2016) e49
[32]
Pryss, R., Reichert, M., Langguth, B., Schlee, W.: Mobile crowd sensing services for
tinnitus assessment, therapy, and research. In: 2015 IEEE International Conference
on Mobile Services, IEEE (2015) 352–359
[33]
Wohlwend, V.: Comparative Analysis of UI Testing Frameworks for Web Applications.
Bachelor’s thesis, Ulm University, Ulm (2019)
74
List of Figures
2.1 Continuum of Patient Influence [7] . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Distress Thermometer [13] . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 As-Is Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 To-Be Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Technical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Registration for Feelback . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Evaluation of a Screening . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Different Parties Request Screenings . . . . . . . . . . . . . . . . . . . . . 22
3.7
Mockups for Welcome, QR Code Scan, Manual Login and Forgot Password
24
3.8 My Screenings Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.9 New Screening Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.10 Permissions Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.11 Profile Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.12 Questionnaire Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.13 Answers Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.14 My Patients Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.15 All Patients Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.16 Screenings Of a Patient . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.17 Add Patient Mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Marczewski’s Player Type Model [24] . . . . . . . . . . . . . . . . . . . . . 31
5.1 Example Responsive Grid of Ionic . . . . . . . . . . . . . . . . . . . . . . 36
5.2
Graphical Result of the Radio Button Example from the Distress Thermometer
39
5.3 Questionnaire evaluation by means of a polar chart . . . . . . . . . . . . . 40
5.4 Generic Component Example . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5 Welcome and Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.6 My Screenings View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.7 Screening 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
77
List of Figures
5.8 Single Screening Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.9 Multiple Screening Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.10 All Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.11 New Screening of Feelback . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.12 Questionnaire Completed . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.13 Permissions View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.14 Profile View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.15 Patients View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.16 Detailed Patient View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1 Pain Squad [26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Pit-a-Pat: daily diary assessment [4] . . . . . . . . . . . . . . . . . . . . . 62
6.3 Changes in compliance over time [28] . . . . . . . . . . . . . . . . . . . . 63
A.1 Example Design for a QR Code Card . . . . . . . . . . . . . . . . . . . . . 75
78
List of Tables
2.1 Basic Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Required Experience For The First Few Levels . . . . . . . . . . . . . . . 32
4.2 Required Experience For The First Few Stars . . . . . . . . . . . . . . . . 33
4.3 The Badge System of Feelback . . . . . . . . . . . . . . . . . . . . . . . . 34
79
Acronyms
API Application Programming Interface. 19, 35, 42, 43, 65, 66
CSS Cascading Style Sheets. 35, 37
EPF European Patients’ Forum. 5
FAB Floating Action Button. 23, 49, 52, 53, 58
GPS Global Positioning System. 41
HIS Hospital Information System. 2, 14, 15, 67, 70
HTML Hypertext Markup Language. 35, 40
JSON JavaScript Object Notation. 38, 39, 42, 75
PWA Progressive Web App. 20
QR Quick Response. 15, 16, 18, 20, 23, 24, 26, 41, 48, 58, 65, 75, 77
REST Representational State Transfer. 42
XP Experience Points. 32, 33, 54
81
Name: Michael Schrempp Matriculation number: 865625
Honesty disclaimer
I hereby affirm that I wrote this thesis independently and that I did not use any other
sources or tools than the ones specified.
Ulm, .................................................................................
Michael Schrempp
07.04.2020
