Medical Voice's Platforms: By: Mohamed Slim Ahan Touati

kkkkjpiosqd
2019 - 2020
Medical Voice’s platforms
INFORMATION TECHNOLOGY
By: Mohamed Slim Ahan Touati
Academic supervisor: Salma Sayah
Corporate Internship Supervisor: Arturo Garcia Sanchez

Signature
of the
supervisor
from the
Signature
of the
supervisor
from the
Dedication
I dedicate this end of studies project as a testimony of my gratitude and my respect to:
My dear parents for all the affection, all the sacrifices, their love and the encouragements that they never
stopped lavishing on me throughout my studies,
All my friends who have helped me in difficult times,
All my colleagues for the unforgettable moments that I shared with them,
All those who have supported me throughout this project.

Huge Thanks
It is very pleasant for me to reserve this page as a testimony of gratitude to all the people who have
supported and encouraged me to do this work.
I would like to express my gratitude to my supervisors Arturo Sanchez and Antoine Hurard for lending
me of their most precious time as well as their rich contribution, their precious advice, their sympathy,
their benevolence and for having been present in each moment to support me and help me carry out this
work.
My thanks also go to my supervisor Ms. Salma Sayah,
for her patience and understanding, to the jury members who dedicated a part of their time for agreeing to
evaluate this work.
I am also grateful to all my teachers who gave me
valuable advices throughout the years in Esprit.
Table of Contents
Introduction....................................................................................................................................................1
Chapter I: General Framework of the project................................................................................................3
Section I: Company presentation: Relief Applications (Oordt..................................................................3
Cloud technologies):...................................................................................................................................3
1. Structure:.............................................................................................................................................3
2. Hiring Process:....................................................................................................................................4
3. Projects:..............................................................................................................................................5
Section II: Partner Presentation:.................................................................................................................6
Parkinson’s disease.................................................................................................................................6
Asociacion Parkinson Madrid.................................................................................................................6
Conclusion:.................................................................................................................................................7
Chapter II: State of the art..............................................................................................................................8
Section I: Problematic................................................................................................................................8
Section II: Existing solutions.....................................................................................................................8
1. Meditech:............................................................................................................................................9
2. MySugr:..............................................................................................................................................9
3. HealthVault:......................................................................................................................................10
Section III: Problems with the existing solutions.....................................................................................10
Section IV: Solution.................................................................................................................................11
Conclusion:...............................................................................................................................................13
Chapter III Sprint 0: General analysis and planification..............................................................................14
Section I: Global analysis.........................................................................................................................15
Section II: Technological orientation.......................................................................................................19
1. Programming Languages:.................................................................................................................19
2. Frameworks:.....................................................................................................................................20
2. Database/Query languages:..............................................................................................................21
3. Software tools:..................................................................................................................................21
Section III: Work methodology................................................................................................................22
1. Agile methodologies:........................................................................................................................23
2. SCRUM methodology:.....................................................................................................................24
3. Scrum team:......................................................................................................................................26
Section IV: Planification and deadlines...................................................................................................26
1. Product backlog:...............................................................................................................................26
2. Sprint planification...........................................................................................................................29
3. Timeline and deadlines.....................................................................................................................29
Conclusion:...............................................................................................................................................30
Chapter V: Sprint 1......................................................................................................................................31
Section I: Sprint backlog..........................................................................................................................31
Section II: Description and Functional Analysis......................................................................................32
1. Description of the use cases:.............................................................................................................34
a. “Login into account” use case:......................................................................................................34
2. Functional Analysis:.........................................................................................................................35
Section III: Realisation.............................................................................................................................37
Conclusion:...............................................................................................................................................41
Chapter VI: Sprint 2.....................................................................................................................................42
Conclusion:...............................................................................................................................................53
Chapter VII: Sprint 3....................................................................................................................................54
Conclusion:...............................................................................................................................................64
Chapter VIII: Sprint 4..................................................................................................................................65

Section III: Realization.............................................................................................................................75
Conclusion:...............................................................................................................................................77
Chapter IX: Sprint 5.....................................................................................................................................78
Conclusion:...............................................................................................................................................89
Chapter X: Sprint 6......................................................................................................................................90
Conclusion:.............................................................................................................................................102
General Conclusion....................................................................................................................................103
Bibliography...............................................................................................................................................104
Abstract......................................................................................................................................................105
Name and other information about the company.......................................................................................105

Table of figures
Figure 1: Relief Applications logo................................................................................................................3

Figure 2: Asociacion Parkinson Madrid's logo..............................................................................................7
Figure 3: Meditech's logo...............................................................................................................................9
Figure 4: mySugr's logo.................................................................................................................................9
Figure 5: HealthVault's logo........................................................................................................................10
Figure 6: Amazon's Alexa............................................................................................................................11
Figure 7: Medical's logo...............................................................................................................................12
Figure 8: General use case diagram.............................................................................................................16
Figure 9: Medical's Architechture................................................................................................................17
Figure 10: General class diagram.................................................................................................................18
Figure 11: Triangle of projects’ constraints.................................................................................................22
Figure 12: SCRUM Methodology’s lifecycle..............................................................................................25
Figure 13: Global use case diagram (Sprint1).............................................................................................33
Figure 14: Specified use case diagram (Sprint1).........................................................................................33
Figure 15: Login's sequence diagram...........................................................................................................36
Figure 16: Account creation API endpoint..................................................................................................37
Figure 17: Success result for account creation query..................................................................................38
Figure 18: Failure case for account creation query......................................................................................38
Figure 19: Login query................................................................................................................................39
Figure 20: Failure case for login query........................................................................................................40
Figure 21: Successful case for login query..................................................................................................40
Figure 22: Hashed passwords......................................................................................................................41
Figure 23: Global use case diagram (Sprint2).............................................................................................44
Figure 24: Specified use case diagram (Sprint 2)........................................................................................44
Figure 25: Contact admins' sequence diagram.............................................................................................47
Figure 26: Homepage of the public website (1st fragment big screen).......................................................48
Figure 27: Homepage of the public website (1st section medium screen)..................................................49
Figure 28: Homepage of the public website (3rd section medium screen)..................................................49
Figure 29: Homepage of the public website (last section big screen).........................................................50
Figure 30: Preguntas page (medium screen)................................................................................................51
Figure 31: Contact page (big screen)...........................................................................................................52
Figure 32: Successful submission for the contact form...............................................................................52
Figure 33: Global use case diagram (Sprint 3)............................................................................................57
Figure 35: Check prescriptions' list's sequence diagram..............................................................................60
Figure 36: Logged-in user information query..............................................................................................61
Figure 37: Logged-in user information query success.................................................................................62
Figure 38: ‘my_caretakers’ query................................................................................................................62
Figure 39: Successful result for ‘my_caretakers’ query..............................................................................63
Figure 40: ‘add_relation’ mutation..............................................................................................................63
Figure 41: Global use case (Sprint 4)...........................................................................................................71
Figure 42: Specified use case (Sprint 4)......................................................................................................72
Figure 43: Check correspondent patients list’s sequence diagram..............................................................74
Figure 44: Patient’s profile page..................................................................................................................75
Figure 45: Patient’s Calendar.......................................................................................................................76
Figure 46: Prescriptions’ page.....................................................................................................................77
Figure 47: Global use case diagram (Sprint 5)............................................................................................80
Figure 49: 'Add admin’ sequence diagram..................................................................................................84
Figure 50: Password reset mutation.............................................................................................................85
Figure 51: Failure case for password reset mutation...................................................................................86
Figure 52: users’ query................................................................................................................................86
Figure 53: Successful case for users’ query.................................................................................................87
Figure 54: Admin invite mutation................................................................................................................88
Figure 55: Successful case for admin invite mutation.................................................................................88
Figure 56: Admin account creation mutation after accepting the invitation................................................89
Figure 57: Global use case (Sprint 6)...........................................................................................................93
Figure 58: Specified use case (Sprint 6)......................................................................................................94
Figure 59: ‘Add admin’ sequence diagram..................................................................................................96
Figure 60: Admin dashboard’s homepage (big screen)...............................................................................97
Figure 61: Admin dashboard’s homepage (medium screen).......................................................................98
Figure 62: Admin dashboard’s homepage (small screen)............................................................................98
Figure 63: users’ page..................................................................................................................................99
Figure 64: searching feature inside users’ page...........................................................................................99
Figure 65: User details page (medium screen)...........................................................................................100
Figure 66: Add user form...........................................................................................................................101
Figure 67: Successful case for sending an admin invite............................................................................102
Introduction
In recent years, there has been an increasing recognition that the ability to understand and
construct simple computer programs (coding) is now a core skill and likely to be even more
so in the future. This reflects the increasingly digital world in which we live and work and the
growing need for more individuals to be able to engage with this type of technology. For
example, the National Health Service (NHS) has recognized that when faced with an
increasingly tight budget and time constraints, technology has the potential to help improve
efficiency. Doctors and other health care professionals are in a unique position to identify
problems that could be resolved or helped, in part, by technology. There have been numerous
examples in the past few years of technology such as computer programs or specialist
websites being used in clinical care or research, and this is likely to continue to be the trend
going forward.
In order to conclude my studies in the field of software engineering in Esprit and entering the
professional life, I had the opportunity to integrate into Relief Applications (legal name =
Oordt cloud technologies), to prepare my end of studies project.
I always wanted to use software programming to make real changes in the world and this
opportunity was the perfect chance for me to apply my skills and learn new things.
The goals of this internship are:
- Discover the professional life.

- Use my abilities and enrich them.
- Work in collaboration with a team of designers, project managers and senior
developers.
- Present and promote achievements.
Therefore, I participated into a project that consists of developing a platform with the purpose
of managing old (aged) patients’ medication.
We had the mission to analyze the features such as: Vocal interfaces, patient information,
prescriptions info.
1
First of all, I will present the company and the internship’s framework.
Secondly, I will present the partner and will describe the goal of the project in detail.
Third, I will talk about the software development workflow and the tools and methodologies
we used to make the process better and team work more efficient.
After that I we will describe the design phase, presenting UML diagrams as: the general and
detailed use case diagrams specifying the actors involved in this application, the sequence
diagram for each feature etc...
Finally, we will describe the phase of implementation and coding of the application. I will
present the components included in the application and I will indicate the techniques used to
achieve the application.
2
Chapter I: General Framework of the
project
The project is a collaboration between Relief Applications and Asociacion Parkinson Madrid.
We will first present the home company: Relief Applications, its main activity sector, its
references and its organization. Then, we’ll define the context of the project and we will
present our main target, and finally we will present the context of the project and its goals.
Section I: Company presentation: Relief Applications (Oordt

Cloud technologies):
Relief Applications (Legal name = Oordt cloud technologies) is an organization situated in

Madrid, Spain that creates innovative solutions for humanitarian organizations in two main
areas: web development and MDCA (Mobile Data Collection and Analysis).
Relief Applications’ mission is bringing innovation to people changing the world by

designing simple yet efficient IT solutions aimed at increasing the impact of humanitarian
assistance and contribute to alleviate human suffering in times of crisis.
Figure 1: Relief Applications logo
1. Structure:
The company itself consists of the following teams:
3
 Software Development Team: This team is responsible for creating the web and
mobile apps that would be used to govern the products designed for the client, making
them smarter solutions that can be governed by the end users from the screen of their
computers or smartphones via a few clicks.
 Design Team: This team is responsible for capturing the clients’ requirements in a
form that is easy-to-use, simple and innovative at the same time. This form is then
brought to reality by the software development team.
 Administration Team: This team is responsible for the overall smooth functioning of
the entire company.
 HR Team: This team is responsible for the hiring of new talent, and the management
of the existing Human Resources of the company.
 Project Management Team: This team is responsible for managing the various projects
within the enterprise as well as communicating with clients regularly to gather the
requirements and then disseminate this information amongst the teams.
2. Hiring Process:
In order to be able to get job at Relief Applications, a whole process is followed, which is
divided into following phases:
 Introductory Interview: This interview was conducted over Hangouts and was a 30-45
minutes session with a HR team member and the Tech Lead. The main goal of this
step was to be introduced to the company values and to discuss basic expectations on
both sides.
 Live test: This test was once again conducted with the Software team lead over
Hangouts and Visual Studio Code’s live share. The goal of this was to gain a more in-
depth understanding of my skills and whether they would be a good fit for the
company or not.
4
 Technical test: As I understood later, this test is required when the team is still not sure
about the candidate, I thankfully was already accepted after making the live test, but I
knew about the technical test when it was given to me as an introduction to the
company’s work style during my first two weeks. It’s a small video-player web
application having Angular 9 as frontend and Django as backend.
3. Projects:
The company’s main expertise are IT Development and Tech Consulting, the IT Development
team creates Web platforms, mobile apps and voice enabled systems to turn the internal or the
client’s ideas into a reality. As for the Tech Consulting, Relief’s team is helping clients
achieve the best way forward through business analyses, technical reviews and training
programs. Some of the great products I can site are:
 MediCal: This is a project created by Relief Applications to help people with chronic
diseases to follow their treatment. Medical will allow them, using their voice, to
monitor their calendar of medicines and access everything they need to know about
their prescription: how many pills are left, control if they already took certain
medicine, check the secondary effects and share all this information with their family
members and caregivers in real time.
 Warchild: War Child empowers children and young people in conflict areas by
providing psychosocial support and stimulating education.
 Their program Can’t Wait to Learn the use of custom gaming technology to deliver
fast, effective and low- cost great quality education. The program enables children to
learn even in places where formal education is not available offering the opportunity
to continue to learn, read and count through playing educational games played on
tablet devices.
5
 WHO: World Health Organization monitors outbreaks and potential high risk
situations all around the world in order to assist governments and private and public
organizations to deliver an effective response to epidemics, natural disasters or general
healthcare emergencies.
Section II: Partner Presentation:
Parkinson’s disease
Parkinson's disease is a brain disorder that leads to shaking, stiffness, and difficulty with
walking, balance, and coordination. Parkinson's symptoms usually begin gradually and get
worse over time. As the disease progresses, people may have difficulty walking and talking.
Over the past generation, the global burden of Parkinson’s disease has more than doubled as a
result of increasing numbers of older people, with potential contributions from longer disease
duration and environmental factors. Demographic and potentially other factors are poised to
increase the future burden of Parkinson’s disease substantially.
Asociacion Parkinson Madrid
Parkinson’s Association is a private non-profit entity formed by more than 2,000 partners and
established in May 1994 to serve, guide, train and inform affected people, their families and /
or caregivers, professionals and society in general about everything related to Parkinson's
disease.
Parkinson's Association wants to offer a pioneering tool to provide Parkinson's sufferers with
greater autonomy and empowerment. This tool will use voice assistants, a category of home
devices that since 2018 has been firmly established in the Spanish market and is expected to
continue growing at a high speed in the coming years. Relief Applications is the partner that is
developing the skill (name of applications in voice assistant environments) that will allow
Parkinson's patients to track their medication more easily, request information from patient
6
associations, carry out physical exercises Guided and control household devices such as lights
and household appliances.
Figure 2: Asociacion Parkinson Madrid's logo
Conclusion:
This chapter allowed us to familiarize with the context of the project and the partner that we
will be working with. The structure of the company is indeed important for the project to
succeed since it’s the guarantee of having a good working environment.
7
Chapter II: State of the art
Software development is the process of creating new software solutions or modifying existing
software solutions. Software can be designed and developed in a lot of different ways. The
approach taken to develop and design a software solution varies from a very simple, limited
planning approach to a very detailed, structured and formal approach.
During this chapter, we will be carrying out a study on the existing solutions on the market.
We will be presenting the criticisms of these solutions as well as the problems encountered
which will be then leading us to highlight our proposed solution.
And to finish this chapter, we will be unveiling the methodology of work developed
throughout our project by the Relief Application’s team. This will be preceded by a small
introduction on the used tools and a comparative study of different working methodologies in
general.
Section I: Problematic
- People with chronic diseases can’t follow their treatment. They find difficulties to
access everything they need to know about their prescriptions (how many pills are left,
control if they already took certain medicine, check the secondary effects etc..).
- Lack of mobility or impaired visualization for some patients (they can’t reach out by
themselves to obtain any information).
- Patient’s family members or care-takers can’t know for sure if the patient had his
medication and can’t get any other important information related to the prescription.
Section II: Existing solutions
8
There are many mobile applications as well as web platforms that have been designed to
provide certain benefits. An essential step before starting each project is to carry out a
preliminary study. This study will be useful for us to deepen our understanding of the subject
to establish and to consider the present solutions to finally obtain the proposal of the most
effective solution.
To do this, we will present a comparative study of an existing solutions on the market.
1. Meditech:
Meditech’s mission is to help build a world where every patient can access their health
information and participate in their own care, and every healthcare organization can serve
their community quicker and more safely through cutting-edge technology with instant access
to records, knowledge, and data.
Figure 3: Meditech's logo
2. MySugr:
This Australian 2012 startup offers an app-based solution for monitoring blood glucose levels.
Users receive a high-quality blood glucose meter, testing supplies, and access to the mySugr
app and platform.
9
Figure 4: mySugr's logo
3. HealthVault:
HealthVault allows users diagnosed with diabetes to gather, store, use, and share their
personal health information. Adding health records, tracking health trends, and sharing your
health information is done easily and securely.
Figure 5: HealthVault's logo
Section III: Problems with the existing solutions
A couple of problems are noticed in the existing solutions:
- There are hundreds of apps useful for anyone with a degenerative disorder that work
as timetables, reminders, training programs, e-health monitoring systems... But none
of the existing apps is summarizing all this tools together.
10
- Some of the elder patients are incapable of using these web platforms because of
their inability of adapting with new technologies.
- Most of patients having dangerous diseases such as Parkinson are unable to use
any visual web platforms because of their lack of mobility, blurred central vision
or disturbance in the shape of the images etc... Low vision is having a lot of bad
outcomes related to using these platforms or even their medications such as:
Not seeing prospects well, confusing boxes with similar colors, confusing pills that
are out of their blisters and having a similar color and shape, inability to discern
medication schedules well, both by hand and digital…
- With the existing platforms, patients would still have high dependency of others for
the management of their medications.
Section IV: Solution
Before moving to the solution, let me first introduce Amazon’s Alexa:
Amazon’s Alexa, also known simply as Alexa, is a virtual assistant AI technology developed
by Amazon, first used in the Amazon Echo smart speakers developed by Amazon Lab126. It
is capable of voice interaction, music playback, making to-do lists, setting alarms, streaming
podcasts, playing audiobooks, and providing weather, traffic, sports, and other real-time
information, such as news.
ALEXA is growing faster as a relevant home product for anybody, but its potential for those
suffering a degenerative disorder can be wider
11
Figure 6: Amazon's Alexa
Relief Applications made this a reality with an innovative approach to ALEXA possibilities
Medical is a project created by Relief Applications to help people with chronic diseases to
follow their treatment. It will allow them, using their voice, to monitor their calendar of
medicines and access everything they need to know about their prescription: how many pills
are left, control if they already took certain medicine, check the secondary effects and share
all this information with their family members and caregivers in real time.
Medical is particularly useful for those who lack mobility or are visually impaired: with the
use of their voice they have easier access to all the information they need for their medication.
It also includes a web platform that can help families and caregivers access all the information
about the treatment anywhere, which is the part that I took care of during my internship
besides the admins’ dashboard.
Medical would help improving the quality of life of groups at risk of exclusion by helping to
manage every aspect of medication intake.
Besides adding reminders, Medical provides information on the color and shape of the pills,
how many are left over, and it confirms the taking of medication. It guarantees greater
autonomy for the patient and security and peace of mind for family members and caregivers,
since the voice interface is synchronized with a web page from which they can observe
whether the patient is following the treatment.
Thanks to voice commands, it is much easier to use than other digital options for people with
mobility or vision problems.
12
Figure 7: Medical's logo
Conclusion:
The study of the existing solutions and goals helped us define what we want in a product by
details. After we presented what’s already on the market, we made sure to include some small
critics and to find solutions for the flaws we found. This drove us to conclude what are the
goal features for this project. Therefore, the next chapter will be dedicated to specifying
exactly what we want in those features and analyzing the way we want to tackle this
technology wisely.
13
Chapter III
Sprint 0: General analysis and planification
This step is very important in the realization of an application. The future of the software
simply depends a lot on this phase, it allows us the development of a sufficient application.
This is why, generally the client and the project manager must be willing to collaborate. In
our case, since the project is internal, it was easier to achieve this step.
Developers need to turn fuzzy ideas into a precise specification of the needs, wants, and
demands expressed by a community of users. Thus, they define a relationship between a
system and its environment.
In order to reach our goals, we needed to consider:
The study of feasibility: resources, time, etc.
Analysis and definition of needs: which allows to find a common agreement between
specialists and users.
Now speaking about the modeling part, it is absolutely necessary to have methods or
languages for modelling object-oriented languages. Therefore, several methods or languages
have emerged, including UML, which allowed us to design our application.
Nowadays, UML2 has thirteen diagrams that can be classified into two categories (dynamic
and static).
14
To achieve this, we would need to extract the main features of our application. Then we
would introduce the actors that act on our system. Then we would identify our technological
direction. And finally, we would present our timeline and deadlines.
For each sprint/feature, we will begin with the corresponding use case diagrams which allows
to give a global view of the application and each feature. Not only for an uninformed
customer (in general) who will have the idea of his future application, but also for the
developer. Finally, the design would be refined by presenting the chronology of the operations
by the sequence diagrams.
Each of these steps are done for each sprint. Additionally, each feature goes through
requirement specifications and gathering first.
Section I: Global analysis
we need to identify the actors that act on our system. We need to extract the main functional
and non-functional requirements of our application.
The application targets chronically ill patients of all ages, but especially the older ones and
those suffering from mobility and vision problems. It is also oriented towards family members
of chronic patients and caregivers. It is conceived under a business to business model bound
to companies and healthcare institutions offering content for chronic patients.
We have three main actors:
- Patients
- Care-takers
- Admins
- Visitors of our public website
The requirements are divided to:
 Non-functional needs are not necessarily related to a use case. However, they are
important to ensure the implementation of an application of good quality and
performance. In the case of our platform, we identified:
Security of access to patient’s information: This is ensured with the use of JWT
tokens.
15
- Security of users accounts: By hashing passwords with MD5.
- Performance: The platform must guarantee the integrity and consistency of the data at
each update. The user needs to know his medicaments status all the time.
- Ergonomics: Our platform has to present a simple and intuitive UI and a good and
simple UX.
 The functional requirements specify the input / output behaviours of the system. They
correspond to the primary needs of the patients who are, generally, quoted in the
specifications.
The main features that our application offers are presented in the general use case diagram
below, and we’ll go later into the details of each one of them:
16
Figure 8: General use case diagram

The architecture of our project is presented in the diagram below:
17
Figure 9: Medical's Architechture
The Class diagram of our project is presented in the diagram below:
18
Figure 10: General class diagram
19
Section II: Technological orientation
To achieve the wanted goals, multiple software tools are used in this project. These tools are
divided into multiple types : Programming languages, Frameworks (which allow a better use
of the programming languages), DevOps tools which allow a better structured process and a
better team work, and other tools and technologies that helped the software team achieve their
goals.
1. Programming Languages:
a. Python [1]:
Python is an interpreted, high-level, general-purpose programming language. Created by
Guido van Rossum and first released in 1991, Python's design philosophy emphasizes code
readability with its notable use of significant whitespace. Its language constructs and object-
oriented approach aim to help programmers write clear, logical code for small and large-scale
projects..
b. Typescript [2]:
Typescript is an object-oriented language which is strongly-typed and supports static typing.

That means Static typing allows for checking type correctness at compile time. This is not
available in JavaScript. In this project, Typescript is used mainly for this purpose, some
components need strong typing for better documentation and consistency. Even though Flow,
which is a static type checker for Javascript exists, Flow tends to have quite a few unfixed
bugs and not a very graceful IDE support. On the other hand, TypeScript is nothing but
JavaScript and some additional features...
Whatever code is written in JavaScript can be converted to TypeScript by changing the

extension from .js to .ts. TypeScript code can be run on any browser, devices or in any
operating system. It also supports JS libraries, developers can use existing JavaScript code,
incorporate popular JavaScript libraries, and can be called from other JavaScript code.
c. HTML [3]:
20
Hypertext Markup Language (HTML) is the standard markup language for documents
designed to be displayed in a web browser. It can be assisted by technologies such as
Cascading Style Sheets (CSS) and scripting languages such as JavaScript.
Web browsers receive HTML documents from a web server or from local storage and render
the documents into multimedia web pages. HTML describes the structure of a web page
semantically and originally included cues for the appearance of the document.
d. SCSS [4]:
Sass is a stylesheet language that’s compiled to CSS. It allows you to use variables, nested
rules, mixins, functions, and more, all with a fully CSS-compatible syntax. Sass helps keep
large stylesheets well-organized and makes it easy to share design within and across projects.
2. Frameworks:
a. Angular [5]:
Angular is an application design framework and development platform for creating efficient
and sophisticated single-page apps.
In Medical, we used Angular 9.
b. Django [6]:
Django is a high-level Python Web framework that encourages rapid development and clean,
pragmatic design. Built by experienced developers, it takes care of much of the hassle of Web
development, so you can focus on writing your app without needing to reinvent the wheel. It’s
free and open source.
c. Node.js [7]:
Node.js is an open-source, cross-platform, JavaScript runtime environment (Framework) that

executes JavaScript code outside a web browser. Node.js lets developers use JavaScript to
write command line tools and for server-side scripting—running scripts server-side to produce
dynamic web page content before the page is sent to the user's web browser.
21
d. Graphene [8]:
Graphene-Python is a library for building GraphQL APIs in Python easily, its main goal is to
provide a simple but extendable API for making developers' lives easier.
2. Database/Query languages:
a. MongoDB [9]:
MongoDB is a cross-platform document-oriented database program. Classified as a NoSQL

database program, MongoDB uses JSON-like documents with optional schemas.
b. GraphQl [10]:
GraphQL is a query language and server-side runtime for application programming interfaces
(APIs) that prioritizes giving clients exactly the data they request and no more.
GraphQL is designed to make APIs fast, flexible, and developer-friendly. It can even be
deployed within an integrated development environment (IDE) known as GraphiQL. As an
alternative to REST, GraphQL lets developers construct requests that pull data from multiple
data sources in a single API call.
3. Software tools:
DevOps is a set of practices that automates the processes between software development
(Dev) and IT operations teams (Ops), in order that they can build, test, and release software
faster and more reliably. The benefits include faster delivery of software with higher quality,
increased trust, and a better handling of critical bugs and unplanned tasks.
The software tools used in Medical are Docker and Gitlab
a. Docker [11]:
Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to
deliver software in packages called containers. Containers are isolated from one another and
bundle their own software, libraries and configuration files; they can communicate with each
22
other through well-defined channels. All containers are run by a single operating system
kernel and therefore use fewer resources than virtual machines.
The service has both free and premium tiers. The software that hosts the containers is called
Docker Engine. It was first started in 2013 and is developed by Docker, Inc.
b. Gitlab [12]:
GitLab is a web-based DevOps lifecycle tool that provides a Git-repository manager

providing issue-tracking and continuous integration/continuous deployment pipeline features,
using an open-source license, developed by GitLab Inc.
Section III: Work methodology
Our objective is to be able to complete our project while respecting the deadlines and the
allocated budget. To achieve this, we must take into account the three constituent constraints
of the project: Quality, cost, deadlines.
Customer satisfaction presents both a constraint and an objective.
Figure 9 summarizes the constraints to be respected for better project management.
Figure 11: Triangle of projects’ constraints
23
In order to have.our.goal achieved, we must have recourse to a method of project
management. Different software development models can be adopted:
- Linear models (waterfall model, V model ...) which divide the development into sequential
and linear stages. They are generally well adopted when the needs are stable and clearly
identified but which present a difficulty to take into account changes in an advanced phase in
the project.
The tests are carried out late in the development process so the reaction time to errors is much
longer and therefore the product appears very late.
- Iterative and incremental models (Agile methods, spiral model, etc.) allow the product to be
delivered in several times, in an incremental manner so that each increment can give rise to a
more or less complete classic life cycle. They are driven by risk reduction and they ensure
better adaptation to changes.
As some of the needs were still unclear even though the general needs were, iterative and
incremental models represents our solution.
1. Agile methodologies:
A software development team is driven by one simple goal which is to meet the needs of its
customers. However, these needs are generally poorly expressed, often incomplete at the start
of the project and above all, they keep evolving.
As a result, the team finds itself developing applications with inaccurate and changing
specifications, resulting in either customer dissatisfaction or delivery delays. These issues
have prompted engineers to reinvent project management and design methods by introducing
what we call the agile methodology.
By deciding to adapt an agile methodology for the conduction of our project, we will break it
down into several iterations of relatively short duration and each resulting in a sub-objective.
At the end of each iteration, a minimum version of the project is developed and delivered.
This will always allow immediate feedback which will guarantee effective adaptation to
changing requirements and validation of the final version of the software which is only the
continuous integration of the different successive versions.
24
Several methodologies respect agile principles while each responding to certain types of
projects according to their size, the development team, the criticality of the system, etc... For
the management of our project, it was agreed to adopt the SCRUM methodology.
2. SCRUM methodology:
Scrum allows a team to collaborate effectively in order to develop a better quality product
while respecting deadlines. The construction of the final product is done in several iterations
called "Sprints" lasting from 1 to 4 weeks. During each of these iterations, a part of the
product called “Increment” is produced based on the parts created during the previous
iterations and delivered at the end of the Sprint.
This allows the team to respond to feedback and change, to build exactly and only what is
needed by the customer, in our case, the customer is obviously our team as this project is
internal.
Scrum synthesizes a process presented in figure 10 and based on:
- The ability of team members to demonstrate creativity, effective interaction and

internal development.
- An iterative and incremental cycle of software development.
- Roles, communication artifacts and meetings.
25
Figure 12: SCRUM Methodology’s lifecycle
The three main roles are:
- Product manager: the representative of customers and users. He determines what

needs to be done.
- Project team: developers responsible for building what is requested by the product
manager and demonstrating it.
- Scrum Master: responsible for the smooth running of the different stages of the
process. He ensures that the collaboration remains efficient and well organized.
The three communication artifacts are:
- Product backlog: presents a list of requested features called “User Stories”, sorted
by priority. Three attributes are associated with each element of the list: a
description, an estimate and an order of priority.
- Sprint backlog: presents a selection of retained tasks from the "Product backlog"
that the team commits to carry out, taking into account their priorities and their
capacity.
- Sprint burndown: presents a graph of the concrete progress of the team’s work and
allows to anticipate in a relatively reliable way the future deadlines of the "To do".
26
The three main meetings are:
- Sprint planning: allows the team and the product manager to set the goal of the
new sprint based on the prioritized "Product Backlog" and to estimate the
necessary production capacity to achieve this goal.
- Daily appointment: also called "Daily meeting" or "Daily scrum". It allows you to
focus on what has been done, the problems encountered and the tasks to be carried
out during the day.
- Sprint demonstration: also called “Sprint Review”. It allows the team to present
what they added to the product during the sprint. Based on this demonstration, the
product manager validates what has been achieved by the team and determines
what to do next. He is likely to offer to add, modify or re-estimate items in the
Product Backlog.
Although this is a simplified view of how Scrum works, this set allows to pace the progress of
the project and ensure communication between stakeholders.
3. Scrum team:
The Scrum team of our project is composed as follows:
- Product manager: Raphael Bonnaud represents customers and users and

determines what needs to be achieved.
- Project team: Myself (Mohamed Slim Ahan Touati) working on both backend and
frontend alongside with Julio and Antoine. Having Gerard Calvet for the designing
phase.
- Scrum Master: Barbara Moure is responsible for the smooth running of the various
stages of the process and ensures that the collaboration remains efficient and well
organized.
Section IV: Planification and deadlines
1. Product backlog:
27
ID FEATURE USER STORY PRIORITY
As a Patient / caretaker, I want to create
Low
an account
As a Patient / caretaker, I want to login
Medium
into my account
Manage profile As a Patient / caretaker, I want to
A1 Low
settings change my password from a form
As a Patient / caretaker, I want to
High
change my password when I forget it
As a Patient / caretaker, I want to
Medium
change my account information
As a visitor, I want to learn about
High
Medical
As a visitor, I want to contact Medical
High
Voice’s administration
As a visitor, I want to be redirected to
Visit public Medium
A2 the login form of the user dashboard
website As a visitor, I want to be redirected to
High
signup form of the user dashboard
As a visitor, I want to see the answers
of some questions that I might have Medium
about the services offered by Medical
As a Patient, I want to see my personal
Low
information
As a Patient, I want to see the list of my
Medium
Caretakers
As a Patient, I want to add a Caretaker High
As a Patient, I want to see my
High
prescriptions list
As a Patient, I want to search for a
specific prescription from the Medium
prescriptions list
Visit Patient’s
A3 As a Patient, I want to see details about
platform High
my medicines
As a Patient, I want the platform to be
translated to my language if it’s Medium
available
As a Patient, I want to check my
High
prescriptions’ calendar
As a Patient / caretaker, I want to logout
Low
from my account
As a Patient, I want to add a new
Medium
medication to my calendar
A4 Visit As a Caretaker, I want to see my Low
28
personal information
As a Caretaker, I want to see the list of
Medium
my Patients
As a Caretaker, I want to see my
High
patients’ prescriptions calendar
As a Caretaker, I want to search a
Medium
specific Patient from the Patients list
Caretaker’s As a Caretaker, I want to remove a
Medium
platform Patient from the Patients list
As a Caretaker, I want to filter the
Medium
Patients list by multiple keys
As a Patient / caretaker, I want to logout
Low
from my account
As a Caretaker, I want the platform to
be translated to my language if it’s Medium
available
As an Admin, I want to add another
High
Admin
As an Admin, I want to see statistics
Medium
about the users of the platforms
Medium
about the users’ logs
Medium
about the medications
As an Admin, I want to see the list of all
Visit Admin’s Low
A5 the users
platform
As an Admin, I want to search a
Medium
specific user from the user list
As an Admin, I want to filter the users
Medium
list by multiple keys
As an Admin, I want to delete a user Low
As an Admin, I want to the list of all the
Medium
logs
As an Admin, I want to search for a
Medium
specific user’s logs
2. Sprint planification
The table below contains the timeline of the realization of each sprint and the time granted for
each one of them:
29
Sprint Content Duration
- Planification
Sprint 0 - Conception 4 weeks
- Research
- JWT Configuration
Sprint 1 (backend) - Authentification 4 weeks
- Profile management
Sprint 2 (frontend +
- Visit public website 2 weeks
backend)
-Visit Patient platform
Sprint 3 (backend) -Visit Caretaker 4 weeks
platform
- Visit Patient platform
Sprint 4 (frontend) - Visit Caretaker 4 weeks
platform
Sprint 5 (backend) - Visit Admin platform 3 weeks
Sprint 6 (frontend) - Visit Admin platform 3 weeks
3. Timeline and deadlines
Usually the development of a feature requires the collaboration of the whole team, so we need
to guarantee that each one of the teams has enough time to do it. The full implementation is
usually split between:
 UI/UX design
 Frontend development
 Backend development
 Testing and QA
Usually, once one feature is done, verified and approved by QA, a new version of the
platform/ app will be released live.
Conclusion:
The global analysis and general feature specifications is maybe the most important step of the
project. It allows us to define our needs and make a feasibility study technologically and
30
based on resources. It allows us the development of a ‘sufficient’ product. Now, all we have
to do next is tackle our features sprint by sprint.
Chapter V: Sprint 1
31
During this chapter, we will present the first sprint which will be focusing on the
implementation of the authentication module alongside with patients and caretakers profile
management modules. We will start by presenting the sprint backlog, we will then move on to
its design and analysis and we will end with the sprint review.
Section I: Sprint backlog
ID USER STORY TASK ESTIMATION

A1: Manage A1.1.1: override the default
profile Django_user class to fit with
3h
settings the project needs
A1.1: As a
Patient / A1.1.2: Create necessairy
caretaker, I classes related to the user 6h
want to create information
an account A1.1.3: Implement the
6h
user_creation method
A1.1.4: Test the call from
3h
API backend and its return
A1.2.1: Set up the
A1.2: As a authentication system 24h
OAuth2 with the JWT token.
Patient /
A1.2.2: Create the
caretaker, I 6h
authentification method
want to login A.1.2.3: Test the
into my account functioning of the token and 5h
the it’s refreshing
A1.3.1: Create the
password_change_by_form 3h
A1.3: As a method
A1.3.2: Validate the
Patient /
compliance of the new
caretaker, I 3h
password with system
want to change
requirements.
my password
A1.3.3: Check the validity of
from a form 2h
the renewal token
A1.3.4: Test the functioning
2h
of the API
A1.4: As a A1.4.1: Create the 6h
Patient / password_change_by_email
32
method
A1.4.2: Create and send the
24h
renewal email
caretaker, I 24h
the renewal token
want to change A1.4.4: Validate the
my password compliance of the new
when I forget it 6h
password with system
requirements
6h
of the API
A1.5.1: Create the
4h
information_change method
A1.5.2: Check the
A1.5: As a
compliance of the new
Patient / 4h
information with the system
caretaker, I
requirements
want to change
my account
the token sent with the 4h
information
request
2h
of the API
Section II: Description and Functional Analysis
The figure below represents the global use case diagram of this sprint:
33
Figure 13: Global use case diagram (Sprint1)
Based on the requirements, we concluded the specified use case diagram below:
Figure 14: Specified use case diagram (Sprint1)
34
1. Description of the use cases:
Since there are so many use cases, we decided to make a description of the most important
and complicated ones.
a. “Login into account” use case:
We concluded the textual description of the related use cases, presented in the table below:
Use case Login into account
Actor Patient/Caretaker
Pre-condition Account creation
Post-conditions User connected
1 – The user choses to login as a Caretaker

or a Patient
2 - The system shows the login interface.
Principal scenario 3 – The user logs in.
4 - The system redirects the user to his

corresponding dashboard.
1a: The user choses to login as a Patient.
1a-1: The system shows the Patient login

interface.
1a-2: Use case continues from point 3.
alternative scenario 1b: User choses to login as a Caretaker.
1b-1: System shows the Caretaker’s login

interface
1b-2 Use case continues from point 3.
E1: Login error.

Error scenario
35
4a: System shows an alert
2. Functional Analysis:
After the description of the use cases above, we were able to conclude the sequence diagrams
for the different functionalities, since that makes a lot of them, we chose to show one diagram
for each sprint, and we chose the login sequence for this one:
36
Figure 15: Login's sequence diagram
To ensure security of the user’s accounts, we used hashing with MD5. And to ensure the
safety of the data requested by any type of user, we used JWT tokens.
37
Section III: Realisation
Since we only worked on the backend part during this sprint, the realization part includes
screenshots of our API’s documentation.
To test our queries, we used the platform Postman, which is a software that focuses on API
testing. It has become very popular for testing Microservices, especially because of its
simplicity and highly specialized features.
The screenshot below represents the registration query made using GraphQL, the query
includes the method’s name in our server’s controller, the method’s parameters and the
chosen returned new user’s parameter (which can be changed since the method returns the
whole created user, but this is one of GraphQL’s benefits, it helps us limit our data easily,
which makes the server’s response faster).
Figure 16: Account creation API endpoint
38
Two response codes can be returned after sending this query: 200 for a successful request and
400 for a failure with the failure’s problem shown in the response message, we took the
existence of the given username as an example of a query that would return that code.
Figure 17: Success result for account creation query
Figure 18: Failure case for account creation query
39
The screenshots below represent the Login query and it’s two types of responses, in case of
success, a token would be generated and returned with the logged in user information. And in
case of failure, an error message would be returned.
Figure 19: Login query
40
Figure 20: Failure case for login query
Figure 21: Successful case for login query
41
The screenshot below shows how the password is stored in our Django database after being
hashed:
Figure 22: Hashed passwords
Conclusion:
During this chapter, we have prepared the sprint backlog, which helped us to conclude the
different user stories of this sprint. We also developed the analysis of this sprint by carrying
out and presenting some diagrams such as the use case diagrams and the sequence diagram.
We have highlighted our work by presenting some screenshots of the documentation
produced during this sprint.
42
Chapter VI: Sprint 2
During this chapter, we will present the second sprint which will focus on the implementation
of the public website destinated to people that doesn’t already know our product, it is an
introduction to Medical Voice and a presentation to common questions that the visitor might
have. This public website also has a contacting option via mail that would allow visitors to
contact us for any further information. We will start by presenting the backlog sprint, we will
then move on to its design and analysis and we will end with the sprint review.
ID USER STORY TASK ESTIMATION

A2.1.1: Create the website
header 3h
A2.1: As a
A2.1.2: Create the page
visitor, I want 6h
footer
to learn about
A2.1.3: Create the home
Medical 6h
page
A2.1.4: Create the questions
3h
page (preguntas)
A2.2.1: Create the contact
24h
A2: Visit page
public A2.2.2: Add a redirection
website link from the home page to
A2.2: As a the contact page with a pre- 6h
visitor, I want condition of the visitor’s
to contact type
Medical A2.2.3: Add the send_email
10h
Voice’s method in the backend
administration A2.2.4: Test the api 3h
A2.2.5 Implement the
method that recovers the 3h
form’s inputs
A2.2.6 Call the send_email 5h
43
api method when the send
button is clicked
A2.3: As a A2.3.1: Add login option to
3h
visitor, I want website header
to be redirected A2.3.2: Add the redirection
3h
to the login when the option is clicked
form of the user A2.3.3: Test the redirection
2h
dashboard functionning
A2.4: As a A2.4.1: Add login option to
1h
visitor, I want website header
to be redirected A2.4.2: Add the redirection
1h
to signup form when the option is clicked
of the user A2.4.3 Test the redirection 1h
dashboard functionning
A2.5: As a A2.5.1: Create the question
24h
visitor, I want and answer item
to see the A2.5.2: create the questions
8h
and answers list
answers of
A2.5.3: Create the questions
some questions 48h
page
that I might A2.5.4: Implement the list in
have about the 6h
the questions page
services offered A2.5.5: Add tabulation to
by Medical 6h
the list
The figure below represents the global use case diagram of this sprint:
44
Figure 23: Global use case diagram (Sprint2)
Based on the requirements, we concluded the use case diagram below:
Figure 24: Specified use case diagram (Sprint 2)
45
Since there are so many use cases, we decided to make a description of a very important and
complicated one.
“Contact admin team” use case:
Use case Contact admin team
Actor visitor
Pre-condition Visitor type specified
Post-conditions Message sent
1 – The visitor chooses to send a message

from the home page redirection section or
from the contact page
2 - The visitor chooses his type of user.

Principal scenario
3 – The visitor fills the form.
4 – the message is sent and a confirmation

message is shown.
2a: The visitor chooses to send the message

as a simple user.
1a-1: The system shows the user’s form.
1a-2: Use case continues from point 3.

alternative scenario
2b: The visitor chooses to send the message
as an organization.
1b-1: System shows the organization’s

contact form.
46
2b: The visitor chooses to send the message
as a health institution professional.
1b-1: System shows the health

professional’s contact form.
E1: Form error.

Error scenario
4a: System shows an alert
For this sprint, we chose to demonstrate the ‘contact admins’ scenario in the sequence
diagram below:
47
Figure 25: Contact admins' sequence diagram
As this sprint was about the public website, the screenshots below represent its different
features. As I already mentioned before, we made sure that the website and the platforms
work perfectly on any device by making all the pages responsive.
48
Figure 26: Homepage of the public website (1st fragment big screen)
The screenshot above represents the first section of Medical voice’s public website opened in
a big screen, it contains a small introduction and a demonstrative video of the platform.
To put some lights on the responsiveness, I took a screenshot of the same fragment after
reducing the screen size (the screenshot below). As the output would be looking bad in a
smaller screen if we keep the text and the video next to each other (which is the case in a lot
of pages of this website and both platforms), we changed the disposition of our view’s
elements. We usually tend to use the CSS elements Flex and media query annotations in order
to handle this type of issues. As for the sizes of the different screens, we always define
constants that represent 5 different turning points, and I’m going to get into details during the
next sprints to explain this.
49
Figure 27: Homepage of the public website (1st section medium screen)
Figure 28: Homepage of the public website (3rd section medium screen)
50
The screenshot above represents the third section of the homepage from which the visitor can
be redirected to the contact page after choosing his type of user (simple user, organization,
health professional). Of course, the choice that the visitor makes is saved and automatically
selected in the contact form.
Another important part of the homepage is the last section which contains gifs that show the
utility of Medical Voice. The screenshot below represents this section.
Figure 29: Homepage of the public website (last section big screen)
As we received a lot of similar questions about the platform, we decided to make a page
containing the answers of the most asked questions, I was asked to make this part dynamic as
more questions might be added later, I used tabulation with my dynamic list of questions to
make it more organized for the visitors. The screenshot below represents some questions and
answers that can be found in the ‘preguntas’ page of public website.
51
Figure 30: Preguntas page (medium screen)
The next screenshot is taken from the contact page, where the visitor fills the form with the
correspondent data, then an email containing the filled information will be sent to the
administration thanks to Gmail’s SMPT service.
In case of an error in the form, a message would be shown to highlight that, otherwise a
success message would appear (figure 32).
52
Figure 31: Contact page (big screen)
Figure 32: Successful submission for the contact form
53
Conclusion:
In this chapter, we have been able to show the different user stories of this second Sprint. We
have developed the analysis of this sprint by presenting some diagrams such as the use case
diagram and sequence diagram. The following chapter will be devoted to the third Sprint
which is dedicated to the implementation of the user dashboard’s backend.
54
Chapter VII: Sprint 3
During this chapter, we’ll present the third sprint which will focus on the implementation of
the user dashboard’s backend (for both patients and caretakers). We will start by presenting
the backlog sprint, we will then move on to some use cases descriptions followed by the
functional analysis, we will pass after that to the realization part.
ID User story Task Estimation

A3: Visit Implement the ‘Me’ method 3h
patient’s As a Patient, I want to see Call the method in the
1h
platform my personal information exportation part
Test the API 2h
Implement the
10h
As a Patient, I want to see ‘my_prescriptions’ method
my prescriptions list Add the necessary permissions 5h
Test the return of the API 2h
Implement the ‘get_medicine’
5h
As a Patient, I want to see method
details about my medicines Add the necessary permissions 3h
Implement the ‘my_caretakers’
4h
As a Patient, I want to see method
the list of my Caretakers Add the necessary permissions 1h
Implement the ‘add_relation’
6h
As a Patient, I want to add a method
Caretaker Add the necessary permissions 5h
As a Patient, I want to Create the ‘calendar-service’
24h
check my prescription’s small server
calendar Create ‘datetime-service.js’ in
the services folder and 12h
implement the necessary code
Create ‘error-handler.js’ in the
services folder and implement 6h
the necessary code
Create ‘token-handler.js’ in the 6h
services folder and implement
the necessary code
55
Create the model ‘Calendar’ 4h
Create the model ‘Medicine 4h
Implement the calendar
7h
controller class
Implement the medicine
7h
controller class
Add the Dockerfile and make
necessary changes to make a 12h
successful deploy
Call the calendar-service from
6h
the main-api
Test the queries 24h
Implement the method
As a Patient, I want to add a ‘add_medicine_to calendar’ in 8h
new medication to my the calendar controller
calendar Test the execution of the query
2h
As a Caretaker, I want Implement the ‘Me’ method 3h

Call the method in the
to see my personal 1h
exportation part
information Test the API 2h
Implement the ‘my_caretakers’
As a Caretaker, I want 6h
method
to see the list of my Add the necessary permissions 4h
Patients Test the return of the API 2h
A4 : Visit Implement the ‘get_calendar’
Caretaker’s As a Caretaker, I want 8h
method
platform to see my patients’ Add the necessary permissions 4h
prescriptions calendar Test the return of the API 3h
Implement the ‘remove_relation’
As a Caretaker, I want 4h
method
to remove a Patient from Add the necessary permissions 1h
the Patients list Test the return of the API 1h
As both sprint 3 and sprint 4 are focused on the same platform visits, we would be having the
same description and functional analysis in both sprints, that’s why I decided to make another
structure just for this part, we will talk about the patient’s visit to the platform during this
sprint’s chapter, and we will get to the caretaker’s visit in the next sprint’s chapter.
56
The figure below represents the global use case diagrams the patient’s visit to the dashboard:
Figure 33: Global use case diagram (Sprint 3)
Based on the requirements, we concluded the use case diagram below. This specified use case
represents both the backend and frontend parts of the patient’s visit to the dashboard.
As all the actions needs the patient to be logged in, I found that it is more appropriate to
mention that without adding the ‘include’ relation with the login use case every time.
With that said, all the use cases in the diagram below are including the login use case.
57
Since there are so many use cases, we decided to make a description of an important one.
“Check correspondent caretakers list” use case:
58
Use case Check correspondent caretakers list
Actor Patient
Patient Logged in
Pre-condition
Post-conditions Related caretakers shown
1 – The patient goes to the profile page
2 - The patient goes to the ‘caretakers’

section.
Principal scenario 3 – The patient’s caretakers are rendered.
3a: The patient wants to add another

caretaker.
3a-1: The system shows available

caretakers.
alternative scenario 3a-2: The user chooses the new caretaker.
3a-3: A confirmation message appears.
3a-4: The caretakers list is refreshed.
E1: Network problem.

Error scenario
4a: List doesn’t load and an alert appears
For this sprint, I chose to demonstrate the ‘Check prescriptions’ scenario in the sequence
diagram below:
59
Figure 35: Check prescriptions' list's sequence diagram
Since we only worked on the backend part during this sprint, the realization part includes
screenshots of our API’s documentation.
60
Just like the first sprint, we used the platform Postman test our queries, and GraphQL as the
query language.
The next two screenshots represent the ‘me’ query which returns the logged in user
information based on the token sent in the header of the query, the query includes the
method’s name in our server’s controller and the chosen fields to grab from the database.
Figure 36: Logged-in user information query
61
Figure 37: Logged-in user information query success
The next two screenshots represent the ‘my_caretakers’ query which returns the caretakers
that are related to a specific user that would have his id sent as a parameter, the query also
includes the method’s name in our server’s controller and the chosen fields to grab from the
database.
Figure 38: ‘my_caretakers’ query
62
Figure 39: Successful result for ‘my_caretakers’ query
The last screenshot represents the ‘add_relation’ query which is called after a patient chooses
to add a caretaker (but is also accessible to admins). The query includes the method’s name in
our server’s controller, the ids of the patient and the caretaker, and the chosen fields to appear
in the response (the fullname of both the caretaker and the patient).
63
Figure 40: ‘add_relation’ mutation
Conclusion:
In this chapter, we have been able to show the different user stories of this third Sprint. We
diagram and sequence diagram. The following chapter will be devoted to the fourth Sprint
which is dedicated to the implementation of the user dashboard’s frontend.
64
Chapter VIII: Sprint 4
During this chapter, we’ll present the fourth sprint which will focus on the implementation of
the user dashboard’s frontend for both patients and caretakers. We will start by presenting the
backlog sprint, we will then move on to some use cases descriptions followed by the
functional analysis, we will pass after that to the realization part.

A3: Visit Implement the
patient’s profile 6h
platform component
Implement the
appolo
4h
As a Patient, I want to see my personal configuration
information file
Add the query
2h
to queries.ts
Add the API
6h
service
Run the tests 2h
Implement the
prescriptions 10h
component
As a Patient, I want to see my prescriptions list
Add the query
1h
to queries.ts
Run the tests 2h
Add the search
2h
bar to html
As a Patient, I want to search for a specific Add the search
prescription from the prescriptions list method to the 4h
typescript
Run the tests 1h
As a Patient, I want to see details about my Implement the 5h
medicines details
65
component
Add the query
1h
to queries.ts
Run the tests 2h
Add the query
1h
to queries.ts
Call the query
As a Patient, I want to see the list of my
when the
Caretakers 4h
profile page is
loaded
Run the tests 1h
Add the
mutation to 1h
mutations.ts
As a Patient, I want to add a Caretaker Add the button
and the 5h
mutation call
Run the tests 2h
Add the logout
1h
button
As a Patient / caretaker, I want to logout from
Add the logout
my account 1h
method
Test the logout 1h
As a Patient, I want the platform to be translated Integrate ngx-
to my language if it’s available translate 6h
library
Call the
translation
service from
12h
the files that
should be
translated
Add the
popups texts in
English,
12h
French,
Spanish and
German
Add the 14h
method that
would get the
browser
language
thanks to ngx-
translate
library and
generate the
corresponding
texts
66
Run the tests 10h
Implement the
Calendar 24h
component
Add the
necessary
12h
queries to
queries.ts
As a Patient, I want to check my
Call the
prescription’s calendar queries in the
6h
service page
methods
Call the service
methods in the 6h
calendar.ts file
Run the tests 12h
Add the
mutation to 1h
mutations.ts
Add the
changes to the 4h
As a Patient, I want to add a new medication to
html page
my calendar
Implement the
addMedication
7h
method to the
typescript file
Run the tests 2h
Implement the
profile 6h
As a Caretaker, I want to see my personal component
information Add the query
1h
to queries.ts
Run the tests 2h
Implement the
patients 6h
As a Caretaker, I want to see the list of my component
Patients Add the query
1h
to queries.ts
A4: Visit Run the tests 2h
Caretaker’s
Add the query
platform 8h
to queries.ts
Add the
necessary html
4h
As a Caretaker, I want to see my patients’ to create the
prescriptions calendar calendar
Add the
necessary 9h
typescript code
Run the tests 3h
67
Add the search
2h
As a Caretaker, I want to search a specific bar to html
Add the search
Patient from the Patients list
method to the 4h
typescript
Run the tests 1h
Add the
filtering
2h
options to the
As a Caretaker, I want to filter the Patients html code
list by multiple keys Add the
filtering
4h
methods to the
typescript code
Run the tests 1h
Call the
translation
service from
12h
the files that
should be
translated
Add the
popups texts in
English,
12h
French,
As a Caretaker, I want the platform to be Spanish and
German
translated to my language if it’s available
Add the
method that
would get the
browser
language
thanks to ngx- 14h
translate
library and
generate the
corresponding
texts
Run the tests 10h
Add the logout
1h
button
As a Caretaker, I want to logout
Add the logout
1h
method
Test the logout 1h
As a Caretaker, I want to remove a Patient Add the delete
from the Patients list mutation to 1h
mutations.ts
Implement the 8h
delete method
68
in the
typescript file
Run the tests 1h
As I mentioned in the previous sprint, as both sprint 3 and sprint 4 are focused on the same
platform visits, we would have the same description and functional analysis in both sprints,
that’s why I decided to make another structure just for this part, we talked about the patient’s
visit to the platform during the previous sprint’s chapter, and we will get to the caretaker’s
visit during this one.
The figure below represents the global use case diagrams the caretaker’s visit to the
dashboard:
Figure 41: Global use case (Sprint 4)
69
represents both the backend and frontend parts of the caretaker’s visit to the dashboard.
Like the patient’s visit to the dashboard, as all the actions needs the caretaker to be logged in,
I found that it is more appropriate to mention that without adding the ‘include’ relation with
the login use case every time.
Figure 42: Specified use case (Sprint 4)
70
complicated one.
“Check a patient’s prescriptions list” use case:
Use case Check a patient’s prescriptions list
Actor Caretaker
Caretaker Logged in
Pre-condition
Post-conditions List of prescriptions shown
1 – The caretaker goes to the patients’

page
2 - The caretaker chooses the ‘see

prescriptions’ option.
Principal scenario
3 – The corresponding prescriptions list
is rendered.
3a: The caretaker wants to search for a

specific prescription.
3a-1: The caretaker enters the name or

alternative scenario the initials of the prescription.
3a-2: The list is updated with

prescriptions that start with what the
caretaker wrote.
E1: The prescription doesn’t exist.

Error scenario
4a: An alert appears
71
For this sprint, I chose to demonstrate the ‘Check correspondent patients list’ scenario in the
sequence diagram below:
Figure 43: Check correspondent patients list’s sequence diagram
72
Section III: Realization
Since this sprint has been about the frontend of the users’ dashboard, this chapter’s
screenshots are taken from the patients and the caretakers’ visits to the platform. As I already
mentioned before, we made sure that everything works perfectly on any device by making all
the pages responsive.
The next screenshot represents the profile page, it is very similar for both a patient or a
caretaker, this one is taken from a patient’s visit.
For the caretaker case, he can see the list of his patients and update it by removing an old
patient.
Patients and caretakers can also change their personal information from this page.
Figure 44: Patient’s profile page
73
The next screenshot represents the calendar page, which is one of the biggest features of the
platform. The patient would find there the calendar of the whole week with reminders
whenever the time is close to take his next medicines. He has also the possibility to add a new
medicine to his calendar, other information is also shown in this page, like the shape of the
medicine, it’s color, and the quantity that he should take every time.
When the patient clicks on a medicine, he would be redirected to a more detailed page where
he can find anything that he needs to know about it.
Figure 45: Patient’s Calendar
The screenshot below is taken from the prescriptions page, which has a small description and
a schedule of the medicines that the patient is supposed to take, if the patient clicks on one of
the medicines, he would be redirected to the details page.
As the prescriptions’ list can become pretty long, we added the possibility of a dynamic
search, when the patient enters the initials of the medicine that he wants to learn about, the list
will be updated with all the medicines that start with what he typed.
74
Just like in the calendar page, the patient has the possibility to add a new medicine from this
page too.
If the patient clicks on the options button next to a prescription, he would have the possibility
to delete that medicine or change its calendar.
Figure 46: Prescriptions’ page
Conclusion:
In this chapter, we have been able to show the different user stories of this fourth Sprint. We
diagram and sequence diagram. The following chapter will be devoted to the fifth Sprint
which is dedicated to the implementation of the admin dashboard’s backend.
75
Chapter IX: Sprint 5
During this chapter, we’ll present the fifth sprint which will focus on the implementation of
the admin dashboard’s backend. We will start by presenting the backlog sprint, we will then
move on to some use cases descriptions followed by the functional analysis, we will pass after
that to the realization part.

Add necessary SMPT
configurations to Gmail 3h
account
As an Admin, I want to add Implement the ‘send_email’
10h
method
another Admin
Implement the ‘add_Admin’
8h
method
Add the necessary
2h
permissions
Test the API 4h
A5: Implement
Visit As an Admin, I want to see 6h
‘get_logs_statistics’ method
Admin’s Add the necessary
statistics about the users’ logs
platform 1h
permissions
Test the API 1h
Implement
As an Admin, I want to see ‘get_prescriptions_statistics’ 6h
method
statistics about the medications
Add the necessary
1h
permissions
Test the API 1h
76
Implement
‘get_users_statistics’ method 6h
As an Admin, I want to see Add the necessary

statistics about the users’ logs permissions 1h
Test the API 1h
Implement the ‘get_users’

8h
As an Admin, I want to see the method
list of all the users Add the necessary
4h
permissions
Implement the ‘delete_user’
4h
method
As an Admin, I want to delete a user Add the necessary
1h
permissions
Implement the
‘change_admin_password’ 3h
As an Admin, I want to change my method
password Add the necessary
permissions 2h

Implement the ‘get_logs’
6h
method
As an Admin, I want to the list of
all the logs Add the necessary
1h
permissions
As both sprint 5 and sprint 6 are focused on the same platform visit, we would be having the
same description and functional analysis in both sprints, so for the use cases part, we will only
77
show those used in the backend part in this sprint, and we will talk about those used in the
frontend in the next sprint.
The figure below represents the global use case diagrams the admin’s visit to his dashboard:
Figure 47: Global use case diagram (Sprint 5)
represents the backend part of the admin’s visit to his dashboard, and during the next sprint,
I’m going to show the use case of the frontend which will have the same use cases that exist
in this diagram in addition to other functionalities that are uniquely found in the frontend part.
As all the actions needs the caretaker to be logged in, I found that it is more appropriate to
78
complicated one.
As our application is mainly about the platform, all the use cases and diagram sequences
would eventually have a part (at least a little one) that is related to the frontend, the next use
cases description is about the users’ list, in order to have it shown, an interaction should be
done in the frontend part, that’s why it should be mentioned even though this sprint is mainly
about the backend.
79
Use case Check users’ list
Actor Admin
Admin Logged in
Pre-condition
Post-conditions List of users shown
1 – The admin goes to the users’ page
2 – The users’ list is rendered.

Principal scenario
3a: The admin wants to delete a specific
user.
3a-1: The admin clicks on the delete

Alternative scenario button next to the user that he wants to
delete.
3a-2: The list is updated with the

removal of the deleted user.
E1: Another admin deleted that user

Error scenario just seconds before that admin does.
4a: A ‘User doesn’t exist’ alert would

appear
E2: Network problems
4a: An ‘Network problem’ alert would

appear
For this sprint, I chose to demonstrate the ‘Add Admin’ scenario in the sequence diagram
below:
80
81
Figure 49: 'Add admin’ sequence diagram
82
Since this sprint has been about the backend of the admin’s dashboard, this chapter’s
screenshots are taken from the API testing platform Postman (just like in the other backend
sprints).
The next screenshot represents the query called when the admin wants to change his password
from the platform. The query includes the method’s name in our server’s controller, the old
password, and the new one.
Figure 50: Password reset mutation
In case the old password is wrong, an error indicating that would appear in the response:
83
Figure 51: Failure case for password reset mutation
The next screenshot represents the query that gets all the users to show them in the admin
platform. The query includes the method’s name in our server’s controller, and the fields that
we want to see in the response, but as I said before, we can always add any other field to the
response as long as it belongs to the same object type (in this case the User type).
Figure 52: users’ query
For a successful case, the success code ‘200’ would be returned long side with the users’ list:
84
Figure 53: Successful case for users’ query
The next mutation is a very important one in the platform, it allows the admin to send an
email to a person of his choice in order to invite him to become an admin himself.
The first mutation includes the method’s name in our server’s controller, and the email that
will receive the invitation.
85
Figure 54: Admin invite mutation
If the mutation is successful, a code would be generated and sent in the email at the end of the
redirecting link that would get the invited user to our platform in order to finish his
subscription as an admin.
Figure 55: Successful case for admin invite mutation
After clicking on that link, the new admin would fill a form with his username, his password,
and his email. The code that was generated before sending the email would be attached to the
86
query and sent as another parameter in order to make sure that only that new admin is able to
get to that phase.
Figure 56: Admin account creation mutation after accepting the invitation
Conclusion:
During this chapter, we have been able to show the different user stories of this fifth Sprint.
We have developed the analysis of this sprint by presenting some diagrams such as the use
case diagram and sequence diagram. The following chapter will be devoted to the last Sprint
which is dedicated to the implementation of the admin dashboard’s frontend.
87
Chapter X: Sprint 6
During this chapter, we’ll present the sixth sprint which will focus on the implementation of
the admin dashboard’s frontend. We will start by presenting the backlog sprint, we will then
move on to some use cases descriptions followed by the functional analysis, we will pass after
that to the realization part.

Add the appolo
configurations 3h
file
Create
10h
As an Admin, I want to add another Admin admin.service
Create the
8h
email_form
Add the
mutation to 2h
mutations.ts
Run the tests 4h
Implement the
users’ statistics
As an Admin, I want to see statistics about the part inside the 6h
A5: homepage
Visit users’ logs component
Admin’s Add the query
platform 1h
to queries.ts
Run the tests 1h
Implement the
medications’
statistics part
As an Admin, I want to see statistics about the 6h
inside the
medications homepage
component
Add the query
1h
to queries.ts
Run the tests 1h
As an Admin, I want to see statistics about the Implement the 6h
88
logs’ statistics
part inside the
homepage
component
Add the query
users’ logs 1h
to queries.ts
Run the tests

1h
Create users’
8h
As an Admin, I want to see the list of all the component
users Add the query
4h
to queries.ts
Run the test 3h
Add the search
2h
bar to html
As an Admin, I want to search a specific user from Add the search
the user list method to the 4h
typescript
Run the tests 1h
Add the
filtering
2h
options to the
html code
As an Admin, I want to filter the users list by
Add the
multiple keys
filtering
4h
methods to the
typescript code
Run the tests 1h
Add the delete
icon with html
4h
inside the
foreach loop
As an Admin, I want to delete a user Add the delete
mutation to 1h
mutations.ts
Run the tests 1h
Add the
necessary html 3h
code
As an Admin, I want to change my password Add the
mutation to 2h
mutations.ts
Run the tests 1h
As an Admin, I want to logout from my account Add the logout 1h
button
89
Add the logout
1h
method
Test the logout 1h
Add Logs
6h
As an Admin, I want to the list of all the logs component
Add the query
1h
to queries.ts
Run the tests 1h
Add the search
bar to html 2h
As an Admin, I want to search for a specific
Add the search
user’s logs method to the 4h
typescript
Run the tests
1h
The figure below represents the global use case diagrams the admin’s visit to his dashboard:
Figure 57: Global use case (Sprint 6)
represents the frontend part of the admin’s visit to his dashboard.
90
As all the actions needs the caretaker to be logged in, I found that it is more appropriate to
Figure 58: Specified use case (Sprint 6)
complicated one.
91
Use case Check logs’ list
Actor Admin
Admin Logged in
Pre-condition
Post-conditions List of logs shown
1 – The admin goes to the logs’ page
2 – The logs’ list is rendered.

Principal scenario
3a: The admin wants to search a specific
user’s logs.
3a-1: The admin starts typing the user’s name

Alternative scenario in the search bar.
3a-2: The list is dynamically updated by the

logs of users that start with the typed name.
E1: The name that the admin typed doesn’t

Error scenario exist.
4a: A ‘Typed user doesn’t exist’ alert would

appear
For this sprint, I chose to demonstrate the ‘Add Admin’ scenario in the sequence diagram
below:
92
Figure 59: ‘Add admin’ sequence diagram

Since this sprint has been about the frontend of the admin’s dashboard, this chapter’s
screenshots are taken from the admin’s visit to his platform. As I already mentioned before,
93
we made sure that everything works perfectly on any device by making all the pages
responsive.
The next three screenshots represent the home page of the admin dashboard, it shows some
information about the users and the products (medications). The admin dashboard is also
responsive like the user dashboard and the public website.
Figure 60: Admin dashboard’s homepage (big screen)
94
Figure 61: Admin dashboard’s homepage (medium screen)
95
Figure 62: Admin dashboard’s homepage (small screen)
The next screenshot represents the users’ page, the admin can filter the users, search for a
specific user or create a new user from that page.
Figure 63: users’ page
The next screenshot represents a filtered list in the same page, when the admin starts typing a
user’s name, the list dynamically changes.
Figure 64: searching feature inside users’ page
96
When the admin clicks on a user from that list, he would be redirected to a details page where
he can find all the information about him such as the email, caretakers if he is a patient (or
patients if he is a caretaker), logs etc...
The next screenshot is taken from the details page.
Figure 65: User details page (medium screen)
In the users’ page, if the admin clicks on ‘Add user’ button, he would be redirected to a first
form where he has to choose the type of the new user.
97
Figure 66: Add user form
If the admin chooses to add a patient or a caretaker, he would be redirected to a form where
he can fill all of their available information, and the new user would of course be able to
modify it later from his dashboard. The previous screenshot is taken from a patient/caretaker
add.
In the other hand, if the admin chooses to add an admin, he would be redirected to another
form where he has to enter the new admin’s email, and the account won’t be added unless the
new admin confirms. The next screenshot is taken from that form.
98
Figure 67: Successful case for sending an admin invite
In case of a success, an invitation code would be generated and sent to the new admin’s email
inside of a link that would grant him access to a new and last form which allows him to finish
the subscription by adding his other info such as the username and the password.
Conclusion:
During this chapter, we have been able to show the different user stories of this last Sprint.
We have developed the analysis of this sprint by presenting some diagrams such as the use
case diagram and sequence diagram and then presented some screenshot from admin’s
platform. We will move now to the general conclusion.
99
General Conclusion
We have presented in this report all the phases that were necessary for the development of a
backend part and two platforms, starting from a general presentation of the project, to then the
description of our solution, its architecture and the methodology of development followed
throughout this internship.
We then applied the Agile Scrum methodology while respecting its different phases from
planning to deployment to present the work done.
The contribution of this work essentially comes down to the creation of three applications. A
Backend part for the management of users, prescriptions, calendars and logs, a dashboard for
the users (patients and caretakers) made with a huge thought of the user experience, and a
dashboard for the admins to see statistics and manage the platform.
We already had a first version of Medical voices’ platform deployed, but we still think of
adding a lot of new features in the future, such as making the voice interaction part available
also for the users of the platform besides the ones already using Amazon’s Alexa, we will also
add the notifications logic to make our app even more helpful to elders.
This internship was an enriching and beneficial experience both individually and
professionally. It didn’t only help me to improve my technical skills by learning new
technologies and new tools of work but also helped me feel that I’m actually contributing to
the world in my own small way.
100
Bibliography
[1] : Python’s documentation : https://www.python.org/doc/
[2] : Typescript’s documentation : https://www.typescriptlang.org/docs
[3] : Html’s documentation : https://developer.mozilla.org/fr/docs/Web/HTML
[4] : Scss documentation : https://sass-lang.com/documentation
[5] : Angular’s documentation : https://angular.io/docs
[6] : Django’s documentation : https://docs.djangoproject.com/en/3.1/
[7] : Noje.js documentation : https://nodejs.org/en/docs/
[8]: Graphene’s official website: https://docs.graphene-python.org/en/latest/
[9] : MongoDB’s documentation : https://docs.mongodb.com/
[10] : GraphQL’s documentation : https://graphql.org/learn/
[11] : Docker’s documentation : https://docs.docker.com/
[12] : Gitlab’s documentation: https://docs.gitlab.com/
101
Abstract
This report presents the work developed during the internship at "Relief Applications" (Legal
name = “Oordt cloud technologies”). The goal of this project is to design and implement three
applications: A Backend application that allows the management of modules like
authentication, profile, calendar, prescriptions and logs, a dashboard for the users (patients
and caretakers) so patients can get easier to information about their prescriptions and their
calendar, and another dashboard for the admins to manage users and see some statistics that
would help improve the platform.
Key words: Angular, Django, GraphQL, MongoDB, Graphene, Docker.
Name and other information about the

company
Company: Relief Applications (Legal name = “Oordt cloud technologies”).
Address: Calle Núñez Morgado, 7 - 28036 Madrid, España
Phone number: +34 629020523
Official website: https://reliefapplications.org
Email: contact@reliefapplications.org
102
103

Medical Voice's Platforms: By: Mohamed Slim Ahan Touati

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Medical Voice's Platforms: By: Mohamed Slim Ahan Touati

Uploaded by

Copyright:

Available Formats

kkkkjpiosqd

Medical Voice’s platforms

Academic supervisor: Salma Sayah

Corporate Internship Supervisor: Arturo Garcia Sanchez

All my friends who have helped me in difficult times,

All those who have supported me throughout this project.

My thanks also go to my supervisor Ms. Salma Sayah,

I am also grateful to all my teachers who gave me

valuable advices throughout the years in Esprit.

Chapter I: General Framework of the project................................................................................................3

Section I: Company presentation: Relief Applications (Oordt..................................................................3

Section II: Partner Presentation:.................................................................................................................6

Asociacion Parkinson Madrid.................................................................................................................6

Chapter II: State of the art..............................................................................................................................8

Section II: Existing solutions.....................................................................................................................8

Section III: Problems with the existing solutions.....................................................................................10

Section IV: Solution.................................................................................................................................11

Chapter III Sprint 0: General analysis and planification..............................................................................14

Section I: Global analysis.........................................................................................................................15

Section II: Technological orientation.......................................................................................................19

Section III: Work methodology................................................................................................................22

Section IV: Planification and deadlines...................................................................................................26

3. Timeline and deadlines.....................................................................................................................29

Chapter V: Sprint 1......................................................................................................................................31

Section I: Sprint backlog..........................................................................................................................31

Section II: Description and Functional Analysis......................................................................................32

1. Description of the use cases:.............................................................................................................34

a. “Login into account” use case:......................................................................................................34

Section III: Realisation.............................................................................................................................37

Chapter VI: Sprint 2.....................................................................................................................................42

Section I: Sprint backlog..........................................................................................................................42

Section II: Description and Functional Analysis......................................................................................43

1. Description of the use cases:.............................................................................................................45

Section III: Realisation.............................................................................................................................47

Chapter VII: Sprint 3....................................................................................................................................54

Section I: Sprint backlog..........................................................................................................................54

Section II: Description and Functional Analysis......................................................................................56

1. Description of the use cases:.............................................................................................................58

Section III: Realisation.............................................................................................................................61

Chapter VIII: Sprint 4..................................................................................................................................65

Section I: Sprint backlog..........................................................................................................................65

Section II: Description and Functional Analysis......................................................................................70

Section III: Realization.............................................................................................................................75

Chapter IX: Sprint 5.....................................................................................................................................78

Section I: Sprint backlog..........................................................................................................................78

Section II: Description and Functional Analysis......................................................................................80

1. Description of the use cases:.............................................................................................................81

Section III: Realization.............................................................................................................................85

Chapter X: Sprint 6......................................................................................................................................90

Section I: Sprint backlog..........................................................................................................................90

Section II: Description and Functional Analysis......................................................................................93

1. Description of the use cases:.............................................................................................................94

Section III: Realization.............................................................................................................................97

Name and other information about the company.......................................................................................105

Figure 1: Relief Applications logo................................................................................................................3

The goals of this internship are:

- Discover the professional life.

Section I: Company presentation: Relief Applications (Oordt

Relief Applications (Legal name = Oordt cloud technologies) is an organization situated in

Relief Applications’ mission is bringing innovation to people changing the world by

Figure 1: Relief Applications logo

The company itself consists of the following teams: