badanti 2.0: a web platform for caregivers & families · master graduation thesis by: ali...

Politecnico di Milano

Scuola di Ingegneria dell’Informazione

Polo territoriale di Como

Master of Science in Computer Engineering

Badanti 2.0: A Web Platform for

Caregivers & Families

Supervisor: Prof. Sara Comai

Co-Supervisor: Prof. Fabio Salice

Master Graduation Thesis by: Ali Kamran Maken

Student Id. number: 10415804

Academic Year 2016-2017

It always seems impossible

until it is done.

(Nelson Mandela, 2001)

Abstract

Due to the improved availability and quality of health care, we have an ever increasing

number of elderly in the society. They need help regarding day to day activities, by

caregivers. This work devise a web platform on which elderly and/or their families

can be connected with caregivers. An algorithm is also created for matching help

requests initiated by the elderly, with willing caregivers, based on their profiles in

the platform, in an automatic way. The platform also supports taking administrative

actions over the process.

Acronyms

Abbreviation Meaning

ACID Atomicity, Consistency, Isolation and DurabilityCRUD Create, Read, Update and DeleteCSS Cascading Style SheetsDB DatabaseDBMS Database Management SystemGDAL Geospatial Data Abstraction LibraryGIS Geographic Information SystemHTML Hyper Text Markup LanguageJS Java-scriptMVC Model-View-ControllerMVT Model-View-TemplateORM Object Relational MapperPIP PIP Installs Packages (recursive)RDBMS Relational DBMSUI User InterfaceURL Universal Resource Locater

Contents

Abstract v

Acronyms vii

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background and Technologies 5

2.1 Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Software Application Architectures . . . . . . . . . . . . . . . . . . . 6

2.3 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Web Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.1 Back-End frameworks . . . . . . . . . . . . . . . . . . . . . . 10

2.4.2 Front-End Frameworks . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Database Management System (DBMS) . . . . . . . . . . . . . . . . 12

2.5.1 Postgres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.2 Object Relational Mapper (ORM) . . . . . . . . . . . . . . . . 12

2.6 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Design & Architecture 17

3.1 Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.2 Elderly or Older Adult Person . . . . . . . . . . . . . . . . . . 18

3.1.3 Family Member . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.4 Caregiver/Care provider . . . . . . . . . . . . . . . . . . . . . 18

x CONTENTS

3.1.5 Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Caregiver Data Entry Form . . . . . . . . . . . . . . . . . . . 19

3.2.2 Family Member / Elderly Data Entry Form . . . . . . . . . . 23

3.3 High Level Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4 High Level Technical Requirements . . . . . . . . . . . . . . . . . . . 25

3.5 Solution Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5.1 Web Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.5.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.6 Algorithmic details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.6.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 29

3.6.2 Planning & Analysis . . . . . . . . . . . . . . . . . . . . . . . 30

3.6.3 Design & Implementation . . . . . . . . . . . . . . . . . . . . 30

3.6.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Database Design 41

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Planning & Analysis Phase . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.1 Available Technologies . . . . . . . . . . . . . . . . . . . . . . 41

4.2.2 Technology Selection Criterion . . . . . . . . . . . . . . . . . . 42

4.2.3 Final Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Database Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.1 Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.2 ER Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.3 Detailed Entities . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 Implementation Details 57

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2 Use-Case Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.3 Code Snippets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Results 65

6.1 Screen Shots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.1.1 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

CONTENTS xi

6.1.2 Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.1.3 Profile section . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.1.4 Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.1.5 Caregiver Application Forms . . . . . . . . . . . . . . . . . . . 73

6.1.6 Family Member Help Request Forms . . . . . . . . . . . . . . 79

6.1.7 Operator Management Area . . . . . . . . . . . . . . . . . . . 83

7 Conclusion & Future work 85

List of Figures

2.1 Web Application Architecture . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Model-View-Controller Architecture . . . . . . . . . . . . . . . . . . 7

2.3 Model-View-Template Architecture . . . . . . . . . . . . . . . . . . . 8

2.4 Three Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Object Relational Mapper . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Object Relational Mapper in action . . . . . . . . . . . . . . . . . . 13

2.7 High Level Application Architecture . . . . . . . . . . . . . . . . . . 14

2.8 Logical Application Architecture (Logical) . . . . . . . . . . . . . . . 15

4.1 Profile and User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2 Family Member Help Request . . . . . . . . . . . . . . . . . . . . . . 51

4.3 Profile and Caregiver . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.4 Basic Profile Entities (Profile, Address & ContactNumber) . . . . . . 52

4.5 Entities related to FamilyMemberHelpRequest . . . . . . . . . . . . . 53

4.6 Entities related to CareGiver . . . . . . . . . . . . . . . . . . . . . . . 54

4.7 Built-in Entities (User, Group & Permission) . . . . . . . . . . . . . . 55

4.8 Built-in Entities (ContentType & LogEntry) . . . . . . . . . . . . . . 55

5.1 User basic actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2 Logged-in user actions . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.3 Caregiver actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.4 Family Member actions . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5 Operator actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.1 New User Registration Screen . . . . . . . . . . . . . . . . . . . . . . 66

6.2 Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.3 Profile Home (Caregiver) . . . . . . . . . . . . . . . . . . . . . . . . 67

xiv LIST OF FIGURES

6.4 Family Member: Profile . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.5 Profile Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.6 Date of Birth Entry at Profile Details . . . . . . . . . . . . . . . . . 70

6.7 Address List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6.8 Address Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.9 Contact Numbers List . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.10 Contact Number Details . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.11 Caregiver: Incomplete Profile Message . . . . . . . . . . . . . . . . . 72

6.12 Caregiver: Complete Profile Percentage Notification . . . . . . . . . 72

6.13 Caregiver: Complete Profile Message . . . . . . . . . . . . . . . . . . 73

6.14 Family Member: Dashboard Overview . . . . . . . . . . . . . . . . . 73

6.15 Caregiver Form for Citizenship Information . . . . . . . . . . . . . . 73

6.16 Caregiver Form for adding CV . . . . . . . . . . . . . . . . . . . . . 74

6.17 Caregiver Form for adding Educational details . . . . . . . . . . . . 74

6.18 Caregiver Form for adding General Availability Information . . . . . 75

6.19 Caregiver Form for entering General Skills . . . . . . . . . . . . . . . 75

6.20 Caregiver Form for adding Health Skills Information . . . . . . . . . 76

6.21 Caregiver Form for entering details about Italian Documents . . . . 77

6.22 Caregiver Form for adding other related Information . . . . . . . . . 77

6.23 Caregiver Form for adding other related skills . . . . . . . . . . . . . 78

6.24 Caregiver Form for adding time availability Information . . . . . . . 78

6.25 Request: Required Time Slots . . . . . . . . . . . . . . . . . . . . . . 79

6.26 Request: Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.27 Request: Disease Information . . . . . . . . . . . . . . . . . . . . . . 80

6.28 Request: Contact Person(s) . . . . . . . . . . . . . . . . . . . . . . . 81

6.29 Request: Caregiver Preferred Citizenship(s) . . . . . . . . . . . . . . 81

6.30 Request: Needed Skills . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.31 Request: Needed Availability . . . . . . . . . . . . . . . . . . . . . . 82

6.32 Request: Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.33 Operator: Dashboard Overview . . . . . . . . . . . . . . . . . . . . . 83

6.34 Operator: Manage Operators . . . . . . . . . . . . . . . . . . . . . . 83

6.35 Operator: Manage Requests . . . . . . . . . . . . . . . . . . . . . . . 83

6.36 Operator: Manage Caregivers . . . . . . . . . . . . . . . . . . . . . . 84

6.37 Operator: Map View . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

LIST OF FIGURES xv

6.38 Operator: Request Match Action . . . . . . . . . . . . . . . . . . . . 84

6.39 Operator: Request Match Results . . . . . . . . . . . . . . . . . . . 84

Listings

3.1 Python: Get Matched Profiles . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Python: Compute Caregiver Matrix . . . . . . . . . . . . . . . . . . . 33

3.3 Python: Evaluate Caregiver against a Request . . . . . . . . . . . . . 34

3.4 Python: Get ranked caregivers . . . . . . . . . . . . . . . . . . . . . . 34

3.5 Python: Get a perfect caregiver . . . . . . . . . . . . . . . . . . . . . 34

3.6 Python: Calculate Score . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Adding support for PostGIS in Postgres . . . . . . . . . . . . . . . . 42

4.2 Configuring Django to use Postgres with PostGIS extension . . . . . 43

5.1 Python: Get euclidean distance . . . . . . . . . . . . . . . . . . . . . 61

5.2 Python: Get difference between lists . . . . . . . . . . . . . . . . . . 62

5.3 Python: Get difference between two generic collections . . . . . . . . 62

5.4 Python: Get normalized geographical distance between two points . . 63

5.5 Python: Get geographical distance between two points . . . . . . . . 63

5.6 Python: Normalize the distance between 0 and 1 . . . . . . . . . . . 63

5.7 Python: Get boolean equality between two strings . . . . . . . . . . . 64

List of Tables

3.1 Sample Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.2 Sample Caregivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Sample Calculated Score . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4 Selected Caregiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.5 Caregiver Evaluation w.r.t Request . . . . . . . . . . . . . . . . . . . 39

3.6 Perfect Caregive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.7 Caregiver 27 Evaluation w.r.t Perfect Caregive PC . . . . . . . . . . . 40

3.8 Sample Selected Caregivers . . . . . . . . . . . . . . . . . . . . . . . . 40

Chapter 1

Introduction

Recent WHO publication ranked Italy to have the second best health care system

in Europe [1]. One of the prominent effects of having a better health care system is

having a higher number of people in their old age. Most of these people are in need of

external help to perform their daily activities. This increases the demand of a system

by which professional caretakers can be hired to help these people in need.

1.1 Background

Italy is one of the leaders when it comes to taking care of its elderly. There is an

increasing need of platforms where the elderly or their representatives and family

members can find appropriate help in the form of people who can work as carers or

caregivers.

Sometimes the help is required for a few hours for some days in a week. While at

other instances the caregiver needs to be present at all times, for all days of the week.

This depends on the specific requirements usually based on the condition of person in

need.

In its current state, if an elderly is in need of help from a professional caretaker,

the family member(s) have to provide all the required information on paper based

forms and submit them to the appropriate authorities.

These forms include information like their needs, the complete address, the time

slots they need and the eventual duration of the job. They also have to provide

the details about the physical constraints and conditions of the person in need.

Similarly, the caregivers provide the authorities with information such as their registry

2 Introduction

information, abilities, availability w.r.t time.

The authorities are then responsible of providing the family with the right person

who satisfies all the requirements mentioned in the forms.

The process is slow and the search for the right person has to be done manually

and on case-to-case bases. The coordination between the caregiver and the family

member is done directly between these parties and it is hard for the authorities to

keep track of the communications and disputes and eventually their resolutions.

1.2 Purpose

A web portal which would assist local governments in managing the connection and

communication between elderly or their representatives and the people who are willing

to work as carers.

The purpose is to handle supply and demand between caregivers and families with

the supervision and administration of professional moderators that handles eventual

conflicts between parties.

The portal should be able to provide a platform for the families and caregivers

to add their information and then they are automatically matched based on their

profiles.

1.3 Organization

This document is organized in the following way:

• Chapter 2 discusses background and technologies.

• Chapter 3 explains the overall design methodology and describes high level

architectural details about the project.

• Chapter 4 discusses the Database aspect of the project. It includes the detailed

information about the selection, design and implementation of the database

technology and expresses its architecture with the help of illustrations and

diagrams.

• Chapter 5 describes the various supporting software terminologies with the

help of industry standard diagrams and charts and also presents code and its

description from some key sections.

1.3 Organization 3

• Chapter 6 shows the results obtained in the form of screen-shots.

• Chapter 7 contains the conclusions and expresses the possible improvements

that can be made in a future extension of the project.

4 Introduction

Chapter 2

Background and Technologies

This chapter contains the required general concepts with a focus on the tools and

technologies used during the project development stage.

2.1 Web Application

A web application is a software that runs in a web architecture and is served by a

web server. The most common architecture and its components are described in the

next subsections:

Figure 2.1 shows a typical layout for a web application:

Figure 2.1: Web Application Architecture

It’s main components include:

• Browser

This is the software application used by a user to connect to the Internet in

order to access any resource available on the Web. A browser, based on the

URL entered, will contact a web server over the Internet and will display the

information received in response.

6 Background and Technologies

• Internet

The communication medium used between a client application (browser) and

the web application.

• Web server

This is a server that is accessible through the Internet. It receives a request

(URL) from the client (browser) and processes it accordingly. In case the request

is for a static resource, then the web server can directly reply with the resource as

a response. If the requested is invalid or the web server is unable to understand

the request altogether, then the server can also reply directly without relaying

the request further downstream. User authentication and security is handled by

web server directly. A worthwhile example is Apache HTTP Server [2].

• Application Server

This server usually sits behind the Web server and is not directly accessible over

the Internet. This increases the overall security of the application. Only trusted

requests are forwarded to the application server. This usually involves requests

for dynamic web content. The business logic of the application resides in this

server. If to complete a request, the server needs data from database then an

appropriate request for the data is forwarded to the database server. Based on

the response received from the database, the application server can respond

accordingly.

• Database Server

Most web applications rely on data and that needs to be stored somewhere.

A database server will host a database management system to support such a

requirement. This server receives request for specific data from the Application

server and it replies with the data if available or an appropriate response in case

of unavailability of data.

2.2 Software Application Architectures

When writing software, multiple approaches can be used. However for any reasonable

sized project, using one of the commonly used software application architectures is

2.2 Software Application Architectures 7

inevitable. Web applications aren’t much different in this regard. Following are the

most common architectures for Web applications:

• Model-View-Controller (MVC)

MVC [3] is a popular software application architecture because it works great in

most kinds of applications software written for desktop, web and even mobile.

It divides the application in to three distinct sections which are interconnected

in a specific way. The information can only flow in one direction as shown in

figure 2.2. This helps in logical separation of the way the information is kept in

the application and the way it is shown to or received from the user. This way

the different components can be implemented and tested efficiently.

Figure 2.2: Model-View-Controller Architecture

• Model-View-Template (MVT)

MVT is inspired by MVC in the way that it keeps different concerns into

multiple interconnected parts. This has been introduced by Django framework

(see section 2.4.1) [4]. In this case the Django framework itself acts as the

controller and also includes another component which is called Templates, as

shown in the figure 2.3, which also means that the framework has a great support

for different templating systems. By default the framework comes with its own

templating language known as Django Template Language [5].


Figure 2.3: Model-View-Template Architecture

• Three-Tier

As the name suggests, this architecture usually means distributing the application

over multiple tiers. Three-tier architecture is a specific type of N-tier architecture.

The application is divided in to three distinct layers which follow a linear flow

of information between each other as depicted in the figure 2.4. These layers

can be described as follows:

– Presentation Layer (UI)

This layer is responsible for presenting data to the user. It also allows

submitting of data from user for example in a data entry form. The data

delivered to the user is usually requested from the layer below, i.e. the

business layer and transforms the data in to appropriate visual and text

elements using HTML that can be displayed in a browser at the user end of

the application.

– Business Logic Layer

This layer contains the business rules for the application. The separation

of the presentation logic and business logic helps keeping the development

and validation simple and efficient. The business layer receives any request

from presentation layer and sends an appropriate response. If the request

needs any data from the next layer then it is forwarded to the next layer

for processing.

– Data Access Layer

This is the final layer in the system and it consists of a DBMS. Keeping the

DBMS on a separate tier helps in easy management and replacement of the

2.3 Python 9

underlying DBMS, if needed.

Figure 2.4: Three Tier Architecture

2.3 Python

Python is a multi-paradigm programming language [6]. Since it’s conception in 1991, it

became hugely popular due to it’s simple syntax. It’s been in the top 10 programming

languages list since 2004 according to the TIOBE Index [7]. It was one of the first

general purpose languages at the time. Being cross platform, it is a goto choice for

a wide majority of developers, from simple scripts to scalable applications. It is a

dynamic typed language, which means that the developer doesn’t have to specify a

data types and they will be inferred at runtime. This makes it easy to grasp for the

programming beginners.

The extensive amount of libraries available for Python helps greatly in reducing

the time spent during development. The official On-line help resource is one of the

best. The on-line community of developers is highly praised for being helpful, sharing

knowledge and support in troubleshooting. Multiple package managers like pip are

available with deep integration which helps in easy setup, development, deployment

and hassle-free dependency management.

Due to all these features, over the years it has acquired usage in many fields of

science:

• Mathematics

• Data Sciences

• Machine Learning

• Artificial Intelligence

• Natural Language Processing

• Common scripting


2.4 Web Frameworks

A web framework provides convenience when writing a web application software. Most

of the frameworks provide out-of-the-box components which are essential in develop-

ment for an application. They provide methods of efficient and secure management

of static and dynamic content of the application. They almost always comes with a

built-in support for one or more Software Architecture patterns.

The web frameworks can be divided into two obvious categories:

• Back-End frameworks

• Front-End frameworks

2.4.1 Back-End frameworks

This type of framework helps writing the back-end part of a web application. It

usually includes all the aspects of a web application except for the presentation and

visual aspect.

Following is the description of a common back-end web framework:

Django

Django is a widely used free and open source Web framework [8]. It was conceived

in 2003, and released for public use in 2005 by Django software foundation, an

independent non-profit organization. It’s itself written in Python and thus is the

goto framework for writing web applications in Python. It uses a slightly modified

MVC software architecture pattern, called MVT as described in section 2.2. To support

the templating aspect of the MVT architecture, Django comes with a built-in Django

Template Language [5]. It also comes with integrated internationalization support

which helps easy translation and delivery of web content in user’s own language [9].

It has a built-in ORM (see section 2.5.2) and it aims at providing seamless abstraction

between user classes and underlying database engine. Although it has its own set

of libraries and extensions, but as written in Python it also benefits from the vast

amount of available libraries for Python. A few worthwhile examples are:

• GeoDjango

It is a geographic web framework [10]. It was developed as a separate module

for the Django Web framework, but due to it’s success, has since been included

2.4 Web Frameworks 11

in the core Django distribution. It tends to keep the simplicity of Django and

provides an easy way to develop GIS centric applications.

• Django FloppyForms [11]

As previously mentioned, Django heavily relies on its templating system for

rendering HTML web-pages. This extensions allows the effortless integration of

a highly acclaimed front-end framework, called Bootstrap (see section 2.4.2),

into the templates.

2.4.2 Front-End Frameworks

Web development is the process of creating web pages which are integral parts of

a web application that are presented to the user inside a web browser. The web

pages usually consist of the combination of HTML, CSS and JavaScript. A front-end

framework assists in the process of web development by providing reusable HTML, CSS

and JavaScript components. Using a front-end framework greatly reduces the effort

required to create visually appealing web interfaces and allows least effort in changing

the visual appearance of web interface if and when required.

Some popular examples for front-end frameworks are:

• Twitter Bootstrap

• Leaflet JS

• Foundation

• Materialize

Twitter Bootstrap

Bootstrap [12] is a hugely popular front-end framework. It was originally developed

at Twitter Inc. as an internal product called Twitter Blueprint but was later open

sourced and made available for public use in 2011. It focuses on reducing the effort to

create multi modal applications keeping the interface responsive, which means that

the visual interface can dynamically adapt to the consumer environment. Effectively,

the same application written for a desktop web browser would work seamlessly on a

mobile web browser. The interface would automatically adapt to the different screen

sizes and input interfaces (mouse vs. touchscreen). The framework consist of CSS


and JavaScript components that can be used for the front-end design which help in

achieving the dynamic (responsive) behavior to adapt to different devices.

Leaflet JS

Leaflet [13] is a JavaScript based Web framework, used to add web mapping

capabilities to web applications. It can be easily configured to use various map sources

like Google Maps, Open Street Maps and many others. It also provides basic, but

extensible, ability to manipulate GIS data at the user-end inside a browser.

2.5 Database Management System (DBMS)

A DBMS is a software application which is responsible for storing, managing and

performing administrative tasks on a database. It allows other applications and users

to interact with the database by allowing the creation, querying and updating of the

data in the database. A Relational DBMS (RDBMS) is a specific type of DBMS which

uses Relational Model which allows the data to be represented and manipulated in

terms of relations between database entities.

2.5.1 Postgres

Postgres [14] is a free and open-source DBMS widely used for its simplicity and reliabil-

ity. It offers several important features like Transactional Processing and ACID

Compliance. It also support pluggable extensions to provide additional functionality,

one such example is PostGIS [15], the GIS extension to provide storing and processing

GIS data in a regular Postgres database.

2.5.2 Object Relational Mapper (ORM)

In Object-Oriented Programming languages, data is usually kept in objects and

actions are performed on objects. Objects have attributes and their values constitute

the actual data. The relationship between objects depends on their hierarchy of the

classes.

However in most RDBMS systems the data is kept in the form of table stores, records

and relationships between tables. CRUD (create, read, update, delete) actions are

performed on records and each record can have one or more fields.

2.6 Architecture 13

These two concepts are different and cannot be used directly without any additional

processing and transformation from one to the other.

An Object Relational Mapper is a component which acts as an intermediary layer

between the Object-Oriented Programming language and a RDBMS. This is done by

defining an Object Relational Mapping which defines the rules on how to translate

data between the two paradigms as shown in the figure 2.5.

Figure 2.5: Object Relational Mapper

The figure 2.6 shows a specific example to help better explain the concept.

Figure 2.6: Object Relational Mapper in action

2.6 Architecture

After having the necessary background information regarding the technologies involved

in the development process, we can proceed by describing the architecture of the

project.


A high level application architecture is depicted in Figure 2.7. The components

are grouped in to different logical layers.

Figure 2.7: High Level Application Architecture

2.6 Architecture 15

The following image describes the logical placement of technologies used w.r.t to

the overall architecture.

Figure 2.8: Logical Application Architecture (Logical)

Chapter 3

Design & Architecture

This section describes the design methodology and related details of the architecture

of the system. At first, the system is described in terms of actors identified during

preliminary analysis and requirement definition phase, then, a high level requirements

description follows, and finally, the solution approach is described.

3.1 Actors

The system is composed of the following main actors also known as stakeholders:

• Customer

• Elderly or Older Adult Person

• Family Member

• Caregiver/Care Provider

• Operator

3.1.1 Customer

Customer is the entity who has requested this system, e.g., a government entity.

Customer is mainly passive in the context but is responsible to enforce the high level

requirements of the final system.

18 Design & Architecture

3.1.2 Elderly or Older Adult Person

It is the person being assisted by the caregiver that can have mobility or cognitive

problems. For this reason, in usual cases, family will be responsible for the management

of web portal activities and keeping a contact with the portal’s staff.

3.1.3 Family Member

As the elderly may not be able to operate and communicate using the web portal

effectively, one or more family members will be required to manage the portal on the

behalf of the elderly. These members could be for example the son, brother or a friend

(in case a close relative is not available for such purpose).

3.1.4 Caregiver/Care provider

A person with Professional qualification and experience as a caregiver, who is willing

to get hired to provide help to the older person in context.

3.1.5 Operator

This is the person responsible of moderating the requests from both the caregiver and

the family side. His/her responsibilities include, but are not limited to, the following

tasks; he:

1. Accepts or rejects a request for help;

2. Operates the system in order to find an appropriate match between a request

for help and an available caregiver;

3. Validates the information provided by other stakeholders and informs them in

case of any clarification;

4. Makes the necessary coordination between stakeholders in order to have a

functioning system.

3.2 Problem Statement 19

3.2 Problem Statement

A web based system should be implemented to support the management and coordi-

nation of family members who are in need of help and the people who are willing to

provide help and are known as caregivers in the system.

The system should consist of a landing home page which allows a user registration.

The registration should be a quick and simple procedure. It should only require basic

information like name and email address. The email address provided during the

registration should be used to validate a user by sending a validation email.

Once registered, the user should be able to describe himself/herself as a caregiver

(who wants to find a suitable work) or a family member (member of the family of care

receiver or care receiver himself/herself).

The appropriate information required from both roles (actors) of the system is

collected with the help of multiple on-line forms. The user must fill in basic profile

information including contact and address details. Then, the user should be able to

proceed with filling in the information required for acquiring the work as a caregiver.

The specific data forms for the roles are described in the following sections.

3.2.1 Caregiver Data Entry Form

The related fields are grouped together into multiple sections. In order to apply

for a job, the caregiver must fill in all the fields with appropriate information. The

percentage of the profile already filled is reported to the caregiver. Fields with an

asterisk (*) are mandatory for registration.

1. Basic registry

(a) Name (*)

(b) Surname (*)

(c) Tax code (*)

(d) Gender (*)

(e) phone (Multiple)

(f) Email (*)

(g) Date of Birth


(h) Fiscal Address (Permanent Address)

• Street

• House/Building number

• City

• Province

• Country

• Zip Code

(i) Dwelling Address (Address of Domicile)

• Street

• Number

• City

• Province

• Country

• Zip Code

2. Citizenship

• Citizenship (Multiple)

• Arrival day in Italy

• input document (documento di ingresso in italian)

• Purpose of visit

• Document Release Date

• Questura

3. Education

• Qualification

• Acknowledged in Italy? (yes/no)

4. Health skills

• able in moving into the Italian social service system

• ASA, OSS certificate or nurse in the origin country


• training as family caregiver

• experience or competence with psychiatric people

• experience or competence with disabled people

• experience or competence in helping in drug assumption over medical

prescription

• experience or competence with medical devices

• experience or competence in rising people from bed

• experience or competence with people affected with ALS

• experience or competence with people affected with Alzheimer or senile

dementia

• experience or competence with people affected with diabetes

• experience or competence with people affected with Parkinson disease

• experience or competence with people affected with oncology disease

• experience or competence with hair and beard care (cut and tint)

• experience or competence with personal hygiene (including feet)

• other experiences or competences (should be a text-area field)

5. General skills

• Italian language knowledge

• available if houses has no private bathroom for caregiver

• available if houses has no private bedroom for caregiver

• available if there are no public transport covering the house

• has a driving license valid in Italy

• able in changing the diaper

• able in ensuring the safety of the people in care

• able in taking care of people with opposite gender

• able in hydration care

• able in taking care of not collaborative people

• able in taking care of no walker people


• able in helping the people in care to eat

• able in helping the people in care to dress

• able in helping the people in care with personal hygiene

• able in helping the people in care going out from home

• able in cooking

• able in doing food shopping for the people in care

• able in washing and ironing

• able in cleaning the house

6. Time willing

• willing to work as temporary displacement

• willing to work in week ends

• willing to work as part-time (morning or afternoon or vertical)

• willing to work on 5 days week



• willing to work on h24/7

• willing to work during summer times in holidays with the people in care

7. Other information

• spouse or partner (yes/no)

• number of sons (total)

• number of underages sons

• number of sons in Italy (total)

• number of underages sons in Italy

8. Resume/CV

• Attached CV file


3.2.2 Family Member / Elderly Data Entry Form

The related fields are grouped together in to multiple sections. In order to request

help, the family member must fill in all the fields with appropriate information. Fields

with an asterisk (*) are mandatory for registration.

1. Basic registry

• Name (*)

• Surname (*)

• Tax code (*)

• Gender (*)

• Phone (Multiple)

• Email (*)

• Date of Birth

2. Disease information

• Percentage of disability

• Prevalent Area

• Effective Family Type

• Registered with by the social service (yes/no)

• Self-sufficient

• Diagnosis type

– Physical

– Psychological

– Sensory)

• Has personal doctor (yes/no)

3. Contact Person (Multiple & sortable.)

• Name

• Surname

• Type


• Phone (more than one)

4. Address

• Street

• House/Building Number

• Floor

• Stairs (yes/no)

• City

• Province

• Country

• Zip Code

5. Request Details

• Date of Request

• Charged to social services

• Preferred height

• Preferred weight

• Needed Time Slots (Multiple & can be Intermittent)

6. Motivations

• Worsening of the elderly conditions

• Night Assistance

• Replacement for an existing or previous caregiver

• Temporary replacement for an existing caregiver

7. Caregiver required Skills

• Gender

• Preferred Citizenship (Multiple & Sortable)

• Preferred Age range

3.3 High Level Requirements 25

3.3 High Level Requirements

These requirements include but are not limited to the following:

1. The system should consist of an on-line web portal.

2. The web portal should allow registration by providing minimum but necessary

information. This allows a quick registration process. The remaining information

can be added or updated later on as and when required.

3. The platform should be implemented in such a way that it automatically presents

itself in the language of the user. At the moment the only supported languages

are Italian and English.

4. A person should be able to register as a family member or a caregiver.

5. The family member should be able to request help for an older person.

6. At the time of request, the family member should be required to add all the

necessary information regarding the condition and situation of the elderly person

and his life style so the system could be effective.

7. The caregiver should be able to see the amount of information successfully

provided and similarly the amount of information remaining to be able to qualify

for as an applicant. This will allow the user to understand when he/she will be

able to apply for an available work opportunity.

8. The caregiver is only allowed to apply for available opportunities if the informa-

tion is completely provided.

9. In event of a successful match, the caregiver would be notified via an email with

detailed instructions on how to proceed with the process.

3.4 High Level Technical Requirements

1. The web portal should be implemented in an easy to use and commonly under-

stood language.

2. An associated web framework shall be used.


3. A relational database management back-end shall be used which is also capable

of handling data in a format that supports basic Geographical Information

System (GIS) capabilities.

4. The resulting product should be able to be used both on regular computers as

well as hand-held devices, such as mobile phones.

5. Some presentation framework should be used to make the product visually

appealing.

3.5 Solution Approach

3.5.1 Web Portal

Planning & Analysis Phase

Available Technologies

For the back-end implementation of the web-portal, multiple programming languages

were evaluated namely (C#, Java, Scala and Python).

For the web frameworks, Asp.Net, Spring, Play, Flask and Django were consid-

ered, which complement the programming languages that were under consideration.

Technology Selection Criterion

The back-end language should be fairly easy to understand and comprehend while

should not pose any extra learning curve for existing developers in the project hierarchy.

The technologies including the Integrated Development Environment (IDE) should

be cross-platform to be able to setup development environments without any specific

requirements of the underlying operating system.

The web framework to be used must be fairly simple and easy to configure. It

must also be well integrated with the back-end language as well as the IDE to ensure

no extra necessary steps needed to use it.

The tools used should be open-source so not to incur any one time or recurring

fees.

3.5 Solution Approach 27

Final Setup

Python was chosen as it can be used to quickly shape the project; many of the

developers in the project hierarchy were already familiar with it. Django was chosen

because of its simplicity and easy of use, towards building simple to real life projects.

To create efficient and responsive front-end interface, Bootstrap was selected. Leaflet

JS was used to display maps on the web pages.

PyCharm Community Edition was used as an IDE as it is extremely comfortable,

open-source, free and cross platform.

3.5.2 Workflow

The following section contains the details of work-flow for each role, from registration

to the end of process. First, the common work-flow for any type of role is described.

Common work-flows

• Registration

All the users of the web portal must register in order to use the services provided

by the on-line platform. The registration is intentionally kept simple and easy

to perform. The new user should enter his/her desired username, password and

a valid email address. The user will receive a validation email on the provided

email address which will contain a link to complete the registration process. The

link will expire after a certain duration (usually 7 days). If the user does not

click the link within this time-period, the registration process will automatically

get canceled and the process has to be started from the beginning. Once the

confirmation link is navigated, the registration process will be completed and

the user will be able to use the services.

• Basic Profile

Once registered and logged in to the portal, the user can proceed to the profile

section where he/she can select the role (Caregiver or Family Member); provide

personal information like name, date of birth etc; add personal contact details

and address. Multiple contacts and addresses can be added for a single profile.


Role based work-flows

After the basic profile has been completed and a specific role has been selected, the

remaining options will be presented according to the role.

• Caregiver

– Profile completion

To successfully apply for a job as a care provider, the caregiver needs

to complete the profile. This requires going through all the sections and

provide at least minimum information.

The chance of getting a job depends on the amount of detailed information

entered at this stage. The more the better.

The amount of profile information completed is reflected on the profile page

so that the caregiver knows his/her progress of the process. The progress

is represented as a percentage so the progress should reach 100% for the

caregiver to be able to apply for a job.

– Applying for job

The caregiver cannot apply for a job on his/her own. The application

action simply enables the caregiver profile for any future selection based

on an available help request in the system.

– The match

Once the caregiver profile gets matched with one or more available help

requests, he/she will be notified via email for further steps.

• Family Member

– Creating a request for help

The family member after being logged into the system can initiate a request

for help. This includes giving basic information about the request and then

proceeding to fill in all the required details.

Most of the details are not mandatory, but a complete request profile will

help in finding a better match.

– Submitting the request

3.6 Algorithmic details 29

The help request can be submitted upon completion. This will be reviewed

by an operator and will either be accepted or rejected. In case of rejection,

the user will be contacted to discuss the reasons of the rejection. In most

cased the operator would ask the user to enter some missing information

or clarify some of the information provided during the process.

– The match

Once approved the request can then be matched with all available caregiver

profiles. A match would find multiple suitable profiles, which can be drilled

down and selected by the operator. The family member will then be notified

with an email with further instructions.

3.6 Algorithmic details

3.6.1 Problem Statement

One of the main features of system is to be able to match the best profiles suitable to

a specific request for help. In most cases the system should generate multiple matches

so that the operator can chose the best option based on the related information as

well. To achieve that goal, a simple algorithm needs to be developed.

The work-flow which is the following:

1. Caregivers can fill in the details in their profile section and then apply for a job,

which basically means that their profile would be enabled for further matching.

2. The Family Members, who are in need to provide care for elderly, fill in the

details of their requirements in the Help Request section of the portal.

3. The features in a Help Request item has to be matched with the details in the

profile section of each caregiver. This will be done according to the algorithm

reported in section 3.6.3.

4. The system should provide at most a certain number of matches ordered by the

degree of meeting the requirements provided in the help request. The ordering

will help in deciding any alternatives.

5. The system has to be designed in a way to allow an operator to check for the

possible best matches on request.


3.6.2 Planning & Analysis

Although it seems to be a simple filtering problem as gradually filtering the caregiver

profiles, should give us all the matching records to declare as possible matches and

then we should be able to sort them with respect to one or more features to get the

best matches.

However, in this simple approach, profiles having some of the features satisfying

the requirements would also get eliminated. The results will vary and they depend on

the order of the filters being applied. A more strict filter on a feature will eliminate

some options which might have the best match in most of the other features.

Finally, in order to get any match, profiles having features which are perfect match

to the requirements must exist. This could be a solution, but a very restrictive one,

as in most cases there will be no matches or very few alternatives available for an

operator to make a final decision.

3.6.3 Design & Implementation

Design

To evaluate one feature of the caregiver at a time, for example Age, we have to

compare the value of the feature in the request profile with the value provided in each

caregiver’s profile. This will be a boolean comparison as there could be one of the

two scenarios:

1. The value of the caregiver’s age lies within the age range provided in the help

request. In this case the result will be true.

2. The value of the caregiver’s age lies outside the age range provided in the help

request. In this case the result will be false.

The following equation describes this kind of comparison:

result(f, x) =

1 if x is in range of feature f

0 if x is outside the range of feature f

For example, f in the above equation is Age and is provided as a range of maximum

and minimum values. Similarly x is the value provided by the caregiver

3.6 Algorithmic details 31

To compensate this scenario, we have to evaluate all of the features of a given

caregiver at the same time. Each feature must be evaluated based on its value and

how different it is from the requirement. In this kind of comparison there could be

one of the two scenarios:

1. The value of the caregiver’s age is not provided. In this case the result will be 0.

2. The value of the caregiver’s age is defined and is evaluated against the range

provided in the help request. In this case the result will be number between 0

(exclusive) and 1 (inclusive).

The following equation describes this kind of comparison:

result(f, x) =

0 if no value for x

normalized(diff(f, x)) otherwise evaluate x against feature f

For example, f in the above equation is Age and is provided as a range of maximum

and minimum values. Similarly x, is the value provided by the caregiver.

In section 5.3, the multiple diff functions are elaborated. As all the features are

not of homogeneous types, they have to be categorized in to the following separate

buckets. Each bucket then has to be handled according to its type.

1. Location

This feature contains the geographical location of the caregiver and the request

initiator. The difference between feature value and the requirement can only be

calculated using geo-spatial operation to calculate the physical distance between

these people.

Examples: Each profile contains an address field represented in geographical

coordinates (latitude, longitude). When trying to match, a caregiver profile

with a family member profile, the physical distance needs to be calculated using

the geographical coordinates provided in their respective profiles.

2. Range

There are multiple features, which are defined in terms of a range of values.


These ranges are compared in terms of the distance between their mode values.

The procedure is described in section 5.1.

Examples: The age feature in a help request is defined in terms of a range,

while a caregiver profile contains a single value for that feature. The weighted

difference between the two feature values, needs to be calculated.

3. List

The features which are lists are compared in terms of the number of missing

elements in the feature as compared to in the list provided as the requirement.

Examples: The list of preferred citizenships provided in a help request needs

to be evaluated against the list of citizenships for a given caregiver in his/her

profile.

4. Boolean

These features are simple and are compared directly.

Examples: A gender specified in the help request needs to be compared with

the gender given in a caregiver profile.

Implementation

In order to match the caregiver profiles with the help request requirements, we have

to evaluate all the features of the caregiver with same precedence.

To do this we calculate a score for each caregiver. The score represents the

similarity of the caregiver’s features with that of the help request requirements.

Then we rank the scores and return the best n scores with caregiver IDs, and then

select the caregivers matching with those IDs.

Data preparation

As the features of the caregivers are separated into logical entities, where each

entity is connected with a Profile entity with its ID value.

To make the evaluation process simple, we have to first reduce this hierarchy into

a simple data structure where we have all the features of the caregiver at the same

level as its main attributes such as ID.

Results

The algorithm matches the maximum number of caregiver profiles. To keep that

down to the best matches, the algorithm returns only the top x best matches.

3.6

Alg

orith

mic

deta

ils33

Algorithm

The following pseudo code segments show how to perform the matching algorithm after the data has been prepared as

described in the previous section.

1. The process of matching starts by calling the match method by providing a help request id for which a match is

requested by the operator.

1 def match(request_id : Integer):

2 r : Request = get_request_for_id(request_id)

3 m : Matrix = calculate_matrix(r)

4 matched_caregivers = rank( m, 5 )

5 reutrn matched_caregivers

6

Listing 3.1: Python: Get Matched Profiles

2. A matrix is calculated for the request r which contains evaluate result against all caregiver profiles.

1 def calculate_matrix(r : Request):

2 all_caregivers : List[Profile] = get_all_caregivers ()

3 matrix : List[Caregiver] =

4 foreach Profile c in all_caregivers:

5 evaluate(c, r)

6 return matrix

7

Listing 3.2: Python: Compute Caregiver Matrix

3. The evaluate method takes a request r and a caregiver profile c and calculates the diff for each feature pair. The

implementation of diff function depends on the type of feature. The description of various diff functions are given

in section 5.3.

34

Desig

n&

Arch

itectu

re

1 def evaluate(c : Profile , r : Request):

2 c: Caregiver =

3 foreach feature f in c:

4 diff(f, r.f)

5 return c

6

Listing 3.3: Python: Evaluate Caregiver against a Request

4. Once the matrix m is calculated, it is passed onto the rank function with a required number of matches n. A perfect

caregiver pc is taken as a reference to calculate the score for each item in the matrix. The best n matches are returned

as a result.

1 def rank(m : Matrix , n : Integer):

2 """

3 m is all caregiver processed profiles using evaluate () method

4 n is the number of matches required

5 """

6 pc: Perfect_Caregiver = get_perfect_caregiver ()

7 c_s_List : List[(c,s)] =

8 foreach caregiver c in m:

9 s: Score = caculate_score(c, pc)

10 (c, s)

11 return n_largest(c_s_List , n)

12

Listing 3.4: Python: Get ranked caregivers

The perfect caregiver is a caregiver with maximum score to be used as a reference.

3.6

Alg

orith

mic

deta

ils35

1 def get_perfect_caregiver ():

2 """

3 Returns a Caregiver object with maximum score.

4 """

5 caregiver: CareGiver = CareGiver(-1, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0)

6 caregiver.set_score(float(’inf’))

7 return caregiver

8

Listing 3.5: Python: Get a perfect caregiver

5. The score is calculated by subtracting each individual score of the feature f of caregiver c from the score of the same

feature in the perfect caregiver pc. All the individual results are added to get the final score for provided caregiver c.

1 def calculate_score(c : Caregiver , pc : PerfectCaregiver):

2 f_score_list : List[double] = foreach feature f in c:

3 f_score = pc.f - c.f

4 return sum_all(f_score_list)

5

Listing 3.6: Python: Calculate Score

3.6.4 Example


In the following section an example is presented with a given help request (Table

3.1). The help request is evaluated against 30 caregiver profiles. The list of caregivers

is presented in Table 3.2. Table 3.3 shows the evaluated profiles and their calculated

scores. Finally, Table 3.8 shows the selected caregiver profiles, which have the highest

score.

3.6

Alg

orith

mic

deta

ils37

Table 3.1: Sample Request

REQUEST-ID LOCATION MIN-AGE MAX-AGE MIN-WT MAX-WT MIN-HT MAX-HT GENDER CITIZENSHIP LANGUAGE

1 (39 13 0) 22 30 50 60 95 110 F [’Italian’, ’Chinese’] [’Italian’]

Table 3.2: Sample Caregivers

CG-ID LOCATION AGE WEIGHT HEIGHT GENDER CITIZENSHIP LANGUAGE

0 (38 14 0) 55 101 178 M [’Italian’, ’Polish’, ’Romanian’] [ ]1 (38 14 0) 38 69 121 M [’Polish’, ’Romanian’, ’Chinese’] [’Italian’]2 (39 14 0) 51 112 188 F [’Italian’, ’Romanian’] [ ]3 (39 12 0) 28 56 199 M [’Romanian’, ’Chinese’] [ ]4 (40 12 0) 42 120 175 M [’Polish’, ’Italian’, ’Chinese’] [ ]5 (39 14 0) 42 48 166 M [’Italian’, ’Romanian’, ’Polish’] [ ]6 (39 12 0) 55 103 197 F [’Italian’, ’Polish’] [ ]7 (38 14 0) 42 117 194 M [’Polish’, ’Romanian’] [ ]8 (39 12 0) 21 115 178 M [’Chinese’] [ ]9 (38 14 0) 39 110 158 F [’Italian’, ’Romanian’] [’Italian’]

10 (40 14 0) 42 104 166 F [’Polish’, ’Italian’, ’Romanian’] [ ]11 (39 14 0) 29 70 165 F [’Romanian’, ’Italian’] []12 (40 14 0) 44 48 146 F [’Chinese’] [’Italian’]13 (38 12 0) 49 117 132 M [’Romanian’] [ ]14 (38 14 0) 20 111 174 F [’Romanian’] [ ]15 (38 12 0) 41 57 192 F [’Polish’] [’Italian’]16 (38 12 0) 30 118 187 F [’Chinese’] [’Italian’]17 (39 14 0) 39 64 149 M [’Romanian’] [ ]18 (38 12 0) 42 64 182 F [’Romanian’, ’Chinese’, ’Polish’] [ ]19 (38 14 0) 60 77 128 M [’Italian’, ’Romanian’, ’Chinese’] [ ]20 (39 14 0) 48 70 132 F [’Italian’, ’Romanian’, ’Chinese’] [’Italian’]21 (40 12 0) 29 41 123 M [’Romanian’, ’Chinese’, ’Polish’] [ ]22 (38 12 0) 33 72 199 M [’Romanian’] [’Italian’]23 (40 13 0) 37 46 141 M [’Romanian’, ’Italian’, ’Chinese’] [ ]24 (38 12 0) 41 66 153 F [’Chinese’, ’Italian’] [’Italian’]25 (40 13 0) 36 44 200 F [’Polish’, ’Romanian’, ’Italian’] [ ]26 (39 12 0) 32 51 131 F [’Romanian’, ’Polish’] [’Italian’]27 (39 13 0) 31 102 178 F [’Italian’, ’Romanian’] [’Italian’]28 (39 13 0) 25 70 174 M [’Polish’] [ ]29 (39 13 0) 44 117 173 M [’Chinese’, ’Italian’] [ ]

38

Desig

n&

Arch

itectu

re

Table 3.3: Sample Calculated Score

CG-ID LOCATION AGE WEIGHT HEIGHT GENDER CITIZENSHIP LANGUAGE SCORECOL: A B C D E F G Z

0 0.565685424949238 2 2 2 2 0.5 2 -4.0656854249492381 0.565685424949238 0.6666666666666667 0.6428571428571428 0.5945945945945945 2 0.5 0.0 2.0301961709323582 0.4 2 2 2 0 0.5 2 -1.93 0.4 0 0 2 2 0.5 2 0.099999999999999984 0.565685424949238 2 2 2 2 0.0 2 -3.5656854249492385 0.4 2 0.2857142857142857 2 2 0.5 2 -2.18571428571428556 0.4 2 2 2 0 0.5 2 -1.97 0.565685424949238 2 2 2 2 2 2 -5.5656854249492388 0.4 0.19999999999999996 2 2 2 0.5 2 -2.19 0.565685424949238 2 2 2 0 0.5 0.0 -0.06568542494923801

10 0.565685424949238 2 2 2 0 0.5 2 -2.06568542494923811 0.4 0 0.6666666666666667 2 0 0.5 2 1.433333333333333112 0.565685424949238 2 0.2857142857142857 2 0 0.5 0.0 1.648600289336476413 0.565685424949238 2 2 2 2 2 2 -5.56568542494923814 0.565685424949238 0.33333333333333337 2 2 0 2 2 -1.899018758282571515 0.565685424949238 2 0 2 0 2 0.0 0.43431457505076216 0.565685424949238 0 2 2 0 0.5 0.0 1.93431457505076217 0.4 2 0.4444444444444444 2 2 2 2 -3.844444444444444618 0.565685424949238 2 0.4444444444444444 2 0 0.5 2 -0.510129869393682419 0.565685424949238 2 2 2 2 0.0 2 -3.56568542494923820 0.4 2 0.6666666666666667 2 0 0.0 0.0 1.933333333333333121 0.565685424949238 0 0.6428571428571428 0.6341463414634146 2 0.5 2 0.657311090730204422 0.565685424949238 0.4285714285714286 2 2 2 2 0.0 -1.994256853520666823 0.4 0.6363636363636364 0.4444444444444444 2 2 0.0 2 -0.480808080808080924 0.565685424949238 2 0.5454545454545454 2 0 0.0 0.0 1.888860029596216625 0.4 0.6 0.5454545454545454 2 0 0.5 2 0.954545454545454626 0.4 0.33333333333333337 0 2 0 2 0.0 2.266666666666666627 0.0 0.19999999999999996 2 2 0 0.5 0.0 2.328 0.0 0 0.6666666666666667 2 2 2 2 -1.66666666666666729 0.0 2 2 2 2 0.0 2 -3.0

In Table 3.3 the last column represents the calculated score. The first column represents the ID of a caregiver profile.

The rest of the columns show the intermediate values of the feature evaluation in terms of distance from the requirement.

Some of the values in the score column are negative as the intermediate feature score values (columns A to G) can be

less than 0. During the calculation of intermediate feature score, if the value is too far, a penalty is applied. That results

in pulling down the overall effective score. This behavior is also described in the following details regarding intermediate

calculations.

To further explain the score calculation procedure, consider the following caregiver with ID 27:

3.6

Alg

orith

mic

deta

ils39

Table 3.4: Selected Caregiver

CG-ID LOCATION AGE WEIGHT HEIGHT GENDER CITIZENSHIP LANGUAGE

27 (39 13 0) 31 102 178 F [’Italian’, ’Romanian’] [’Italian’]

To calculate individual feature scores, each related feature is evaluated using an appropriate diff() function (see

Section 5.3).

Table 3.5: Caregiver Evaluation w.r.t Request

ID LOCATION AGE WEIGHT HEIGHT GENDER CITIZENSHIP LANGUAGE

CG (39 13 0) 31 102 178 F Italian, Romanian ItalianREQ (39 13 0) 22 to 30 50 to 60 95 to 110 F Italian, Chinese Italian

diff( ) score 0.0 0.19999999999999996 2 2 0 0.5 0.0

Take a reference Caregiver with maximum overall score.

Table 3.6: Perfect Caregive

CG-ID LOCATION AGE WEIGHT HEIGHT GENDER CITIZENSHIP LANGUAGE SCORECOL: A B C D E F G Z

-1 1.0 1.0 1.0 1.0 1.0 1.0 1.0 ∞

To calculate individual feature score, the results obtained in the previous step are subtracted from feature scores of

Perfect Caregiver.

40

Desig

n&

Arch

itectu

re

Table 3.7: Caregiver 27 Evaluation w.r.t Perfect Caregive PC

CG-ID LOCATION AGE WEIGHT HEIGHT GENDER CITIZENSHIP LANGUAGECOL: A B C D E F G

PC 1.0 1.0 1.0 1.0 1.0 1.0 1.027 0.0 0.19999999999999996 2 2 0 0.5 0.0

− 1.0 0.80000000000000004 -1.0 -1.0 1.0 0.5 1.0

The final overall score for a caregiver is calculated by adding all the individual feature scores obtained. In this specific

case it would be calculated as follows:

1.0 + 0.80000000000000004 + (−1.0) + (−1.0) + 1.0 + 0.5 + 1.0 = 2.3

Final score for all caregivers can be calculated following the same procedure. Rank the results w.r.t SCORE. In Table 3.8

the profiles with the best match according to the calculated score are presented. The number of profiles selected in the

final step depends on number of best profiles requested. In this specific case the number was set to 2.

Table 3.8: Sample Selected Caregivers

CG-ID LOCATION AGE WEIGHT HEIGHT GENDER CITIZENSHIP LANGUAGE SCORE

27 0.0 0.19999999999999996 2 2 0 0.5 0.0 2.326 0.4 0.33333333333333337 0 2 0 2 0.0 2.2666666666666666

Chapter 4

Database Design

The majority of the features and functionalities of the project are data centric. This

chapter reports Database design details of the project.

4.1 Introduction

4.1.1 Requirements

The following are the high level requirements towards the implementation of the

database back-end of the system.

• Reliable

• Open-source

• Free/No licensing fees

• Capable of performing GIS operations

• Easy to deploy

• Minimal effort required for maintenance and/or continuous operation

4.2 Planning & Analysis Phase

4.2.1 Available Technologies

As of today, there are multiple different database management systems available. Most

of the options have their unique features and they target different systems. During

42 Database Design

the planning phase of the project, the following database management systems were

evaluated:

• MS SQL Server

• MySql

• Postgres

4.2.2 Technology Selection Criterion

To select the right database technology for the project, the database management

system should at least have the following features:

• Open source

• Free

• GIS capable out of the box

• Easy to use

• Simple to deploy

4.2.3 Final Setup

At the end of the technology selection step, it has been decided to use Postgres as

the main relational database management system. This database itself doesn’t have

the capability of handling geo-spatial data and operations. For that purpose another

module, PostGIS [15] has to be added to the software after its installation. There are

also some preliminary steps to be performed in order to correctly initialize and utilize

the geo-spatial capabilities of the PostGIS extension for Postgres.

1 sudo -u postgres psql -c "CREATE EXTENSION postgis; CREATE EXTENSION

postgis_topology;" <DATABASE_NAME >

Listing 4.1: Adding support for PostGIS in Postgres

The <DATABASE NAME> is the name of the target database, which should have been

already created. This feature needs to be enabled for each database separately.

The database has to be configured with Django project as well. To do that we

have to add the following snippet in settings.py.

4.3 Database Structure 43

1 DATABASES = {

2 ’default ’: {

3 ’ENGINE ’: ’django.contrib.gis.db.backends.postgis ’,

4 ’NAME’: ’<DATABASE_NAME >’,

5 ’USER’: ’<USER_NAME >’,

6 ’PASSWORD ’: ’<PASSWORD >’,

7 ’HOST’: ’<HOST_NAME >’,

8 ’PORT’: ’<PORT >’,

9 }

10 }

Listing 4.2: Configuring Django to use Postgres with PostGIS extension

By default the Postgres connector for Django doesn’t not support PostGIS capa-

bilities. So django.contrib.gis.db.backends.postgis is used as an ENGINE instead

of the default Postgres connector django.db.backends.postgresql psycopg2

4.3 Database Structure

4.3.1 Entities

Entities are the recognizable ”nouns” of the system for which we need to store any

information. There are two kinds of entities present in the current system. These are

described in detail as following:

• Built-in Entities

By using a framework like Django, we get the advantage of utilizing many of

the ready-to-use features which are available out-of-the-box. Handling of the

session and user management is one of them. Although we can create our own

entities by modeling them appropriately and creating proper relations with the

rest of the system to achieve the same results. But why reinvent the wheel when

a thoroughly tested and well integrated solution is already available.

There are many built-in entities at work. But in the subsequent section, we will

discuss just the major ones.

– User

This is the main built-in entity to hold an instance of a user. It contains

main attributes like:

44 Database Design

∗ email

∗ username and

∗ password etc.

When a person attempts to login in to the system, his/her credentials

entered on the login page are checked against the values present in this

entity.

– Group

This is an entity to group multiple User instances in to a single parent

instance. This makes it easier to assign permissions on ContentType objects

to multiple Users at the same time instead of applying permissions to each

individual User one at a time.

– Permission

This entity holds the information about the effective permissions of a User

or a Group on a given ContentType object.

– LogEntry

This entity is present to keep a track of user operations which include the

successful operations that were performed as well as the operations which

were declined due to the user not having enough permissions on the current

content object.

– ContentType

A content object would be a model from the list of available models. It

is further identified by the name of application, in case there are more

than one applications present in a Django project and both contains an

application with the same name.

This entity is used in direct relation to the Permission and LogEntry

entities to check for the permission on the current content object and log

the results of such permission checking operation to the LogEntry.

– Session

This entity hold the information about the currently logged in Users. It

also contains the information about the validity of the currently logged in

users and when are they going to be asked again to re-enter their login

credentials based on an expiry data and time value for each active session.


• Created Manually

The remaining entities are created manually after they were identified in a prior

planning phase. They are described in the following section.

– Profile

The two main actors of the system Caregivers and Family Members have

many common attributes. The Operator actor also shares some attributes

with these two actors. To keep the system simple and to avoid excessive

duplication of the attributes, the same entity Profile is used to hold the

information about all three actors that are Caregivers, Family Members

and Operators.

To distinguish between Caregivers and Family Members a special field in

Profile entity is used which is named as type. If the value of this type

is CAREGIVER the profile instance holds information about a caregiver and

if the value is FAMILY MEMBER, then the profile instance holds information

about a family member.

The operator on the other hand are handled in a different way. They are

uniquely identified as an operator based on the attribute value present

in User entity. The relation can be traversed from the user field of the

Profile entity. In User entity, the field is staff defines an operator. The

field is a boolean so if the value is true, that means the connected instance

of the Profile is an operator and vice versa.

The attributes percent completed and profile enabled for matching

are fields specific for Caregiver actor profiles. They contain the amount of

information already filled in to the profile and whether the specific user’s

profile will be used while match finding process, respectively.

– Address

This is a common entity with generic fields to hold the information about

the address of any type of actor profiles. The type attribute further

differentiates different types of addresses that can be added. The values

could be one of:

∗ DOMICILE

∗ RESIDENCE

46 Database Design

∗ CONTACT

The field geom contains the geographical coordinates of the address in

geospatial format. This field is automatically populated by adding a ’pin’

on the map available in the Address Management area of the portal.

The entity can be traced back to a specific profile by traversing the relation

profile. This also allows more than one addresses to be stored for the

same profile.

– ContactNumber

This entity contains the information about the contact number(s) associated

with a profile. All the contact numbers of a profile can be obtained by

traversing the ContactNumber.profile field. Each contact number entry

can be specified for a type. The values of the type can be one of the

following:

∗ HOME

∗ WORK

∗ OTHER

∗ FAX

– Caregiver specific entities

∗ CareGiverCitizenship

A cregiver can have one or more citizenships. The information about

all the citizenships is held in this entity as a separate record for each

citizenship.

∗ CareGiverCV

The caregivers, during their job application procedure, have to upload

a copy of their CV/Resume. The reference to the uploaded file is

maintained in this entity.

∗ CareGiverEducation

This entity holds the information about obtained education by a

caregiver. The caregiver can enter one or more educational records.

All of the records are maintained by the profile id.

∗ CareGiverGeneralAbilities

Information about some general abilities of the caregiver. These include

ability to cook and clean etc.


∗ CareGiverGeneralAvailability Information about the availability of

the caregiver in absence/presence of facilities like public transport or

private bathroom etc.

∗ CareGiverHealthRelatedSkills This entity holds the information about

the professional competence and vocational experience in providing

care to people with specific medical disorders and ability to operate

related devices and apparatus.

∗ CareGiverTimeAvailability

This entity holds the information about the willingness to work with

respect to working days and holidays. For example working for 5 days

a week or availability for part time etc.

∗ CareGiverItalianDocuments

This entity hold information about the documents that are required for

a valid working contract. This is only used for management purposes.

∗ CareGiverOtherInformation

Some other details about the family structure of the caregiver. This is

also used for management purposes only.

∗ CareGiverOtherSkills

It contains the information about having a driving license and the

knowledge of Italian language.

∗ CareGiverExclusionFromMatch

A caregiver profile can be explicitly flagged for not suitable in an

automatic match. The information needs to be kept for each of the

caregiver profile per request basis. This entity will keep the status of

the flag.

– Family Member specific entities

∗ FamilyMemberHelpRequest

After adding preliminary information in Personal Information, Address

and Contact Number sections of the Profile area, the Family Members

can initiate a Help Request process.

This process will gather required information by asking multiple ques-

tions. The main record for such a process is held in this entity. It also

contains the final status of the application, it’s starting and ending

48 Database Design

dates and a short description.

∗ FamilyMemberCaregiverNeededSkills

This entity holds the requirements for age range and preferred gender

of the care provider.

∗ FamilyMemberCaregiverPreferredCitizenship

This entity contains the list of preferred citizenships and their order of

preference which will be checked against the caregiver profiles.

∗ FamilyMemberDiseaseInformation

Specific information about the physical condition and details regarding

any disease will be held in this entity. The information would be

percentage of disability, dominant area, self sufficient or not etc.

∗ FamilyMemberMotivations

This entity will indicate the family member’s motivation behind the

application. The motivation could be one of:

· Elderly person condition is degrading

· Caregiver replacement

· Caregiver temporary replacement

· Night time assistance

∗ FamilyMemberNeededAvailability

This entity holds the information about the requirement for a care

provider to work with respect to working days and holidays. For

example working for 5 days a week or required availability for part

time etc.

∗ FamilyMemberRequestDetails

Information about the date of request initiation and required height

and weight for a care provider would be kept in this entity.

∗ FamilyMemberRequestTimeSlots

The requirement for a caregiver to be present could be continuous like

throughout the day etc. or could be for multiple separate time frames

during a full day. This entity will contain all the required time slots

for which a caregiver presence is required.

∗ FamilyMemberContactPerson

A help request may contain one or more contact persons. The infor-


mation about these people will be kept in the following entity. Each

instance can be traversed back to the FamilyMemberHelpRequest en-

tity.

∗ ContactPersonPhone

Each contact person can have one or more contact numbers. They

are all maintained in the following entity. All contact numbers for a

given FamilyMemberContactPerson can be retreieved by traversing

the contact person field of ContactPersonPhone.

– Job

After a successful match has been found between a caregiver and family

member’s help request, the professional agreement of work is established

and the related information is maintained in this entity.

The entity also holds the traversable relation between a Caregiver and

a Family Member by adding the identifiers of their profile in to the same

record.

– JobFeedback

The feedback provided by the family will be maintained in this entity.

This will help the operators in making the final decision when a match is

suggested for a given caregiver.

– JobTimeSlot

This entity will hold the information about the working hours as agreed in

result of the work contract between a caregiver and the family. This is to

maintain the availability of unavailability of the caregiver in order to make

the matching happen without any conflicts with the existing and ongoing

jobs of that caregiver.

– JobWorkingHoursLog

This entity will keep the log for the hours spent by the caregiver. This will

help identify the punctuality of the caregiver and will help in resolution of

any conflicts between the related parties.

– Ticket

In order to resolve conflicts related to time and work, both family members

and caregivers can create tickets in the system. Tickets are associated

50 Database Design

with a Job as well as the related profiles of both caregiver and the family

member. This allows obtaining tickets associated with a Job or a specific

person.

– TicketComment

This entity will hold the comments from either the caregiver or the family

member, related to a specific Job and Ticket.

4.3.2 ER Diagrams

The following section contains the Entity-Relationship diagrams for the main entities

in the system.

Figure 4.1: Profile and User


Figure 4.2: Family Member Help Request

Figure 4.3: Profile and Caregiver

52 Database Design

4.3.3 Detailed Entities

Web Portal Entities

The following section contains the diagrams which show various major entities present

in the system.

(a) (b) (c)

Figure 4.4: Basic Profile Entities (Profile, Address & ContactNumber)


(a) (b) (c)

(d) (e) (f)

(g) (h) (i)

Figure 4.5: Entities related to FamilyMemberHelpRequest

54 Database Design

(a) (b)

(c) (d) (e)

(f) (g) (h)

(i) (j)

Figure 4.6: Entities related to CareGiver


Built-in Entities

The following section contains the built-in entities.

(a) (b) (c)

Figure 4.7: Built-in Entities (User, Group & Permission)

(a) (b)

Figure 4.8: Built-in Entities (ContentType & LogEntry)

56 Database Design

Chapter 5

Implementation Details

5.1 Overview

This chapter includes implementation details of the project. It’s contents are organized

as following:

• Use-Case Diagrams

Describes basic use-cases as identified during the requirement analyses phase.

• Code Snippets

Some key sections from the code, which are referred to, in other parts of this

document.

5.2 Use-Case Diagrams

The following section contains the most common scenarios depicted using use-case

diagrams.

A new user can register on the web portal by following the registration procedure,

or proceed with the login if he/she is already registered. This changes the role of

the user from being a Visitor to an Registered User. Operator on the other hand

doesn’t go through registration process and this type of user will login and access the

dashboard to perform management activities.

58 Implementation Details

Figure 5.1: User basic actions

Once a user logins into the portal, he/she can proceed to the profile section to start

filling the personal information. After first login the user should chose his/her role to

be either a caregiver or a family member. This selection will change the way the user

can interact with the portal as some of the work-flows depend on specific roles. The

personal information, address and contact information sections are available for every

role, so the user can fill this information in the profile section.

5.2 Use-Case Diagrams 59

Figure 5.2: Logged-in user actions

As a caregiver, the user has to fill in the complete profile with information regarding

the job. This step is important as it will allow the user to apply for a job. If the

profile isn’t entirely completed, an informational message will tell the user to complete

it.

Figure 5.3: Caregiver actions

A family member can create one or more requests for help from the dashboard

section. The requests can be modified/updated any number of times before they are

submitted. Once submitted, the request can also be withdrawn. The user can also

check the status of his/her current applications in the dashboard section.

60 Implementation Details

Figure 5.4: Family Member actions

Operators can perform all the administrative tasks from their dashboard section.

They can view profiles of both caregivers and family members. An Admin can also view

profiles of other operators and manage them. An operator can’t view the profiles

of other operators. The operator is presented with the list of the submitted help

requests. He/she can approve or reject the request. From an approved request page,

the operator can initiate the process to find matching caregiver profiles.

Figure 5.5: Operator actions

5.3

Code

Snip

pets

61

5.3 Code Snippets

The following section describes diff( ) functions from the source code.

The method get e distance [Listing 5.1] is used to calculate the distance between a range of values of a feature (from

the help request) and a single value of feature (associated with a caregiver). It returns euclidean distance between the

center of the range [x1, x2] and the single value represented as y.

1 def get_e_distance(x1 , x2 , y):

2 """

3 Calculated the normalized euclidean distance between the mid of the range (x1, x2) and the

point y in One Dimension.

4 :param x1: start of range x

5 :param x2: end of range x

6 :param y: point to check

7 :return: distance weighted between ~0 and 1. The lower the distance , the better the match

between range x

8 and point y in One dimension.

9 """

10 d = x2 - x1

11 if (y > x2 and abs(x2 - y) > d) or (y < x1 and abs(x1 - y) > d):

12 return 2 # 2 is the penalty

13 else:

14 middle_point = (x2 + x1) / 2

15 normalized_middle_point = abs(middle_point - x1)

16 result = abs(middle_point - y)

17 if result == 0.0:

18 return 0

19 else:

62

Imple

menta

tion

Deta

ils

20 return 1 - min(1, normalized_middle_point / result)

Listing 5.1: Python: Get euclidean distance

The method get q distance [Listing 5.2] quantifies the difference between two provided lists x and y. It checks for the

items that are requested (in a request for help) to be present or absent in the list of items that are available (for a current

caregiver profile). The difference is then normalized between 0 and 1. The check is performed in the method diff [Listing

5.3] presented further below.

1 def get_q_distance(x, y):

2 """

3 Get the normalized distance between two lists , x is required , y is provided.

4 :param x: list of required items

5 :param y: list of provided items

6 """

7 missing_items = diff(x, y)

8 result = len(missing_items) / len(x)

9 return 2 if result == 1 else result # 2 is the penalty

Listing 5.2: Python: Get difference between lists

1 def diff(first , second):

2 """

3 Returns the difference of collections passes as first and second.

4 """

5 second = set(second)

6 return [item for item in first if item not in second]

Listing 5.3: Python: Get difference between two generic collections

5.3

Code

Snip

pets

63

The method get loc distance [Listing 5.4] calculates the normalized distance between two geographical points. One

of the points is taken from the address provided in the caregiver profile and the other comes from the address of the

family member. The physical distance is calculated using method distance between points [Listing 5.5] which is then

normalized using method normalize distance [Listing 5.6] to limit the result between 0 and 1.

1 def get_loc_distance(caregiver: Profile , request_geom: Point , distance_limit: float) -> float:

2 """

3 Get the distance between the request initiator and the current caregiver.

4 :param caregiver: Profile of caregiver

5 :param request_geom: Point of request

6 :param distance_limit: Limit threshold

7 :return: The distance in float

8 """

9 domicile_address = caregiver.addresses.filter(type="DOMICILE").first()

10 if domicile_address:

11 caregiver_geom = domicile_address.geom

12 distance_between_request_caregiver = distance_between_points(caregiver_geom , request_geom)

13 if distance_between_request_caregiver <= distance_limit:

14 return normalize_distance(distance_between_request_caregiver)



Listing 5.4: Python: Get normalized geographical distance between two points

1 def distance_between_points(pnt1: Point , pnt2: Point) -> float:

2 return pnt1.distance(pnt2) * 100

Listing 5.5: Python: Get geographical distance between two points

1 def get_distance_threshold () -> float:

64

Imple

menta

tion

Deta

ils

2 return 25.0

3

4 def normalize(min_val , max_value , value):

5 return (value - min_val) / (max_value - min_val)

6

7 def normalize_distance(distance: float):

8 return normalize (0.0, get_distance_threshold (), distance)

Listing 5.6: Python: Normalize the distance between 0 and 1

The method get b distance [Listing 5.7] returns the result of boolean equality of two feature values.

1 def get_b_distance(x: str , y: str):

2 """

3 Get the normalized boolean distance between two strings.

4 :param x: String 1

5 :param y: String 2

6 :return: 0 if strings match. 2 otherwise. (Translates to 1 or -1)

7 """

8 if not y:


10 else:

11 if x.strip ().upper () == y.strip().upper():

12 return 0

13 else:


Listing 5.7: Python: Get boolean equality between two strings

Chapter 6

Results

This chapter includes the results of the project. The output of the project is a

web application, so this section contains screen-shots of different aspects of running

application.

The screen shots are organized in the following order:

• Registration

• Login

• Profile

– Caregiver

– Family Member

– Address

– Contact Information

• Dashboard

– Caregiver

– Family Member

• Application Forms

– Caregiver

– Family Member

• Administration

– Operator Dashboard

66 Results

6.1 Screen Shots

6.1.1 Registration

Figure 6.1: New User Registration Screen

6.1 Screen Shots 67

6.1.2 Login Screen

Figure 6.2: Login Screen

6.1.3 Profile section

Caregiver Profile

Figure 6.3: Profile Home (Caregiver)

68 Results

Family Member Profile

Figure 6.4: Family Member: Profile

6.1 Screen Shots 69

Personal Information

Figure 6.5: Profile Details

70 Results

Figure 6.6: Date of Birth Entry at Profile Details

Address Management

Figure 6.7: Address List

6.1 Screen Shots 71

Figure 6.8: Address Details

Contact Information Management

Figure 6.9: Contact Numbers List

72 Results

Figure 6.10: Contact Number Details

6.1.4 Dashboard

Caregiver Dashboard

Figure 6.11: Caregiver: Incomplete Profile Message

Figure 6.12: Caregiver: Complete Profile Percentage Notification

6.1 Screen Shots 73

Figure 6.13: Caregiver: Complete Profile Message

Family Member Dashboard

Figure 6.14: Family Member: Dashboard Overview

6.1.5 Caregiver Application Forms

Figure 6.15: Caregiver Form for Citizenship Information

74 Results

Figure 6.16: Caregiver Form for adding CV

Figure 6.17: Caregiver Form for adding Educational details

6.1 Screen Shots 75

Figure 6.18: Caregiver Form for adding General Availability Information

Figure 6.19: Caregiver Form for entering General Skills

76 Results

Figure 6.20: Caregiver Form for adding Health Skills Information

6.1 Screen Shots 77

Figure 6.21: Caregiver Form for entering details about Italian Documents

Figure 6.22: Caregiver Form for adding other related Information

78 Results

Figure 6.23: Caregiver Form for adding other related skills

Figure 6.24: Caregiver Form for adding time availability Information

6.1 Screen Shots 79

6.1.6 Family Member Help Request Forms

Figure 6.25: Request: Required Time Slots

80 Results

Figure 6.26: Request: Details

Figure 6.27: Request: Disease Information

6.1 Screen Shots 81

Figure 6.28: Request: Contact Person(s)

Figure 6.29: Request: Caregiver Preferred Citizenship(s)

82 Results

Figure 6.30: Request: Needed Skills

Figure 6.31: Request: Needed Availability

6.1 Screen Shots 83

Figure 6.32: Request: Motivation

6.1.7 Operator Management Area

Figure 6.33: Operator: Dashboard Overview

Figure 6.34: Operator: Manage Operators

Figure 6.35: Operator: Manage Requests

84 Results

Figure 6.36: Operator: Manage Caregivers

Figure 6.37: Operator: Map View

Figure 6.38: Operator: Request Match Action

Figure 6.39: Operator: Request Match Results

Chapter 7

Conclusion & Future work

During this thesis, the goal was to develop a web portal which will be used as a platform

to support the management of caregivers and families who want caregiver services for

someone in the family. The work started with the analysis of the requirements, was

followed by an investigation to identify best tools and technology to develop the web

portal. As a result, the web portal was developed, which supports caregivers, family

members and management operators in better coordination. It provides easy access

to job for care providers and required services to families.

In particular, an algorithm was proposed and implemented during the realization

phase of the project, which allows analysis and identification of best matching caregiver

profiles for a given help request.

Based upon the existing design, the simple matching algorithm can be extended

to incorporate the availability of caregivers with respect to time. The information

about their schedule is already a part of the platform and can be utilized during the

search for appropriate caregivers.

Furthermore the algorithm, in its current state only takes into consideration, one

profile at a time and evaluates all caregivers against it. This can be improved by

evaluating all caregivers against all approved and yet-to-be-processed help requests,

to find the optimal match, as a match for one help request changes the potential

availability of the caregiver for other requests.

86 Conclusion & Future work

Bibliography

[1] Measuring overall health system performance for 191 countries. www.who.int/

healthinfo/paper30.pdf.

[2] Httpd, apache http server. https://httpd.apache.org/.

[3] Model-view-controller software architecture pattern. https://developer.

mozilla.org/en-US/Apps/Fundamentals/Modern_web_app_architecture/

MVC_architecture.

[4] Model-view-template software architecture pattern. https://docs.

djangoproject.com/en/2.0/faq/general/.

[5] Django template language. https://docs.djangoproject.com/en/2.0/

topics/templates/.

[6] Python programming language. https://www.python.org/.

[7] Tiobe index. https://www.tiobe.com/tiobe-index/.

[8] Django web framework. https://www.djangoproject.com/.

[9] Django internationalization and localization. https://docs.djangoproject.

com/en/2.0/topics/i18n/.

[10] Geodjango gis extension for django. https://docs.djangoproject.com/en/2.

0/ref/contrib/gis/.

[11] Django floppyforms. https://github.com/gregmuellegger/

django-floppyforms.

[12] Twitter bootstrap. https://getbootstrap.com.

www.who.int/healthinfo/paper30.pdf

www.who.int/healthinfo/paper30.pdf

https://httpd.apache.org/

https://developer.mozilla.org/en-US/Apps/Fundamentals/Modern_web_app_architecture/MVC_architecture



https://docs.djangoproject.com/en/2.0/faq/general/

https://docs.djangoproject.com/en/2.0/faq/general/

https://docs.djangoproject.com/en/2.0/topics/templates/

https://docs.djangoproject.com/en/2.0/topics/templates/

https://www.python.org/

https://www.tiobe.com/tiobe-index/

https://www.djangoproject.com/

https://docs.djangoproject.com/en/2.0/topics/i18n/

https://docs.djangoproject.com/en/2.0/topics/i18n/

https://docs.djangoproject.com/en/2.0/ref/contrib/gis/

https://docs.djangoproject.com/en/2.0/ref/contrib/gis/

https://github.com/gregmuellegger/django-floppyforms

https://github.com/gregmuellegger/django-floppyforms

https://getbootstrap.com

88 BIBLIOGRAPHY

[13] Leaflet, an open-source javascript based web mapping framework. http://

leafletjs.com/index.html.

[14] Postgres, a dbms. https://www.postgresql.org/.

[15] Postgis, a gis extension for postgres dbms. http://postgis.net/.

http://leafletjs.com/index.html

http://leafletjs.com/index.html

https://www.postgresql.org/

http://postgis.net/