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
It always seems impossible until it is done.
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 Durability
CRUD
Create, Read, Update and Delete
CSS
Cascading Style Sheets
DB
Database
DBMS
Database Management System
GDAL
Geospatial Data Abstraction Library
GIS
Geographic Information System
HTML
Hyper Text Markup Language
JS
Java-script
MVC
Model-View-Controller
MVT
Model-View-Template
ORM
Object Relational Mapper
PIP
PIP Installs Packages (recursive)
RDBMS
Relational DBMS
UI
User Interface
Contents
Abstract v Acronyms vii 1 Introduction 1 1.1 Background . . . 1 1.2 Purpose . . . 2 1.3 Organization . . . 22 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.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
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.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
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
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
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
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.
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.
• 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 managedevelop-ment 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.
2.6 Architecture 15
The following image describes the logical placement of technologies used w.r.t to the overall architecture.
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.
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
3.2 Problem Statement 21
• 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 6 days week • willing to work on 7 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
3.2 Problem Statement 23
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.
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.
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(dif f (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
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
Algorithmic
details
33
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 m a t c h ( r e q u e s t _ i d : I n t e g e r ) : 2 r : R e q u e s t = g e t _ r e q u e s t _ f o r _ i d ( r e q u e s t _ i d ) 3 m : M a t r i x = c a l c u l a t e _ m a t r i x ( r ) 4 m a t c h e d _ c a r e g i v e r s = r a n k ( m , 5 ) 5 r e u t r n m a t c h e d _ c a r e g i v e r s 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 c a l c u l a t e _ m a t r i x ( r : R e q u e s t ) : 2 a l l _ c a r e g i v e r s : L i s t [ P r o f i l e ] = g e t _ a l l _ c a r e g i v e r s () 3 m a t r i x : L i s t [ C a r e g i v e r ] = 4 f o r e a c h P r o f i l e c in a l l _ c a r e g i v e r s : 5 e v a l u a t e ( c , r ) 6 r e t u r n m a t r i x 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.
Design & Arc hitecture 2 c : C a r e g i v e r = 3 f o r e a c h f e a t u r e f in c : 4 d i f f ( f , r . f ) 5 r e t u r n 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 r a n k ( m : Matrix , n : I n t e g e r ) : 2 """ 3 m is all c a r e g i v e r p r o c e s s e d p r o f i l e s u s i n g e v a l u a t e () m e t h o d 4 n is the n u m b e r of m a t c h e s r e q u i r e d 5 """ 6 pc : P e r f e c t _ C a r e g i v e r = g e t _ p e r f e c t _ c a r e g i v e r () 7 c _ s _ L i s t : L i s t [( c , s ) ] = 8 f o r e a c h c a r e g i v e r c in m : 9 s : S c o r e = c a c u l a t e _ s c o r e ( c , pc ) 10 ( c , s ) 11 r e t u r n n _ l a r g e s t ( c _ s _ L i s t , n ) 12
Listing 3.4: Python: Get ranked caregivers
3.6 Algorithmic details 35 1 def g e t _ p e r f e c t _ c a r e g i v e r () : 2 """ 3 R e t u r n s a C a r e g i v e r o b j e c t w i t h m a x i m u m s c o r e . 4 """ 5 c a r e g i v e r : C a r e G i v e r = C a r e G i v e r ( -1 , 1.0 , 1.0 , 1.0 , 1.0 , 1.0 , 1.0 , 1 . 0 ) 6 c a r e g i v e r . s e t _ s c o r e (f l o a t(’ inf ’) ) 7 r e t u r n c a r e g i v e r 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 c a l c u l a t e _ s c o r e ( c : C a r e g i v e r , pc : P e r f e c t C a r e g i v e r ) : 2 f _ s c o r e _ l i s t : L i s t [ d o u b l e ] = f o r e a c h f e a t u r e f in c : 3 f _ s c o r e = pc . f - c . f
4 r e t u r n s u m _ a l l ( f _ s c o r e _ l i s t ) 5
Listing 3.6: Python: Calculate Score
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
Algorithmic
details
37
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’] [ ]
Design
&
Arc
hitecture
CG-ID LOCATION AGE WEIGHT HEIGHT GENDER CITIZENSHIP LANGUAGE SCORE
COL: A B C D E F G Z 0 0.565685424949238 2 2 2 2 0.5 2 -4.065685424949238 1 0.565685424949238 0.6666666666666667 0.6428571428571428 0.5945945945945945 2 0.5 0.0 2.030196170932358 2 0.4 2 2 2 0 0.5 2 -1.9 3 0.4 0 0 2 2 0.5 2 0.09999999999999998 4 0.565685424949238 2 2 2 2 0.0 2 -3.565685424949238 5 0.4 2 0.2857142857142857 2 2 0.5 2 -2.1857142857142855 6 0.4 2 2 2 0 0.5 2 -1.9 7 0.565685424949238 2 2 2 2 2 2 -5.565685424949238 8 0.4 0.19999999999999996 2 2 2 0.5 2 -2.1 9 0.565685424949238 2 2 2 0 0.5 0.0 -0.06568542494923801 10 0.565685424949238 2 2 2 0 0.5 2 -2.065685424949238 11 0.4 0 0.6666666666666667 2 0 0.5 2 1.4333333333333331 12 0.565685424949238 2 0.2857142857142857 2 0 0.5 0.0 1.6486002893364764 13 0.565685424949238 2 2 2 2 2 2 -5.565685424949238 14 0.565685424949238 0.33333333333333337 2 2 0 2 2 -1.8990187582825715 15 0.565685424949238 2 0 2 0 2 0.0 0.434314575050762 16 0.565685424949238 0 2 2 0 0.5 0.0 1.934314575050762 17 0.4 2 0.4444444444444444 2 2 2 2 -3.8444444444444446 18 0.565685424949238 2 0.4444444444444444 2 0 0.5 2 -0.5101298693936824 19 0.565685424949238 2 2 2 2 0.0 2 -3.565685424949238 20 0.4 2 0.6666666666666667 2 0 0.0 0.0 1.9333333333333331 21 0.565685424949238 0 0.6428571428571428 0.6341463414634146 2 0.5 2 0.6573110907302044 22 0.565685424949238 0.4285714285714286 2 2 2 2 0.0 -1.9942568535206668 23 0.4 0.6363636363636364 0.4444444444444444 2 2 0.0 2 -0.4808080808080809 24 0.565685424949238 2 0.5454545454545454 2 0 0.0 0.0 1.8888600295962166 25 0.4 0.6 0.5454545454545454 2 0 0.5 2 0.9545454545454546 26 0.4 0.33333333333333337 0 2 0 2 0.0 2.2666666666666666 27 0.0 0.19999999999999996 2 2 0 0.5 0.0 2.3 28 0.0 0 0.6666666666666667 2 2 2 2 -1.666666666666667 29 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.
3.6
Algorithmic
details
39
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 Italian
REQ (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 SCORE
COL: 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.
Design
&
Arc
hitecture
CG-ID LOCATION AGE WEIGHT HEIGHT GENDER CITIZENSHIP LANGUAGE
COL: A B C D E F G
PC 1.0 1.0 1.0 1.0 1.0 1.0 1.0
27 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.3 26 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
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 s u d o - u p o s t g r e s p s q l - c " C R E A T E E X T E N S I O N p o s t g i s ; C R E A T E E X T E N S I O N
p o s t g i s _ t o p o l o g y ; " < D A T A B A S E _ N A M E >
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 D A T A B A S E S = { 2 ’ d e f a u l t ’: { 3 ’ E N G I N E ’: ’ d j a n g o . c o n t r i b . gis . db . b a c k e n d s . p o s t g i s ’, 4 ’ N A M E ’: ’ < D A T A B A S E _ N A M E > ’, 5 ’ U S E R ’: ’ < U S E R _ N A M E > ’, 6 ’ P A S S W O R D ’: ’ < P A S S W O R D > ’, 7 ’ H O S T ’: ’ < H O S T _ N A M E > ’, 8 ’ P O R T ’: ’ < 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:
∗ 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.
4.3 Database Structure 45
• 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
∗ 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.
4.3 Database Structure 47
∗ 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
