Template Final Rapport PFE Latex 85 Copy

Republic of Tunisia
Ministry of Higher Education and Scientific

Research
Carthage University
Higher Institute of Information and
Communication Technologies
End of study report

Presented to obtain the
Bachelor’s degree in Science and Technology
Mention: Computer Sciences
Specialty: Computer Sciences
Computerized and shared medical records
Presented by
Mustapha Kerrou
Fakhreddine Ben Fraj
Performed within Dar Blockchain
Defended on May 25th 2019 in front of Jury composed of:
President: Mr. Khaled FOURATI, Chief Operating Officer, Innov-alliance-tech

Reviewer: Mr. Seifeddine AZZABI, Teacher, ISTIC
Examiner: Mrs. Abir MASMOUDI, Teacher, ISTIC
Profesional advisor: Mr. Nasseur MSEDDI, Co-founder, DAR BLOCKCHAIN
Academic advisor: Mrs. Syrine SAHMIM, Teacher, ISTIC
Academic year: 2018-2019

Republic of Tunisia
Ministry of Higher Education and Scientific
Research
Carthage University
Higher Institute of Information and
Communication Technologies
End of study report

Presented to obtain the
Bachelor’s degree in Science and Technology
Mention: Computer Sciences
Specialty: Computer Sciences
Computerized and shared medical records
Presented by
Mustapha Kerrou
Fakhreddine Ben Fraj
Performed within Dar Blockchain
Authorization to submit the report of the End of Studies Project:
Professional Advisor: Academic Advisor:

Mr. Nasseur MSEDDI Mrs. Syrine SAHMIM
The: The:
Signature: Signature:
Abstract
In this project framework we realized an application that strengthen the relation be-
tween Patients and Providers (Doctor, Pharmacist, Insurer) by allowing the patient to
store his complete and accurate Electronic Health record (EHR), And share it in the
blockchain network.
This technology offers the patient security, integrity, immutability and transparency over
his personal medical data shared in the network. and let him choose the desired provider
to update his record by granting access to his EHR.
As for the providers, they are able to read or update the patient’s EHR only if he give
them access to his EHR. This project is based on deployment of smart contract used
by Hyperledger Fabric. This framework allowed us to create the consortium blockchain
which is based on agreement between all actors using it.
Keywords: Patients, Providers, Electronic Health Record (EHR), blockchain ,

Network, Update, Granting access, Smart contract, Hyperledger fabric, consortium.
Adresse du site: Route de Soliman, Technopole de Borj Cedria, Adresse postale : BP 123,
Hammam Chatt 1164, Ben Arous, Tunisie - Telephone: (216) 79 32 67 63 ; (216) 79 32 67 90 ;
(216) 79 32 67 91 ; (216) 79 32 67 92 - Fax: (216) 79 32 67 64 - Site web: www.istic.rnu.tn
Dedication
I would like to dedicate this work to our families with all feelings of respect, love and
gratitude for all the sacrifices they made to raise us with dignity and prideful and ensure
our education in the best conditions. It is thanks to their efforts and advises that we have
been able to overcome all challenges and obstacles. To all our friends thank you for being
always there to cheer and support us.
ii
Appreciations
First of all, I would like to thank Mr. Chedid Haythem, the founder and Mr. Nasseur
Mseddi co-founder of DAR BLOCKCHAIN, for having welcomed us as a trainee, their
generosity, their support and the comfort and the flexibility they have given us. I would
like to particularly thank Mrs. Syrine Sahmim and Mr.Nasser Mseddi for their advices
and the confidence given to us throughout our internship. all of them have contributed, by
their availability and good humor, to make our training fruitful, rewarding and motivating.
iii
Contents
Dedication ii
Appreciations iii
Introduction 1
1 Preliminary studies 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Project context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Company presentation . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Problem context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Project goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.4 Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.5 Proposed solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.6 Project description/Features specifications . . . . . . . . . . . . . . 5
1.3 State of the art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Pros and cons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.4 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.5 Added value to the solution . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Project management methodology . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 Adapted methodology: Agile . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 The "SCRUM" method . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Sprint 0 backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6 Sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.1 Tasks done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.2 Acceptance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Analysis and specification of requirements 14

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Identification of Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Requirements specification . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Non-Functional requirements . . . . . . . . . . . . . . . . . . . . . 15
2.4 Project management with Scrum . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Sprints planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
iv
2.5 Analyse of needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1 Use case diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.2 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 Application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.7 Technological choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.7.1 Software environment . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.7.2 The technologies used . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.7.3 The languages used . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.8 Sprint backlogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.8.1 Tasks done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.8.2 organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.8.3 Acceptance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3 Release 1 : Digital workspace 38

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Analysis and specification of needs . . . . . . . . . . . . . . . . . . . . . . 40
3.4.1 Identification of sprint 1 actors . . . . . . . . . . . . . . . . . . . . 40
3.4.2 Reused use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.4 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.5 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.6 Acceptance criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 Release 2: Chaincode Development 51

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.4.1 Identification of the actors in sprint 2: . . . . . . . . . . . . . . . . 52
4.4.2 Reused use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4.3 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.6 Acceptance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.7 Sprint conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.8 Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.9 Sprint 3 backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.10.1 Identification of the actors in sprint 3: . . . . . . . . . . . . . . . . 55
4.10.2 Reused use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.10.3 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.11 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.12 Acceptance Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.13 Sprint conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.14 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
v
Conclusion 58
Bibliography 60
vi
List of Figures
1.1 Blockchain logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Hyperledger logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Modeling of the Agile methodology . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Scrum Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Global use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2 Doctor use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Patient use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Pharmacist use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5 Insurance use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.7 Application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Authentication use case diagram . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 Register use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Logout use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4 Authentication sequence diagram . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Register sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6 Logout sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7 Authentication form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8 Home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.9 Registeration page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.10 Display health record page . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.11 Insert into health record page . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.12 Give access to health record page . . . . . . . . . . . . . . . . . . . . . . . 48
3.13 Doctor home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.14 Doctor Display health record page . . . . . . . . . . . . . . . . . . . . . . . 49
3.15 Doctor insert to health record page . . . . . . . . . . . . . . . . . . . . . . 49
3.16 Doctor insert to health record page 2 . . . . . . . . . . . . . . . . . . . . . 50
4.1 Sprint 2 use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2 Sprint 3 use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
vii
List of Tables
1.1 Sprint 0 backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Sprints planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Sprint backlog of sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Authentication use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Register use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Logout use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Sprint 2 product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2 Patient Read EHR use case . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3 Patient insert to EHR use case . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4 Patient grant access use case . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 Sprint 3 product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6 Doctor Read EHR use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.7 Patient insert to EHR use case . . . . . . . . . . . . . . . . . . . . . . . . . 56
viii
Introduction
The Tunisian health care system faced a lot of evolving phases since it’s creation and
has been struggling to find a technology that can offer security and integrity. Many new
technologies have risen to solve many health care system problems, These technologies
keep on evolving over time and they are growing remarkably. One of these technologies is
the blockchain since January 2009. Although still a new technology but it has proven itself
sufficient and effective and it stood out above the others, It first started as an engine for
cryptocurrency but now it has evolved to other domains such as the health care system
with the use of smart contracts, according to Chris Douthit (CEO/Analyst [0]). This
technology is meant to computerize all the medical data and provide security and remove
all the physical paper work needed in health care.
Unfortunately with the traditional medical healthcare system of Tunisia we are facing
some difficulties such as physical records and archives that is very hard to share with
providers since the process can take a long time, effort and cost, as well as preventing
fraud and bad use of patient informations, also computerized data can be easily lost or
manipulated etc...
Since the interaction between the evolution of technologies and the medical health care
system, Dar Blockchain decided to develop the "Ehealth" platform which aims to digitize
and secure national healthcare data by registering, creating and clustering data to ease
access and use of medical records with the use of blockchain technology. All projects that
use blockchain technology are in startup stage especially in incubation phase, this idea
can be game changing for Tunisia if applied because over the world not many applications
are achieved for this issue and they are still in their early stage of development.
Our project can be summarized in:

• Chapter one presents description and some details about the company, Inventory and
problem statement with some proposed solutions, - State of art where we explained
The Blockchain technology with pros and cons - and the methodology chosen and
used during our development to stay organized and to follow the plan.
• Chapter two presents our project planning and division into sub projects, Identifi-
cation of actors, some functional and non functional requirements, project manage-
ment with scrum , use case and class diagrams and the technological choice for this
project.
• Chapter three presents the release 1 of this project "digital workspace" in which
we presented the first sprint of realization, Analysis and specification of needs and
realization dedicated to platform users.
1
• Chapter four presents the release 2 of this project "chaincode development", in which
we presented the second sprint of realization, analysis and specification of need and
realization.
2
Chapter 1
Preliminary studies
1.1 Introduction
In this chapter, we will focus on the presentation of the project context. Starting by the
DARBLOCKCHAIN incubator presentation, we will after deal with the exposure of the
problem statement that gave rise to this work, we will present the study of what existed
as a state of the art and then we will present the proposed solution and Finally, we will
give a presentation of the adapted project management methodology.
This release represents the first 2 sprints as shown in the global product backlog :
• Research on Basic Blockchain, different types of blockchain and the existing use
cases over the world about health care blockchain based platforms similar to our
project.
• Research on Hyperledger fabric.
1.2 Project context

1.2.1 Company presentation
• Dar Blockchain incubator
Dar Blockchain is a an incubator that offers a collaborative work space where stu-
dents, freelancers, and small businesses can connect, create amazing work and con-
quer their goals.
• Mission and vision
– Vision :
Dar Blockchain is working on the installation and development of the IT in-
frastructure based on Blockchain technology. This Startup is committed to
facilitate the access to the infrastructure by reducing costs and offering a prod-
uct with the best quality of the applied technology and its services.
– Mission :
3
∗ Collaborate closely with incubators specialized in innovation and high-tech
∗ Develop innovative solutions for its customers.
∗ Initiate a partnership and working relationships with academic institutions
and contribute to the promotion of its know-how for future generations.
∗ Work to meet needs through the creation and application of new IT.
1.2.2 Problem context

The traditional tunisian medical healthcare system is based on physical records and
archives that is very hard to share with providers since the process can take a long time,
effort and cost, as well as preventing fraud and bad use of patients informations, also the
physical records are highly vulnerable to being damaged and getting lost so they are not
guaranteed to last a lifetime.
1.2.3 Project goal

The objective is to digitize and secure national healthcare data and develop a solution for
registering, creating, storing and clustering data to ease access and use of medical records
with respect to the privacy of the patient’s personal details.
1.2.4 Inventory
Unlike Tunisia situation where we are still relying on physical records other countries
(Canada, France, United state of america, etc..) has already adapted their healthcare
system with many effective technologies such as Blockchain that provides security and
integrity.
1.2.5 Proposed solution

The solution consist on a platform, where a patient can access his medical records, share
it with healthcare providers (Doctors, Pharmacies, Insurance), and grant them permission
to add new set of data according to their status (pharmacist/ physiciens....). This data
should be encrypted stored and secured in a decentralized database with permissioned
access and guarantee the privacy of the personal information. This solution would benefit
the tunisian healthcare system a lot but due to the short time period of the internship
we wont be able to cover a most of the project because it is rich of features and options
that require more time to develop. So, our scope is to cover these steps such as described
in the global product backlog(figure 2.1) and thereafter the solution advantages detailed.
The advantages of the solution

• Transparency : Storing complete and accurate patient’s Electronic Health Records
(EHR), sharing them between different actors (Patients and healthcare providers)
in a secure and transparent way and validation of each transaction in real time by
all nodes in our blockchain consortium.
This should avoid patients to have their health information spread as multiple frag-
mented records over multiple systems (practitioners, institutions, networks..) and
let all actors see every single crypted transaction in the network.
4
• Preserving confidentiality and privacy of personal data by using cryptographic method(multi
signature algorithm).
• Multi signature Algorithm : Any changes to the electronic health record(EHR)

requires both the provider and patient certificate(private key).
• Anonymity : Providing limited and permissioned access to a plethora of data types,

either for research, statistical, and economic purposes, or to improve the perfor-
mance of the health insurance system but also the overall healthcare quality, while
keeping the anonymity of the data owner.
• Reinforcing Trust between different peers by Insuring the prior consent when ac-
cessing to the patient EHR.
• Integrity and authenticity : Warranting inviolability and immutability of EHR Ac-

curacy and authenticity of the data stored.
• Decentralization : Avoiding the resort to a trusted third party for storing personal
health data.
• Costless : Reducing costs of health records storing and securing in centralized sys-
tems (provided by existing digital solutions.
• Transactions tracking and anti-corruption system : By digitizing health records and

empowering users we can leverage countless healthcare and industry synergies.
1.2.6 Project description/Features specifications

• EHR will be stored in a decentralized DB/distributed ledger.
• The system will be implemented using a permissioned-Blockchain (Hyperledger Fab-

ric).
• Data security will be implemented using a double encryption mechanism (symmetric

key cryptography).
• EHR will be held in a centralized data system in an encrypted format, Blockchain

acting as a pointer to the data location.
• - The system should provide the following features:
– Patient has Read access to his entire EHR.

– Patient can grant full or limited Read/Write access to a practitioner/institution
for his EHR.
– Patient can revoke access from a provider for his EHR.
– Patient can have Write limited access to some kind of notes related to his eating
attitude, self medication, substances consumption, physical exercise, etc...
– Provider can request permission from a patient to have full or limited READ/Write
access to his EHR.
5
1.3 State of the art
1.3.1 Introduction
In this section, we will start by exploring further how the blockchain can impact many
different domains. The section is organized in the following way.
• Defining the Blockchain and provide an overview of how Blockchain has evolved
over time.
• Dive into how Blockchain work and review the features that make the technology
important.
• Introducing how the Blockchain may impact notable use cases and reviews the
advantages and disadvantages of Blockchain technology.
• Explore further Derivatives of Blockchain.
1.3.2 Blockchain
History of Blockchain
In 2008, an individual (or group) writing under the name of Satoshi Nakamoto published a
paper entitled "Bitcoin: A Peer-To-Peer Electronic Cash System"[1]. This paper described
a peer-to-peer version of the electronic cash that would allow online payments to be sent
directly from one party to another without going through a financial institution. Bitcoin
was the first realization of this concept. Now "cryptocurrencies" is the label that is used to
describe all networks and ways of exchange that uses cryptography to secure transactions
against those systems where the transactions are conducted through a centralized trusted
entity. The author of the first paper wanted to remain unknown and for this reason no
one knows Satoshi Nakamoto to this day. A few months later, an open source program
implementing the new protocol was released, beginning with the Genesis block of 50 coins.
Anyone can install this open source program and become part of the bitcoin peer-to-peer
network. It has grown in popularity since then. The popularity of the Bitcoin has never
ceased to increase since then. Moreover, the hidden BlockChain technology is now finding
new range of applications beyond finance[1].
Important Definitions
• Nodes: Any computer or device connected to a blockchain network.
• Ledger: A shared and distributed history of all transactions and balances.
• Mining/Miners: In Bitcoin, mining is the process of generating a new legitimate

block by applying proof-of-work. There are people that dedicate their nodes to
"mine" new blocks. These nodes are considered "miners".
• Consensus: A consensus algorithm is the mechanism by which all nodes in the

network agree on the same version of the truth. A consensus algorithm allows
nodes on the system to trust that a given piece of data is valid and that it has been
synchronized with all other nodes.
6
• Cryptocurrency: A digital currency built upon cryptographic protocols. Decentral-
ized Application (DAPP): A decentralized application built on top of a blockchain-
based system.
• Secure Cryptographic Hash Functions: A secure cryptographic hash function is a

hash function that preserves one-wayness-easy to compute but virtually impossible
to reverse engineer.
• Cryptographic Keys: The use of symmetric (same) keys and asymmetric (public-
private) key pairs for the use of signing and verifying transactions.
Defining Blockchain
A blockchain is composed of a distributed digital ledger that is immutable cannot be
edited and is shared among all participants in a blockchain network. More specifically,
a blockchain is a data structure composed of time-stamped and cryptographically linked
blocks. Each block has a cryptographic hash, a list of validated transactions, and a
reference to the previous block’s hash. Through this mechanism, nodes can verify that a
participant owns an asset without the need for a central governing authority[2].
Figure 1.1: Blockchain logo
Structure of Blockchain
Components of the block’s header:
• Version: The version of block validation rules it follows.
• Previous Block Hash: The hash of the previous block in the blockchain.
• Current Block Hash: The hash of the current block in the blockchain.
• Timestamp: The Unix epoch time the block was mined.
• Data: data contained within the Block.
A blockchain is very similar to a linked list-each block contains a pointer to the previous
block. A key difference in blockchain is that each block contains a hash pointer to the
previous block. A hash pointer contains two things: a pointer, or reference to the location
of the previous block, and the cryptographic hash of that block. Storing the cryptographic
hash of the previous block allows us to verify that the block we are pointing to has not
been tampered with. To verify a block, we simply compare our stored hash pointer with
the previous block’s hash and make sure they are equal[2].
7
Smart contracts
Originally introduced by Nick Szabo in 1994[1], smart contracts consist of small com-
puter programs that contain-embedded in their code an agreement between two entities.
This contract is then distributed across the blockchain and is responsible for facilitating
the execution, verification, and enforcement of an agreement between seller and buyer.
Essentially, a smart contract is just a digital, auto-enforceable version of a traditional
paper-based contract. Ethereum is the most popular blockchain system with embodied
smart contracts. As we will see in later sections, smart contracts allow devices to negoti-
ate and execute previously agreed actions automatically, enabling a new set of functions
and use cases for Electronic health solutions.
Hyperledger fabric
Hyperledger Fabric is a blockchain framework implementation and one of the Hyperledger
projects hosted by The Linux Foundation[7]. Intended as a foundation for developing
applications or solutions with a modular architecture, Hyperledger Fabric allows com-
ponents, such as consensus and membership services, to be plug-and-play. Hyperledger
Fabric leverages container technology to host smart contracts called "chaincode" that
comprise the application logic of the system.
Figure 1.2: Hyperledger logo
1.3.3 Pros and cons

Pros
• Enable security between parties through cryptographic principles.
• Decentralized architecture.
• A "trustless" system.
• Consensus mechanism.
• History of transactions.
• Ensured immutability.
Cons
• The technology is initially difficult to understand and adopt.
• Energy consuming and high computation time.
• Scalability.
• Size of the network.
8
1.3.4 Use cases
• Embleema
– After launching its Version 1 of its Health Blockchain Network on July 17th,
2018, Embleema, is introducing Version 2 of its Health Blockchain Network
that connects dispersed Patient Generated Health Data ("PGHD"), Electronic
Medical Records ("EMRs") and other sources of patient information into a
consolidated and highly-secure repository, providing the healthcare ecosys-
tem an undisputed and 360 degree view of the patient’s medical history and
thus setting the foundation for the delivery of safer, better and personalized
medicine[3].
• Medicalchain
– Medicalchain uses blockchain technology to create a user-focused electronic

health record whilst maintaining a single true version of the user’s data. en-
ables the user to give healthcare professionals access to their personal health
data. Medicalchain then records interactions with this data in an auditable,
transparent and secure way on Medicalchain’s distributed ledger[4].
• MedRec
– A novel, decentralized record management system to handle EHRs, using

blockchain technology. The system gives patients a comprehensive, immutable
log and easy access to their medical information across providers and treatment
sites, they propose an alternative a distributed access and validation system
using the blockchain to replace centralized intermediaries[5].
1.3.5 Added value to the solution

Blockchain is a big factor for providing security and integrity to the medical data by
linking all the blocks that contains the encrypted data and removing all possibilities of
data modification. Also the smart contract is a great way to ensure an agreement between
entities (Patient, Doctor, Insurance etc..) and is responsible for facilitating the execution,
verification, and enforcement of an agreement between the Patient and providers.
1.4 Project management methodology

In this section, we will present the work methodology adapted to our work
1.4.1 Adapted methodology: Agile

An Agile method is an iterative and collaborative approach, capable of taking into ac-
count the initial needs of the customer and those related to evaluations. Agile methods
can be defined as software design procedures that are more pragmatic than traditional
methods... By involving the customer as much as possible, these methods make real
customer satisfaction their first priority
9
Figure 1.3: Modeling of the Agile methodology
1.4.2 The "SCRUM" method

Application modeling provides a better understanding of the system under development.
It helps to visualize and specify the structure and behavior of the system.
In order to achieve this solution, we must use a working methodology that presents both
the possibility of collaborative work and confidence to the developer. In addition, for our
application, we found that SCRUM is the most flexible and proven Agile methodology
today.
The SCRUM methodology is particularly designed for the management of IT projects.
Its purpose is to:
• Improve team productivity.
• Multiply the development speed.
• Strengthen communication between members of the development team.
• Provides a framework for the personal development of individuals.
• Choose freely the development techniques.
The implementation of our application requires a strong interaction between team mem-
bers and the client in order to fully understand their business processes. So, using a
work methodology that presents both collaborative work and developer trust is the most
appropriate for our case. In addition, we chose the SCRUM methodology to monitor and
update the needs during daily meetings and iterations lasting 15 days.
Main principles of the method

We can notice four main values in agile methods:
• The team: we focus on people and their interactions rather than about processes
and tools.
10
Figure 1.4: Scrum Cycle
– Mrs. Syrine Sahmim.

– Mr. Nasser Mseddi.
– Mr. Chedid Haythem.
– Mr. Mustapha Kerrou.
– Mr. Fakhreddine Ben Fraj.
• The application (Electronic health record): The most important thing is to have a
functional application rather than to have complete documentation.
• Collaboration: This method is based on collaboration with the product owner (Mr.
Nasser Mseddi).
• The acceptance of change: We do not follow a plan but we react with each new
change.
Organization
The SCRUM methodology involves 4 main roles which are:
• Product owner: most of the projects, the product owner is the head of the client
project team. He will define and prioritize the list of product features and choose the
date and content of each sprint on the basis of the values (charges) communicated
to him by the team.
• Scrum Master: Facilitator of the project, he ensures that everyone can work in the
best conditions abilities by removing obstacles and protecting the team of external
disturbances. He also pays particular attention to the respect of the various phases
of SCRUM.
• Team: The team organizes itself and remains unchanged for the duration of a sprint.
He must do everything to deliver the product.
• Speakers: They observe and give advice to the team.

In our project, we can distinguish the following roles:
11
– Product owner: Mr. Nasser Mseddi.
– Scrum Master: Mrs. Sahmim Syrine/Mr. Nasser Mseddi.
– Speakers: Mrs. Sahmim Syrine, Mr. Nasser Mseddi.
– Testers: Mr.Fakhreddine Ben Fraj, Mr. Mustapha Kerrou.
– Developers: Mr.Fakhreddine Ben Fraj, Mr. Mustapha Kerrou.
1.5 Sprint 0 backlog
ID User story Tasks Estimation/H

Project study(problematic,
96
As a developer, i need to manage goal, solution).
1
my project well. Project requirements
96
(tools and technologies).
Project analysis(features and
96
added values).
Research on Basic Blockchain and
As a developer, i need to acquire 216
2 different types of blockchain.
atleast the minimum knowledge
Research on Hyperledger fabric
of the technologie im going to use 216
and existing sanitary systems.
Table 1.1: Sprint 0 backlog
1.6 Sprint 0
The first sprint consist on developing our knowledge on the blockchain technology by
researching the basic blockchain, its different types and Hyperledger fabric, with this we
can gather enough information about the basics of blockchain and how to utilize the
Hyperledger tool which we explained in the previous sections.
1.6.1 Tasks done

Document is prepared about what we have done in this sprint 0 and sent to the product
owner to review and validate. A presentation is done to evaluate our knowledge level after
sprint 0 release.
1.6.2 Acceptance Criteria

Mr. Nasser Mseddi and Mr. Haythem Chedid as a product owner accepted the document
and gave us some recommendations to go in depth in the technology and asked us to
choose tools and begin the test development to perform the technology.
1.7 Conclusion
Through out this chapter, we have discussed the general context of the project. We started
with a presentation of the host organization following that with a study of the existing
12
and a brief explanation of the state of art. This allowed us to understand the needs and
to consider the most appropriate solution to the product owner’s expectations. In the
next chapter, we will detail the specification of requirements of our project.
13
Chapter 2
Analysis and specification of

requirements
2.1 Introduction
By following the Scrum method for the management of our application we start with
defining the product backlog, the planning of different sprints and then we specify the
functional and non-functional needs. The analysis of these needs allowed us to identify
the various functions, the actors of the system and The UML diagrams.
2.2 Identification of Actors

The analysis of an application starts with the determination of its different actors. A
study of the interaction of the system with its external environment made it possible to
reduce mainly:
• Models :
– Participants :
∗ Patient : patient is the owner of the EHR(electronic health record) can
access his own EHR but cannot create it but he can modify only some
fields related to his habits and automedication in his EHR..
∗ Provider : can be (Doctor, Pharmacist, insurer) he can access certain
data of patient’s EHR, can modify EHR or insert certain data of the
EHR(especially when he got permission from the patient).
∗ Insurer : He can READ certain data of patient’s EHR, but cannot modify
or insert(after having permission from the patient).
– Assets :
∗ Electronic Health Record (EHR) :
· Owned by the patient, contains all of the Patient medical data, pro-
vided by the providers or by himself.
14
2.3 Requirements specification
2.3.1 Functional requirements
What is the purpose of our system? We group these needs into the following points:
• Allows patient to access his complete and accurate EHR and share them in the
ledger.
• Allows patient to access his medical health history.
• Allows doctor to access his Patient’s EHR and update it with new data when he’s
granted permission.
• Real time information sharing and transparency.
• the user can view the encrypted transactions in the ledger.
• Extract data from the database in real time and visualize them in form of charts to
clarify data analysis.
• Strengthening the relation between patients and providers.
2.3.2 Non-Functional requirements

In addition to the functional requirements mentioned above, to respond well to user needs,
the system must be able to provide the following non-functional requirements:
• Ergonomics and usability: The application will provide a friendly-user interface and
simple to use.
• Security: Access to information is only possible if the patient wishes to share it

by the privileges rights and access rights. So any user will go through a phase of
authenticity to consult the services offered by the platform.
• Extensibility: The architecture of the application will allow evolution and mainte-
nance (add or delete or update) at its different modules in a flexible way.
2.4 Project management with Scrum

2.4.1 Product backlog
The Scrum methodology is based on product, release, sprint and defect backlogs. The
product Backlog contains the list of features that the client asks the team to perform.
Items in the Backlog are called stories (user stories). A story must have a business
purpose, in addition the backlog must generally justify added value.
The table below summarizes the product backlog of our application :
15
Id Feature Id story User story
1.1 As a user, I want to register
1.2 As a patient, i want to authenticate with Labes card
1.3 As a patient, i want to read my EHR
1.4 As a patient, i want to update my EHR
1.5 As a patient, i want to grant acces to a provider
1.6 As a provider, i want to authenticate
1 Actor access management
1.7 As a doctor, i want to read my patient’s EHR
1.8 As a doctor, i want to update my Patient’s EHR
1.9 As a Pharmacist, i want to read patient’s EHR
1.10 As a Pharmacist, i want to update Patient’s EHR
1.11 As an insurer, i want to read patient’s billing informations
1.12 As an insurer, i want to update Patient’s EHR
2.1 As a patient, i want to submit readEhr transaction
2.2 As a patient, i want to submit updateEhr transaction
2.3 As a patient,i want to submit grantAccess transaction
As a doctor, i want to submit readEhr transaction
2.4
2 EHR access management on a patient record
As a doctor, i want to submit updateEhr transaction
2.5
on a patient record
As a Pharmacist, i want to submit readEhr transaction
2.6
on a patient record
As a Pharmacist, i want to submit updateEhr transaction
2.7
on a patient record
As an insurer, i want to submit readBillingInfo transaction
2.8
on a patient record
As an insurer, i want to submit updateEhr transaction
2.9
on a patient record
As an administrator, i want to generate participants
3.1
certificates
3 Transactions cryptography
As a provider, i must write on patient EHR when we
3.2
both present our certificates (multisignature technique)
As an administrator, i must check if the smart contract
3.3
is working
4.1 As a miner, i want to validate transactions
4 Transaction validation As a miner, i want to mine validated transactions into
4.2
blocks
As a peer admin, i want to check if all nodes are running
4.3
the smart contract
As a peer admin, i want to create the business network
5.1
application file
5 Deployment and testing
As a peer admin, i want to install the business network
5.2
application on the fabric network
As a peer admin, i want to start or upgrade the business
5.3
network application
Table 2.1: Product Backlog
16
2.4.2 Sprints planning
At this point, we have completed and organized the Product Backlog. We then performed
the meeting plan whose purpose is to build the sprint backlog based on the product backlog
produced by the Product Owner. Subsequently, we set the projected work times to be
performed during each sprint. During our project, we divided the work into four sprints.
The table below shows the planning of different sprints :
Sprint No. Tasks Description Estimation/Hour

-Study of the development
environment.
-Study of the architecture of
the application.
Documentation and -Research on the technologies
Sprint 0 1080
realization of work plans (Blockchain
, smart contract and
hyperledger)
-Realization of the UML diagrams.

-Realization of Front-end.
Conception and realization
Sprint 1 -Realization of back-end 360
of the front-end / back-end
(Register, login and logout).
-Creating models
realization of the blockchain (Patient, Providers and EHR).
Sprint 2 720
based back-end -Creating smart contract logic.
-Creating transactions.
Table 2.2: Sprints planning
2.5 Analyse of needs

This phase represents the ’functional’ view of the system architecture. In what follows,
we identify the main use cases of our application. This identification will be followed by
a detailed description of each of them.
2.5.1 Use case diagrams

A use case diagram captures the behavior of a system, subsystem, class, or component as
an external user sees it. It splits the functionality of the system into coherent units, use
cases, making sense to the actors. The use cases make it possible to express the need of
the users of a system, so they are a user-oriented vision of this need unlike a computer
vision. To clarify the use case and facilitate its understanding we decided to divide it by
actor:
• Doctor
• Patient
• Pharmacist
17
• Insurance (example CNAM)
In the rest of this section we will present the different use case diagrams that we designed
to illustrate the different interactions between the different actors and our system. To
prevent the repetition of some refinements and to make it small and simple we will get
rid of some refinements that may seem obvious or repetitive.
Global use case diagram

The global use case gives a general view of the system functionality and the users inter-
actions with it, as presented in figure 2.1
Figure 2.1: Global use case diagram
Refinement of the use case "Update EHR"(figure 2.1):

Use case : Update EHR.
Actor : Patient, Provider.
Precondition :
• The actor is authenticate.
• The actor click the button.
Post condition :
• The actor accesses to a form.
Main scenario :
• A form to be filled will be displayed to the actor where he insert data into patient
EHR after verifying the patient.
Exceptions :
• The actor is not identified.
• The Patient doesn’t exist.
18
• The actor didn’t get permission from the patient(in case you are provider).
Refinement of the use case "Read EHR"(figure 2.2):

Use case : Read EHR.
Actor : Patient, Provider.
Precondition :
• The actor is authenticated.
Post condition :
• The actor accesses to a form where he can see the patient medical.
Main scenario :
• A form will be displayed where the actor can see the patient electronic health record
data after the patient is verified.
Exceptions :
• The actor didn’t get permission from patient(in case you are provider).
Refinement of the use case "Grant access"(figure 2.3):

Use case : Grant access.
Actor : Patient.
Precondition :
Post condition :
• The actor can access to a form.
Main scenario :
• A form will be displayed where the patient can enter id of the provider he wishes
to give access(READ/WRITE).
Exceptions :
• The system will display an error in case the id of the provider is not correct.
19
Doctor use case diagram
Figure 2.2: Doctor use case diagram
Refinement of the use case "Create doctor account"(figure 2.2):

Use case : Create doctor account.
Actor : Doctor.
Precondition :
• The actor click the link.
Post condition :
Main scenario :
• A form to be filled will be displayed to the actor where he can register his doctor
account.
Exceptions :
Refinement of the use case "Update EHR"(figure 2.2):

Use case : Update EHR.
Actor : Doctor.
Precondition :
• The actor click the button.
20
Post condition :
Main scenario :
• A form to be filled will be displayed to the actor where he insert data into patient
EHR after verifying the patient.
Exceptions :
• The actor didn’t get permission from the patient.
• When the transaction is not validated and registered in the ledger.

Actor : Doctor.
Precondition :
Post condition :
• The actor accesses to a form where he can see the patient medical.
Main scenario :
data after the patient is verified.
Exceptions :
• The actor didn’t get permission from patient.

Refinement of the use case "Make consultation"(figure 2.2):
Use case : Make consultation.
Actor : Doctor.
Precondition :
• The actor have access to patient EHR.

Post condition :
• The actor accesses to a form where he can insert data.
21
Main scenario :
• A form will be displayed where the actor can insert data to his patient EHR after
verification that he have permission from the patient.
Exceptions :
• The patient doesn’t exist.
• The actor didnt get permission from patient.
Refinement of the use case "define billing consultation"(figure 2.2):

Use case : define costs.
Actor : Doctor.
Precondition :
Post condition :
Main scenario :
verifying the patient and that he have permission from him.
Exceptions :
• The actor didnt get permission from patient.
22
Patient use case diagram
Figure 2.3: Patient use case diagram
Refinement of the use case "Describe habits"(figure 2.3):

Use case : Describe habits.
Actor : Patient.
Precondition :
Post condition :
Main scenario :
• A form will be displayed where the patient can enter new data to his existing EHR.
Exceptions :

Refinement of the use case "Register automedication"(figure 2.3):
Use case : Register automedication.
Actor : Patient.
Precondition :
Post condition :
23
Main scenario :
• A form will be displayed where the patient can enter new data in his existing EHR.
Exceptions :

Refinement of the use case "Grant access"(figure 2.3):
Use case : Grant access.
Actor : Patient.
Precondition :
Post condition :
• The actor can access to a form.
Main scenario :
• A form will be displayed where the patient can enter id of the provider he wishes
to give access(READ/WRITE).
Exceptions :
• The system will display an error in case the id of the Provider is missing or not
correct.

Actor : Patient.
Precondition :
• The actor presses a link.

Post condition :
• The actor accesses to his own medical record.
Main scenario :
• A form will be displayed where the actor can see his own medical record.
Exceptions :
24
Refinement of the use case "Create patient account"(figure 2.3):

Use case : Create patient account.
Actor : Patient.
Precondition :
• The actor is authentified.
• The actor presses a link.
Post condition :
Main scenario :
• A form will be displayed where the actor can fill it to create his account.
Exceptions :
• Patient account already exist.
25
Pharmacist use case diagram
Figure 2.4: Pharmacist use case diagram
Refinement of the use case "Create Pharmacist account"(figure 2.4):

Use case : Create Pharmacist account.
Actor : Pharmacist.
Precondition :
Post condition :
Main scenario :
• A form to be filled will be displayed to the actor where he can register his Pharmacist
account.
Exceptions :
• Pharmacist account already exist.

Actor : Pharmacist.
Precondition :
Post condition :
• The actor accesses to a form where he can see the patient medicines.
Main scenario :
26
after the patient is verified.
Exceptions :
Refinement of the use case "Sell medicine"(figure 2.4):

Use case : Sell medicine.
Actor : Pharmacist.
Precondition :
Post condition :
Main scenario :
the patient is verified and that he have permission from the him.
Exceptions :
27
Insurer use case diagram
Figure 2.5: Insurance use case diagram
Refinement of the use case "Create Insurer account"(figure 2.5):

Use case : Create Insurer account.
Actor : Insurer.
Precondition :
Post condition :
Main scenario :
• A form to be filled will be displayed to the actor where he can register his Insurance
account.
Exceptions :
• Insurance account already exist.
Refinement of the use case "Read billing information"(figure 2.5):

Use case : Read billing information.
Actor : Insurer.
Precondition :
28
• The actor has access to patient EHR.
Post condition :
Main scenario :
• A form will be displayed showing medicines costs from patient EHR, , and types of
privileges offered to him according to his insurance system, his APCIs, etc ...
Exceptions :
• The patient EHR doesn’t contain the insurance category transaction not registered
neither validated.
• The actor doesn’t have access to patient ehr.
Refinement of the use case "Refund decision"(figure 2.5):

Use case : Refund decision.
Actor : Insurer.
Precondition :
Post condition :
• The actor take a decision about this patient file.
Main scenario :
• A form will be displayed where the actor can select an item to be refunded after
verifying the patient.
Exceptions :
• The actor doesn’t have access to patient EHR.
29
• The patient did not register his insurance category transaction non validated and
non registered in the ledger.
Refinement of the use case "claim processing"(figure 2.5):
Use case : claim processing.
Actor : Insurer.
Precondition :

Post condition :
Main scenario :
• A form will be displayed where the actor can select an item to be claimed after
verifying the patient.
Exceptions :
non registered in the ledger
Refinement of the use case "take prior agreement decision decision"(figure 2.5):
Use case : Refund decision.
Actor : Insurer.
Precondition :

Post condition :
• The actor take a decision about this patient file.

Main scenario :
• A form will be displayed where the actor can see agreement decisions from patient
EHR
Exceptions :
30
non registered in the ledger.
31
2.5.2 Class diagram
The figure 2.6 presents the class diagram of the project:
• Actor class: which contains the id of the actor and composed of Address and
Contact and Idtx since these attributes are common between Patient and provider.
• Provider class: which contains the healthfacility and registrationNumber since

these attributes are common between Doctor, Pharmacien and Insurance.
• Contact class: which contains firstname, lastname, email and phone that compose
the contact attribute in Actor class.
• Adress class: which contains adress, city, state and country that compose the
address attribute in Actor class.
• Patient class: inherits the actor class and contains all the attributes from the actor
class, it also contains affiliation and mutual insurance attributes, also grantaccess,
readEhr and updateEhr methods.
• Doctor class: inherits the actor class and contains all the attributes from the
provider class, it also contains medicalSpeciality attribute and readEhr and upda-
teEhr methods.
• Provider class: inherits the actor class and contains all the attributes from the
actor class and contains healthFacility and registrationNumber attributes.
• Insurer class: inherits the Provider class and contains all the attributes from the
Provider class plus readEhr, updateEhr, validPatientInfo methods.
• Pharmacist class: inherits the provider class and contains all the attributes from
the provider class plus the readEhr and updateEhr methods.
• Transaction class: which contains the id of the transaction since this attribute is
common between PatientTx and ProviderTx classes. it also contains the updateRe-
cord method.
• MedicalRecord class: It is the asset of the patient, contains medical history

of the patient (Id, LastConsultation, allergies, lastDispensiation, automedication,
hospitalisation, assuranceRecord), associated with the Patient class.
• Automedication class: It contains form information answered by the patient.

and it compose the MedicalRecord class.
• Consultation class: It contains form information answered by the doctor. and it

compose the MedicalRecord class.
• Dispensiation class: It contains form information answered by the Pharmacist .

• Medecine class: It contains id number (noId) and name attributes and compose
the Dispensiation class.
32
• InsuranceRecord class: It contains form information answered by the Insurance.
• Hospitalisation class: It contains form information answered by the patient, Doc-

tor(entryDate, address, medicalActs, leavingDate, hositalAddress), composed of the
Address class and compose the MedicalRecord class.
33
34
2.6 Application architecture
Figure 2.7: Application architecture
• Patient
1. The patient can register to the application with the labes card.
2. The application submits a transaction to the blockchain network processing.
3. The blockchain network sends a response to the application for the Patient to
see in the interface after validation done by miners.
• Provider
1. The provider can register to the application.

2. The application submits a transaction to the blockchain network processing.
3. The blockchain network sends a response to the application for the Patient to
consult in the interface.
• Labes Card
– Its an electric card launched April 22 2019 by CNAM organism, It’s the new
Tunisian electronic health insurance card that will be used by patients in
september 2019, no more details are spread to the public and it’s mechanism
is still unknown, We just have a picture of it.
2.7 Technological choice

2.7.1 Software environment
Platform development required the use of the following software :
• Visual Studio Code : is a lightweight but powerful source code editor which runs
on your desktop and is available for Windows, macOS and Linux. It comes with
built-in support for JavaScript, TypeScript and Node.js and has a rich ecosystem
of extensions for other languages (such as C++, C sharp, Java, Python, PHP, Go)
and runtimes (such as .NET and Unity).
35
2.7.2 The technologies used
The frameworks and technologies that we used during the realization of our project are
as follows :
• Hyperledger fabric : Hyperledger is an open source collaborative effort created to
advance cross-industry blockchain technologies. It is a global collaboration, hosted
by The Linux Foundation, and IBM including leaders in finance, banking, Internet
of Things, supply chains, manufacturing and Technology.[6]
• Node.js : Node.js is an open-source, cross-platform JavaScript run-time environment
that executes JavaScript code outside of a 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. Consequently, Node.js represents a "JavaScript everywhere" paradigm,
unifying web application development around a single programming language, rather
than different languages for server side and client side scripts.[7]
• Angular : Angular is a platform that makes it easy to build applications with the
web. Angular combines declarative templates, dependency injection, end to end
tooling, and integrated best practices to solve development challenges. Angular
empowers developers to build applications that live on the web, mobile, or the
desktop.[8]
• MongoDB : is a Nosql document database with the scalability and flexibility that
you want with the querying and indexing that you need, MongoDB stores data in
flexible, JSON-like documents, meaning fields can vary from document to docu-
ment and data structure can be changed over time, the document model maps to
the objects in your application code, making data easy to work with, MongoDB
is a distributed database at its core, so high availability, horizontal scaling, and
geographic distribution are built in and easy to use.[9]
• CouchDB : Apache CouchDB lets you access your data where you need it. The
Couch Replication Protocol is implemented in a variety of projects and products
that span every imaginable computing environment from globally distributed server-
clusters, over mobile phones to web browsers.[13]
2.7.3 The languages used

The development languages that we used during the realization of our project are as
follows :
• TypeScript is an open-source programming language developed and maintained by
Microsoft. It is a strict syntactical superset of JavaScript, and adds optional static
typing to the language.
TypeScript is designed for development of large applications and transcompiles to
JavaScript. As TypeScript is a superset of JavaScript, existing JavaScript programs
are also valid TypeScript programs. TypeScript may be used to develop JavaScript
applications for both client-side and server-side (Node.js) execution.[10]
• JavaScript : JavaScript is a light, object-oriented scripting language, mainly known
as the scripting language of web pages. But it is also used in many environments.[11]
36
• HTML : Hypertext Markup Language, usually abbreviated HTML, is the data for-
mat designed to represent web pages. Above all, it allows you to embed hypertext
in the content of pages and relies on a markup language, hence its name.
• Angular 7 : It is a free and open source JavaScript framework that allowed us to

implement the client part of our project. With this framework, we can do automatic
data synchronization between the model and the view. It is intended to simplify
the creation of progressive Web applications[12]
2.8 Sprint backlogs

The third sprint consist on studying the project in many aspects such as requirements,
analysis and features, designing the architecture of the platform and brainstorming for
advanced features and functional and non functional needs.
This will come in handy in the next sprint as it will simplify technical work progress.
2.8.1 Tasks done

• Identifying actors and methods.
• Requirements specifications.
• Developing diagrams(class and use case diagrams).
2.8.2 organization
Product owner : Mr. Nasser Mseddi.
Scrum master : Mrs. Syrine Sahmim / Mr. Nasser Mseddi.
2.8.3 Acceptance Criteria

Mrs. Syrine Sahmim and Mr. Nasser Mseddi as a Scrum master and Product owner
respectively accepted these specifications of requirements and gave us some recommenda-
tions to go in depth in the realization of the project using these diagrams.
2.9 Conclusion
We presented the backlog of the product specifying the different functions that compose
it. We also detailed the functional requirements and non functional and presented project
functionality and actors by use case diagrams and the class diagram. The next chapter is
dedicated to the realization of our solution.
37
Chapter 3
Release 1 : Digital workspace
3.1 Introduction
In this chapter, we will begin the detailed description of our first Sprint, which is titled
"Front-end/back-end" of the Sprint Backlog, using the various conceptual tools of the
project. We are content to present here some use case diagrams.
3.2 Sprint 1
The goal of the first sprint is to develop a functional dashboard for patient, and another
dashboard for doctor
3.3 Sprint backlog
38
User
Id Story/ Id User Story/ Fonctionali-
Id Features Estimation/H
Story Fonction- Story ties
alities
Creating Angular HTML
component for the
As a user 1.1.1 24
1.1 data display
i want to
(read EHR)
read my EHR
Front-end Creating Angular typescript
1
management 1.1.2 component for the 24
data display(read EHR)
As a user 1.2.1 component for inserting 48
1.2
i want to insert data(update EHR)
data into my Creating Angular typescript
EHR 1.2.2 component for inserting 24
data(update EHR)
As a user 1.3.1 24
1.3 component for giving access
i want to give
Creating Angular typescript
access to my
1.3.2 component for 24
EHR(patient)
giving access
As a user
i should be Creating HTML home
able to component with links to
1.4 1.4.1 48
navigate other interfaces(read, insert
the platform give access)
easily.
As a user 2.1.1 48
component for registering.
2.1 i should be
Creating controller
able to
Back-end responsible for registering
2 register 2.1.2 48
management user and inserting to
mongodb
2.1.3 Test and validation 1
As a user 2.2.1 48
2.2 component for login
i should be
Implementation of Token
able to
Authentication Service
authentificate
(JWT) by implementing
2.2.2 48
a filter that verifies each
query and the validity of
its Token
As a user 2.3.1 24
2.3 component for logout
i want to log-
Creating controller
out
responsible for deleting the
2.3.2 48
token and redirecting
to login page
Table 3.1: Sprint backlog of sprint 1 39

3.4 Analysis and specification of needs
In this section, we will analyze and specify the functional requirements for the first sprint
of our application
3.4.1 Identification of sprint 1 actors

Patient and Providers : They represents the main actors for the solution, they have
the role of navigating, registering and authenticating.
3.4.2 Reused use cases

To simplify our use cases, we will continue by analyzing diagrams, detailed use cases
actors in our system.
Detailed description of the "Authentication" use case
The system must allow all users to authenticate.
Figure 3.1: Authentication use case diagram
Textual Description of the "Authentication" use case
Objective Authentication
Actor Patient and Providers
Summary Authentication phase
Precondition Actor needs to consult digital workspace
Postcondition Actor logged in successfully
1-The system display the main page(login).
2-The actor fill out the email the password fields.
3-The System verify the user inputs.
Main scenario
4-The System redirect the actor to the dedicated page if the
input is correct else it redirect him to the login page again so
he can fill the fields again
Table 3.2: Authentication use case
40
Detailed description of the "Register" use case
The system must allow all actors to register
Figure 3.2: Register use case
Textual Description of the "Register" usecase
Objective Register
Summary Register phase
Precondition Actor needs to consult digital workspace
Postcondition Actor registered successfully
1-The system display the main page(login).
2-The actor presses the register
button.
3-The system redirect to the dedicated. page.
Main scenario
4-The actor fills the inputs.
5-The system verify if the email is unique.
6-The system redirect to the login page
if the input is correct else it shows an error.
Table 3.3: Register use case
41
Detailed description of the "logout" use case
The system must allow all users to logout.
Figure 3.3: Logout use case
Textual Description of the "logout" usecase
Objective Logout
Summary Logout phase
Precondition Actor needs to consult digital work space
Post condition Actor Logged out successfully
1-The actor presses the logout button.
Main scenario
2-The system redirect the actor to the login page and removes the token.
Table 3.4: Logout use case
42
3.4.3 Conception
Authentication module
For all actors of this platform they need to authenticate. The authentication interface
displays a form with these authentication parameters (email, password). Then the Patient
or Provider fills the form with his email and password then these 2 parameters will be
sent to the controller responsible for authentication and then verifies if the user exist or
not from the mongoDB database. if the respective actor successfully log in, the system
generate a token and send it with the user while he gets redirected to his dedicated inter-
face (PatientDashboard/DoctorDashboard).
If the informations is not correct the controller will display an error message on the au-
thentication interface.
Figure 3.4: Authentication sequence diagram
43
Register actors module
before the authentication if the Patient or Provider wishes to register, he will find a
hypertext to redirect him to registerform page in which he can register his account after
filling the displayed form by all the required fields for it to be submited successfully.
Figure 3.5: Register sequence diagram
Logout module
After the authentication, the actor will be redirected to the main page (PatientDashboard
/DoctorDashboard). The actor wants to logout, he clicks on logout button the controller
will clear the context and destroy the token received with the request as well, in the end
the actor will be redirected to the authentication interface.
Figure 3.6: Logout sequence diagram
44
3.4.4 Realization
In this section, we will present the different phases of realization of this sprint.
Authentication
The figure 3.7 represents the authentication form and the fields that need to be filled in
order to login (email and password) so the patient or the provider access the Dashboard.
Figure 3.7: Authentication form
Once you are verified and logged in the system will redirect you to the home page of
the dashboard.
45
Figure 3.8: Home page
Registering
The image (figure 3.9) shows the registration form where you need to fill the form in order
to successfully register.
Figure 3.9: Registeration page
Once registered the actor is then redirected to login page to authenticate.
46
Navigating through the patient dashboard
The images shows the different routes you can take once logged in home page.
Display health record : Where patient can access and read his EHR.
Figure 3.10: Display health record page
Insert into health record : Where patient can insert data into his EHR.
Figure 3.11: Insert into health record page
47
Give access to health record : where patient can give access to a provider.
Figure 3.12: Give access to health record page
Navigating through doctor dashboard

For the doctor once logged in, before accessing a patient EHR he needs to fill out a form
where he need to provide patient id and he must have access from the patient.
Home page
Figure 3.13: Doctor home page
48
Doctor Display health record : The doctor need to provide patient id before
proceeding in order to verify if the patient exist.
Figure 3.14: Doctor Display health record page
Doctor insert to health record : The doctor need to provide patient id before
proceeding in order to verify if the patient exist.
Figure 3.15: Doctor insert to health record page
After verifying the patient he proceed to the main page.
49
Figure 3.16: Doctor insert to health record page 2
3.5 Organization
3.6 Acceptance criteria

respectively accepted these interfaces and gave us some recommendations to do in order
to make the interface more appealing and some new features .
3.7 Conclusion
This chapter allowed us to describe the sprint of this release by mentioning the sprint 2
backlog, althought we have four actors, we could only manage to create two dashboards
for Patient and Doctor due to time shortage.
In the next chapter, we will present the next and final release of this project.
50
Chapter 4
Release 2: Chaincode Development
4.1 Introduction
This chapter will present the second release that contains the work dedicated to develop
the smart contract needed for the network.
4.2 Sprint 2
The goal of this sprint is to develop Patient smart contract by giving him access to read
or write his EHR and the ability to give access to a provider.
4.3 Sprint backlog

The following table presents a description for the second sprint Backlog .
51
User
Id Id Estimation
ID Feature Story/Fonctio- Tasks
Story Task /H
nalities
Creating queries
As a patient, 1.1.1 24
needed
1.1 i want to read
Creating logic
my EHR
1.1.2 to verify if i 48
Back-end management have access
1 (Blockchain and smart Creating
1.1.3 24
contract) transaction
Creating logic
that grants to the
As a patient, 1.2.1 48
patient the ability
1.2 i want to grant
to give access
access to a
1.2.2 Creating queries 24
provider
Creating
1.2.3 48
transaction
Creating logic to
As a patient, 1.3.1 to verify if i have 48
1.3 i want to update access
my EHR Creating
1.3.2 48
transaction
1.3.3 Creating queries 24
Testing and
1.4 1.4.1 Testing 24
verifying
Table 4.1: Sprint 2 product backlog

4.4.1 Identification of the actors in sprint 2:
The patient: The patient is the main actor of this sprint, we will focus on his role in
the project.
4.4.2 Reused use case

The second sprint of our application is analyzed by the functional requirements presented
by the use case diagram shown in the figure below.
52
Figure 4.1: Sprint 2 use case diagram
Textual description of the "Read EHR" use case
Objective Read EHR

Actor Patient
Summary display phase
Precondition Patient need to consult work space.
Post condition EHR displayed successfully
1-The Patient presses the Display EHR button.
Main scenario
2-The system redirect the Patient to the page and displays the EHR.
Table 4.2: Patient Read EHR use case
Textual description of the "Update EHR" use case
Objective Update EHR

Actor Patient
Summary Insert phase
Post condition data inserted successfully
1-The Patient presses the insert to EHR button.
Main scenario 2-The system redirect the Patient to the page and displays a
form to be filled.
Table 4.3: Patient insert to EHR use case
53
Textual description of the "Grant access" use case
Objective Grant access

Actor Patient
Summary Grant access phase
Post condition Access granted successfully
1-The Patient presses the grant access button.
Main scenario
2-The system redirect the Patient to the page and a form displays.
Table 4.4: Patient grant access use case
4.4.3 Realization
In this section we are going to present the implementation of the sprint
Patient Read EHR

Once the Patient clicks the display EHR link, The system send a request to the restserver
to collect Patient medical data from the ledger(CouchDB database) through a transaction,
then the data is displayed in the interface, Although we still haven’t implemented it in
the front-end.
Patient Update EHR

Once the Patient clicks the insert to EHR link, Then he needs to fill out a form that
contains automedication and describe habits inputs, Then the system send a request to
the restserver to insert Patient new data to the ledger(CouchDB database) through a
transaction.
Patient Grant access

Once the Patient clicks the Grant access to EHR link, Then he needs to choose the type
of access and fill out provider id in order to verify if he exist, Then after submitting a
request is sent to the restserver to grant access to the provider throught a transaction.
4.5 Organization
4.6 Acceptance Criteria

respectively accepted these features and their prototype version although they haven’t
been implemented in the interface yet .
54
4.7 Sprint conclusion
At the end of this sprint, the tasks planned in the Sprint Backlog have been developed
tested and validated. Although they are still work in progress due to time shortage, we
still managed to validate the transactions.
4.8 Sprint 3
The goal of this sprint is to develop Doctor smart contract by giving him the ability to
read or write patient EHR if he have permission from the patient.
4.9 Sprint 3 backlog
User
Id Id Estimation
ID Feature Story/Fonctio- Tasks
Story Task /H
nalities
Creating queries
As a Doctor, 1.1.1 24
needed
1.1 i should be able
Creating logic
to read my Patient’s
1.1.2 to verify if he 48
EHR
back-end management have access
1 (Blockchain and smart Creating
1.1.3 24
contract) transaction
Creating logic
As a Doctor, 1.2.1 needed to verify 96
1.2 i should be able if he have access
to insert and 1.2.2 Creating queries 24
update to my Creating
1.2.3 48
Patient’s EHR transaction
Testing and
1.4 1.4.1 Testing 24
verifying
Table 4.5: Sprint 3 product backlog

4.10.1 Identification of the actors in sprint 3:
The doctor : The doctor is the main actor of this sprint, we will focus on his role in
this project.
4.10.2 Reused use case

The third sprint of our application is analyzed by the functional requirements presented
by the use case diagram shown in the figure below.
55
Figure 4.2: Sprint 3 use case diagram
Textual description of the "Read EHR" use case
Objective Read EHR

Actor Doctor
Summary display phase
Precondition Doctor need to consult work space.
Post condition EHR displayed successfully
1-The doctor presses the Display EHR button.
2-The system redirect the doctor to the Display EHR page.
3-The doctor provides patient id in order to verify
Main scenario
if the patient exist.
4-Once the patient is verified
the doctor is redirected to the main page
Table 4.6: Doctor Read EHR use case
Textual description of the "Update EHR" use case
Objective Update EHR

Actor Doctor
Summary Insert phase
Precondition Doctor need to consult work space.
Post condition data inserted successfully
1-The doctor presses the insert to EHR button.
2-The system redirect the doctor to the insert into EHR page.
3-The doctor provides patient ID in order to verify
Main scenario
if the patient exist.
4-Once the patient is verified
the doctor is redirected to the main page
Table 4.7: Patient insert to EHR use case
56
4.10.3 Realization
In this section we are going to present the implementation of the sprint
Doctor Read Patient’s EHR

Once the Doctor Presses the link Read EHR, The doctor is redirected to the Read EHR
page, Then the Doctor needs to fill out the Patient ID in order to verify if he exist and
if the Doctor have access to the Patient EHR, Once the patient is verified and the form
is submitted a request is sent to the restserver to collect medical data about the Patient
through a transaction from the ledger(CouchDB database), then the data is displayed in
the interface.
Doctor Updates Patient’s EHR

Once the Doctor Presses the link Insert to EHR, The doctor is redirected to the Insert to
EHR page, Then the Doctor needs to fill out the Patient ID in order to verify if he exist
and if the Doctor have access to the Patient EHR, Once the patient is verified, The doctor
needs to fill out a form that contains consultation and billing consultation fields a request
is sent to the restserver to insert medical data about the Patient through a transaction
into the Ledger (CouchDB database).
4.11 Organization
4.12 Acceptance Criteria

respectively accepted these features and their prototype version although they haven’t
been implemented in the interface yet .
4.13 Sprint conclusion

At the end of this sprint, the tasks planned in the Sprint Backlog have been developed
tested and validated. Although these are also still work in progress due to time shortage,
we still managed to validate the transactions.
4.14 Conclusion
In this last chapter, we have detailed the current tasks of our second release, About our
report, we will present the general conclusion and possible perspectives.
57
Conclusion
In this report, we have presented, in the first place, the general context of the project
that took place within DAR BLOCKCHAIN. Our project is to create a digital platform
to strengthen the relation between patients and providers (Doctors, Pharmacies, Insur-
ance) in order to help the development of Tunisian health care system. Our project has
as added values compared to the current health care system, a new form of security and
integrity which was possible with the Blockchain technology and the hyperledger fabric
tool, computerized medical data that cannot be lost or tempered with, paperwork and
physical records are not much needed anymore.
We did a detailed study of the product. We also discussed the methodology applied for
good management of our project.
We exposed the planning of our work that allowed us to detail the different tasks of our
solution by specifying the deadlines and the order of priority of each one.
Then, we presented the product backlog of our solution as well as the functional and
non-functional requirements. We also discussed the analysis of these needs. And in the
end, we presented our application detailing each sprint.
The phase of the specifications elaboration and the in-depth study on the blockchain has
required a considerable effort to search for information necessary to deduce our solution.
The period we have devoted to learn how to manipulate the hyperledger fabric tool and
how exactly the blockchain works was very critical as they required considerable time
in order to know the many different notions. But, we were able in the end to familiar-
ize ourselves with it. It was a completely new technology with a new experience, as we
struggled to find documentations and help from the internet it became harder and harder
but thanks to the advises we received from the DAR BLOCKCHAIN engineers and our
advisor we managed to bypass the obstacles.
Thanks to our experience at DAR BLOCKCHAIN, we learned from a personal point of
view how to manage our project in a methodical and organized way. This work has been
beneficial to us in that it allowed us to put into practice our theoretical knowledge acquired
throughout our training at the High Institute of Information Technology and Communi-
cation. It also allowed us to deepen our knowledge and appreciate the importance of a
project management methodology. Our project is therefore a source of technical, cultural,
personal and human enrichment.
The implementation phase of our solution also required a great effort to satisfy the needs
of DAR BLOCKCHAIN and to make a product deliverable on time. And to better realize
this rich work we will continue the project even after the internship deadlines.
Communication was a very important factor in this phase to prepare and implement the
desired application. We encountered some challenges during the implementation phase of
our application. But despite everything, we were able to find solutions at the right time
so not to delay our project. The relationship between trainees and engineers has been
very rewarding and user-friendly. The climate of trust and respect with the superiors was
58
actually favorable to achieve better productivity. Each stage of our project required effort
and thorough research.
59
Bibliography
[0] title = CryptoInvestingInsider.com, year = 2018, url = OptionStrategiesInsider.com,

urldate = 2018-11-10.
[1] Blockchain technology: Beyond bitcoin. author=Crosby, Michael and Pat-

tanayak, Pradan and Verma, Sanjeev and Kalyanaraman, Vignesh and others, jour-
nal=Applied Innovation, volume=2, number=6-10, pages=71, year=2016.
[10] https://www.typescriptlang.org/.
[11] https://www.exoplatform.com/fr/.
[12] https://www.developpez.com/actu/170633/angular-5-0-est-disponible-la-nouvelle-
version-du-framework-javascript-de-google-veut-faciliter-la.
[13] http://couchdb.apache.org/.
[2] Blockchain: Blueprint for a new economy. author=Swan, Melanie, year=2015, pub-
lisher=" O’Reilly Media, Inc.".
[3] author = http://whitepaper.embleema.com, title = Embleema, year = 2018, url =

http://whitepaper.embleema.com, urldate = 2018-11-10.
[4] author = Dr. Abdullah Albeyatti, title = https://medicalchain.com/Medicalchain-

Whitepaper-EN.pdf, year = 2018, url = http://whitepaper.embleema.com, urldate
= 2018-11-10.
[5] author = https://medrec.media.mit.edu/, title = Medrec, year = 2018, url =

https://medrec.media.mit.edu/, urldate = 2018-11-10.
[6] https://www.hyperledger.org/.
[7] https://en.wikipedia.org/wiki/node.js.
[8] https://angular.io/docs.
[9] https://www.mongodb.com/what-is-mongodb.
60

Template Final Rapport PFE Latex 85 Copy

Uploaded by

Document Information

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

Template Final Rapport PFE Latex 85 Copy

Uploaded by

Copyright:

Available Formats

Republic of Tunisia

Ministry of Higher Education and Scientific

End of study report

Computerized and shared medical records

Performed within Dar Blockchain

Defended on May 25th 2019 in front of Jury composed of:

President: Mr. Khaled FOURATI, Chief Operating Officer, Innov-alliance-tech

Academic year: 2018-2019

End of study report

Computerized and shared medical records

Performed within Dar Blockchain

Authorization to submit the report of the End of Studies Project:

Professional Advisor: Academic Advisor:

Keywords: Patients, Providers, Electronic Health Record (EHR), blockchain ,

2 Analysis and specification of requirements 14

3 Release 1 : Digital workspace 38

4 Release 2: Chaincode Development 51

1.1 Blockchain logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Global use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Authentication use case diagram . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 Sprint 2 use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

1.1 Sprint 0 backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Sprint backlog of sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Sprint 2 product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Our project can be summarized in:

• Research on Hyperledger fabric.

1.2 Project context

• Mission and vision

1.2.2 Problem context

1.2.3 Project goal

1.2.5 Proposed solution

The advantages of the solution

• Multi signature Algorithm : Any changes to the electronic health record(EHR)

• Anonymity : Providing limited and permissioned access to a plethora of data types,

• Integrity and authenticity : Warranting inviolability and immutability of EHR Ac-

• Transactions tracking and anti-corruption system : By digitizing health records and

1.2.6 Project description/Features specifications

• The system will be implemented using a permissioned-Blockchain (Hyperledger Fab-

• Data security will be implemented using a double encryption mechanism (symmetric

• EHR will be held in a centralized data system in an encrypted format, Blockchain

• - The system should provide the following features:

– Patient has Read access to his entire EHR.

• Explore further Derivatives of Blockchain.

• Ledger: A shared and distributed history of all transactions and balances.

• Mining/Miners: In Bitcoin, mining is the process of generating a new legitimate

• Consensus: A consensus algorithm is the mechanism by which all nodes in the

• Secure Cryptographic Hash Functions: A secure cryptographic hash function is a

Figure 1.1: Blockchain logo

• Version: The version of block validation rules it follows.

• Timestamp: The Unix epoch time the block was mined.

• Data: data contained within the Block.

Figure 1.2: Hyperledger logo

1.3.3 Pros and cons

• Energy consuming and high computation time.

• Size of the network.

– Medicalchain uses blockchain technology to create a user-focused electronic

– A novel, decentralized record management system to handle EHRs, using

1.3.5 Added value to the solution

1.4 Project management methodology

1.4.1 Adapted methodology: Agile

1.4.2 The "SCRUM" method

• Improve team productivity.