Requirements and Design of a Platform for Internet- and Mobile-based Interventions [original]

Ulm University | 89069 Ulm | Germany

Faculty of Engineering,

Computer Science and Psychology

Institute of Databases and Information Systems (DBIS)

Requirements and Design of a Platform

for Internet- and Mobile-based

Interventions

Bachelor Thesis at Ulm University

Submitted by:

Sabrina Böhm

[email protected]

868071

Reviewer:

Prof. Dr. Manfred Reichert

Advisor:

Robin Kraft

2020

Last updated: May 28, 2020

2020 Sabrina Böhm

This work is licensed under the Creative Commons

Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of

this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ .

Typesetting: PDF-L

TEX2ε

Abstract

Mental health and the therapeutic care of patients is a topic that is applied daily. Whether

mental or physical health, usually everyone can complain about something. Due to

digitalisation, the topic of mental health must also be raised to a higher level. The

eSano system represents a platform that explicitly deals with the concept of e-health in

order to provide online support for therapeutic care. The online therapy is provided via

so-called Internet- and Mobile-based interventions (IMIs), which are carried out by the

patients. The basic principle is that an eCoach accompanies the patient through guided

interventions, but the patient also has the possibility to carry out an unguided intervention

in a self-guiding manner. As a result of the possibility to perform the interventions on

the mobile phone at any time, the use is very flexible, independent of location and can

be easily integrated into everyday life. In addition to an application for patients and

therapists, there is also a platform for intervention creation and editing, which is the

beginning of the development of IMIs for psychological support. In this bachelor thesis

the requirements and the conceptual design of the eSano platform are identified and

presented. The functional and non-functional requirements to be realized in the final

system form the basis of the design concept. Starting with the basic architecture of the

platform, creating and participating in interventions and the implementation of individual

modules of the therapy, this thesis presents the connection and communication between

the systems and roles involved. Furthermore, aspects such as distribution of rights,

privacy and security are addressed and basically defined. Due to the realization of a

requirements engineering process of the complete eSano system, the results of this

thesis form a good basis for any further work with the project.

Contents

Abstract iii

1 Introduction 1

1.1 Motivation................................... 1

1.2 Purpose.................................... 1

1.3 Approach ................................... 2

1.4 Structure of the thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Fundamentals 5

2.1 Glossaryofterms .............................. 5

2.2 Structure of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Actors..................................... 8

2.4 RelatedWork................................. 9

3 Requirements 13

3.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Accounts ............................... 14

3.1.2 Groups ................................ 18

3.1.3 Interventions ............................. 22

3.1.4 Therapy................................ 27

3.1.5 Furtherfeatures ........................... 30

3.2 Non-Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Design 41

4.1 Architecture.................................. 41

4.2 Groups, roles and rights . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 DataModel .................................. 47

4.4 Communication channel . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.5 PrivacyandSecurity............................. 60

5 Conclusion 63

5.1 Summary ................................... 63

5.2 Discussion .................................. 63

5.3 Outlook .................................... 64

1 Introduction

The Institute of Psychology and Education, Department of Clinical Psychology and

Psychotherapy at Ulm University, which intensively researches online therapy and

especially the work with interventions, founded a project in which the concept of online

therapy will be implemented, called eSano [

]. In the following a short motivation of the

realization of e-health is the given, as well as the approach and the structure of this

thesis.

1.1 Motivation

Each of us may one day have physical, emotional or psychological complaints. Through

changes in our thinking and acting these problems can be improved or even eliminated.

For any kind of personal restriction, e.g., back pain, depression or anxiety disorders,

there should be online modules that are specially adapted. In order to be able to

implement these changes, continuous and individual care is necessary. Some people

do not have the courage to contect a psychotherapist or are not willing to undertake a

weekly practice. For beginners as well as patients who have been in care for a long

time, the eSano project will offer support. This platform should not only provide support

for patients, but also for therapists and intervention editors. Patients can be guided

and treated by online therapists. Besides that, the therapists can use the facility to

treat and care for their patients easily. Its is a user-friendly E-Mental Health platform,

with a versatile product catalogue of online modules, diaries and interventions. Further,

patients can join different studies through which they can participate in interventions

that are either unguided or guided by an online therapist, also called eCoach. It is said,

that online interventions work for many conditions, have long-term effects and can be

as effective as face-to-face therapy. The mobile app for patients also offers a feeling of

independence of place and time.

1.2 Purpose

The eSano mobile app created for patients should be seamlessly integrated into a

patient’s everyday life, thus creating comfortable and flexible usage. Also for therapists

1 INTRODUCTION

the application should offer advantages like a good overview of their patients as well as a

digitalized version of all tasks a patient has done and especially how they manage them.

In addition, the progress should be easily tracked and related persons should be easily

integrated via the platform. In order to be able to offer this patient overview, a system is

required which can manage a lot of data and also treat it confidentially. Studies should

be created and managed for specific groups of patients and diseases by therapists. The

individual online interventions that a patient performs should be created in the content

management system (CMS) and should there be managed and also edited. To finally

offer such a software product good requirements and design specifications are needed.

1.3 Approach

To get an introduction to the existing project, I met with all the people responsible for the

respective subsystems. Weekly meetings in which all participants were represented and

additional individual meetings depending on the current topic were held throughout the

entire project. In order to get an exact idea of the system design and a specification for

the requirements, many mockups, drawings and ideas had to be discussed. Many new

improvements of various aspects were made throughout the project, including existing

requirements as well as completely new designs. Also individual meetings with the

responsible psychologists of the University of Ulm of the eSano project were informative,

since they acted as clients. They always had the health technology perspective, so that

the specifications never lost sight of the goal. On the other hand, they were also open

to technical suggestions from the computer scientist’s point of view in order to stand out

from the similar systems already in existence. All in all, many suggestions to improve

the existing system and the question how to bring it to its goal were thought through and

then written down in requirements and design proposals. The results of these meetings

therefore the requirement specification is summarized in this thesis.

1.4 Structure of the thesis

This thesis gives an overview of the project requirements and describes its functionality

and purpose. In Chapter 2, it will be explained into which subcomponents the system

is divided and what they do in detail. Furthermore, all roles involved in the system

and their interaction with each other and with the system itself are described. The

communication is explained in Section 4.4. The focus is on the functional and non-

functional requirements presented in Chapter 3 which must all be fulfilled by the final

system. The second main aspect of this work is the conceptual design, which deals with

the realisation of all requirements. In Chapter 4, particular reference is made to certain

1.4 STRUCTURE OF THE THESIS

aspects such as communication and organisation between the users of the system. In

addition, a number of processes are presented, in which the most important interactions

of the users involved are described.

2 Fundamentals

In the following the basic boundary conditions are summarized and explained to get a

first insight and a good understanding of the system that should be implemented.

2.1 Glossary of terms

The following tables will explain crucial individual technical terms, which are needed for

a better understanding of the requirements.

Name intervention

Description

Interventions, also known as training, in coaching to

provide the client with the appropriate tools to achieve

his or her self-chosen goal or to support him or her in a

certain phase of life. They consist of individual lessons

and are either unguided or guided by an eCoach.

Name training

Description

Training describes the interventions that can be carried

out by patients without guidance. So-called unguided

interventions.

Name study

Description

Studies are groups created by eCoaches on the eCoach

platform to treat a particular area. This is where the ac-

tual guidance between patient and eCoach takes place

through an intervention.

2 FUNDAMENTALS

Name guidance

Description

The guidance refers to the assignment of a patient to

an intervention accompanied by an eCoach. All pa-

rameters are defined, which are valid for each patient

as an individual at his guidance with his eCoach per

intervention.

Name lesson

Description

Interventions consist of individual lessons, also called

modules, which consist of various pages with lesson

elements. For example, an element in a lesson can be

of the following type:

•Text (pictures are also possible here)

•

Media (including pictures, videos, audio files, etc.)

•Questions (yes/no, slider, multiple choice, etc.)

Lessons may be time-dependent, which means that the

patient has a certain amount of time to process the

lesson to move on to the next lesson.

Name eCoach

Description

An eCoach is an online therapist who cares for patients.

He is participant of special groups or studies. He is the

first point of contact for patients.

Name editor

Description

An editor is a user of the system who can create the

interventions in the CMS. He can also edit and assign

the interventions to studies.

Name mentor

Description

The relationship between patient and eCoach can be de-

scribed in that each patient has one eCoach as mentor

per intervention.

2.2 STRUCTURE OF THE SYSTEM

2.2 Structure of the system

There are different roles in the system such as editors, eCoaches and patients, therefore

it is necessary to provide an adapted representation of the eSano system for the

respective user. For this reason, the system is essentially divided into four parts, three

of which represent the platforms of the respective users.

The eCoach platform

The eCoach platform is a work environment for therapists that supports the monitoring

and feedback processes and simplifies the management of studies, groups, interven-

tions, and training for patients and other therapists. With components and external tools

to observe and evaluate patients’ activities, messages, and answer sheets, it allows

therapists to provide better care, manage ongoing interventions and take preemptive

measures to intervene in cases of emergency.

The patient app

The patient platform embodies the patient’s access point to the system. It shows

interventions of the patient and provides all functionalities to be able to participate in

them and grants the possibility to interact with the corresponding eCoach. This module

can be used by any kind of user. A mobile app is also available helping to integrate the

application even more into everyday life.

The content management system

The content management system (CMS) allows its users to create and manage inter-

ventions and their corresponding lessons. This module will only be available to editors

and admins. Interventions or individual lessons can be created and modified in this

part of the system. Editors can also assign rights those who have access to individual

interventions. Furthermore, all administrative tasks are controlled from here.

The backend

The backend is a web server that provides and manages all data used by the other

system parts. All data generated by the other three parts is stored on the backend

and can be exchanged through it. Communication takes place exclusively through the

backend. The data is sent to the backend and from there to the corresponding platform.

For the storage of the account data and all other important data, a database is available

which is connected to the backend. More details about the architecture can be found in

chapter 4.

2 FUNDAMENTALS

2.3 Actors

The following section describes the actors of the system. Actors are the different user

roles describing capabilities, duties and restrictions for different parts of the system.

Actor eCoach

Role

The eCoach is a therapist for patients providing tasks and

monitoring the progress of such. The therapist can assign

interventions to patients and monitor their progress. He

stays in contact with the patients and thus represents the

connection from patient to the therapy.

Actor editor

Role

The editor can create or modify interventions in the content

management system. When he creates an intervention

he becomes the owner of such and can only modify those

of which he has got the editing rights or those that are

contained in the workgroups of which he is a member of.

For his own interventions he can further enable other editors

to edit.

Actor patient

Role

Is the most basic user of the system. Patients can facilitate

the system to complete therapeutic measures and interact

with eCoaches. One can register for studies and receives

assigned interventions from the responsible eCoach. He

can also participate in guided or unguided interventions.

Actor admin

Role

Admins administers the system and assigns roles such as

the manager status to users. He can login to the content

management system and the eCoach platform. He has full

control of the system and also takes care of the IT support

as well as help requests.

For the final system, it is intended that a user who has an editor and also an eCoach

account, that it is possible to change the platform and the role easily. So it should be

2.4 RELATED WORK

explicitly possible that an editor creates an intervention in a workgroup in the CMS and

assigns it directly after publishing to a study in which he wants to have this intervention.

2.4 Related Work

E-therapy is initially understood as the interaction between a person and a therapist via

the Internet. Help is to be offered in conjunction with a structured web-based program for

medical psychological care. In the field of mental health there are a numerous systems

that already offer this in the form of internet based interventions (IMIs). A few of these

are presented below. By digitizing the therapy, progress can be recorded and observed

in digital form. This has advantages for both patient and therapist. In addition, there are

no restrictions with regard to the disease or age groups. The problems to be treated

range from physical illnesses such as back pain to psychological problems like exam

nerves or depression. For each topic there are different studies, in which one can get

support in the form of individual modules, also called interventions. The interventions

can be either guided or unguided. The possible guidance by a supervising eCoach is an

advantageous feature of IMIs. Since the concept of online support carries a great deal of

health responsibility, some guidelines must be followed on the psychological as well as

on the implementation side. These include, for example, the confidential handling of data

and the Medical Devices Act, which must be observed during programming [

]. On

the whole, the integration of the system into the everyday life of the patient offers many

advantages but also new difficulties that arise compared to the outdated face-to-face

approach.

Internet- and mobile-based interventions

Internet- and mobile-based interventions, also called IMIs, are applications based

on an instructive online program, which are provided on a website or as part of an

app. They are used by people seeking health-related assistance [

]. Usually the

interventions consist of individual lessons with different types of elements. These

lessons are individual modules consisting of questionnaires and media, which can

be used flexibly and individually, regardless of time and place. Feedback from the

mentor after the completion of the lessons is an important process to show the patient’s

individual progress. Further benefits for patient care, especially for monitoring safety,

progress and outcomes, as well as input for research purposes are also provided [

For unguided interventions the control of the modules is in the hands of the patient. In

itself, the internet version of the therapy is associated with a lot of self-initiative and

self-discipline. The difference in the effect between guided and unguided interventions

is less pronounced than assumed, but studies show that results of guided interventions

2 FUNDAMENTALS

were significantly superior to those of unguided interventions [

]. If all study participants

are conducted in a uniform manner, progress can also be seen depending on the

therapist, although the qualification of the eCoaches seems to be less important [

Even though a smartphone use is more likely to be associated with younger people,

but the concept also has potential for older age groups, these are generally less likely

to seek psychological treatment [

]. Furthermore, not only older people have an

inhibition to seek support for their complaints. Through the anonymity that the internet

offers, the gap between treatment and demand is reduced, e.g., patients who may

have been left untreated for many years can now receive psychological treatment

adapted to their needs through the internet and health management [

]. Through

apps patients are actively enabled to participate in the decision how their health or

illness is to be managed, even for those who have not been able to obtain specialist

care due to financial constraints [

]. The concept of internet addiction, which is

common among young people today, suggests that online therapy is not advisable in

these cases. However, studies have shown that here too, interventions can be helpful

to divert excessive concentration on certain activities of the young people and thus

influence their behaviour in a positive way [

]. Another advantage in addition to flexibility

in the execution of the tasks is the cost-benefit effect. There is no need to actively

consult a therapist and further the support is intensified. Evidence of the cost-utility of

self-guided interventions were also found [

]. Also evidence to date shows that these

treatments often produce results similar to those of face-to-face psychotherapy and

that they are cost-effective [

]. A comparison between face-to-face treatment and IMIs,

reported in some studies, revealed small trends in the direction of the effectiveness of

assisted interventions [

]. In any case, the doctor-patient relationship is changing

radically as a result of digitization in the health care system. Effects on the relationship

are a stronger autonomy of the patient as well as a better protection of the doctor [

Despite the multifaceted nature of online care, some diagnoses cannot be made without

face-to-face contact. In some cases, this type of Internet-based treatment can also

be seen as a supportive accompaniment [

]. Even those diseases that cannot be

supported by IMIs will be supported by automated reminders and similar solutions in

the future, which will lead more and more hospitals to offer such services as part of their

regular health care. The question in how far internet interventions can best be integrated

into existing services and in how far optimal strategies for combining interventions and

drugs are possible is becoming more and more topical [

]. Taking into account the

health aspects to be considered, we now turn to the implementation of such a system.

Requirements engineering

At the start of a software project, the requirements of the system are always collected

first. Requirements define what properties and functions are expected from the software

2.4 RELATED WORK

system as a whole [

]. Requirements engineering can be seen as a combination of

three simultaneously running and interacting processes: finding knowledge, ensuring the

validity of this knowledge and formally specifying the problem. An important approach

here is the thorough discussion of requirements in an agile process [

]. Weekly

discussions of upgrades and emerging issues, as well as discussions with clients and

final system users, are essential to the engineering process. A common concept is

user-centered design, in which the user is at the center of attention in order to make

the final product as good as possible [

]. The focus is on constant reconciliation and

discussion with the end user so that the end system cannot miss the target [

]. It

is difficult to define the requirements for a software product and then evaluate them

as well, because the requirements have a certain dynamic [

]. In the information

system context they are characterized as soft and ambiguous, which usually leads to

qualitative data [

]. In order to define goals, visions and framework conditions, the

distinction between non-functional and functional requirements is a standard procedure.

How to ensure that all relevant stakeholders are consulted or how to better involve

users in development is of paramount importance. Attention should be paid to an

adequate, timely and effective consultation of relevant stakeholders in the engineering

process [

]. While functional requirements, as the name suggests, describe the functions

of the system, non-functional requirements go beyond these and describe the system

more qualitatively in how far the functional requirements should be implemented. The

way of representation in an accompanying document should be carried along with

the software development process and should be formulated uniformly and clearly

understandable [16, 4].

Following such a requirement analysis process also offers further advantages for

generating test cases, simulating usability, generating traditional text-based use cases

and refining design ideas [

]. An integrated usability engineering process can add

valuable activities to the existing development processes, such as a cost-benefit anal-

ysis or an analysis of the environmental conditions of the end users [

]. Since the

quantity of demands usually quickly becomes substantially large, a classification, as

well as prioritization and grouping is in demand [

]. Besides a good overview of the

requirements themselves, the roles of the system involved, a exact description and

dependencies among themselfs should be annotated.

The dynamics of the system requirements mentioned above is a challenge for all

those who are involved in the project. Early discussion and specification of the design is

necessary to avoid errors at an early stage. Another important procedure is the creation

of scenarios to group the requirements based on these scenarios. Mockups, user

stories and other flowcharts can be used to define clear design specifications [

These are then uniformly implemented by the respective programmers in their parts of

the system.

2 FUNDAMENTALS

Once the system has implemented all requirements it is of utmost importance that

it is possible for everyone to use the system trouble-free. This means that the system

must run on different platforms, keyword: cross-platform programming. In the mobile-

app context there are now more than five major platforms on which the application

should run. Unfortunately some functions are not equally usable on all platforms, which

emerged into a challenge for both professionally and financially aspects [

]. Since

the smartphone development is so far advanced, certain applications can be accessed

just as well and quickly on it as on a computer. This means that the qualitative aspect

remains the same and we have the advantage of a flexible usage [8].

Systems that use IMIs

One of the best known platforms on the market is probably the minddistrict system. This

system is currently also used by the University of Ulm at the Institute of Psychology.

Minddistrict understands E-health as the application of digital aids, which is mainly

to support people on their way to recovery. Here, in the field of mental health care,

personal therapy conversations with online therapy elements are used [24].

A further app called mental health intervention provides, according to its own state-

ments, a supplement accompanying a therapy. The therapist can follow the patient’s

well-being through mood pictures, diaries and voice recordings [23].

The platform youper is a mental health application. With undirected interventions

it mainly supports self-help. It was created by physicians and psychologists to offer a

long-lasting and durable support through the internet. However, they also warn that this

app does not replace a doctor in that sense and cannot make diagnoses [32].

Another anonymous free study offers online training to strengthen mental well-being:

ICare Prevent. The focus of the inventors of the app is on coping with fear and sadness.

They want to support the patient in dealing with their feelings and offer background

information on how they arise in the first place. They conducted studies in various areas,

such as depression, anxiety disorders, stress management, sleep disorders, alcohol

abuse and procrastination [19].

As can be seen from all systems, the use of a mobile app has become indispensable

for integrating the therapy into everyday life. From the lower part of these already

existing platforms some functions are inspired by, which the eSano project should also

be able to execute. For this we have included our own experiences and studies to get

an even better system that uses the advantages of all these and can do even more

than is possible today. Some features such as tracking your own learning progress and

including your private environment like family members and friends take online therapy

to a higher level. Additionally, playful learning and an attractive design will be offered for

use by patients and therapists as well as content creators.

3 Requirements

Besides the functional requirements, non-functional requirements are also necessary

for every software system. While the functional requirements refer to the implementation

of the product purpose and define the exact functionalities, the non-functional require-

ments rather refer to the qualitative requirements like usability and user experience

for the system and related quality assurance measures like tests or developer/user

documentation [

]. The non-functional requirements are more oriented towards the

quality in which the required functionality has to be provided [

]. The requirements cover

all subsystems and refer to the entire project. As the project has been running for some

time, some requirements have already been implemented, whereas some are currently

being implemented and some will only be needed in later versions of the system. These

have therefore lower priority as can be seen in the individual requirements. The already

existing requirements were extended, categorized and specified with the main respon-

sible persons of the respective subprojects. In addition, several meetings were held

with persons responsible from the psychological side, who act as clients here. In the

context of this work, all requirements, whether already implemented or still in prospect,

are listed and evaluated, as well as connected to each other through dependencies.

3.1 Functional requirements

A functional requirement (FA) is the requirement whose implementation directly serves

the intended purpose of the product [

]. They are usually precisely described

functions that make the best possible use for the end user. The representation of

requirements can logically be done in many ways, but a table construction with different

properties is chosen here. In most cases, the actors involved are added to the properties

of the requirement, but this has been realized here by the individual subsystems,

since the individual actors can perform the same functions per platform in most cases

independent of their status. For a better overview, the requirements are divided into

categories, which are: Accounts, Groups, Interventions, Therapy, Further features.

The characteristics chosen to obtain a detailed description of the FA are the following.

The FAs can be uniquely assigned using an ID. A Description (DES) describes the

requirement. In Addition, the motivation (MOT) behind the FA is described and the

dependencies (DEP) to other requirements are also linked. Besides, each FA has a

3 REQUIREMENTS

priority (PRIO) that indicates how important it is for the working system. The scale goes

in ascending importance from -,0,+ and ++. The requirements are also assigned to the

individual subprojects (SUBP).

3.1.1 Accounts

This section describes how to start the system and how to log in and register for all users.

It also describes all settings concerning the administration of accounts. In particular, the

individual dashboards that can be accessed per actor are described in detail.

ID FA-A 1

DES Sign up to the patient application

MOT

When a patient gets invited to an intervention/study or in general to

the application via email, patients are able to sign up using their email

address and a secure password. There should be the opportunity to

DEP FA-A 4, FA-G 5

SUBP patient application

PRIO ++

ID FA-A 2

DES Login

MOT

Every user is able to login to the platform using their email address and

password. After logging in, users will be redirected to the dashboard of

their platform.

DEP FA-A 8, FA-A 9, FA-A 10

SUBP patient application, eCoach platform, CMS

PRIO ++

ID FA-A 3

DES Reset password

MOT

All users of the system have the possibility to reset their password if they

forget it or if they want to change it. If their login fails, they can reset their

password using their email address to create a new password. Also, the

password can be changed at any time in the settings.

DEP FA-A 6

SUBP patient application, eCoach platform, CMS

PRIO ++

3.1 FUNCTIONAL REQUIREMENTS

ID FA-A 4

DES Create account

MOT

The eCoaches can create other eCoach accounts in the eCoach plat-

form and editors can create other editor accounts in the CMS. More

specifically, editors and eCoaches prefill a form that creates an account.

However, an admin must confirm and activate this account creation. In

addition, admins can create eCoach, editor and other admin accounts

and promote users to specific roles per group. Patient accounts can

only be registered via the invitation of an eCoach and the following

registration.

DEP -

SUBP patient application, eCoach platform, CMS

PRIO ++

ID FA-A 5

DES Delete account

MOT

Patients are able to delete their account, so that their private data is

deleted from the entire system. After deletion, only the anonymous data

remains in the system. Other users like an editor or eCoach are also

able to delete their account. Admins can also delete any accounts.

DEP -

SUBP patient application, eCoach platform, CMS

PRIO ++

ID FA-A 6

DES Profile

MOT

Registered users can create a personal profile including their name or a

username, birth date, a profile picture and personal description. You can

also make visual adjustments, such as changing the color of the platform

(design templates). The profile can be designed by yourself and can be

set up as anonymous as desired.

DEP FA-A 6, FA-A 7

SUBP patient application, eCoach platform, CMS

PRIO +

3 REQUIREMENTS

ID FA-A 7

DES Personal settings

MOT

Any user can access a settings page where he can make system settings,

edit his profile or set various features. Additionally, the users can change

some settings regarding notifications. This is also the location where the

saved files from lessons and the personal activity log can be found.

DEP FA-A 6

SUBP patient application, eCoach platform, CMS

PRIO +

ID FA-A 8

DES Dashboard for patients

MOT

On the home page a user can find the lessons that need to be edited at

the moment. With the menu button you can get to the following pages:

•Home

•My Lessons (the own to be done)

•

Interventions (all, here the user can filter and search for new

interventions)

•Chat (messages and feedback)

•Favorites (all saved media)

•Diary

•Notifications

•Settings (my profile, language, my activity log, etc.)

DEP FA-A 2, FA-A 6

SUBP patient application

PRIO ++

3.1 FUNCTIONAL REQUIREMENTS

ID FA-A 9

DES Dashboard for eCoaches

MOT

On the start page the user will find a navigation bar at the top of the

following subpages:

•Home

•My Groups/Studies

•Patients (my patients, search for patients, send invitations, etc.)

•Tasks

•Feedback (all ever created)

•Catalogue (search for groups or interventions)

•Chat (messages and feedback)

•Notifications

•Settings (my profile, language,my activity log, etc.)

DEP FA-A 2, FA-A 6

SUBP eCoach platform

PRIO ++

ID FA-A 10

DES Dashboard for editors

MOT In the CMS a user can navigate through the following pages:

•Home

•My Workroups

•

Interventions (lesson editor, create lesson, intervention preview,

search for groups or interventions, ..)

•Chat

•Notifications (intervention requests, workgroup activities, etc.)

•Settings (my profile, language, my activity log, ...)

DEP FA-A 2, FA-A 6

SUBP CMS

PRIO ++

3 REQUIREMENTS

3.1.2 Groups

The following requirements give a list of all groups and their most important functions

and settings as well as restrictions and actors per group type. These groups form the

most important architectural grouping of users and interventions to be able to carry out

online therapy.

ID FA-G 1

DES Groups

MOT

There are various groups in the system that can be divided into three

types: organisationgroup, study and workgroup. The workgroups are in

the CMS, where the editors have special access rights to the same inter-

ventions to create and edit them. There is at least one editor manager

with increased rights who manages this group. The organisationgroups

are located on the eCoach platform in order to group departments and

subject areas of eCoaches that belong together anyway.

DEP FA-G 4,FA-G 5

SUBP patient application, eCoach platform, CMS

PRIO ++

ID FA-G 2

DES Create groups

MOT

In CMS an editor can create a workgroup and thus automatically become

the editor manager of it. An organisationgroup can be created mainly by

admins, or in special cases by a request similar to an account creation

form by eCoaches. Studies are always created by eCoaches on the

eCoach platform. An admin can create any of the three group types from

within the CMS.

DEP FA-G 1, FA-G 3

SUBP patient application, eCoach platform, CMS

PRIO ++

3.1 FUNCTIONAL REQUIREMENTS

ID FA-G 3

DES Studies

MOT

Studies are groups that can be created by eCoaches. These can invite

patients or other eCoaches and they can add interventions. The owner is

then the person who created the study and can also turn other eCoaches

into eCoach managers of the group and assign rights. At this point the

care of the patient takes place.

DEP FA-G 2,FA-G 4, FA-G 5

SUBP patient application, eCoach platform

PRIO ++

ID FA-G 4

DES Group information

MOT

Each group has certain information that can be accessed via an informa-

tion button. This includes:

•Name, description, picture, meta data

•Participants and their roles

•Forum

•Settings

DEP FA-G 1, FA-G 5

SUBP patient application, eCoach platform, CMS

PRIO ++

3 REQUIREMENTS

ID FA-G 5

DES Group settings

MOT

Each type of group (organisationgroup/study/workgroup), no matter on

which platform, has its own settings in which certain properties can be

defined and changed. That includes: (depends on the platform)

•Access type

•Whether a member can leave a group independently

•Group messages/forum

•Visibility

•Notification settings

•Members

DEP FA-G 1, FA-G 4, FA-G 9

SUBP eCoach platform, CMS

PRIO 0

ID FA-G 6

DES Participate in a study

MOT

A user has several possibilities to become a participant of a study. This

includes the following options:

•Request

•Self-enrollment (with or without password)

•Invitation (from an eCoach manager)

This applies to eCoaches as well as to patients. If a user applies for the

participation this request gets forwarded to the corresponding eCoach

manager, who decides whether to accept the request. The eCoaches

can also send requests to participate in studies or they are invited/added.

Every patient receives an ecoach when entering a study.

DEP FA-G 1, FA-G 3, FA-A 1, FA-I 8

SUBP patient application, eCoach platform

PRIO ++

3.1 FUNCTIONAL REQUIREMENTS

ID FA-G 7

DES Participation in a organisationgroup/workgroup

MOT

Users of the system can always make a request to join a group. This

means an editor can send a request to be included in a workgroup or an

eCoach can request to be part of a organisationgroup. In most cases,

however, they are simply added.

DEP FA-G 1, FA-G 4, FA-G 5

SUBP patient application, eCoach platform

PRIO ++

ID FA-G 8

DES Study forum

MOT

There should be group forums, possibly anonymously, in which different

patients can exchange information according to their complaints. When

creating the study, it can be specified whether the study wants this

feature. Afterwards this property can be changed in the study settings.

DEP FA-G 1, FA-G 4, FA-G 5

SUBP patient application, eCoach platform

PRIO 0

ID FA-G 9

DES Activity log of a group

MOT

The eCoach platform provides an activity log that displays any activities

that are performed by their patients or any member of the study or the

interventions in it. This log can only be seen by eCoaches and not by

patients. The workgroups and organisationgroups have also activity logs.

Also, they have the possibility to see when their patients were last online.

DEP FA-G 5

SUBP eCoach platform, CMS

PRIO +

3 REQUIREMENTS

ID FA-G 10

DES Group rights

MOT

In organisationgroups and workgroups there is always at least one

eCoach manager/editor manager who has extended group rights by his

role. This person can assign these rights to other eCoaches/editors

in the group. These rights can also be controlled by admins. These

extended rights of a manager include:

•Nominate other managers

•Edit settings

•Answer requests

•Add and remove members

In workgroups there is another difference besides the normal editor

and the editor manager, namely there are read-only or edit rights per

intervention. The editing rights also include the permission to copy

certain interventions or lessons.

DEP FA-G 4, FA-G 5

SUBP eCoach platform, CMS

PRIO +

3.1.3 Interventions

The most important function of the system is the care of patients through participation

in IMIs. This section lists the functional requirements from creating such interventions

to assigning them to patients.

ID FA-I 1

DES Create Interventions

MOT

An editor is able to create an intervention in a workgroup he is enrolled in.

After creation, the intervention is initially only visible in the workgroup and

not activated. All editors of the workgroup can now edit this intervention

and the lessons in it. Once the intervention has been processed to

the point where it can be used with patients, it can be activated. This

intervention can only then be assigned to studies.

DEP FA-I 2, FA-I 3

SUBP CMS

PRIO ++

3.1 FUNCTIONAL REQUIREMENTS

ID FA-I 2

DES Copy lessons/interventions

MOT

Entire interventions, individual lessons and certain elements can be

copied to be used for multiple interventions. If an editor has read-only

permissions, he can request permission to copy. This request goes to

the editor managers of the workgroup.

DEP FA-I 3, FA-I 4, FA-G 10

SUBP CMS

PRIO ++

ID FA-I 3

DES Intervention settings

MOT

There are interventions that can be "guided", “unguided” and both simul-

taneously. The matter of the intervention can be chosen at the time of

creation in the CMS. The state of "guided", “unguided” or both must be

set to one value when publishing the intervention. All interventions have

default configurations that can be set during creation. Some properties

should only be set later, when the intervention is executed with patients.

DEP FA-I 1, FA-G 10, FA-G 10

SUBP CMS

PRIO ++

ID FA-I 4

DES Lesson elements

MOT

An intervention consists of several lessons. There can be different

elements in each lesson:

•Heading

•Text (pictures are also possible in here)

•Question

•Media : including pictures, videos, audio files

•File upload

Questions can be further subdivided into: yes/no, exactly one answer,

potentially several answers, slider, date, short text, long Text, table.

DEP FA-I 3, FA-I 5

3 REQUIREMENTS

SUBP CMS

PRIO ++

ID FA-I 5

DES Preselect folder of media

MOT

When creating interventions or lessons, there should be a selection of

already used media that can be quickly reused in this way.

DEP FA-I 2, FA-I 3, FA-I 4

SUBP CMS

PRIO +

ID FA-I 6

DES Preview for interventions

MOT

The preview for an intervention shows lessons and the related elements.

It is intended to give an overview. In the CMS admins and editors can get

previews for created interventions. In the eCoach platform, eCoaches

can get a preview for interventions they want to assign to their patients.

DEP FA-I 3, FA-I 4

SUBP eCoach platform, CMS

PRIO ++

ID FA-I 7

DES Assign interventions to a study

MOT

An eCoach manager should be able to assign interventions to his study.

When searching for interventions he can send a request to the workgroup

of the intervention to have a copy of the intended intervention in his study.

The other possibility to assign an intervention to a study is to assign the

intervention directly from an editor manager in CMS.

DEP FA-I 3, FA-G 3, FA-G 6

SUBP patient application, eCoach platform, CMS

PRIO ++

3.1 FUNCTIONAL REQUIREMENTS

ID FA-I 8

DES Guidance

MOT

When a patient is added to a study, he automatically gets an eCoach

assigned to him, so the eCoach is his mentor and first point of contact.

Care takes place within studies. The eCoaches then assign interventions

to their patients and the guidance mainly represents the accompainment

by feedback on answer sheets. The allocation from patient to eCoach

can be adjusted by eCoach managers.

DEP FA-A 1, FA-I 11, FA-G 6

SUBP patient application, eCoach platform

PRIO ++

ID FA-I 9

DES Participate in an intervention

MOT

A patient has several possibilities to become a participant of an interven-

tion. If the intervention is guided, then he will be mostly invited/assigned

by an eCoach. The entry into an intervention depends on the access

type.

DEP FA-A 1, FA-I 8, FA-I 10

SUBP patient application, eCoach platform

PRIO ++

ID FA-I 10

DES Invitation for interventions/studies

MOT

An eCoach can invite his own patients and also via e-mail patients who

do not yet have an account. If a patient already has an account, the

invitation to an intervention should be visible inside the app and the

patient should have the possibility to accept the invitation inside the app.

If he doesn’t have an account, the invitation is sent by e-mail.Then he

can follow the link and create an account. After that he has the possibility

to confirm the link to the intervention/study.

DEP FA-A 1, FA-I 9

SUBP patient application, eCoach platform

PRIO ++

3 REQUIREMENTS

ID FA-I 11

DES Assign an intervention

MOT

An eCoach can arbitrarily assign their patients to any available training

or intervention. Training (unguided interventions) can be activated or

deactivated by the respecting eCoaches for certain patients. When

assigning, certain parameters are set such as the order of the lessons

and the default time until the next lesson is available. Using the guidance

settings, these parameters can be adjusted later if desired.

DEP FA-I 3, FA-I 8, FA-I 9, FA-I 1, FA-G 6

SUBP patient application, eCoach platform

PRIO ++

ID FA-I 12

DES Filter function for interventions

MOT

In the list of all interventions all users of the system should be able to

filter this list with given keywords like e.g. “depression”, “tinnitus”, “eating

disorder”. This is useful to find specific interventions and not to have to

go through each one to find fitting ones.

DEP -

SUBP patient application, eCoach platform, CMS

PRIO ++

ID FA-I 13

DES Intermediate storage

MOT

If a patient only partially completes a lesson, the current state of the

answers should be saved. If the processing time of a guided lesson

is running out and the whole lesson has not yet been processed, the

incomplete lesson will be returned to eCoach. In addition, the feedback

of a therapist should also be cached and if an editor creates a new

content in CMS, it should also be cacheable.

DEP FA-I 9, FA-T 1, FA-T 2

SUBP patient application, eCoach platform, CMS

PRIO ++

3.1 FUNCTIONAL REQUIREMENTS

3.1.4 Therapy

Based on the interventions, an online therapy can now be offered through the implemen-

tation of the guidance principle. Individual lessons can thus be guided by an eCoach

or completed independently by a patient. In each case, the patient receives individual

feedback and sees the progress of the therapy.

ID FA-T 1

DES Answer sheet for a lesson

MOT

After a patient has finished a lesson, an answer sheet is sent to his

eCoach. An answer sheet contains the patient’s answers to each lesson.

If a lesson is only partially completed, it will be cached. If the lesson is

finished and has not been completed, the accompanying eCoach will be

informed and an answer sheet with partial solutions will be sent.

DEP FA-I 8, FA-I 9, FA-I 13

SUBP patient application, eCoach platform

PRIO ++

ID FA-T 2

DES Feedback for a lesson

MOT

Once a patient finishes a lesson, the eCoach has access to their answers

and can provide feedback by commenting and rating the answersheet.

At the end of the feedback, an eCoach can control whether their patient

•Can unlock the next lesson

•Has to repeat the same lesson again

•Skip next lesson

•

Has to wait until the eCoach manually unlock the next lesson (the

eCoach can set an exact time and date when the next lesson is

available)

of course depending on the default config settings per guidance. Before

sending the feedback he can set a date and time when the patient should

receive the feedback. As soon as the eCoach has sent the feedback,

the patient receives a notification. This procedure allows the possibility

of a guided intervention.

DEP FA-I 9, FA-I 8, FA-T 1

SUBP patient application, eCoach platform

PRIO ++

3 REQUIREMENTS

ID FA-I 14

DES Activity log of a user

MOT

Each member of the system has his or her own activity log. The system

provides an activity log that displays any activities that are performed by

a user (e.g. for a patient is logged “X logged in”, “X finished training Y”).

Each user can see his/her own acitivity log. The supervising eCoach of

an patient can see the activity log of them, too.

DEP FA-I 8, FA-G 6, FA-G 7

SUBP patient application, eCoach platform, FA-A 7

PRIO ++

ID FA-T 3

DES Confidentiality of patient information

MOT

By default, eCoaches are only allowed to see the activities of their own

patients. Exceptions are representations or emergencies. In addition,

eCoaches can see all patients who are in a group/study with them, but

not their exact activities.

DEP FA-G 8, FA-T 4, FA-A 7

SUBP eCoach platform

PRIO ++

ID FA-T 4

DES Release patient files

MOT

On request, patients can be given access to data for third parties, for

example for further eCoaches or possibly relatives of the patient. This

request goes to the responsible eCoach, who has to process it. The

patient is informed about the passing on of the data.

DEP FA-A 7

SUBP eCoach platform

PRIO 0

3.1 FUNCTIONAL REQUIREMENTS

ID FA-T 5

DES Messages

MOT

The patient and eCoach can communicate via sending messages or

chatting inside the system. The messages should be instant with a

maximum delay of 10 seconds. This enables the communication between

patient and eCoach. These messages include feedback from lessons

for the patient and other messages that are related to the lesson and

normal messages between the patient and an eCoach.

DEP FA-G 8,FA-I 9

SUBP patient application, eCoach platform

PRIO ++

ID FA-T 6

DES Embedded video calling

MOT

There should be the possibility to request a video call with a therapist in

the message chat. If the eCoach does not answer the call or vice versa,

he will be notified by e-mail that he has been called. The video must be

reliable and in real time.

DEP FA-G 8

SUBP patient application, eCoach platform

PRIO 0

ID FA-T 7

DES Flexible lesson activation

MOT

It should be possible to activate lessons individually and flexibly, even

afterwards. The eCoaches are able to unlock the next lesson for their

patients independently of the feedback and other lessons.

DEP FA-I 9, FA-T 2

SUBP patient application, eCoach platform

PRIO +

3 REQUIREMENTS

3.1.5 Further features

In the last section, general features were collected that are not explicitly essential to

the basic functioning of the system. Rather, the following requirements complement

the final system to a user-friendly system and lay out special features. Therefore, most

requirements are rather less prioritized.

ID FA-F 1

DES Tutorial

MOT

When a new user logs in, a small tutorial should be available to make it

easier for them to get started by showing them how to use the app.

DEP FA-A 1

SUBP patient application

PRIO 0

ID FA-F 2

DES Export data

MOT

Individual lessons or individual media can be exported to a pdf file, a

csv file or printed directly from within the app. E.g. the answer sheets

can be exported to a csv format for further utilization in other statistical

programs like SPSS or for excel.

DEP FA-I 4

SUBP patient application, eCoach platform, CMS

PRIO +

ID FA-F 3

DES Languages

MOT

The system should be available in different languages and you can

choose at any time which language you want to have displayed. Further,

individual interventions and their lessons should be easily translated into

other languages as they are created. It is always displayed in which

language the respective lesson is available.

DEP FA-A 7

SUBP patient application, eCoach platform, CMS

PRIO +

3.1 FUNCTIONAL REQUIREMENTS

ID FA-F 4

DES Reporting function for inappropriate contents

MOT

If a user reads inappropriate content, he can report it. The complaint

goes to an admin.

DEP -

SUBP patient application, eCoach platform, CMS

PRIO -

ID FA-F 5

DES Gamification

MOT

There should be rewards, visual feedback (medals, goals, etc.), possibly

groups for successfully completed lessons/interventions that serve for

social reinforcement.

DEP FA-I 9

SUBP patient application

PRIO +

ID FA-F 6

DES Adaptive intervention proposals

MOT

Based on the course of the patient, new interventions should be pro-

posed. This automated recommendation of interventions also applies to

eCoach accounts.

DEP FA-A 7, FA-I 14, FA-T 3

SUBP patient application, eCoach platform

PRIO +

ID FA-F 7

DES Chatbot

MOT

The provision of a chat bot should be available to all patients. E.g.

in unguided interventions, the patient should receive an automatically

generated personalized feedback. Personalized means, for example, to

enter the patient’s name in the feedback.

DEP -

SUBP patient application

PRIO -

3 REQUIREMENTS

ID FA-F 8

DES Spell checker

MOT

There should be a spell checker that you can use to check whether

something you have written contains spelling mistakes.

DEP FA-T 1, FA-T 2, FA-T 5

SUBP eCoach platform, CMS

PRIO 0

ID FA-F 9

DES Progress overview

MOT

A certain illustration like a graph or some statistical pictures should

enable the patient and his mentor to follow the progress. This serves to

encourage the patient.

DEP FA-I 9

SUBP patient application, eCoach platform

PRIO 0

ID FA-F 10

DES Diary

MOT

The user has the possibility to write a diary entry. In this diary he can look

at, as desired and write new entries. The diary can have the following

elements:

•Text

•Scales (slider, multiple choice)

•Media

He can look at this diary at will and write new entries and then upload

them. The diary can have different focuses, such as a mood diary. The

eCoach is able to unlock the diary and follow the entries.

DEP FA-I 8, FA-I 9, FA-A 7

SUBP patient application

PRIO +

3.1 FUNCTIONAL REQUIREMENTS

ID FA-F 11

DES Calendar

MOT

Between patient and eCoach there should be an easy possibility to

arrange personal appointments. A view of the free appointments of the

therapist should allow the patient to choose an appointment that suits

him.

DEP FA-I 8, FA-I 9, FA-A 7

SUBP patient application, eCoach platform

PRIO 0

ID FA-F 12

DES Emergency button

MOT

The emergency button should be permanently visible everywhere and by

clicking the button a window should open with a confirmation question.

To ensure quick help for the patient, further emergency information is

displayed. The patient’s emergency will be forwarded to a separate email

with a contact person available at all times.

DEP -

SUBP patient application

PRIO +

ID FA-F 13

DES Contact IT support

MOT

For all users of the system there should be the possibility to contact the

IT support. This can be done via the help function of the system.

DEP -

SUBP patient application, eCoach platform, CMS

PRIO 0

ID FA-F 14

DES Attach media to messages

MOT

For all users of the system there should be the possibility to attach some

media at the end of a message like a picture or video.

DEP FA-I 5, FA-T 1, FA-T 2, FA-T 5

SUBP patient application, eCoach platform

PRIO 0

3 REQUIREMENTS

ID FA-F 15

DES Store data

MOT

Individual media can be stored. This means that the file can be found

quickly in a folder of the saved files. This function is intended to assist

the patient in viewing past media again.

DEP FA-A 7, FA-I 5, FA-T 1, FA-T 2, FA-T 5

SUBP patient application

PRIO +

ID FA-F 16

DES Reportings

MOT

Different types of reportings should be available. These can be divided

into the following groups:

•General reportings (e.g., like ID and date export)

•

All parameters for the patient’s access to the platform such as the

initial contact between the patient and his therapist.

•

Intervention execution and the associated parameters for, among

other things, each lesson

•

Guidance (e.g., like the number of messages between patient and

eCoach during the intervention)

DEP FA-F 2, FA-I 1, FA-T 2, FA-T 4, FA-T 5

SUBP eCoach platform

PRIO +

3.1 FUNCTIONAL REQUIREMENTS

ID FA-F 17

DES Notifications

MOT

The platform should be able to deliver notifications depending on the

user role and platform. Notifications are prioritized and can be basically

divided into the following groups:

•Chat Message

•Group

•Guidance

•Reminder

•System

DEP FA-A 7, FA-T 5, FA-T 6, FA-T 2, FA-I 10, FA-G 5, FA-F 18

SUBP patient application, eCoach platform, CMS

PRIO ++

ID FA-F 18

DES Email reminder

MOT

If a message is sent while the user is not online, a setting can ensure

that the user receives a reminder mail. These reminders via email are

possible for all types of notifications and can be set individually.

DEP FA-A 7, FA-F 17

SUBP patient application, eCoach platform, CMS

PRIO ++

3 REQUIREMENTS

3.2 Non-Functional requirements

The next part describes the non-functional requirements (NFA). These are requirements

that address specific areas such as security aspects but also basic functionalities that

should facilitate the use of the software. They are usually recorded in the form of work-

flow notations to form a task flow model of the system. This in turn provides a framework

for the collection and appropriate recording of non-functional requirements [31, 9].

Most NFA’s are interlinked, so for example, NFA usability cannot exist without NFA

correctness. Further dependencies can be read in the tables. In addition, the following

requirements are similar to the FAs presented in the previous section. Besides a

description and motivation, a priority is also defined here, whereby these can only

assume the two levels + and ++. The priority here also does not describe the importance

of the implementation for the final system itself, but rather the order of implementation

of a variant of the system.

ID NFA 1

DES Maintainability

MOT

The maintainability of the software should be ensured. In case of impor-

tant changes or adjustments afterwards, it should be possible to easily

edit the system without losing functionality.

DEP NFA 11, NFA 12

PRIO ++

ID NFA 2

DES Integrity

MOT The data sent through the system should not be able to be accidentally

or maliciously altered, stolen or destroyed. Data integrity ensures a

consistent and secure system.

DEP NFA 6, NFA 8, NFA 10, NFA 11

PRIO ++

3.2 NON-FUNCTIONAL REQUIREMENTS

ID NFA 3

DES Time performance

MOT

The system time performance, in particular the response time perfor-

mance, describes the data transmission rate in the components involved,

including the waiting time and the processing time of messages. This

time performance should take place within an appropriate time frame.

DEP NFA 5

PRIO +

ID NFA 4

DES Comprehensibility

MOT

In order to be able to reach its goal, the presentation should be struc-

tured in an understandable way. The system should also provide visible

feedback and it should be clearly arranged to avoid confusion.

DEP NFA 3, NFA 5, NFA 11

PRIO ++

ID NFA 5

DES Usability

MOT

In addition to all functions of the system, these should also be usable

in a way appropriate to the task. A good usability aims to ensure that

the task to be performed in the platform can be mastered efficiently and

satisfactorily. Good usability also prevents incorrect use and supports

the user in case of incorrect entries or questions on the operation.

DEP NFA 3, NFA 4, NFA 6, NFA 7, NFA 8, NFA 9, NFA 10

PRIO ++

ID NFA 6

DES Reliability

MOT

The whole system should be reliable and react appropriately in case of

failures and provide feedback to the user. The reaction of the system

should therefore always meet expectations.

DEP NFA 3, NFA 4, NFA 5, NFA 7, NFA 11

PRIO ++

3 REQUIREMENTS

ID NFA 7

DES Compatibility and Flexibility

MOT

The system should run flawlessly on all operating systems and any

mobile devices like Android, iOS, Windows, macOS and Linux. Further-

more, the platforms should be compatible with all browsers (e.g., Google

Chrome, Firefox, Microsoft Edge,...).

DEP NFA 5, NFA 9, NFA 12

PRIO +

ID NFA 8

DES Robustness

MOT

The application should be designed to be robust, especially against

misbehaviour from a technical point of view and also against incorrect

input from system users. A system crash should be prevented in any

case.

DEP NFA 1, NFA 11, NFA 12

PRIO ++

ID NFA 9

DES Reusability

MOT

All parts of the system should be redundancy-free, reusable reusable

and as atomar as possible. This is especially true for internal reusability

as well as for passing on to external software projects.

DEP NFA 11, NFA 12

PRIO +

ID NFA 10

DES Privacy and security

MOT

All personal data that is transported through the application and also

stored in the database should be safely stored and protected against

attacks. All account data is kept encrypted. On all platforms, each user

should be able to set how much of his profile he wants to share with

others.

DEP NFA 2, NFA 6

PRIO ++

3.2 NON-FUNCTIONAL REQUIREMENTS

ID NFA 11

DES Correctness

MOT

The correctness of the given data is of utmost importance. Any type of

communication and data transmission in the system must be transmitted

and displayed correctly.

DEP NFA 2, NFA 6, NFA 10

PRIO ++

ID NFA 12

DES Scalability/Extensability

MOT

The system should be well scalable and able to cope with large growth.

Any expansion should be possible so that the system can continue to

function without errors.

DEP NFA 1, NFA 8, NFA 11

PRIO +

Now that the requirements for the software have been specified, classified and

prioritized, they will be converted into a design concept, whereby the functional and

non-functional requirements will be related to each other.

4 Design

The requirements just listed are now set in connection with the design. It is explained

to what extent the individual parts of the system need to be adapted or redesigned to

meet all requirements, from the architecture to the exact specification of the functions

the system must have. The structure of the system is first of all explained by the rough

architecture, so that one can see all systems involved and how they are connected

to each other. In addition, the roles that a user can take on are described in more

detail. It is explained how they can interact with the software and other users. Through

interaction diagrams, the most important processes in the platform can be shown, so

that all work processes and the necessary requirements can be brought into connec-

tion [

]. Furthermore, the communication channels are demonstrated and supported by

examples of use. The data structure of the groupings, users and all user rights required

for the implementation of all functions are also indicated, which are supported by some

graphics. It is important to know that the software architecture is only superficially

presented here to show the complete software concept. Some deeper insights are also

given into communication, roles and group rights, notifications and security aspects. In

summary, basic rules and data concepts are presented which are observed by all parts

of the system when implementing the whole functional and non-functional requirements.

4.1 Architecture

The different components patient application, eCoach platform and CMS communicate

with each other via a backend as already described in the introduction. One can see

the rough architecture as shown in Figure 4.1. The individual platforms are connected

by the backend, which is represented by the API and the database. All system-relevant

data is safely stored here. Data access is given for retrieval with valid authorizations,

which is matched via the database. In the CMS, the creation of an intervention begins

through the work of an editor. In addition, all administrative work is initially controlled

from the CMS. The eCoach platform is the place where an online therapy is planned

and where the therapists organize themselves and the studies. The patient application,

which should be available as a website and a mobile phone application, is the interface

where the patient should be able to interact with any time and any place. Therefore

it is important that the software runs on different operating systems and browsers.

4 DESIGN

Basically, a client-server architecture is chosen, whereby the server holds the data and

the clients make requests via an internet connection within a network. This is about an

REST- interface. The individual parts of the system can perform services at the server,

which then distributes the information [

]. The extended connections between the

subsystems that can be used for communication are described in Section 4.4.

Figure 4.1: The basic architecture of the software.

4.2 Groups, roles and rights

For the organization of grouping of users together there are different types of groups

per platform as already mentioned. In the CMS there is a workgroup to organize

and structure the editors belonging together. In workgroups the interventions can be

created and edited. On the eCoach platform, similar to the workgroups, there are

organisationgroups in which exclusively eCoaches are organized and grouped together

for example for departments in the university. That means there are no patients included

here. Each eCoach can create a study, which is the third type of group in the system.

When creating the study, the eCoach automatically has eCoach manager rights in

this study and he can invite other eCoaches and organize the study. Furthermore, all

eCoaches with manager rights can add interventions and patients or other eCoaches to

4.2 GROUPS, ROLES AND RIGHTS

a study. Groups can be created at different places in the system. One also need a role

that has the authority to create it.

The conceptual level of the ANSI/SPARC architecture is used to explain the impor-

tance of a logical data model in relation to the implementation of all requirements. A

conceptual model can be translated into a logical model that corresponds to a data

specification implemented in the database system [

]. In order to get an overview of

how the groups are related to the platforms, the three groups are shown graphically in

Figure 4.2 realized by an extended ER diagram. The following grouping data model

illustrates the functional requirements from Chapter 3.1.2.

Figure 4.2: The extended ER diagram of the group types.

There are no other attributes mentioned except the ID, but it can be assumed that each

type of group has a number of properties which must be observed during implementation.

The workgroups are specifically designed for CMS and are used to group editors and

interventions. The organisationgroups are the counterpart to this on the eCoach platform.

Different departments and therapy groups are organized right here. These two groups

have a similar data structure and are therefore represented in the same way internally.

In the studies, there are patients and their supporting eCoaches grouped together.

Besides these three roles there is also the admin role as shown in Figure 4.3.

4 DESIGN

Figure 4.3: The different types of actors.

The guidance between patients and eCoaches is established in the studies. In

difference to the organisationgroups, this group also contains users with patient roles

as can be seen in Figure 4.4. The admin role is assigned to the CMS, since this role

acts from here in the current system. This division of the groups is especially important

when it comes to the allocation of group and intervention rights.

Figure 4.4: The types of groups with the allocated actors.

In addition to the four technical actors, special statuses are added for two roles in the

mapping into our system. Per group, extended rights can be assigned to eCoaches or

editors.

The

eCoach manager

role is a status that an eCoach can have per group. This role

is passed on hierarchically to the interventions in the study group. He manages the

group, eCoaches and patients as required by the therapy. He also has the possibility

to assign the eCoach manager role to other eCoaches. So there can be more than

one eCoach manager per group. The eCoach managers stand hierarchically above

the eCoaches and have special rights. The extended rights that the eCoach manager

status brings with include:

•edit group settings

•add users to the group

4.2 GROUPS, ROLES AND RIGHTS

•grant manager status to other eCoaches

•making intervention copy requests for a study

The manager role applies exclusively at group level and can therefore apply to eCoaches

in organisationgroups and in studies. This means that even if an eCoach does not have

the manager status in an organisationgroup, he can have it in a study, or vice versa.

Similar to the eCoach manager, the

editor manager

has a higher position with more

rights. This status is valid per workgroup and can be distributed to other editors through

the manager role. The most important tasks are the organization of the workgroup and

its editors as well as the answering of intervention requests to add the interventions to

studies. If an editor has a manager role in a workgroup, he has the following extended

rights:

•edit workgroup settings

•add editors to the group

•grant manager status to other editors

•grant intervention copy rights

•respond to intervention copy requests for a study

•adding interventions to a study

When an eCoach or editor creates his own study or a workgroup he is automatically

the first member of this group and has manager status. The following Figure 4.5 shows

a graphical representation of the roles with extended rights and they are indicated

graphically below by a black hat.

Figure 4.5: The actors with manager status.

In each group there must be at least one user with extended rights to manage

the group as shown in Figure 4.6. Each groups have their own settings regarding

notifications and access restrictions. All group types can be created from the CMS by

an admin. In addition, groups and accounts can be requested by eCoaches and editors

via a form, which an admin has to edit. Since the admin role is a special one, it is not

directly listed in a workgroup.

4 DESIGN

Figure 4.6: Possible compositions in the groups.

4.3 DATA MODEL

4.3 Data Model

The next logical step is to integrate the interventions to perform an IMI. The main entities

of the project are now represented by a semantic data model through an ER diagram,

as this graphical representation provides a good overview of the facts and is also a

template for modeling the database [4].

In Figure 4.7, it can be clearly seen that the connection of all components is charac-

terized by the interventions. The detailed attribute descriptions that the entities have

are omitted here for reasons of clarity. For example, each group should implement

the group settings explained in Section 3.1.2. Further, each user has an account with

various settings as listed in the requirements in Chapter 3.1.1, too. The functions that

an eCoach or editor can perform on the basis of his manager status were also ignored

here.

Figure 4.7: ER diagram of the basic components of the system.

4 DESIGN

The lesson entity has a full participation in the intervention entity. There is a weak

relationship that describes a dependence of the lessons on the interventions. The

used entities are the basis of the data model of the end system which enables the

functionality of IMIs. Since an intervention can be included in different studies and used

there adapted to the patients, there is an extra configuration per assignment. In detail

even an extra configuration per patient, which is not considered here.

Interaction diagrams

To go more into detail, the functional requirements included in Chapter 3.1 are now

grouped by and represented in diagrams. The interaction of all users and the respective

platforms can be presented by scenarios realized in interaction diagrams.

First, the requirements of Section 3.1.1 Accounts are presented in scenarios. After

creating an account, the system can be used depending on the role. These accounts

can be created in several ways as described above. In Figure 4.8 we can see the

representation of the registration via an invitation. If the patient already has an account,

the eCoach will see the nickname of the patient and the adding process runs without the

registration. If a patient or eCoach has an account, they can join any study depending

on the access types.

Figure 4.8: Patient registration through an invitation by an eCoach.

Another way to create an account is via a form. If, for example, an eCoach wants

to create an account for another therapist, the eCoach can fill out a form. This will be

4.3 DATA MODEL

forwarded to an admin. Then the admin checks this request and rejects the form or

confirms it and so submits the data into the database. The communication before an

account is created is done via email traffic, as we can see in Section 4.4 Communication

channel. With this procedure of filling out a form, organisationgroups can also be

requested by eCoaches.

Figure 4.9: Account creation through a form.

The example of a patient’s login in Figure 4.10 shows how this process can be

transferred to all other roles and their respective platforms. That specific roles cannot

The authentication data is requested from the backend on the platform. The maintenance

of the connection is controlled by so-called tokens, which are sent with every interaction

of the user and stored in the backend. These tokens prevent the user from having to

from staying logged in unintentionally after he has forgotten to log out. The use of tokens

is also an important issue in terms of security and it is controlled by the backend.

4 DESIGN

Figure 4.10: Standard login of a user on his platform using the example of a patient.

In the next Figure 4.11, several functions running in the same way are processed

using the example change settings. These are mainly requirements from the Accounts

section, such as FA-A 3 Reset Password,FA-A 7 Personal Settings, and any kind of

system changes like FA-G 5 Group settings. Starting from the user, the command is

passed to the backend via the corresponding platform. If the changes the user wants

to make have an impact on other groups and users, the changes are passed on and

updated from the backend. Deleting data in itself is not an easy task in this system,

as the data must be kept very confidential. Certain data security aspects have been

established for this purpose, which are shown in more detail in Chapter 4.5. The system

may only keep the data anonymously or must delete it completely. This creation is also

intercepted by the confirmation of an admin. The process of such a deletion is similar to

the functions just mentioned, with the addition that further actions must be performed in

the backend.

4.3 DATA MODEL

Figure 4.11: The procedure for changing settings.

The creation of organisationgroups is handled by the admin, but editors can create

workgroups and eCoaches can create studies themselves. As shown in the diagram in

Figure 4.12 a therapist can create a study on the eCoach platform. To do so, he has

to provide all information of the study and then he can add members. This procedure

works exactly the same in the CMS where an editor is able to create a workgroup.

Afterwards everything is stored in the database, so every member can get the study

information. When IMIs are created in a workgroup, a default configuration is created for

it. Certain settings, e.g., which rights other editors have for the intervention, can also be

set. The intervention data and that of the individual lessons are stored in the backend.

If editors edit the intervention before it is published, the changes in the database will be

adjusted. A published intervention cannot be changed anymore after taking it into use,

as it will be added to studies as it was published.

4 DESIGN

Figure 4.12: The creation of a study.

There are two ways in which an intervention finds its way into a study. First, an eCoach

can request an intervention. This request is forwarded to an editor who is responsible for

this intervention and who is the editor manager in the concerned workgroup as shown

in Figure 4.13. Secondly, an editor would perform the assignment step on his own,

which is shown by the solid line in the diagram in Figure. The dotted line describes the

process by a request from an eCoach 4.13. When assigning interventions in studies, a

copy is created in the background and thus also a separate configration. For example,

an eCoach who also has an editor role may have just created a particular study and

then create interventions for it himself and link them directly together. To illustrate a

generalized case, in Figure 4.14 is a life cycle of an intervention from its conceptual

inception, through the assignment to a study and the performance of a patient until the

patient has completed the intervention. The end of an intervention has to be considered

separately because a therapy does not simply stop when the intervention is over. The

moment the eCoach assigns an intervention to the patient, an individual sequence of

intervention lessons is put together for the patient, as each patient may need a different

length of time for a task. Thus a guidance instance is created, which realizes the FAs

from Section 3.1.4 Therapy and Section 3.1.3 Interventions. If the patient does the

procedure unguided, then the feedback part is not performed.

4.3 DATA MODEL

Figure 4.13: Assigning an intervention to a study.

Figure 4.14: A simplified life circle of an intervention.

Between each guided module or lesson we see in Figure 4.14, you can see how a

feedback allocation takes place. When the patient completes the lesson, the answer-

sheet is sent to the supervising eCoach. The eCoach can control the therapy in any

way he wants, for example by letting the patient repeat the lesson or enabling him to

continue with the next one. The feedback can be in different forms, media or just text

and it will be sent to the patient as soon as the eCoach wants it.

All diagrams are part of the online therapy process and have a different importance

depending on the actor. Communication is probably the most important element. Who

communicated with each other at what time was explained yet. How communication

takes place will be referred to in the next section.

4 DESIGN

4.4 Communication channel

The start of the life cycle of a patient who registers up to the accompainment by

an eCoach must of course start with a registration of the patient which cannot yet

run over the backend. The initial connection between the two runs over a separate

communication channel as shown in Figure 4.15.

The eCoach can send his invitation to a study in the beginning only via the email

channel (e.g., Outlook), in which the patient gets a link to register. The system creates

this link and saves it. For this reason this email must still be passed on to the API via

the eCoach platform, because the invitation must be remembered by everyone and the

validity must be defined. The authentication in general is always done via the backend.

A second server to secure this data would be a consideration to avoid the transmission

of passwords to third parties. Currently the data is stored encrypted on a server with all

other files.

Figure 4.15: The communication channels during patient registration.

The later main communication channel will be the patients’ answersheets and the

therapists’ feedback on the lessons worked on. This content exchange has its own

4.4 COMMUNICATION CHANNEL

communication channel which is also handled via the API and runs between the patient

application and the eCoach platform. Another way of communication between patient

and therapist is a chat for the exchange of messages, which will be extended by video

call and the attachment of media. This channel is represented by a separate thread. It

is important that communication takes place via the backend and not directly between

the platforms, since all interactions are played back here.

Figure 4.16: The seperate feedback thread for guided interventions.

4 DESIGN

The CMS communicates mainly with the backend and has less communication with

the other two platforms. The provision of the interventions consists of the editors passing

the created content to the database via the API. This is also where all retrieval takes

place, both from the CMS when copying or assigning interventions to studies and from

the patient app and eCoach platform when retrieving.

Figure 4.17: The communication between eCoach and editor.

In detail, all data sent and exchanged by the server is sent using the json format. All

subsystems must take this into account. The server determines this and all subsystems

must follow it to communicate. The storage of the data in the database via the API is

4.4 COMMUNICATION CHANNEL

done using a mixture of NoSQL and SQL database systems. The relationships are in

themselves based on a relational schema, but the individual elements of the tables are

often json elements.

The data sent is user account data, groupings and affiliations of users through groups,

interventions and their lessons, as well as the module answersheets filled out by patients

and the therapists’ feedback. Additionally, of course, group invitations, group requests,

assignment of interventions, accompanying associations of patient and therapist and

normal chat messages. The legally correct storage of data is discussed in the security

section.

Another feature includes an emergency help button for the user when he is in an

emergency situation and in the worst case has suicidal thoughts. This concept only

makes sense if the help message is forwarded to a responsible person as soon as

possible and does not arrive in the email inbox a few hours later. Here an extra email

channel will be set up, which is under 24/7 supervision, as shown in Figure 4.18.

Additionally, push notifications are sent through all channels to reach a responsible

person as quickly as possible.

Figure 4.18: The extra channel for emergency situations.

The group notifications or system notifications as explained in chapter 4.4 have their

own communication channel. These notifications are sent from the API.

4 DESIGN

Notifications

Another communication channel is the notifications that are sent from the backend to

the subsystems and their users. It should be able to deliver all types of notifications

(see FA-F 17 Notifications). Notifications are prioritized and can generally be divided for

every user into the following four groups:

•Chat Message

•Group/Intervention

•Reminder

•System

There are slightly different notifications for the different platforms and roles, because

an editor, for example, does not need the same notifications as a patient. Besides,

there are undoubtedly notifications for admins that include IT support/help notifications

and so on, but these are not listed here in detail. Furthermore, the frequency of

reminder notifications can be changed or turned off in the settings, if desired. Priorities

are assigned to notifications, because some notifications such as a patient sending

emergency messages should have a higher priority than a normal chat message. Next,

the differences in notifications between the roles are shown.

The patient

The app notifications for patients can be divided into six groups. The guidance group

is new here, as this type of notification is only relevant between patient and eCoach.

Reminder messages are displayed by pop up messages on the phone/desktop and also

by email. For some studies the reminder notifications for patients cannot be turned off.

This can be set by the responsible eCoach managers in the study settings.

Chat Message: This includes the normal message flow inside the patients mes-

sage area from any other user or group (also missed video calls, transmitted

media, etc.)

Study/Intervention: This includes study notifications of any kind and the interven-

tions contained therein. (E.g., "You have been assigned to the study xy." or "New

lesson available.")

Guidance: Everything that has to do with the support and feedback of the eCoach.

(E.g., "You have received feedback for lesson xy." or "The eCoach example is

your mentor for the study xy.")

Reminder: Notifications to remind of upcoming lessons or reminder of new chat

messages.

5) System: Contains all system notifications such as updates.

4.4 COMMUNICATION CHANNEL

The eCoach

Notifications are also available for eCoaches with or without manager status on their

platform and slightly different from those for patients. The eCoaches can set which

notifications they want to receive by email as reminder and how often they want to

receive them. Moreover, they are able to send reminders to the patients manually.

Chat Message: This includes the normal message flow inside the eCoach mes-

sage area from any other user or group (also missed video calls, transmitted

media, etc.)

Group/Intervention: This includes organisationgroup and study notifications and

also the interventions contained therein. (E.g., "The patient example would like to

join your study xy." or "You have been assigned to the role eCoach manager in

organisationgroup xy.")

Guidance: Everything that has to do with the support per se and also answer-

sheets of the patients. (E.g., "The patient example has completed the lesson,

your feedback is required." or "The Patient example was assigned to you.")

Reminder: Notifications to remind of required feedback, group requests or re-

minder of new chat messages. This also includes emergency notifications if a

patient wrote an answer with critical words like death for example.

5) System: Contains all system notifications such as updates.

The editor

Notifications are also available for editors in the CMS. The editors can set how often

they want to receive them as well. Clearly these notification groupings also apply to

editors with manager status.

Chat Message: This includes the normal message flow inside the editor message

area from any other user and group messages as well.

Workgroup/Intervention: This will include all notifications that occur in the work-

group and the interventions contained therein. (E.g., "The editor example would

like to join your workgroup xy." or "The eCoach example would like to have the

intervention xy in the study xy.")

Reminder: Notifications to remind of new chat messages or workgroup/intervention

requests.

4) System: Contains all system notifications such as updates.

4 DESIGN

4.5 Privacy and Security

As mentioned before, it is very important to maintain the privacy and security policies.

For this purpose, a list of regulations was also developed in this project to ensure data

security. It must be ensured that the General Data Protection Regulation (GDPR) is

observed, to achieve GDPR compliance [

]. The software company Idera,Inc., which

offers a system and application management software for Microsoft Windows and Linux

servers, provides an overview on their website about what you should consider as a

developer in the data protection context [18].

In order to consider a data protection and security concept, all security-critical in-

teractions with the software were first collected. The NFA’s from Chapter 3.2 were

considered.

•

Authentication: what should the password look like, how often should it be entered

wrong, reset password

•

Encrypted channels for communication (chats and messages, answersheets and

feedback)

•Secure personal data, granular visibility of user data

•Storage of personal data

•Deletion of personal data

•Rights management of the roles involved

•

Intercept from the API which role can login to which platform (e.g., patient cannot

•

Transfer of patients and their data, keyword: guidance (holiday replacement, sick

leave, etc.)

•

Visibility of profiles (which account can see which other accounts or which profile?)

For a security and privacy policy some considerations have been made, which

sometimes concern the use of the system, especially user security, network security,

organizational and administrative security are presented.

The network environment is secured by firewalls and the communication is end-to-end

encrypted using TLS. Organizational security also includes the planning of training so

that all system employees are sensitized to the handling of personal data. For their

protection, this administrative information is subject to a two-factor authentication, where

a proof of identification means using two different and independent components [27].

User security mainly covers the processing and storage of data. The intervention

data is archived for the patient and the regarding mentor. In activity logs both can trace

4.5 PRIVACY AND SECURITY

and monitor the processes of the modules. The user accounts are pseudonymised and

linked to the accruing data so that no conclusions can be drawn from individual data to

persons. During registration, a basis for protected data is created by entering an email

address and a password of sufficient complexity. To ensure privacy, all passwords are

encrypted.

What the system knows about the user must not be passed on to unauthorized

third parties and must be completely and timely deleted if the person concerned so

wishes. Already during the creation of the interventions, certain fields can be marked

as personal, which offers considerable advantages when deleting from the database.

This saves anonymous data that cannot be traced back to the patient. This is a big

advantage if you want to use the data for an evaluation. Moreover, every system user

has the possibility to export his data. Mainly the functional requirements of Section 3.1.1

Accounts have been considered here. Furthermore, just like the requirement reportings,

confidentiality of patient information and exporting data are considered here.

A data protection declaration precisely records all legal provisions. A declaration of

consent informs patients about their rights and safety regulations when they start using

the system. [25]

5 Conclusion

Finally, this section offers a summary as well as self-reflection on the process and

execution of the task. Moreover, the thesis gives an outlook on the challenges the

project will face and the topics that will be investigated in the future to improve the

system

5.1 Summary

Carrying out a requirements analysis was essential in order to specify exact guidelines

for the system, which can be followed when implementing the upcoming features.

Based on the existing requirements, functional and non-functional requirements were

distinguished, grouped and partly specified in detail. After that, mockups and interaction

diagrams with the involved subplatforms were collected in order to rebuild the data

model so that the patient app, the eCoach platform and the CMS could use a common

new data model regarding the basic data structure. This included the new concept of

groupings, the types of notifications that can occur per platform and user, as well as the

procedure for assigning interventions to a group. In order to create a security concept

the functional requirements and the created scenarios then were used and categorized.

Thus the basis was laid to form the security-critical parts of the software into a data

protection concept and a security declaration. As discussed in the Fundamentals, some

features such as the future inclusion of family and friends and smart sensing features

are essential to take online therapy to the next level. In addition to the requirements

for the basic functionality of IMIs, some additional future features were defined and

considered in the design concept to avoid later expensive and difficult adjustments to

the system.

5.2 Discussion

Collecting and specifying the functional requirements proved to be extremely time-

consuming due to their dynamics. It was also a challenge to include all parts of the

system in all decisions, more precisely the team members working on them. In order

to get detailed guidelines and requirements it was important that the sub-parts and

5 CONCLUSION

members of the psychology team agreed on them. With regard to reach the best

possible agreement on drafts and requirements, many meetings and conversations

were helpful and goal-oriented. As the system was built on the basis of a similar

software project, difficulties were also apparent. The restructuring of the data model

that was developed through this work was necessary and has now been fully adapted

to the IMIs context. To specify the design concept, discussions were held with the

therapeutic workers of the Institute of Psychology, who also gave feedback from their

studies of test patients. Another advantage was the experience of the psychologists

with the minddistrict system, because they were able to tell precisely about what they

dislike about the system and what had to be retained in the new software system. The

preliminary work that was already available in the project was definitely a help and gave

a basis for requirements engineering. The task to keep the requirements always up to

date and available for everyone was one of the most important work of the project. The

biggest lessons learned are certainly the difficulty of the engineering process itself in

such a large project involving several people.

5.3 Outlook

Considering the fact that the system is to be used by many patients and therapists

as well as health insurance companies, there is a lot of visionary thinking. Before the

system can be used for treatment, the implementation of extra features must first be

moved back in the implementation order. If the basic functionalities all work smoothly,

the future requirements will be implemented, which have also been recorded above in

this work.

Some important further work will be the integration of the patients private environment,

whereby the therapy can be integrated even further into everyday life. Through studies

the software can be observed on test persons and possible errors can be corrected

before operational use. The whole additional software development process should

be supported by a usability engineer, who keeps the goal in mind and stays in contact

with all project participants. If we take a look at the visionary requirements, we find that

extensions of the chat module can be used for a video call, as already described in the

functional requirements. The priority of such requirements was therefore deliberately

set low. These requirements, which are taken into account in the specification, will

be set up in later software versions. Another issue for future research to explore is

multi-client capability, disjunct client-oriented data storage and its presentation and

configuration. Moreover, smart sensing, artificial intelligence and detailed usability

tests provide an interesting subject area for further research. Also, automated CI/CD

pipelines will be used to monitor the application development. Before the platform can

be used throughout Germany or even worldwide, some functions must be expanded.

5.3 OUTLOOK

Looking forward, the eSano software must comply with the requirements of the Medical

Devices Act, as it uses a so-called healthcare app.

For all further work with the system, the collected data can be seen as a basic

concept and can be used as orientation for following steps. The current state of the

software maps all basic functionalities, which is why less prioritized requirements can be

implemented as the next step. The visions of the project are clearly defined and point to

a successful implementation of an online intervention platform. Looking to the future, it

can be said that due to increasing digitalisation, the relationship between therapists and

patients can be intensified through online care. In summary, such systems are more

up-to-date than ever.

List of Figures

4.1 The basic architecture of the software. . . . . . . . . . . . . . . . . . . . 42

4.2 The extended ER diagram of the group types. . . . . . . . . . . . . . . . 43

4.3 The different types of actors. . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4 The types of groups with the allocated actors. . . . . . . . . . . . . . . . 44

4.5 The actors with manager status. . . . . . . . . . . . . . . . . . . . . . . 45

4.6 Possible compositions in the groups. . . . . . . . . . . . . . . . . . . . . 46

4.7 ER diagram of the basic components of the system. . . . . . . . . . . . 47

4.8 Patient registration through an invitation by an eCoach. . . . . . . . . . 48

4.9 Account creation through a form. . . . . . . . . . . . . . . . . . . . . . . 49

4.10 Standard login of a user on his platform using the example of a patient. 50

4.11 The procedure for changing settings. . . . . . . . . . . . . . . . . . . . . 51

4.12 The creation of a study. . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.13 Assigning an intervention to a study. . . . . . . . . . . . . . . . . . . . . 53

4.14 A simplified life circle of an intervention. . . . . . . . . . . . . . . . . . . 53

4.15 The communication channels during patient registration. . . . . . . . . . 54

4.16 The seperate feedback thread for guided interventions. . . . . . . . . . . 55

4.17 The communication between eCoach and editor. . . . . . . . . . . . . . 56

4.18 The extra channel for emergency situations. . . . . . . . . . . . . . . . . 57

Bibliography

[1]

C. Abras, D. Maloney-Krichmar, J. Preece et al., “User-centered design,” Bain-

bridge, W. Encyclopedia of Human-Computer Interaction. Thousand Oaks: Sage

Publications, vol. 37, no. 4, pp. 445–456, 2004.

[2]

Abteilung Klinische Psychologie und Psychotherapie Universität Ulm. (2020) eSano

last accessed: 2020-05-24. [Online]. Available: https://esano.klips-ulm.de/de/

[3]

G. Andersson and N. Titov, “Advantages and limitations of internet-based

interventions for common mental disorders,” World Psychiatry, vol. 13, no. 1, pp.

4–11, 2014. [Online]. Available: https://www.onlinelibrary.wiley.com/doi/abs/10.

1002/wps.20083

[4]

H. Balzert, Lehrbuch der softwaretechnik: Basiskonzepte und requirements engi-

neering. Springer-Verlag, 2010.

[5]

A. Barak, L. Hen, M. Boniel-Nissim, and N. Shapira, “A comprehensive review

and a meta-analysis of the effectiveness of internet-based psychotherapeutic

interventions,” Journal of Technology in Human Services, vol. 26, no. 2-4, pp.

109–160, 2008. [Online]. Available: https://doi.org/10.1080/15228830802094429

[6]

H. Baumeister, L. Reichler, M. Munzinger, and J. Lin, “The impact of

guidance on internet-based mental health interventions — a systematic review,”

Internet Interventions, vol. 1, no. 4, pp. 205 – 215, 2014. [Online]. Available:

http://www.sciencedirect.com/science/article/pii/S2214782914000244

[7]

V. Bell, “Online information, extreme communities and internet therapy: Is the

internet good for our mental health?” Journal of Mental Health, vol. 16, no. 4, pp.

445–457, 2007. [Online]. Available: https://doi.org/10.1080/09638230701482378

[8]

M. Bilal, M. Waqar, and A. Javed, “An effective quality model for evaluating mobile

websites,” University of Engineering and Technology Taxila. Technical Journal,

vol. 20, no. 3, p. 54, 2015.

[9]

L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, Non-functional requirements in

software engineering. Springer Science & Business Media, 2012, vol. 5.

BIBLIOGRAPHY

[10]

M. R. Civanlar and B. G. Haskell, “Client-server architecture using internet and

public switched networks,” Nov. 30 1999, uS Patent 5,995,606.

[11]

B. F. Dear, J. B. Zou, S. Ali, C. N. Lorian, L. Johnston, M. D. Terides,

L. G. Staples, M. Gandy, V. J. Fogliati, B. Klein, and N. Titov, “Examining

self-guided internet-delivered cognitive behavior therapy for older adults

with symptoms of anxiety and depression: Two feasibility open trials,”

Internet Interventions, vol. 2, no. 1, pp. 17 – 23, 2015. [Online]. Available:

http://www.sciencedirect.com/science/article/pii/S2214782914000323

[12]

M. Domhardt, H. Geßlein, R. E. von Rezori, and H. Baumeister, “Internet-and

mobile-based interventions for anxiety disorders: A meta-analytic review of in-

tervention components,” Depression and anxiety, vol. 36, no. 3, pp. 213–224,

2019.

[13]

C. Fankam, S. Jean, L. Bellatreche, and Y. Aït-Ameur, “Extending the ansi/sparc

architecture database with explicit data semantics: An ontology-based approach,”

in European Conference on Software Architecture. Springer, 2008, pp. 318–321.

[14]

G. H. Galal and R. J. Paul, “A qualitative scenario approach to managing evolving

requirements,” Requirements Engineering, vol. 4, no. 2, pp. 92–102, 1999.

[15]

J. J. Garrett, Elements of user experience, the: user-centered design for the web

and beyond. Pearson Education, 2010.

[16]

M. Glinz, “On non-functional requirements,” in 15th IEEE International Require-

ments Engineering Conference (RE 2007). IEEE, 2007, pp. 21–26.

[17]

H. Heitkötter, S. Hanschke, and T. A. Majchrzak, “Evaluating cross-platform devel-

opment approaches for mobile applications,” in International Conference on Web

Information Systems and Technologies. Springer, 2012, pp. 120–138.

[18]

Idera,Inc. (2020) Idera,Inc. last accessed: 2020-05-24. [Online]. Available:

https://www.ideracorp.com/Legal/PrivacyShield

[19]

Kooperationsprojekt im Rahmen des Projekts "ICare - Integrating Technology into

Mental Health Care Delivery in Europe". (2020) ICare Prevent last accessed:

2020-05-22. [Online]. Available: https://icareprevent.com/

[20]

P. Loucopoulos and V. Karakostas, System Requirements Engineering. USA:

McGraw-Hill, Inc., 1995.

[21]

J. Ludewig and H. Lichter, Software Engineering: Grundlagen, Menschen,

Prozesse, Techniken. dpunkt. verlag, 2013.

BIBLIOGRAPHY

[22]

J. L. Martin, B. J. Norris, E. Murphy, and J. A. Crowe, “Medical device development:

The challenge for ergonomics,” Applied ergonomics, vol. 39, no. 3, pp. 271–283,

2008.

[23]

Mental Health Intervention. (2020) Mental Health Intervention last accessed:

2020-05-22. [Online]. Available: https://mentalhealthintervention.org/

[24]

minddistrict. (2020) minddistrict last accessed: 2020-05-22. [Online]. Available:

https://www.minddistrict.com/

[25]

M. Offergeld, “Vorlesung Usability Engineering - 06-UE-Integration-

Entwicklungsorganisation-download-uni,” Wintersemester 2019/2020.

[26]

R. Pichler, Scrum: agiles Projektmanagement erfolgreich einsetzen. dpunkt.

verlag, 2013.

[27]

M. Rouse. (2020) Zwei-Faktor-Authentifizierung last accessed: 2020-

05-24. [Online]. Available: https://www.computerweekly.com/de/definition/

Zwei-Faktor-Authentifizierung

[28]

S. Saddichha, M. Al-Desouki, A. Lamia, I. A. Linden, and M. Krausz, “Online

interventions for depression and anxiety–a systematic review,” Health Psychology

and Behavioral Medicine: an Open Access Journal, vol. 2, no. 1, pp. 841–881,

2014.

[29]

E. Scheuer, “Wie medical-decision-support-systeme die arzt-patient-beziehung

verändern–digitalisierung von informationen führt zu einer erhöhten autonomie des

patienten,” in Digitale Transformation von Dienstleistungen im Gesundheitswesen I.

Springer, 2017, pp. 311–321.

[30]

The General Data Protection Regulation. (2020) GDPR.EU last accessed:

2020-05-27. [Online]. Available: https://gdpr.eu/

[31]

S. Thonse, N. Siddaramappa, R. Sindhgatta, P. Mahalingam, S. Dhulipala, and

R. Subramanian, “Software system requirements specification framework and tool,”

Aug. 3 2006, uS Patent App. 11/084,730.

[32]

Youper. (2020) Youper - Emotional Health last accessed: 2020-05-22. [Online].

Available: https://www.youper.ai/

NAME: SABRINA BÖHM MATRICULATION NUMBER: 868071

Declaration

I, Sabrina Böhm, matriculation number 868071, hereby declare that I created this work

on my own. Except where referenced and credited to the original author, I have not

used the material of others in my work.

Ulm, ...................................................................

Sabrina Böhm