HealTech PFE 2022 2023

MEMOIRE DE FIN D'ETUDES
Présenté pour l’obtention du diplôme d’Ingénieur d’Etat
FILIERE : Génie Informatique
SPECIALITE : Systèmes d'Information d'Aide à la Décision
Par : -EOC MADANI Mahmoud Bader Eddine

-EOC MOKKEDEM Miloud
Thème
Développement d’une plateforme de partage des dossiers médicaux

sur une blockchain privée
Soutenu le 31-Mai-2023 devant le jury composé de :
Président : COL AMAROUCHE Idir Amine HCA/1°RM
Membre : CDT BENKHADDRA Ilyas IRD-DAT
Rapporteur Critique : CNE BOULAHIA Said Yacine EMP
Promoteur (s) : LtCol KENAZA Tayeb EMP
COL ZAIDI Abdelhalim EMP

Remerciements
En préambule à ce travail,
Pour nous avoir permis d’être ce que nous sommes devenus aujourd’hui, pour la
force et le courage qu’il nous a donné afin de terminer ce travail, nous remercions le
SEIGNEUR des mondes par qui tout est possible, Allah le tout Miséricordieux.
Nous tenons à adresser notre gratitude et nos sincères remerciements à nos encadrants
Lt-Col. KENAZA Tayeb et Col. ZAIDI Abdelhalim. Nous les remercions pour la
confiance qu’ils nous ont témoigné en nous proposant ce sujet, leur disponibilité, leur
patience, leurs conseils et directives très instructives. Nous les remercions énormément
pour l’autonomie qu’ils nous ont laissé tout en nous aiguillant sur des prises de réflexions
riches et porteuses.
Nos vifs remerciements vont également aux membres du jury pour l’intérêt qu’ils ont
porté à notre travail en acceptant de l’examiner et de l’enrichir par leurs propositions.
Nous remercions aussi tous les officiers de la Brigade Élèves pour l’encadrement qu’ils
nous ont garanti le long de notre cursus au sein de l’École Militaire Polytechnique (EMP).
Enfin, nous remercions tout le personnel du département Informatique ainsi que nos
enseignants pour la qualité de la formation qu’ils nous ont prodiguée au cours de ces trois
années passées à l’EMP, pour leurs conseils, leur disponibilité, ainsi que leur patience et
leur encadrement.
Dédicaces
Merci Au Noble Allah Dieu le Tout-Puissant qui m’a donné le courage et la patience
pour réaliser ce travail.

- éJ¯ A¿PAJ.Ó AJ. J£ @Q J» @ YÔ g é<Ë YÒ mÌ '@ -
À ma chère mère, source de tendresse, l’être le plus cher, l’ âme de mon cœur, parfum de
ma vie, toi qui es toute la générosité et magnanimité, tu as été le fondement et le pilier à
chaque étape de ma vie. Aujourd’hui, Ayant terminé un long parcours, je t’exprime mon
profond respect et ma gratitude infinie. Que dieu te garde pour moi.
À mon cher père, mes yeux avec lesquels je vois, mon ami dans les moments difficiles et
les moments de joie, la source de ma détermination. Tu as été le pilier solide sur lequel
j’ai construit ma vie. Aujourd’hui, ayant atteint ce que tu espérais de ton fils, je te
présente avec sincérité ma gratitude pour tout ce que tu as fait pour moi.
A mes merveilleux frères, toujours présents pour me soutenir sans hésitation, à mon
frère Amin, Younes, Hamza et ma sœur Sara, je prie Allah de vous protéger, de vous
guider tout au long de votre vie et de vous remplir de bonheur et de réussite.
À ma deuxième famille, mes chers amis que j’ai eu la chance de rencontrer : Abdelkader,
S.Yacine, Houcine, Zakaria, Lotfi, Aymen, Idris, Sohaib, Tarek, Nacera, Narimane,
Fatiha, Amina, Chahinez et Fatima. Je souhaite exprimer ma gratitude particulière
envers mes amis Lahcen et Lamis. Leur amitié sincère et leur soutien inébranlable ont
été d’une grande valeur tout au long de mon parcours.
Je souhaite également souligner la contribution précieuse de mon binôme, Bader Eddine,

qui m’a apporté un soutien moral sans faille, une patience inébranlable et une
compréhension profonde tout au long de ce projet. Je lui adresse mes vœux les plus
sincères pour une vie comblée de succès et de bonheur.
Je remercie sincèrement du fond du cœur tous ceux qui m’ont connue, qui m’ont
soutenue par leurs mots ou qui m’ont offert un sourire. Je vous suis infiniment
reconnaissante.
Miloud
Dédicaces
Je souhaite exprimer ma gratitude envers le noble Allah , Dieu tout-puissant, qui m’a
accordé le courage, la force et la patience nécessaires pour accomplir ce travail.
Je dédie humblement ce travail à ceux envers qui, quelles que soient les paroles que
j’emploie, je ne pourrai jamais exprimer sincèrement mon amour.
À mes chers parents, à l’homme précieux offert par Dieu, à qui je dois ma vie, ma
réussite et tout mon respect, à mon cher père qui ne cesse de me conseiller, d’encourager
et de soutenir tout au long de mes études.
À la femme qui a souffert sans me laisser souffrir, qui n’a jamais refusé mes demandes et
qui a déployé tous les efforts pour me rendre heureux, ma merveilleuse mère. Que ce
travail soit l’accomplissement de vos souhaits les plus chers et le fruit de votre soutien
infaillible. Merci d’être toujours là pour moi.
À celui qui sait toujours comment apporter la joie et le bonheur à toute la famille, à ma
chère sœur Soumaya pour son soutien, ses encouragements, son humour dans les
moments difficiles et la joie qu’elle a apportée jour et nuit.
À mes adorables frères Abdelghani et Bilal pour leur présence dans ma vie et leur
soutien. Que Dieu les protège et leur accorde chance et bonheur.
À toute la famille, mes oncles, mes tantes, mes cousins et mes cousines. Que Dieu leur
accorde une longue et heureuse vie, remplie d’amour et de réussite.
À toure mes amis, mes chers amis que j’ai eus la chance de rencontrer : Hamza,
Elarousi, Moussa, Mwafak, Issa, Aymen, Ammar et Tedjani.
Sans oublier mon binôme Miloud pour son soutien moral, sa patience et sa
compréhension tout au long de ce projet. Je lui souhaite une vie pleine de prospérité.
À ma deuxième famille, mes chers amis que j’ai eus la chance de rencontrer : Tarek,
Adil, Mohamed, Salah, Ishak, yahia, Adel, Nadji, Abdelmalek, Oussama, Merabet, Djafar
et Mehdi.
À tous les confrères et consœurs de la promotion.
Mahmoud Bader Eddine

Table des matières
Liste des figures xiii
Liste des tableaux xv
Liste des acronymes xvii
Introduction générale 1
I Concepts fondamentaux sur le partage des dossiers médicaux 3

I.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I.2 Données médicales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I.2.1 Différentes catégories de données médicales . . . . . . . . . . . . . . 6
I.2.2 Sources de données médicales . . . . . . . . . . . . . . . . . . . . . 6
I.2.3 Caractéristiques des données médicales . . . . . . . . . . . . . . . . 7
I.3 Dossier de santé électronique (DSE) . . . . . . . . . . . . . . . . . . . . . . 8
I.3.1 Avantages de dossier de santé électronique . . . . . . . . . . . . . . 9
I.3.2 Défis de dossier de santé électronique . . . . . . . . . . . . . . . . . 10
I.3.3 Standards des dossiers de santé électroniques . . . . . . . . . . . . . 10
I.4 Partage des dossiers médicaux . . . . . . . . . . . . . . . . . . . . . . . . . 11
I.4.1 Définition de système de partage des dossiers médicaux . . . . . . 12
I.4.2 Avantages des systèmes de partage de données médicales . . . . . . 12
I.4.3 Défis des systèmes de partage des dossiers médicaux . . . . . . . . . 13
I.4.4 Technolgies support de partage de dossiers médicaux . . . . . . . . 14
I.5 Comparaison et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
I.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
II Blockchain et gestion des dossiers médicaux 23

II.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
II.2 Technologie blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
II.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
ix
EMP Table des matières
II.2.2 Éléments de la blockchain . . . . . . . . . . . . . . . . . . . . . . . 26

II.2.3 Fonctionnement de la blockchain . . . . . . . . . . . . . . . . . . . 29
II.2.4 Types de la blockchain . . . . . . . . . . . . . . . . . . . . . . . . . 31
II.3 Bénéfices de l’utilisation de la blockchain dans la e-santé . . . . . . . . . . 32
II.3.1 Decentralization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
II.3.2 Robustesse / Disponibilité . . . . . . . . . . . . . . . . . . . . . . . 33
II.3.3 Vérifiabilité et immutabilité des données . . . . . . . . . . . . . . . 33
II.3.4 Sécurité et transparence . . . . . . . . . . . . . . . . . . . . . . . . 33
II.4 Système de fichiers interplanétaire (IPFS) . . . . . . . . . . . . . . . . . . 34
II.4.1 Système pair à pair de IPFS . . . . . . . . . . . . . . . . . . . . . . 34
II.4.2 Stockage dans IPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
II.5 Blockchain pour les dossiers de santé électroniques (DSE) . . . . . . . . . . 36
II.5.1 Analyse des études de recherche existantes . . . . . . . . . . . . . . 36
II.5.2 Comparaison et discussion . . . . . . . . . . . . . . . . . . . . . . . 38
II.5.3 Défis et restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
II.6 Délimitation du contexte de travail . . . . . . . . . . . . . . . . . . . . . . 41
II.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
III Conception de la plateforme HealthTech 43

III.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
III.2 Architecture de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . 45
III.2.1 Autorité de santé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
III.2.2 Utilisateurs de la plateforme . . . . . . . . . . . . . . . . . . . . . . 46
III.2.3 Réseau IPFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
III.2.4 Réseau Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
III.3 Fonctionnement de la plateforme . . . . . . . . . . . . . . . . . . . . . . . 50
III.3.1 Inscription des participants . . . . . . . . . . . . . . . . . . . . . . 50
III.3.2 Demande d’autorisation . . . . . . . . . . . . . . . . . . . . . . . . 51
III.3.3 Publication des DSE . . . . . . . . . . . . . . . . . . . . . . . . . . 54
III.3.4 Consultation des DSE . . . . . . . . . . . . . . . . . . . . . . . . . 55
III.4 Réalisation d’une application pour les hôpitaux . . . . . . . . . . . . . . . 56
III.4.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . 56
III.4.2 Modélisation de l’application . . . . . . . . . . . . . . . . . . . . . 59
III.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
IV Réalisation de la plateforme HealthTech 65

IV.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
x
EMP Table des matières
IV.2 Mise en œuvre d’un réseau blockchain . . . . . . . . . . . . . . . . . . . . . 67

IV.2.1 Outils et technologie utilisé . . . . . . . . . . . . . . . . . . . . . . 68
IV.2.2 Déploiement de réseau blockchain . . . . . . . . . . . . . . . . . . . 72
IV.3 Mise en œuvre d’un réseau IPFS . . . . . . . . . . . . . . . . . . . . . . . . 74
IV.4 Prototype d’une application web pour l’autorité de santé . . . . . . . . . . 75
IV.5 Réalisation et test d’une application pour les hôpitaux . . . . . . . . . . . 77
IV.5.1 Outils logiciels exploités . . . . . . . . . . . . . . . . . . . . . . . . 78
IV.5.2 Présentation de l’application web . . . . . . . . . . . . . . . . . . . 79
IV.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Conclusion générale et perspectives 89
Bibliographie 91
Annexes 97
A Contrats intelligents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
B Déploiement du réseau blockchain . . . . . . . . . . . . . . . . . . . . . . . 114
C Application web pour les hopitaux . . . . . . . . . . . . . . . . . . . . . . . 115
xi
Liste des figures
I.1 Architecture centralisée de partage . . . . . . . . . . . . . . . . . . . . . . 15

I.2 Architecture décentralisée de partage . . . . . . . . . . . . . . . . . . . . 16
I.3 Partage des DSE dans le cloud. . . . . . . . . . . . . . . . . . . . . . . . . 17
I.4 Décentralisation dans la blockchain . . . . . . . . . . . . . . . . . . . . . 18
II.1 Structure d’un bloc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

II.2 Fonctionnement de la blockchain. . . . . . . . . . . . . . . . . . . . . . . 29
II.3 Diagramme explicatif de l’algorithme ”preuve de travail”. . . . . . . . . . 30
II.4 Comparaison entre le modèle client-serveur et le modèle pair à pair. . . . 35
III.1 Architecture de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . 46

III.2 Diagramme explicatif des vérifications requises pour l’accomplissement
d’une demande. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
III.3 Diagramme de séquence pour la demande de consultation. . . . . . . . . . 53
III.4 Diagramme de séquence pour la publication des DSE. . . . . . . . . . . . 54
III.5 Diagramme de séquence pour la consultation des DSE. . . . . . . . . . . . 55
III.6 Diagramme des cas d’utilisation de l’application. . . . . . . . . . . . . . . 61
III.7 Modèle conceptuel de données de l’application. . . . . . . . . . . . . . . . 63
IV.1 Comptes blockchain fournis par le simulateur Ganache. . . . . . . . . . . 69

IV.2 Nœud Geth en pleine exécution . . . . . . . . . . . . . . . . . . . . . . . 70
IV.3 Déploiement et du test des comptes blockchain avec Remix. . . . . . . . . 71
IV.4 Scénario de démonstration . . . . . . . . . . . . . . . . . . . . . . . . . . 72
IV.5 Lancement du premier nœud . . . . . . . . . . . . . . . . . . . . . . . . . 73
IV.6 Mise en marche du deuxième nœud . . . . . . . . . . . . . . . . . . . . . 73
IV.7 Lancement du troisième nœud . . . . . . . . . . . . . . . . . . . . . . . . 73
IV.8 Illustration du nœud IPFS en exécution. . . . . . . . . . . . . . . . . . . . 74
IV.9 Interface WebUI pour le statut d’un nœud IPFS . . . . . . . . . . . . . . 75
IV.10 Interface WebUI pour la gestion des données dans un nœud IPFS. . . . . 75
xiii
EMP Liste des figures
IV.11 Interface web pour l’autorité de santé. . . . . . . . . . . . . . . . . . . . . 76

IV.12 Interface web pour l’ajour d’un nouveau centre de santé. . . . . . . . . . . 76
IV.13 Interface pour l’ajout d’un nouveau médecin. . . . . . . . . . . . . . . . . 77
IV.14 Interface pour l’ajout d’un nouveau patient. . . . . . . . . . . . . . . . . . 77
IV.15 Procédure d’importation d’un compte dans MetaMask. . . . . . . . . . . 79
IV.16 Interface web pour la création des DSE. . . . . . . . . . . . . . . . . . . . 80
IV.17 Interface web pour les demandes d’accès au DSE. . . . . . . . . . . . . . . 81
IV.18 Interface web montre le processus de partage d’un DSE. . . . . . . . . . . 82
IV.19 Processus de partage d’un DSE. . . . . . . . . . . . . . . . . . . . . . . . 82
IV.20 Interface web montre la partie de demande d’une consultation. . . . . . . 83
IV.21 Processus de consultation d’un DSE. . . . . . . . . . . . . . . . . . . . . 84
IV.22 Processus d’authentification pour les différents utilisateurs de la plateforme 85
IV.23 Interface web pour l’authentification des utilisateurs. . . . . . . . . . . . . 85
IV.24 Interface web pour la gestion des différents utilisateurs. . . . . . . . . . . 86
IV.25 Interface web pour voir l’ensemble des patients. . . . . . . . . . . . . . . . 86
IV.26 Interface web pour voir les DSE locaux. . . . . . . . . . . . . . . . . . . . 87
IV.27 Interface web pour voir les DSE globaux. . . . . . . . . . . . . . . . . . . 87
xiv
Liste des tableaux
I.1 Comparaison des caractéristiques des réseaux informatique, du cloud com-

puting et la blockchain pour le partage des dossiers médicaux. . . . . . . . 19
II.1 Comparaison des plateformes de partage de DSE basé sur la blockchain . 38
III.1 Structure d’une demande stockée dans la blockchain. . . . . . . . . . . . . 52

III.2 Illustration d’un résumé de DSE . . . . . . . . . . . . . . . . . . . . . . . 55
III.3 API de l’ensemble des fonctionnalités et de leurs méthodes. . . . . . . . . 60
IV.1 Structure d’une demande stockée dans la blockchain. . . . . . . . . . . . . 73
xv
Liste des acronymes
API Application Programming Interface

BEAS blockchain-based EHR Abstract System
CDA Clinical Document Architecture
CID Content Identifier
CDS Clinical Decision Support
CPOE Computerized Physician Order Entry
CRUD Create, Read, Update and Delete
DSE Dossier de Santé Électronique
DOM Document Object Model
FHIR Fast Healthcare Interoperability Resource
HIE Health Information Exchange
HIPAA Health Insurance Portability and Accountability Act
HITECH Health Information Technology for Economic and Clinical Health
HL7 Health Level Seven International
HTTP Hypertext Transfer Protocol
IEFS IPFS-based EHR File System
IHTSDO International Health Terminology Standards Development Organisation
IPFS InterPlanetary File System
IRM Imageries par Résonance Magnétique
ISO International Organization for Standardization
JSON JavaScript Object Notation
JS JavaScript
LPRPDE Loi sur la Protection des Renseignements Personnels et les Documents
Électroniques
MCD Modèle Conceptuel des Données
PHR Personal Health Record
PoS Proof of Stake
xvii
EMP Liste des acronymes
PoW Proof of Work

P2P Peer-to-Peer
REST Representational State Transfer
SNOMED Systematized Nomenclature of Medicine Clinical Terms
WAN Wide Area Network
XML Extensible Markup Language
XDS Cross-Enterprise Document Sharing
xviii
Introduction générale
L’avènement récent de la technologie affecte toutes les parties de la vie humaine et

modifie la façon dont nous utilisons et percevons les choses auparavant. Tout comme les
changements que la technologie a offert dans divers autres secteurs de la vie, elle trouve
également de nouvelles façons d’améliorer le secteur des soins de santé. Les principaux
avantages des progrès technologiques sont l’amélioration de la sécurité, de l’expérience
utilisateur et d’autres aspects du secteur des soins de santé. Ces avantages étaient offerts
par les systèmes de dossiers de santé électroniques (DSE).
Avant l’avènement de la technologie moderne, le secteur des soins de santé utilisait un
système papier pour stocker les dossiers médicaux, c’est-à-dire un mécanisme manuscrit.
Ce système de dossiers médicaux sur papier était inefficace, peu sûr, non organisé et n’était
pas étanche. Il a également fait face à la question de la duplication des données et de la
redondance, car tous les établissements visités par le patient disposaient de diverses copies
des dossiers médicaux du patient. Aujourd’hui l’usage de DSE par les centres de santé a
remédie à tous ses inconvénients.
Cependant, ce domaine fait toujours face à certains problèmes concernant la sécurité des
DSEs, la propriété des utilisateurs des données, l’intégrité des données, etc. La solution à
ces problèmes pourrait être l’utilisation d’une nouvelle technologie, à savoir, la blockchain.
Cette technologie offre une plateforme sécurisée et résistante pour le stockage des dossiers
médicaux et d’autres informations relatives aux soins de santé.
Du point de vue juridique, les Dossier de Santé Électronique (DSE) sont des données
personnelles privées. Cela signifie que les individus en sont les propriétaires, même s’ils
sont stockés et gérés par les hôpitaux. Par conséquent, pour mettre en œuvre un partage
efficace et raisonnable des DSE, les patients ont besoin de droits et d’un soutien technique
suffisants pour connaı̂tre et contrôler l’accès à leurs propres dossiers médicaux dans les
hôpitaux.
La problématique dans notre projet est la nécessité d’une plateforme qui permet un
partage sécurisé et assure une disponibilité élevée des données stockées, tout en offrant
une interopérabilité conforme aux normes universelles entre les différents centres de santé.
1
EMP Introduction générale
De plus, il est essentiel de maintenir une symétrie de l’information pour les patients et de
leur accorder le droit de contrôler leurs données en termes d’accès et de partage.
Dans ce projet, une architecture basée sur la blockchain est proposée pour sécuriser
le partage des données de santé sous le contrôle des patients. Le schéma proposé inclut
la technologie blockchain et la technologie du système de fichiers interplanétaire (IPFS).
Dans cette architecture, les DSE sont stockés et gérés dans l’IPFS et accessibles selon les
adresses cryptés sur les systèmes basés sur la blockchain, qui visent à sécuriser le partage
des DSE avec une grande efficacité.
Nous nous intéressons dans notre travail à concevoir et développer un nouveau méca-
nisme d’accès aux DSE fondé sur la blockchain pour soutenir le partage des DSE entre
les hôpitaux sous le contrôle des patients. En plus, nous choisissons l’IPFS pour accéder
aux fichiers de DSE de grande taille à haute vitesse avec l’autorisation des patients.
Le reste de ce rapport est structuré comme suit.
— Dans le chapitre I, nous traitons des spécifications concernant les données médicales.
Nous allons ensuite porter notre attention sur le dossier de santé électronique et
examiner les diverses technologies qui facilitent le partage de ces dossiers.
— Dans le chapitre II, nous introduisons la technologie de la blockchain et d’IPFS.

Ensuite, nous effectuons une synthèse des travaux de l’état de l’art portant sur les
systèmes de partage de dossiers de santé électroniques basés sur la technologie de la
blockchain, puis nous exposons notre propre démarche à ce sujet.
— Dans le chapitre III, nous décrivons l’architecture du système proposé en exami-

nant ses différents composants. Nous suivons un processus qui commence par la
conception et la modélisation et se termine par la mise en œuvre. Nous présenterons
également une application développée pour les hôpitaux afin de faciliter l’interaction
avec la plateforme.
— Dans le chapitre IV, nous présentons les technologies utilisées pour mettre en œuvre
l’architecture proposée et démontrons le système avec des cas d’utilisation et des
tests de performance.
Le rapport sera clôturé par une conclusion générale résumant l’essentiel de ce que nous
avons réalisé dans ce projet ainsi qu’une série de perspectives qui peuvent l’améliorer.
2
Chapitre I
CONCEPTS FONDAMENTAUX SUR LE

PARTAGE DES DOSSIERS MÉDICAUX
EMP Chapitre I. Concepts fondamentaux sur le partage des dossiers médicaux
I.1 Introduction
Les dossiers médicaux sont des documents essentiels pour la prise en charge des patients,
et leur partage entre les professionnels de santé peut améliorer la qualité des soins et la
coordination des interventions. Le DSE est une solution numérique qui permet de stocker
et de partager les informations médicales des patients de manière sécurisée et efficace. Les
systèmes de partage des dossiers médicaux électroniques se sont développés pour offrir des
solutions innovantes aux professionnels de santé et aux patients.
Cependant, le choix d’un système de partage de dossier de santé électronique approprié
peut être complexe, car il existe de nombreux critères à prendre en compte, tels que la
sécurité, la confidentialité, l’interopérabilité et des autres critères importants. Dans ce
chapitre, nous allons explorer ce qu’est la gestion des données médicales et les différentes
options de partage des dossiers médicaux électroniques, en examinant leurs avantages et
leurs inconvénients.
Nous aborderons également les tendances et les perspectives futures en matière de tech-
nologie de partage de dossiers médicaux électroniques, ainsi que les technologies utilisées,
telles que la blockchain, le cloud et les réseaux informatique.
I.2 Données médicales
Les données médicales sont des informations relatives à la santé d’un individu, telles
que ses antécédents médicaux, les diagnostics reçus, les traitements suivis et les résultats
de ces traitements [1]. Ces données peuvent être collectées à partir de diverses sources,
notamment les dossiers médicaux, les résultats d’examens médicaux, les données de sur-
veillance de la santé publique, les enquêtes sur la santé et les essais cliniques.
L’utilisation de ces données est cruciale pour la recherche en santé, car elle permet
de mieux comprendre les maladies, de développer de nouveaux traitements et de mieux
évaluer l’efficacité des interventions médicales. Les données médicales peuvent également
être utilisées pour améliorer la qualité des soins de santé, en surveillant les résultats des
traitements et en favorisant la recherche médicale [2].
Cependant, l’utilisation de données médicales soulève des questions de confidentialité et
de sécurité. Les informations relatives à la santé sont des données sensibles et doivent être
protégées pour garantir la confidentialité des patients et préserver leur droit à la vie privée.
Les lois et les règlements en matière de confidentialité des données, tels que la Loi sur la
Protection des Renseignements Personnels et les Documents Électroniques (LPRPDE) [3]
et la loi algeriènne n° 18-07 du 10 juin 2018 relative à la protection des personnes physiques
dans le traitement des données à caractère personnel, ont été établis pour protéger les
5
données médicales et garantir leur utilisation responsable et éthique [4].
I.2.1 Différentes catégories de données médicales
Les données médicales peuvent être classées en différentes catégories en fonction de

leur origine, de leur contenu et de leur utilisation. Voici quelques-unes des principales
catégories de données médicales [5] :
1. Données de diagnostic : Ces données sont utilisées pour identifier une maladie ou
une condition médicale chez un patient. Elles peuvent inclure des résultats d’exa-
mens médicaux tels que des analyses de sang, des radiographies ou des Imageries
par Résonance Magnétique (IRM), ainsi que des informations sur les symptômes
rapportés par le patient.
2. Données de traitement : Ces données comprennent des informations sur les trai-
tements médicaux administrés à un patient, tels que les médicaments prescrits, les
interventions chirurgicales ou les thérapies de réadaptation.
3. Données de surveillance de la santé publique : Ces données sont collectées pour

surveiller l’incidence et la prévalence de maladies dans une population donnée. Elles
peuvent inclure des données sur les maladies infectieuses, les maladies chroniques et
les comportements de santé.
4. Données de recherche clinique : Ces données sont collectées dans le cadre d’essais
cliniques pour évaluer l’efficacité et la sécurité des interventions médicales. Elles
peuvent inclure des données sur les participants à l’étude, les protocoles de l’étude,
les résultats des examens médicaux et les résultats des traitements administrés.
5. Données de gestion des soins de santé : Ces données sont utilisées pour gérer les
soins de santé d’un patient, telles que les informations sur les rendez-vous médicaux,
les traitements suivis et les factures médicales.
Chacune de ces catégories de données médicales peut être utilisée pour différentes appli-
cations, notamment la recherche médicale, la surveillance de la santé publique, la gestion
des soins de santé et l’amélioration de la qualité des soins de santé.
I.2.2 Sources de données médicales
Il existe une variété de sources de données médicales qui peuvent être exploitées pour
la recherche médicale, la surveillance de la santé publique et la gestion des soins de santé.
Il est primordial de sélectionner une source fiable et pertinente en fonction de ses besoins.
Voici quelques-unes des sources de données médicales utilisées à travers le monde.
6
Dossiers médicaux : Les dossiers médicaux des patients contiennent des informations sur
leur historique médical, y compris les antécédents familiaux, les diagnostics, les traitements
et les résultats des examens médicaux. Les dossiers médicaux électroniques sont de plus
en plus courants et permettent une collecte de données plus facile et plus précise [3].
Registres de santé : Les registres de santé sont des bases de données qui contiennent des
informations sur des groupes spécifiques de personnes atteintes d’une maladie ou d’une
condition médicale donnée. Ces registres peuvent être utilisés pour suivre l’incidence et
la prévalence de la maladie, évaluer l’efficacité des traitements et surveiller les tendances
dans l’évolution de la maladie.
Enquêtes sur la santé : Les enquêtes sur la santé sont des enquêtes menées auprès
d’échantillons de populations pour collecter des données sur leur santé et leur comporte-
ment. Ces enquêtes peuvent fournir des informations sur les facteurs de risque de maladies,
les comportements de santé et les attitudes à l’égard des soins de santé .
Administration de la santé : Les données administratives de santé sont des données

collectées dans le cadre de la gestion des soins de santé, telles que les factures médicales,
les codes de diagnostic et les informations sur les hospitalisations. Ces données peuvent
être utilisées pour évaluer l’utilisation des services de santé et identifier les tendances en
matière de santé.
Essais cliniques : Les données de recherche clinique sont collectées dans le cadre d’essais
cliniques pour évaluer l’efficacité et la sécurité des interventions médicales. Ces données
peuvent inclure des données sur les participants à l’étude, les protocoles de l’étude, les
résultats des examens médicaux et les résultats des traitements administrés [6].
Chacune de ces sources de données médicales peut fournir des informations précieuses
pour la recherche médicale, la surveillance de la santé publique et la gestion des soins de
santé. Cependant, il est important de protéger la confidentialité et la sécurité des données
pour garantir l’utilisation responsable et éthique de ces informations.
I.2.3 Caractéristiques des données médicales
Les données médicales présentent plusieurs caractéristiques qui les rendent uniques et
parfois difficiles à utiliser [7]. Les caractéristiques clés des données médicales incluent :
Complexité : Les données médicales peuvent être très complexes, car elles peuvent in-
clure des informations sur plusieurs aspects de la santé d’un patient, comme les antécédents
7
médicaux, les résultats d’examens médicaux et les prescriptions [1].
Confidentialité : Les données médicales sont souvent sensibles et confidentielles, ce qui

peut limiter leur accès et leur utilisation [2].
Hétérogénéité : Les données médicales peuvent provenir de différentes sources, être col-
lectées à des moments différents et être stockées dans des formats différents, ce qui peut
rendre difficile leur intégration et leur analyse [1].
Volume : Les données médicales peuvent être volumineuses, surtout lorsqu’elles sont
collectées sur de grandes populations, ce qui peut nécessiter des outils et des méthodes
d’analyse sophistiqués [1].
Qualité : Les données médicales peuvent varier en termes de qualité et de précision, en

fonction de la façon dont elles ont été collectées et enregistrées.
Disponibilité limitée : Certaines données médicales peuvent ne pas être accessibles en

raison de restrictions légales ou d’autres raisons liées à la confidentialité ou à la sécurité
des données [2].
I.3 Dossier de santé électronique (DSE)
Les dossiers de santé électroniques (DSE) sont devenus une composante clé des systèmes
de santé au cours des dernières années. Selon la définition de International Organization
for Standardization (ISO), le DSE est un référentiel numérique de données sur les patients
stocké et échangé de manière sécurisée, accessible par plusieurs utilisateurs autorisés.
Il contient des informations rétrospectives, concurrentes et prospectives et son objectif
principal est de soutenir des soins de santé continus, efficaces et intégrés de qualité. Les
DSE stockent une multitude de données sur chaque rencontre du patient avec le système
de santé, telles que les informations démographiques, les diagnostics, les résultats des tests
de laboratoire et d’imagerie, les ordonnances, les notes cliniques, et bien plus encore. Bien
que principalement conçus pour améliorer l’efficacité opérationnelle des soins de santé, de
nombreuses études ont mis en évidence des utilisations secondaires pour les applications
d’informatique clinique, telles que la recherche, les initiatives d’amélioration de la qualité,
la gestion de la santé de la population et les systèmes de prise de décision clinique [8].
8
I.3.1 Avantages de dossier de santé électronique
Certains des avantages fondamentaux associés aux dossiers de santé électroniques

(DSE) comprennent la possibilité d’accéder facilement aux dossiers informatisés et l’éli-
mination de la mauvaise écriture, qui a historiquement affecté le dossier médical. Les
systèmes qui gère les DSE peuvent inclure de nombreuses capacités potentielles, mais
trois fonctionnalités particulières offrent de grandes promesses pour améliorer la qualité
des soins et réduire les coûts au niveau du système de soins de santé :
— Clinical Decision Support (CDS)
— Computerized Physician Order Entry (CPOE)
— Health Information Exchange (HIE)
Ces capacités et d’autres liées aux DSE sont des exigences des critères ”d’utilisation
significative”énoncés dans la loi Health Information Technology for Economic and Clinical
Health (HITECH) de 2009 [1].
Un système CDS est un système qui aide les professionnels de santé à prendre des
décisions en matière de soins aux patients. Certaines fonctionnalités d’un système CDS
incluent la fourniture des dernières informations sur un médicament, la recoupement des
allergies d’un patient à un médicament et des alertes pour les interactions médicamen-
teuses et autres problèmes potentiels signalés par l’ordinateur. À mesure que de plus en
plus de systèmes CDS sont utilisés, on peut s’attendre à ce que certains erreurs médicales
soient évitées et qu’au final, le patient reçoive des soins plus efficaces et plus sûrs.
Les systèmes CPOE permettent aux professionnels de santé de saisir les ordres (par
exemple, pour les médicaments, les tests de laboratoire, la radiologie) dans un ordina-
teur plutôt que sur papier. La numérisation de ce processus élimine les erreurs médicales
potentiellement dangereuses causées par la mauvaise écriture des médecins. Cela rend
également le processus de commande plus efficace. L’utilisation d’un système CPOE, en
particulier lorsqu’il est lié à un système CDS, peut entraı̂ner une amélioration des soins.
HIE est le processus de partage d’informations de santé électroniques au niveau du
patient entre différentes organisations et peut réduire les coûts liés aux tests redondants
qui sont commandés parce qu’un fournisseur n’a pas accès aux informations cliniques
stockées dans un autre lieu. Les patients ont généralement des données stockées dans
plusieurs endroits où ils reçoivent des soins. Historiquement, les fournisseurs s’appuient
sur l’envoi par fax ou par courrier postal d’informations pertinentes les uns aux autres,
ce qui rend difficile leur accès en ”temps réel” lorsque cela est nécessaire. HIE facilite
l’échange de ces informations via les DSEs, ce qui peut entraı̂ner une prestation de soins
plus rentable et de meilleure qualité.
9
I.3.2 Défis de dossier de santé électronique
Certains chercheurs ont noté que l’intégration de la technologie DSE dans les flux de
travail cliniques peut perturber les habitudes de travail des acteurs de santé et entraı̂ner
des coûts financiers pour les organisations de soins de santé. De plus, l’adoption des
DSE peut entraı̂ner une perte temporaire de productivité car les acteurs de santé doivent
consacrer du temps à la formation et à l’apprentissage de la nouvelle technologie.
En ce qui concerne les questions de confidentialité et de sécurité, les DSE contiennent
des informations sensibles sur les patients, Ce qui soulève des préoccupations quant à la
protection de ces données contre les accès non autorisés et pour éviter l’utilisation de ces
dossiers à des fins malveillantes [9].
Enfin, les DSE peuvent également avoir des conséquences imprévues sur la relation
entre les patients et les acteurs de santé, ainsi que sur la qualité globale des soins. Il est
donc important pour les organisations de santé d’évaluer soigneusement les avantages et
les inconvénients de l’adoption des DSE avant de les mettre en œuvre, et de prévoir des
mesures pour atténuer les effets négatifs potentiels [10].
I.3.3 Standards des dossiers de santé électroniques
Les dossiers de santé électroniques (DSEs) ont révolutionné la façon dont les données
de santé sont stockées, partagées et utilisées dans les systèmes de santé modernes. Pour
assurer l’interopérabilité et la qualité des données, des normes ont été mises en place pour
les DSEs.
Les normes de DSE sont des spécifications techniques pour l’organisation, l’échange
et l’utilisation de données de santé électroniques. Elles sont essentielles pour garantir
l’interopérabilité des DSE entre les différents systèmes de santé et éviter les problèmes
d’échange [11]. À cette fin, plusieurs normes de DSE ont été développées afin de struc-
turer les données des DSE pour les échanges de données. La structuration des DSE pour
l’échange de données médicales en soutenant une représentation d’informations signifi-
catives entre les systèmes d’information de santé à l’intérieur ou entre les organisations
de soins de santé. Ces normes comprennent Clinical Document Architecture (CDA) [12],
Health Level Seven International (HL7) [13], openEHR [14] et Cross-Enterprise Document
Sharing (XDS) [15].
Pour le transfert des données, l’organisation HL7 a développée Fast Healthcare In-
teroperability Resource (FHIR) qui est une norme moderne d’interopérabilité en matière
de santé. Elle est conçue pour faciliter l’échange d’informations de santé entre différents
systèmes et applications de santé, tels que les dossiers de santé électroniques (DSE), les
10
systèmes d’aide à la décision clinique et les applications mobiles de santé. La norme FHIR
fournit un ensemble d’Application Programming Interface (API) RESTful basées sur
Hypertext Transfer Protocol (HTTP), permettant aux plateformes de soins de santé de
communiquer et de partager des données représentées sous forme de formats Extensible
Markup Language (XML) ou JavaScript Object Notation (JSON) [13]. Et pour la structu-
ration des dossiers de santé électronique, la norme Systematized Nomenclature of Medicine
Clinical Terms (SNOMED) est une terminologie clinique exhaustive utilisée dans le do-
maine de la santé pour décrire les observations cliniques, les procédures et les résultats.
Elle est gérée par International Health Terminology Standards Development Organisa-
tion (IHTSDO) et elle fait partie des terminologies les plus populaires dans le domaine
de la santé.
SNOMED offre une façon standardisée de capturer et de partager les données cliniques
dans différents environnements et systèmes de santé, permettant ainsi aux professionnels
de la santé de communiquer efficacement et avec précision sur l’état de santé d’un patient.
Elle comprend plus de 350 000 concepts, avec des identifiants uniques pour chaque concept,
et est régulièrement mise à jour pour refléter les changements dans les pratiques cliniques
et la terminologie [16].
Ces normes sont devenues des outils indispensables pour faciliter l’échange de données
et la collaboration entre les professionnels de santé, améliorant ainsi la qualité des soins et
réduisant les erreurs médicales [17]. L’adoption des normes DSE communes est essentielle
pour améliorer la qualité des soins de santé et la gestion des données de santé électroniques
à l’échelle nationale et internationale.
I.4 Partage des dossiers médicaux
La numérisation des dossiers médicaux a permis de stocker les informations de santé

des patients de manière centralisée et plus efficace. Cependant, la distribution des données
entre les différents acteurs du domaine de la santé reste un enjeu majeur. Le partage des
dossiers médicaux est devenu essentiel pour une prise en charge optimale des patients,
notamment en cas d’urgence ou de consultation auprès de différents professionnels de
santé. Dans cette section, nous étudions les technologies existantes pour assurer la sécurité
et la confidentialité des données lors du partage des dossiers médicaux. Dans la littérature,
il existe plusieurs technologies pour le partage de dossiers médicaux. Nous nous intéressons
particulièrement au la blockchain, cloud computing et les réseaux informatique, qui sont
aujourd’hui des solutions émergentes [18, 19]. Nous présentons une analyse comparative
de ces différentes technologies selon plusieurs critères.
11
I.4.1 Définition de système de partage des dossiers médicaux
Les systèmes de partage de données médicales sont des plateformes technologiques qui
permettent aux prestataires de soins de santé, aux patients et à d’autres entités autorisées
d’échanger et d’accéder de manière sécurisée à des informations médicales. Ces systèmes
facilitent le transfert de données de patients dans différents environnements de soins de
santé, tels que les hôpitaux, les cliniques et les laboratoires, dans le but d’améliorer les
soins et les résultats pour les patients.
Les systèmes de partage de données médicales peuvent inclure des dossiers de santé élec-
troniques (DSE), des échanges d’informations de santé et le partage des données cliniques,
telles que les antécédents médicaux, les résultats de tests et les plans de traitement [2].
L’objectif de ces systèmes est de s’assurer que les prestataires de soins de santé ont accès
à des informations complètes et précises sur les patients, leur permettant de prendre des
décisions plus éclairées en matière de soins.
I.4.2 Avantages des systèmes de partage de données médicales
Les systèmes de partage de données médicales sont devenus de plus en plus importants
dans les soins de santé ces dernières années en raison des nombreux avantages qu’ils
offrent. Certains des principaux avantages des systèmes de partage de données médicales
comprennent [9] :
— Amélioration des soins pour les patients : Les systèmes de partage de données
médicales permettent aux prestataires de soins de santé d’accéder à des informations
complètes et à jour sur les patients, ce qui peut les aider à prendre des décisions plus
éclairées en matière de soins. Cela peut conduire à une amélioration du diagnostic,
du traitement et des résultats pour les patients.
— Augmentation de l’efficacité et des économies de coûts : En permettant aux pres-

tataires de soins de santé d’accéder rapidement et facilement aux informations sur
les patients, les systèmes de partage de données médicales peuvent aider à réduire
la duplication des tests et des procédures, ce qui peut entraı̂ner des économies de
coûts et une augmentation de l’efficacité.
— Amélioration de la sécurité des patients : Les systèmes de partage de données

médicales peuvent aider à réduire les erreurs et à améliorer la sécurité des patients
en veillant à ce que les prestataires de soins de santé aient accès à des informations
précises et complètes sur les patients, y compris les antécédents médicaux et les
allergies.
— Amélioration de la coordination des soins : Les systèmes de partage de données
12
médicales peuvent aider à améliorer la coordination des soins entre différents pres-
tataires de soins de santé, tels que les médecins généralistes de soins primaires, les
spécialistes et les hôpitaux. Cela peut conduire à de meilleures transitions de soins
et à des soins plus cohérents pour les patients.
— Facilitation de la recherche et de l’innovation : Les systèmes de partage de données

médicales peuvent être une ressource précieuse pour les chercheurs et les innovateurs,
en leur fournissant un accès à de grands ensembles de données qui peuvent être
utilisés pour développer de nouveaux traitements et améliorer les résultats des soins
de santé.
Ces systèmes sont devenus nécessaires dans les centres de santé tels que les hôpitaux
pour aider les professionnels de santé et améliorer la qualité des soins.
I.4.3 Défis des systèmes de partage des dossiers médicaux
Le partage des dossiers médicaux est un aspect crucial de la prestation de soins de santé
efficaces et coordonnés. Cependant, la mise en place de systèmes de partage de dossiers
médicaux soulève de nombreux défis pour les prestataires de soins de santé, les patients et
les fournisseurs de technologies de l’information. Dans cette partie, nous allons examiner
les défis les plus courants auxquels sont confrontés les systèmes de partage des dossiers
médicaux :
— Interopérabilité : Les données médicales sont souvent stockées dans des formats
et des systèmes différents, ce qui peut rendre difficile le partage et l’intégration
des données entre différentes organisations de santé. Les systèmes de partage des
données médicales doivent être en mesure de gérer une variété de formats de données
et de communiquer efficacement avec différents systèmes.
— Asymétrie de l’information : Aujourd’hui, le plus grand problème dans le secteur de

la santé est l’asymétrie de l’information qui se réfère à une partie ayant un meilleur
accès à l’information que l’autre partie. Dans le cas des systèmes de partage des
DSEs, ou dans le secteur de la santé en général, ce problème est d’autant plus
prégnant car les médecins ou les hôpitaux ont accès aux dossiers des patients, ce
qui les rend centraux. Si un patient veut accéder à son dossier médical, il devra
suivre un processus long et fastidieux pour y parvenir. L’information est centralisée
auprès d’un seul organisme de santé et son contrôle n’est assuré qu’aux hôpitaux ou
organismes [7].
— Violations de données : Les violations de données peuvent compromettre la confi-

dentialité des patients, leur sécurité et leur vie privée, et peuvent entraı̂ner des
13
conséquences graves pour les patients, les prestataires de soins de santé et les or-
ganisations de soins de santé. De plus, ces violations peuvent entraı̂ner des pertes
financières importantes pour les organisations, des sanctions réglementaires et des
poursuites judiciaires.
— Confiance et adoption : Les patients et les prestataires de soins de santé doivent

avoir confiance dans les systèmes de partage des données médicales pour protéger
les données des patients et s’assurer qu’elles sont utilisées de manière éthique et
appropriée [8].
Les systèmes de partage de dossiers médicaux sont essentiels pour améliorer la qualité
des soins de santé et la coordination entre les différents prestataires de soins de santé.
Cependant, ces systèmes sont confrontés à plusieurs défis et pour surmonter ces défis,
il est important de mettre en place des mécanismes de sécurité solides pour protéger la
confidentialité des patients et de favoriser l’adoption des systèmes de partage de données
par les professionnels de la santé et les patients. En outre, il est crucial de choisir la
technologie la plus appropriée pour les systèmes de partage de données médicales, qui doit
être capable de gérer efficacement les différents formats de données et de communiquer
avec d’autres systèmes de santé. En fin de compte, le choix de la technologie utilisée peut
avoir un impact significatif sur la sécurité, l’efficacité et l’adoption des systèmes de partage
de données médicales.
I.4.4 Technolgies support de partage de dossiers médicaux
Le partage des dossiers médicaux a beaucoup évolué au cours des années précédentes.
Dans cette partie, nous présentons les technologies pertinentes utilisées pour le partage
des dossiers médicaux. Nous commençons par les réseaux informatiques (spécialement
Wide Area Network (WAN)) basés sur les entrepôts et les bases de données [19], le cloud
computing [20] et la blockchain [21].
I.4.4.1 Réseau Informatique
L’utilisation des réseaux informatiques a un grand impact dans l’interconnexion entre

les organisations et les fournisseurs de soins. Les hôpitaux ont pris le choix d’utiliser
des réseaux WAN pour partager les dossiers médicaux. Cette approche est divisée en
deux types d’architectures, telles qu’une architecture centralisée basée sur un entrepôt
de données et une architecture décentralisée basée sur l’utilisation d’une base de données
locale pour chaque fournisseur et le partage des données médicales basé sur un réseau
WAN entre les centres de soins tels que les hôpitaux [19].
14
Dans l’architecture centralisée (voir Figure I.1), des copies des dossiers médicaux élec-
troniques - sous forme exhaustive ou résumée - sont transmises à un système centralisé
à l’échelle nationale, qui fonctionne comme un référentiel pour l’ensemble des dossiers
médicaux électroniques des patients dans le pays. Cela est appelé un modèle ”push”, basé
sur le concept de pousser les données des fournisseurs de soins de santé vers le site central.
Le ”poussage” des données médicales des centres médicaux vers les référentiels centraux
se produit périodiquement,par exemple, au Danemark, cela se produit chaque nuit [22].
Figure I.1 — Architecture centralisée de partage [19].
Dans l’architecture distribuée (voir Figure I.2), toutes les informations seraient stockées
et gérées localement dans les différents fournisseurs de soins de santé et établissements.
Des liens de référence maintenus de manière centrale dans un système central indiqueraient
où se trouvent les enregistrements de données d’origine. Cela est appelé un modèle ”pull”,
car l’agence centrale demande toutes les données nécessaires aux fournisseurs chaque fois
qu’une demande de dossier médical électronique d’un patient est émise. Le modèle ”pull”
n’implique pas de référentiel central, car les données ne peuvent être demandées que
lorsqu’un utilisateur en fait la demande [23].
L’architecture centralisée présente les avantages de la disponibilité, de la performance
et de la rapidité de réponse aux requêtes. En revanche, l’utilisation d’un entrepôt de
données centralisé contenant des données provenant de sources multiples présente souvent
des difficultés de contexte et de codification des données, et leur complexité de conception
conduit généralement à des retards importants dans la mise en œuvre et l’utilisation
effective [23]. De plus, cela peut nécessiter des coûts énormes pour la mise en place du
magasin d’informations central, et il souffre d’incohérences de données sur le système
central puisque les données du patient sont généralement envoyées périodiquement au
15
Figure I.2 — Architecture décentralisée de partage [19].
système central. Enfin, la création d’un système accessible à l’échelle nationale contenant
toutes les données des patients augmenterait le risque de violations de la sécurité [22].
L’architecture distribuée présente l’avantage d’un coût réduit pour la mise en place
du système central car elle ne contient aucune duplication de données médicales. Cette
architecture a également l’avantage unique de la cohérence des données et de l’accès aux
dernières informations sur le patient en fonction des besoins. De plus, cette approche aide
à assurer la protection des informations des patients et à répondre aux préoccupations
concernant les menaces pesant sur la vie privée et la sécurité, car les informations du
patient restent à la source plutôt que d’être dupliquées dans une base de données centra-
lisée. Cependant, les requêtes pour accéder aux données du patient chez les fournisseurs
de soins de santé distants peuvent prendre beaucoup de temps pour être traitées. Cela
place des charges supplémentaires sur le réseau de communication et les systèmes sources
auxquels on accède, donc les retards d’accès sont susceptibles d’être inacceptables [23].
I.4.4.2 Cloud Computing
Le partage des dossiers médicaux sur le Cloud Computing est devenu une pratique
courante pour les professionnels de la santé en raison de l’importance grandissante de cette
technologie et ses avantages. Les organisations sont incitées à utiliser le Cloud Computing
pour le partage des dossiers médicaux en raison des nombreux avantages qu’il offre. Cela
permet aux praticiens de collaborer plus efficacement en partageant des informations sur
les patients, ce qui peut améliorer la qualité des soins. Les dossiers médicaux stockés dans
16
le Cloud sont accessibles à distance et peuvent être mis à jour en temps réel, ce qui peut
faciliter la coordination entre les professionnels de la santé. Cependant, le stockage des
données médicales sur des serveurs distants comme le montre dans la Figure I.3 qui soulève
des inquiétudes concernant la confidentialité et la sécurité des données. Des mesures de
sécurité et des protocoles doivent être mises en place pour assurer la protection des données
sensibles, tels que la cryptographie, l’authentification forte, et la sauvegarde régulière des
données [24].
Figure I.3 — Partage des DSE dans le cloud [25].
En effet, cela présente une difficulté importante qui réside dans la confiance que les uti-
lisateurs peuvent accorder aux fournisseurs de services cloud. Un tel manque de confiance
découle du manque de transparence et de la perte de contrôle des données [26, 27] par les
utilisateurs dans les environnements cloud, notamment :
1. L’externalisation de données vers le cloud revient essentiellement à transférer le

contrôle physique d’un domaine de forte confiance (stockage local) à un autre do-
maine de faible confiance (stockage cloud).
2. Les données de l’utilisateur sont stockées dans de nombreux emplacements physiques

et sites Web. Les utilisateurs ne sont pas conscients de l’emplacement exact de leurs
données et de savoir si les mécanismes de sécurité de ces sites répondent à leurs
besoins.
Il existe plusieurs travaux qui utilisent le cloud pour le partage des dossiers médicaux,
parmi ceux-ci, on peut citer CamFlow [28] et le travail de Ji-Jiang et al. [29]. La gestion des
informations médicales basée sur le cloud computing est confrontée aux mêmes problèmes.
De plus, en raison des réglementations de sécurité et de confidentialité de la loi Health
17
Insurance Portability and Accountability Act (HIPAA), le partage de données médicales

entre institutions devient encore plus compliqué et difficile.
I.4.4.3 Blockchain
L’adoption croissante de la technologie de blockchain dans le domaine du calcul dis-

tribué, a récemment incité de nombreux chercheurs à désormais utiliser cette technologie
pour sécuriser le partage et la gestion des données médicales. Cette tendance est due à
la nécessité de protéger les informations de santé sensibles des patients et de les rendre
accessibles de manière efficace et rapide aux professionnels de santé autorisés [30].
Comme illustré dans la Figure I.4, la blockchain permet de stocker les données médicales
de manière décentralisée. Ceci se réfère au concept de transfert de contrôle et de prise
de décision d’une entité centrale vers un réseau distribué. Dans un système blockchain
décentralisé, les décisions sont prises de manière collective par les membres du réseau
plutôt que par une autorité centrale unique. Les transactions sont vérifiées et enregistrées
par les nœuds du réseau plutôt que par une entité centrale telle qu’une organisation ou
une entreprise.
Cette procédure permet de réduire la dépendance envers une autorité centrale et garan-
tir un partage sécurisé grâce à des mécanismes de cryptographie et de consensus [32], ainsi
qu’à augmenter la transparence et la sécurité. En éliminant les points de contrôle centra-
lisés, les utilisateurs peuvent interagir directement les uns avec les autres et maintenir le
système sans avoir à faire confiance à une autorité centrale. Cela rend le système plus
résistant aux attaques et aux pannes, et permet également une plus grande confidentialité
et une plus grande sécurité pour les utilisateurs.
De plus, l’utilisation de la blockchain pour la gestion des données médicales permet
d’éviter les erreurs de transmission et de duplication, qui peuvent avoir des conséquences
Figure I.4 — Décentralisation dans la blockchain [31].
18
graves pour la santé des patients [21]. En effet, la blockchain permet de garantir l’intégrité
des données et d’éviter toute altération ou falsification. Il y a plusieurs travaux dans le
domaine de la blockchain qui contiennent des points forts et des points faibles en fonction
des critères de sécurité, confidentialité, et le stockage. Parmi ces travaux, on peut citer
MedRec [33], MedRec+ [34] et MedBlock [35].
L’utilisation de la blockchain pour la sécurisation du partage et de la gestion des don-
nées médicales offre de nombreux avantages et représente une évolution majeure dans le
domaine de la santé numérique.
I.5 Comparaison et discussion
La Table I.1 met en évidence les caractéristiques clés de trois technologies de partage
des données médicales, à savoir les réseaux informatique [19], Cloud Computing [24] et
la Blockchain [36, 37] , dans le contexte du partage des dossiers médicaux. En examinant
les critères clés il est possible de voir que les technologies ont leurs avantages et leurs
inconvénients distincts.
En termes de sécurité, la blockchain est considérée comme ayant une sécurité élevée,
ce qui est particulièrement important pour les dossiers médicaux contenant des informa-
tions sensibles et personnelles. Le cloud computing, quant à lui, a une sécurité moyenne,
tandis que les réseaux informatiques ont une sécurité faible, ce qui peut entraı̂ner une
vulnérabilité aux violations de données.
En termes de confidentialité, la blockchain est également considérée comme ayant une
confidentialité élevée, tandis que le cloud computing et les réseaux informatiques ont une
confidentialité faible. L’accessibilité est considérée comme élevée pour la blockchain, ce qui
facilite l’accès aux dossiers médicaux par les professionnels de la santé, tandis que le cloud
Réseau informa-
Critères Cloud Computing Blockchain
tique
Sécurité Faible Moyen Élevé
Confidentialité Faible Moyen Élevé
Accessibilité Faible Moyen Élevé
Évolutivité Moyen Élevé Moyen
Interopérabilité Faible Élevé Élevé
Asymétrie de l’in-
Faible Faible Élevé
formation
Confiance Moyen Moyen Élevé
Table I.1 — Comparaison des caractéristiques des réseaux informatique, du cloud

computing et la blockchain pour le partage des dossiers médicaux.
19
computing a une accessibilité moyenne et les réseaux informatiques ont une accessibilité
faible.
L’évolutivité est considérée comme moyenne pour la blockchain, tandis que le cloud
computing a une évolutivité élevée et les réseaux informatiques ont une évolutivité
moyenne. En termes d’interopérabilité, la blockchain et le cloud computing sont consi-
dérés comme ayant une interopérabilité élevée, tandis que les réseaux informatiques ont
une interopérabilité faible. L’asymétrie de l’information est considérée comme élevée pour
la blockchain, ce qui signifie que l’information est partagée de manière équitable entre les
parties concernées, tandis que le cloud computing et les réseaux informatiques ont une
asymétrie de l’information faible.
Enfin, en ce qui concerne la confiance, la blockchain est considérée comme ayant une
confiance élevée, car elle utilise une technologie décentralisée qui garantit l’authenticité
et l’intégrité des données. Le cloud computing a une confiance moyenne, tandis que les
réseaux informatiques ont une confiance moyenne à faible en raison de la vulnérabilité
aux attaques malveillantes et aux violations de données.
Dans notre solution de partage de dossiers médicaux, nous avons choisi d’utiliser la
blockchain en raison de ses avantages en matière de sécurité, de confidentialité, d’inter-
opérabilité et l’asymétrie de l’information pour les données des médicales. Nous avons
également pris en compte l’évolutivité et les coûts supplémentaires associés à la mise en
place et à la maintenance de la blockchain, et nous avons travaillé pour optimiser son
utilisation en fonction de nos besoins spécifiques.
I.6 Conclusion
Les données médicales sont cruciales pour les professionnels de la santé car elles leur
permettent de diagnostiquer les maladies, prescrire des traitements adaptés et fournir
des soins personnalisés. Ces données aident également à identifier les tendances en santé
publique, évaluer l’efficacité des traitements et soutenir la recherche médicale. Le partage
des données médicales entre les professionnels de la santé peut améliorer la qualité des
soins, éviter les erreurs médicales et faciliter la coordination des soins pour les patients
Dans ce chapitre, nous avons présenté les notions essentielles relatives aux données
médicales et aux systèmes de partage de ces données. Nous avons exposé les avantages et
les défis du partage des dossiers médicaux, ainsi que les différents technologies de partage
des DSEs. Enfin, nous avons effectué une comparaison entre les technologies existantes
dans le domaine du partage des dossiers médicaux, en se basant sur leurs caractéristiques
respectives. À la suite de cette analyse, nous avons choisi la blockchain comme solution
pour le partage des dossiers médicaux, en raison de ses caractéristiques uniques et de ses
20
avantages potentiels. Dans le chapitre suivant, nous allons approfondir notre présentation
de cette technologie et expliquer comment elle peut être utilisée pour le partage des
dossiers médicaux de manière sécurisée et efficace.
21
Chapitre II
BLOCKCHAIN ET GESTION DES DOSSIERS

MÉDICAUX
EMP Chapitre II. Blockchain et gestion des dossiers médicaux
II.1 Introduction
La technologie de la blockchain est en train de transformer divers secteurs et a le

potentiel de révolutionner également le secteur de la santé. L’une des applications les plus
prometteuses de la blockchain dans le domaine de la santé est la gestion et le partage
des dossiers de santé électroniques DSE. Les dossiers de santé électroniques contiennent
des informations précieuses et sensibles sur la santé des patients, et il est crucial pour les
fournisseurs de soins de santé de garantir la confidentialité, l’intégrité et la disponibilité
de ces données.
La technologie de la blockchain offre un moyen sécurisé, décentralisé et transparent
de gérer et de partager les DSE, ce qui peut résoudre les défis actuels des systèmes de
DSE tels que l’interopérabilité, les violations de données et la propriété des données. En
utilisant la technologie de la blockchain, les fournisseurs de soins de santé peuvent créer
un enregistrement inaltérable et immuable des données de santé des patients qui peut être
accessible de manière sécurisée et efficace par les parties autorisées.
Plusieurs systèmes de DSE basés sur la blockchain ont été développés et mis en œuvre,
démontrant le potentiel de cette technologie dans le domaine de la santé. Cependant, il
reste des défis et des limites à relever pour réaliser pleinement le potentiel des systèmes de
DSE basés sur la blockchain, tels que la complexité technique, la conformité réglementaire
et d’autres problèmes.
Dans ce chapitre, nous fournissons un aperçu de la technologie de la blockchain et de
ses caractéristiques fondamentales, et de la manière dont elle peut être appliquée à la
gestion et au partage des DSE. Nous discuterons des avantages et des défis de l’utilisation
de systèmes de DSE basés sur la blockchain et donnerons des exemples de mises en œuvre
réussies. Nous passerons également en revue les travaux connexes dans ce domaine et
discuterons des orientations futures et des avancées potentielles.
II.2 Technologie blockchain
La technologie blockchain est une façon révolutionnaire de stocker et de partager des

données de manière sécurisée sur un réseau décentralisé. Elle est souvent décrite comme
un registre numérique, où chaque transaction est enregistrée et vérifiée par un réseau
d’utilisateurs, plutôt qu’une seule autorité. Cette nature distribuée de la technologie blo-
ckchain la rend résistante aux falsifications, aux piratages et à d’autres types d’attaques
malveillantes.
Le concept de la blockchain a été introduit initialement en 1991 par Haber et Stor-
netta [38], qui ont suggéré l’utilisation d’une séquence de tampons horodatés numériques
25
pour vérifier l’authenticité de la propriété intellectuelle. La première application de la tech-

nologie blockchain, et la plus connue, est la monnaie numérique Bitcoin [39]. Cependant,
depuis lors, la blockchain a été appliquée à un large éventail d’industries, de la gestion de
la chaı̂ne d’approvisionnement et de la santé, à la finance et à l’immobilier. La technologie
a le potentiel de transformer la façon dont nous échangeons de la valeur, transférons des
actifs et gérons l’information.
Dans cette section, nous examinons le fonctionnement de la technologie blockchain, ex-
plorons ses caractéristiques clés et discuterons de ses avantages et limites. Nous examinons
également certains des cas d’utilisation les plus prometteurs de la technologie blockchain
et discuterons de la façon dont elle pourrait changer notre façon de vivre et de travailler.
II.2.1 Définition
Une blockchain est une base de données ou un registre distribué partagé entre les
nœuds d’un réseau informatique [40]. Il enregistre des informations au format numérique
de manière électronique et est surtout connu pour son rôle crucial dans les systèmes de
cryptomonnaie, comme Bitcoin [39], pour maintenir un enregistrement sécurisé et décen-
tralisé des transactions sans avoir besoin d’un tiers de confiance.
La principale différence entre une base de données classique et une blockchain réside
dans la structure des données. Une blockchain collecte des informations sous forme de
groupes, appelés blocs, qui contiennent des ensembles d’informations [41]. Une fois remplis,
les blocs sont fermés et liés au bloc précédent, formant ainsi une chaı̂ne de données connue
sous le nom de blockchain. Toutes les nouvelles informations sont compilées dans un
nouveau bloc qui sera ajouté à la chaı̂ne une fois rempli.
II.2.2 Éléments de la blockchain
La technologie de la blockchain peut sembler complexe ; cependant, elle peut être sim-
plifiée en examinant chaque composant individuellement. À un niveau élevé, la technologie
de la blockchain intègre des mécanismes bien connus de la science informatique ainsi que
des primitives cryptographiques (telles que les fonctions de hachage cryptographiques, les
signatures numériques et la cryptographie à clé asymétrique). Ces éléments sont combinés
avec des concepts de tenue de registres, tels que des registres à ajout uniquement.
II.2.2.1 Cryptographie à clé asymétrique
La cryptographie à clé asymétrique, également connue sous le nom de cryptographie

à clé publique, est une technique de chiffrement qui utilise deux clés différentes pour
26
le chiffrement et le déchiffrement des données [42]. Contrairement à la cryptographie à

clé symétrique, où la même clé est utilisée pour le chiffrement et le déchiffrement, la
cryptographie à clé asymétrique utilise une paire de clés : une clé publique et une clé
privée. La clé publique est distribuée publiquement et peut être utilisée pour chiffrer
les données, tandis que la clé privée est gardée secrète et est utilisée pour déchiffrer les
données chiffrées à l’aide de la clé publique.
La cryptographie à clé asymétrique est souvent utilisée pour des tâches telles que la
signature numérique et la gestion des clés dans les systèmes de sécurité informatique.
Elle permet également l’authentification mutuelle entre des parties qui ne se sont jamais
rencontrées auparavant et n’ont pas de relation de confiance préalable. Cependant, elle
est plus lente que la cryptographie à clé symétrique en raison du processus de génération
de clés et du chiffrement/déchiffrement des données avec deux clés différentes.
II.2.2.2 Fonctions de hachage
Les fonctions de hachage cryptographiques sont des algorithmes mathématiques qui

prennent en entrée des données de n’importe quelle taille et produisent en sortie une
empreinte numérique unique de taille fixe, appelée hachage [42]. Ces fonctions sont conçues
pour être à sens unique, ce qui signifie que le hachage ne peut pas être utilisé pour récupérer
les données d’origine. De plus, les fonctions de hachage cryptographiques sont conçues
pour être résistantes aux collisions, c’est-à-dire que deux ensembles de données différents
ne doivent pas produire le même hachage. Parmi les fonctions de hachage cryptographiques
couramment utilisées, on trouve SHA-256 et MD5.
II.2.2.3 Processus de transaction
Une transaction représente une interaction entre les parties. Dans les cryptomon-
naies [43], par exemple, une transaction représente un transfert de la cryptomonnaie entre
les utilisateurs du réseau de blockchain. Pour les entreprises, une transaction pourrait
être un moyen d’enregistrer les activités qui se produisent sur des actifs numériques ou
physiques. Chaque bloc dans une blockchain peut contenir zéro ou plusieurs transac-
tions. Pour certaines implémentations de blockchain, un approvisionnement constant en
nouveaux blocs (même avec zéro transaction) est essentiel pour maintenir la sécurité du
réseau de blockchain [44].
Les données qui composent une transaction peuvent être différentes pour chaque im-
plémentation de blockchain, cependant, le mécanisme de transaction est largement le
même. Un utilisateur du réseau de blockchain envoie des informations au réseau, telles
que l’adresse de l’expéditeur (ou un autre identifiant pertinent), la clé publique de l’expé-
27
diteur, une signature numérique, des entrées et des sorties de transaction.
II.2.2.4 Structure des blocs dans la blockchain
Comme expliqué précédemment, la blockchain consiste en une série de blocs connectés

dans un réseau Peer-to-Peer (P2P) pour créer une application décentralisée. L’en-tête de
ces blocs contient des hashs de blocs précédents. Un bloc contient principalement trois
choses qui sont les données, le hash du bloc courant et le hash du bloc précédent (voir
la Figure II.1). Les données dépendent de l’application de la blockchain, comme dans
le cas de Bitcoin, les données se compose de pièces qui sont effectivement de l’argent
électronique [39]. Les blocs contiennent un hachage généré par une fonction de hachage
pour assurer l’identification unique de chaque bloc dans la chaı̂ne.
Figure II.1 — Structure d’un bloc [45].
II.2.2.5 Contrat intelligent
Les contrats intelligents sont des programmes informatiques autonomes stockés sur la
Blockchain [46]. Lorsque des conditions prédéfinies sont remplies, ils s’exécutent automa-
tiquement, ce qui permet de gérer et d’exécuter des transactions sans intervention d’une
tierce partie, comme une organisation gouvernementale, une banque ou toute autre en-
tité. Les termes de l’accord sont codés dans les lignes de code, ce qui les différencie des
contrats papier traditionnels, dans lesquels les termes et conditions sont énoncés dans un
28
document et sont exécutoires par la loi. Les contrats intelligents permettent donc une
automatisation des transactions, ce qui les rend plus sûrs et plus rapides que les contrats
traditionnels.
II.2.3 Fonctionnement de la blockchain
Pour comprendre le fonctionnement de la blockchain, prenons comme exemple la Fi-

gure II.2 qui explique le processus des transactions effectuées sur le réseau.
Figure II.2 — Fonctionnement de la blockchain.
1. Un nouveau bloc est créé à chaque fois qu’une transaction est envoyée par un utili-
sateur.
2. Les blocs sont ensuite distribués à tous les nœuds connectés du réseau et chacun
d’entre eux dispose d’une copie complète de la blockchain.
3. Une fois que le bloc est diffusé à tous les nœuds connectés, ils effectuent une véri-
fication pour s’assurer que le bloc n’a pas été modifié. Ce processus entier du bloc
étant ajouté sur la blockchain est fait par les nœuds atteignant un consensus où ils
décident quels blocs sont valides pour être ajoutés sur la blockchain et quels blocs
ne le sont pas. Ce processus de validation de la transaction est connu sous le nom
d’exploitation minière et le nœud effectuant cette validation est connu sous le nom
de mineur.
4. Si cette vérification se déroule avec succès, les nœuds ajoutent ce bloc à leur propre
copie de la blockchain et la transaction est terminée.
29
II.2.3.1 Algorithme de consensus
Puisque la blockchain est entièrement reliée à la décentralisation, il n’y a pas de tiers de

confiance responsable de la sécurisation et de la gestion des données ou de la responsabilité
en cas de violations de sécurité. Tous les participants collectent ces transactions dans un
nouveau bloc et commencent à travailler sur le protocole de consensus pour identifier la
validation de la transaction.
Preuve de travail : Dans le modèle preuve de travail, appelé en anglais Proof of Work
(PoW), un utilisateur publie le prochain bloc en étant le premier à résoudre une énigme
computationnelle intensive [44]. La solution à cette énigme est la ”preuve” qu’il a effectué
un travail. L’énigme est conçue de telle sorte que la résolution de l’énigme soit difficile,
mais que la vérification de la validité d’une solution soit facile. Cela permet à tous les
autres nœuds complets de facilement valider tous les blocs proposés suivants, et tout bloc
proposé qui ne satisfait pas l’énigme serait rejeté.
Une méthode d’énigme courante consiste à exiger que la somme de contrôle de hachage
d’un en-tête de bloc soit inférieure à une valeur cible (voir la Figure. II.3).
Nouveau bloc
En-tête du bloc Générer du

hachage Nonce
précédent
Si hash < Non Incrémentation du

valeur cible Nonce
Oui
Publication du
bloc
Figure II.3 — Diagramme explicatif de l’algorithme ”preuve de travail”.
Les nœuds de publication effectuent de nombreuses petites modifications à leur en-

tête de bloc (par exemple, en modifiant le nonce) en essayant de trouver une somme de
contrôle de hachage qui satisfait l’exigence. Pour chaque tentative, le nœud de publication
30
doit calculer le hachage de l’ensemble de l’en-tête de bloc. Le hachage de l’en-tête de bloc

à de nombreuses reprises devient un processus intensif en termes de calcul. La valeur cible
peut être modifiée avec le temps pour ajuster la difficulté (à la hausse ou à la baisse) pour
influencer la fréquence à laquelle les blocs sont publiés.
Preuve d’enjeu : La preuve d’enjeu, appelé en anglais Proof of Stake (PoS), a été propo-
sée pour surmonter les inconvénients de la consommation excessive d’énergie de la preuve
de travail PoW dans le bitcoin. Ethereum utilise la preuve d’enjeu pour parvenir à un
consensus. Au lieu d’investir dans des ressources qui peuvent effectuer des calculs rigou-
reux pour les calculs de hachage en preuve de travail, la preuve d’enjeu propose d’acheter
de la cryptomonnaie et de l’utiliser comme enjeu dans le réseau [44]. L’enjeu est direc-
tement proportionnel à la chance de devenir le validateur de bloc. Pour parvenir à un
consensus, le validateur de bloc est sélectionné de manière aléatoire et n’est pas prédéter-
miné. Les nœuds produisant des blocs valides reçoivent des incitations, mais s’ils ne sont
pas inclus dans la chaı̂ne existante, ils perdent également une certaine quantité de leur
enjeu.
Preuve d’autorité : Le modèle de consensus de la preuve d’autorité (également appelée

preuve d’identité) repose sur la confiance partielle des nœuds de publication grâce à leur
lien connu avec des identités du monde réel [44]. Les nœuds de publication doivent avoir
prouvé leur identité et être vérifiables dans le réseau blockchain (par exemple, des docu-
ments d’identification qui ont été vérifiés et notariés et inclus sur la blockchain). L’idée
est que le nœud de publication engage son identité/réputation pour publier de nouveaux
blocs. Les utilisateurs du réseau blockchain affectent directement la réputation d’un nœud
de publication en fonction de son comportement. Les nœuds de publication peuvent perdre
leur réputation en agissant de manière contraire à l’avis des utilisateurs du réseau block-
chain, tout comme ils peuvent gagner en réputation en agissant de manière conforme à
l’avis des utilisateurs du réseau blockchain. Plus la réputation est basse, moins il y a de
chances de pouvoir publier un bloc. Il est donc dans l’intérêt d’un nœud de publication
de maintenir une réputation élevée. Cet algorithme s’applique uniquement aux réseaux
blockchain autorisés avec des niveaux élevés de confiance.
II.2.4 Types de la blockchain
Les réseaux blockchain sont classés en trois types : publics, privés et consortiaux. Les
blockchains publiques sont ouvertes à tous et sont caractérisées par une décentralisation
totale. Les blockchains privées sont utilisées pour le partage de données privées entre un
31
groupe restreint d’individus ou d’organisations, tandis que les blockchains consortiales

sont partiellement centralisées et sont gérées par un groupe de nœuds prédéfinis.
II.2.4.1 Blockchain publique
Une blockchain publique est une plateforme ouverte où n’importe qui peut rejoindre,
effectuer des transactions et miner, sans restriction [41]. Elle est également connue sous
le nom de blockchain sans autorisation. Tous les utilisateurs ont l’autorité totale pour lire
et écrire des transactions, vérifier la blockchain ou examiner n’importe quelle partie de
celle-ci à tout moment. La blockchain est transparente et il n’y a pas de nœuds validateurs
spécifiques. Le consensus est atteint par l’un des mécanismes de consensus décentralisés
tels que la preuve de travail ou la preuve d’enjeu.
II.2.4.2 Blockchain privée
Une blockchain privée est un système de partage et d’échange de données privées

entre un groupe de personnes ou plusieurs organisations, où le minage est contrôlé par
une organisation ou des individus sélectionnés [41]. Il exige l’autorisation au sens où les
utilisateurs ne peuvent y accéder qu’avec une invitation spéciale. La participation des
nœuds est contrôlée par des règles ou un réseau qui en contrôle l’accès, ce qui le rend
plus centralisé et moins décentralisé que les blockchains publiques. Les nœuds collaborent
pour parvenir à un consensus pour la mise à jour, mais contrairement aux blockchains
publiques, l’écriture est restreinte.
II.2.4.3 Blockchain de consortium
Une blockchain de consortium est une blockchain partiellement privée et avec autorisa-
tion, contrôlée par un ensemble de nœuds prédéterminés qui décident qui peut rejoindre et
miner [41]. Elle utilise un schéma de multi-signature pour la validation de bloc, la rendant
partiellement centralisée. Les autorisations de lecture et d’écriture peuvent être publiques
ou limitées aux participants du réseau, et un consortium contrôlé par une majorité peut
conduire à la manipulation de la blockchain, compromettant ainsi son immuabilité et son
irréversibilité.
II.3 Bénéfices de l’utilisation de la blockchain dans la e-santé
La technologie de blockchain est une innovation majeure dans le domaine de la ges-

tion des données et des transactions. Elle présente un ensemble de caractéristiques qui
la rendent unique et qui ont contribué à son adoption rapide dans divers secteurs. Ces
32
caractéristiques incluent la décentralisation, la transparence, la sécurité, la distribution

et l’immutabilité. Chacune de ces caractéristiques offre des avantages significatifs pour
les entreprises et les particuliers qui utilisent cette technologie pour effectuer des tran-
sactions, stocker des données et échanger des actifs numériques. La compréhension de ces
caractéristiques est essentielle pour comprendre le fonctionnement de la blockchain et les
possibilités qu’il offre.
II.3.1 Decentralization
La blockchain peut apporter des solutions en rendant le système de gestion des données
distribué, où toutes les parties prenantes peuvent contrôler les dossiers médicaux sans avoir
besoin d’une autorité centralisée. De plus, cela encourage l’innovation et l’autonomie, car
chacun peut rejoindre le réseau en tant que nœud et contribuer à son fonctionnement.
La décentralisation dans la blockchain est une avancée importante qui révolutionne de
nombreux domaines.
II.3.2 Robustesse / Disponibilité
Avec le concept de décentralisation, des copies répliquées des informations de santé

sont disponibles sur plusieurs nœuds participants. La disponibilité des données peut être
garantie, de sorte que le système est résilient contre les pertes ou la corruption de données.
II.3.3 Vérifiabilité et immutabilité des données
Grâce à l’utilisation de la blockchain, il devient possible de vérifier l’intégrité et l’au-

thenticité des enregistrements de santé stockés, sans avoir besoin d’accéder aux infor-
mations en texte clair. Chaque bloc contient en effet une valeur de hachage qui sert de
référence pour l’ensemble des transactions enregistrées dans ce bloc. L’immutabilité joue
un rôle crucial dans la sécurité des dossiers de santé stockés sur la blockchain, car elle
garantit que les données, une fois écrites, ne peuvent être ni modifiées, ni corrompues, ni
altérées.
II.3.4 Sécurité et transparence
Les informations enregistrées dans la blockchain sont toutes encodées, horodatées et

organisées dans un ordre séquentiel. La sécurité des données et la confidentialité des infor-
mations des patients peuvent être garanties grâce à l’utilisation de clés cryptographiques
appropriées. La nature ouverte et transparente de la blockchain contribue à instaurer un
climat de confiance au sein des applications de santé distribuées.
33
II.4 Système de fichiers interplanétaire (IPFS)
Le système de fichiers interplanétaire (InterPlanetary File System (IPFS)) est un sys-

tème de stockage et de partage de fichiers décentralisé qui vise à rendre le web plus
ouvert, sécurisé et efficace [47]. En utilisant des contrats intelligents en conjonction avec
IPFS dans le cadre du partage de données médicales, nous pouvons garantir la sécurité, la
confidentialité et la transparence de ces données. IPFS fonctionne en utilisant le principe
de l’adressage par contenu [48], ce qui signifie que chaque fichier ou ensemble de données
est attribué à un identifiant unique basé sur son contenu, plutôt que sur sa localisation.
Cela permet à IPFS de faire référence et de récupérer des données à partir de n’importe
quel nœud qui en possède une copie, ce qui permet une distribution et un accès rapides,
efficaces et décentralisés à de grandes quantités de données.
Les données sont stockées de manière distribuée à travers un grand nombre des nœuds
dans IPFS, plutôt que dans un emplacement centralisé unique. Cela rend non seulement
le système plus résilient aux défaillances et à la censure, mais permet également une
récupération de données plus efficace, car les données peuvent être récupérées à partir du
nœud le plus proche, sans avoir à parcourir tout le réseau [49].
IPFS offre également une gestion de version intégrée, ce qui signifie que les versions
antérieures d’un fichier peuvent être récupérées, même si elles ont été mises à jour ou
supprimées. Cela, combiné à la nature décentralisée du réseau, en fait un outil utile pour
stocker et partager de grandes quantités de données de valeur, telles que les données
médicales, de manière sûre et insensible à la modification.
II.4.1 Système pair à pair de IPFS
L’une des caractéristiques principales d’IPFS est qu’il s’agit d’un réseau pair à pair.
Contrairement au modèle client-serveur où vous avez généralement de nombreux clients
qui consomment à partir d’un seul serveur, avec le modèle pair à pair, chaque ordinateur
(généralement appelé un pair) dans le réseau IPFS joue à la fois le rôle de serveur et de
client. Cela signifie que chaque pair IPFS peut devenir un membre productif du réseau.
Comme illustré dans la Figure. II.4, au lieu de dépendre d’un seul serveur au centre du
réseau auquel les clients se connectent, chaque pair se connecte à plusieurs pairs. Étant
donné que le fichier jpg est stocké sur trois des pairs, deux de ces trois nœuds peuvent être
hors service et le fichier sera toujours accessible au réseau. De plus, n’importe quel nombre
de pairs peut devenir un fournisseur pour le fichier jpg, une fois qu’ils l’ont téléchargé à
partir du réseau [47].
Avec IPFS, les nœuds mettent en commun leurs ressources, telles que la connexion
34
Figure II.4 — Comparaison entre le modèle client-serveur et le modèle pair à pair.
Internet et l’espace disque, et veillent à ce que la disponibilité des fichiers soit résiliente
et décentralisée.
II.4.2 Stockage dans IPFS
Dans IPFS, les données sont adressées par contenu plutôt que par emplacement, rom-
pant ainsi avec le modèle traditionnel client-serveur du web. Cela signifie qu’un même
fichier peut être hébergé sur plusieurs nœuds IPFS, et chaque fichier stocké dans le sys-
tème est identifié par un hachage cryptographique de son contenu, appelé Identifiant de
Contenu ou CID. Ce CID est une longue chaı̂ne de lettres et de chiffres qui est unique à
ce fichier, garantissant son intégrité et permettant son identification précise [50].
IPFS possède également la capacité de découper un fichier en plusieurs blocs en fonction
de sa taille, et chaque bloc se voit attribuer son propre CID. Cette approche permet
d’optimiser l’efficacité du système, en permettant une distribution plus efficace des données
et une récupération plus rapide des fichiers.
L’un des avantages majeurs de l’adressage par contenu est la flexibilité qu’il offre aux
utilisateurs. En effet, il est possible de récupérer un CID à partir de n’importe quel nœud
IPFS tant qu’il y a au moins un nœud qui le fournit au réseau. Ainsi, la disponibilité des
fichiers n’est pas dépendante d’un seul emplacement centralisé, mais plutôt de la capacité
collective des nœuds du réseau à fournir les données demandées.
Cette approche décentralisée et basée sur le contenu rend IPFS résilient aux pannes
et aux changements de serveurs, offrant une meilleure expérience d’utilisation et une plus
grande fiabilité dans l’accès aux données [47].
35
II.5 Blockchain pour les dossiers de santé électroniques (DSE)
Le stockage des dossiers médicaux des patients peut se faire sous forme de dossiers
de santé électroniques DSE, qui sont généralement conservés dans des bases de données
largement distribuées ou centralisées ou sur des serveurs cloud [51]. Le but principal du
stockage des DSE sur une blockchain est de permettre aux patients d’accéder facilement
à leurs dossiers médicaux chaque fois que cela est nécessaire, tout en permettant aux
professionnels de santé d’accéder aux dossiers de manière réglementée [52].
L’interopérabilité est un défi important en ce qui concerne la gestion des dossiers des
patients, et il est préférable que les dossiers des patients soient accessibles à plusieurs
hôpitaux pour améliorer à la fois l’interopérabilité axée sur les patients et celle axée
sur les hôpitaux. En outre, la technologie blockchain peut être utilisée pour authentifier
les transactions sur les dossiers médicaux des patients grâce à l’utilisation de contrats
intelligents [53].
II.5.1 Analyse des études de recherche existantes
Il existe plusieurs méthodes décrites dans la littérature qui utilisent la technologie

de la blockchain pour assurer le partage sécurisé des données de santé. Cependant, la
taille de stockage limitée de la blockchain peut empêcher le stockage des données de santé
échangées. Dans ces cas, il est possible de stocker ces données dans le Cloud ou dans l’IPFS.
Dans les sections suivantes, nous détaillons quelques exemples récents de ces méthodes.
II.5.1.1 Partage des DSE stockés localement via la blockchain
Liu et al. [36] ont élaboré un système de partage de données médicales basé sur la
blockchain, qui permet le stockage, la gestion et le partage sécurisé de ces données, tout
en ayant des coûts de calcul et de communication réduits. Leur modèle de partage et
de protection de données médicales est léger et utilise la technologie de re-encryption
de proxy pour permettre aux médecins de différents hôpitaux de partager des données.
Les informations médicales stockées dans la blockchain sont hautement sécurisées et ne
peuvent pas être altérées facilement. Les auteurs ont également amélioré le mécanisme de
consensus en utilisant une version améliorée du protocole de preuve d’enjeu délégué, ce
qui le rend à la fois sécurisé, fiable et efficace.
Azaria et al. [33] ont présenté un cadre appelé MedRec, qui utilise la technologie de
blockchain pour décentraliser les dossiers de santé. Leur mise en œuvre a utilisé une
catégorie de blockchain publique qui incite les mineurs à extraire de nouveaux blocs en
offrant l’accès à des données cliniques dépersonnalisées. Selon les auteurs, leur approche
36
améliore l’accessibilité, la sécurité et la confidentialité des dossiers de santé. Nchinda

et al. [54] ont construit sur l’architecture de MedRec en incorporant des contrats de
consentement dans la blockchain. Leur système permet aux fournisseurs de rejoindre le
réseau et de fournir aux patients et à d’autres entités autorisées l’accès à leurs bases de
données via leurs identifiants.
II.5.1.2 Partage des DSE via la blockchain et le cloud
Thwin and Vasupongayya [55] ont proposé un modèle de contrôle d’accès utilisant
la technologie blockchain pour les dossiers de santé personnels (Personal Health Re-
cord (PHR)). Les auteurs ont utilisé la re-encryption par proxy comme système de contrôle
d’accès ainsi que d’autres techniques cryptographiques pour préserver la confidentialité
des données. Les enregistrements cryptés ont été stockés dans un cloud tandis que les mé-
tadonnées ont été stockées dans la blockchain. Dans ce modèle, le processus de partage des
données dépend d’un intermédiaire, le serveur mandataire responsable de la re-encryption.
Ainsi, le serveur mandataire est responsable des clés de cryptage et d’autres informations
nécessaires pour le processus d’authentification.
Les travaux de Boumezbeur et al. [37] proposent un cadre sécurisé de partage et de
contrôle d’accès aux dossiers de santé électroniques (DSE) appelé ”BAcP-EHR”, tout en
préservant la vie privée des utilisateurs, dans le contexte de l’étude des méthodes de
gestion des données de santé partagées via la blockchain et le Cloud. Cette proposition
utilise la technologie blockchain Ethereum pour le DSE et garantit le stockage sécurisé des
dossiers électroniques dans le Cloud en spécifiant les autorisations d’accès des utilisateurs
à travers des contrats intelligents de la blockchain. Elle utilise également des primitives
cryptographiques pour chiffrer les DSE et les clés secrètes afin de garantir la confidentialité
des DSE et la vie privée des utilisateurs.
II.5.1.3 Partage des DSE via la blockchain et IPFS
Weiquan Ni et al. [56] ont proposé une architecture appelée ”Healchain” qui comprend
trois couches : la couche utilisateur, la couche Blockchain et la couche de stockage. Dans
la couche utilisateur, différentes sortes de données de santé sont découvertes et collectées
par de nombreux dispositifs portables tels que des bracelets, des gants intelligents, des
montres intelligentes, des bagues intelligentes et des vêtements intelligents. Elles sont
ensuite envoyées via une station de base et un point d’accès wifi à des serveurs spécifiques
agissant en tant que nœuds Blockchain de consortium. Dans la couche Blockchain, les
mineurs coopèrent pour vérifier l’intégrité des données et l’authenticité des utilisateurs
correspondants en examinant les informations d’authentification. Lorsque des données de
37
santé authentiques sont vérifiées, les données sont stockées dans la couche de stockage
IPFS. IPFS est introduit en tant que couche hors chaı̂ne et les données de santé sont
stockées dans l’IPFS, tandis que l’entrée de hachage est enregistrée dans la Blockchain.
L’avantage de ce système est qu’il assure une authentification appropriée des données
grâce à différents processus d’authentification. Il collecte des données en temps réel, ce
qui est très bénéfique pour l’analyse prédictive de la santé des patients.
Honglei et al. [57] présente une méthode sécurisée de partage des DSE, nommée ”BEAS-
IEFS”, dans le cadre de l’étude des méthodes de partage de données de santé via la block-
chain et l’IPFS. Cette méthode repose sur une blockchain Ethereum, nommée blockchain-
based EHR Abstract System (BEAS), qui assure la sauvegarde des résumés des DSE et
le contrôle d’accès, ainsi que sur un système de fichiers interplanétaires (IPFS) nommé
IPFS-based EHR File System (IEFS) qui permet de sauvegarder et partager des DSE de
grande taille. Dans la blockchain BEAS, seules les adresses des hachages des fichiers DSE
générées par l’IEFS sont cryptées par les clés publiques des patients et sauvegardées dans
les résumés DSE.
II.5.2 Comparaison et discussion
Dans cette section, nous discutons l’utilisation de la technologie blockchain pour le

partage des (DSE). Plusieurs solutions ont été proposées par les chercheurs basés sur la
blockchain, telles que MedRec et BEAS-IEFS, qui visent à atteindre la décentralisation
des DSE et à augmenter la simplicité, la sécurité et la confidentialité des informations.
La Table II.1 rapporte quelques critères d’évaluation des plateformes de partage de DSE
existantes. Certains auteurs ont également utilisé des contrats intelligents pour gérer le
contrôle d’accès et l’interopérabilité entre les hôpitaux.
Révocation Recherche
Année Stockage Chiffrement Évolutivité Anonymisation Complexité
de l’accès par mot-clé
[33] 2016 Local ✗ ✓ ✓ ✓ ✗ Élevée
[56] 2019 IPFS ✓ ✓ ✗ ✗ ✗ Moyen
[36] 2019 Local ✗ ✓ ✗ ✗ ✗ Élevée
[37] 2022 Cloud ✓ ✓ ✗ ✓ ✗ Moyen
[57] 2022 IPFS ✗ ✓ ✓ ✓ ✓ Faible
Table II.1 — Comparaison des plateformes de partage de DSE basé sur la blockchain.
Dans ce qui suit, nous mettons l’accent sur quelques aspects nécessitant plus de re-
cherche :
38
— Stockage : Une façon pratique de stocker et de sécuriser les Données de Santé Élec-
troniques (DSE) consiste à les conserver dans la blockchain. Une approche courante
est le stockage On-chain comme dans le cas de MedBlock [35]. Cependant, cette
méthode entraı̂ne une charge de stockage élevée sur le système, et toute modifica-
tion des données ou autorisation d’accès nécessite l’ajout d’un nouveau bloc à la
blockchain. Afin de surmonter les limitations des méthodes On-chain, d’autres ap-
proches stockent les DSE en dehors de la blockchain, appelées Off-chain. Cela peut
être réalisé via le stockage local, comme dans le cas de MedRec [33], le stockage en
cloud, comme dans les cas de BBDS [58] et Boumezbeur et al. [37], ou encore en
utilisant l’IPFS, comme dans les cas de BEAS-IEFS [57].
— Chiffrement : Le rôle essentiel du chiffrement dans les systèmes de partage de dos-
siers médicaux ne peut être sous-estimé. Grâce à l’utilisation de techniques de chif-
frement symétrique et asymétrique, les informations médicales sensibles sont proté-
gées et sécurisées contre tout accès non autorisé, assurant ainsi leur confidentialité
et leur intégrité. Différentes approches ont été proposées pour atteindre cet objec-
tif. D’une part, les méthodes Healchain [56] et Boumezbeur et al. [37] utilisent le
chiffrement symétrique pour sécuriser les DSE. Cela signifie que les données sont
chiffrées à l’aide d’une clé secrète partagée entre les parties autorisées, garantissant
ainsi une protection robuste des informations médicales. D’autre part, les méthodes
MedRec [33], Liu et al. [36], BEAS-IEFS [57] adoptent une approche différente en
conservant les DSE en clair, c’est-à-dire sans les chiffrer. Cependant, ces méthodes
mettent en place des mécanismes de sécurité et de contrôle d’accès rigoureux pour
prévenir les accès non autorisés et garantir la confidentialité des données.
— Evolutivité : Le terme ”Evolutivité” ou ”scalabilité” est généralement utilisé pour
décrire la manière dont un système gère une augmentation du nombre de tâches et
d’opérations, en termes de débit, de latence, de temps de démarrage et de coûts
de transaction. Les méthodes MedRec [33], BBDS [58], Boumezbeur et al. [37],
BEAS-IEFS [57] sont des exemples de travaux qui gèrent correctement l’aspect de
l’évolution, car cet aspect est essentiel au partage de DSE entre différentes entités.
— Anonymisation : Cette méthode permet de préserver l’anonymat des propriétaires
de données lorsqu’ils externalisent leurs informations dans le Cloud ou sur l’IPFS, en
utilisant différentes techniques, telles que l’utilisation de l’adresse de la blockchain
de l’utilisateur. Les méthodes MedRec [33] et BEAS-IEFS [57] sont des méthodes
qui anonymisent les données sans les chiffrer. Cela rend plus difficile l’identification
des propriétaires des données en cas de vol. Les travaux BBDS [58], Boumezbeur
et al. [37] n’assurent pas l’anonymisation des données, Cela indique que ces mé-
39
thodes s’appuient sur le chiffrement afin de compliquer davantage l’identification

des propriétaires des données en cas de vol.
— Révocation de l’accès : L’une des composantes essentielles des méthodes de contrôle

d’accès est la capacité pour les propriétaires de données de révoquer l’autorisation
d’accès des utilisateurs. Cette fonctionnalité est mise en œuvre à l’aide de différentes
techniques, telles que le ré-encryptage par proxy, la fenêtre temporelle et d’autres
techniques. Les methodes MedRec [33], Boumezbeur et al. [37] et BEAS-IEFS [57]
sont des exemples qui garantissent la révocation d’accès.
— Recherche par mot-clé : Il s’agit d’une technique permettant aux utilisateurs de

rechercher des données chiffrées sans avoir besoin de les déchiffrer, afin de préserver
leur vie privée. Parmi les différentes méthodes disponibles, seule l’approche BEAS-
IEFS [57] a abordé la recherche par mots-clés, tandis que toutes les autres méthodes
étudiées ne permettent pas la recherche, même dans le cas de données en clair.
— Complexité : La complexité se réfère généralement à la difficulté ou à l’effort requis

pour mettre en place et maintenir le système. Cela peut inclure plusieurs aspects :
complexité technique, opérationnelle, réglementaire et d’adoption. Cet aspect est
principalement lié aux méthodes de stockage utilisées. Dans le cas du stockage dans
l’IPFS et le cloud, la complexité est modérée à faible, comme dans les méthodes
Healchain [56], Boumezbeur et al. [37] et BEAS-IEFS [57]. Cependant, dans le cas
du stockage local, tel que dans les méthodes MedRec [33] et Liu et al. [36], l’accès
au DSE est très complexe, ce qui rend la complexité globale très élevée.
Cependant, il existe encore des défis à surmonter, tels que la consommation de puissance
de calcul et la capacité de stockage dans la blockchain. Pour résoudre ces problèmes,
certains auteurs ont adopté un design de stockage croisé où seules les informations de
référence sont stockées dans une blockchain et une copie réelle des informations peut être
stockée en utilisant IPFS. Il est clair que l’utilisation de la blockchain pour gérer les
informations de santé est un domaine de recherche en développement qui présente des
avantages prometteurs pour améliorer les soins de santé.
II.5.3 Défis et restrictions
Les systèmes de partage de dossiers de santé électronique (DSE) fondés sur la blockchain
ont le potentiel de résoudre de nombreux problèmes dans le domaine de la santé, tels que
la gestion des données médicales et la sécurité des données. Cependant, ils sont également
confrontés à des défis et des restrictions.
L’un des défis les plus importants est lié à la confidentialité des données [51]. Les
40
informations médicales sont hautement sensibles et doivent être protégées contre l’accès
non autorisé. Les systèmes de partage de DSE basés sur la blockchain doivent s’assurer
que les données ne sont accessibles qu’aux personnes autorisées, tout en garantissant que
les patients ont un contrôle total sur l’accès à leurs propres informations.
Un autre défi est lié à la complexité des données médicales [59]. Les dossiers de santé
contiennent souvent des informations complexes et volumineuses, ce qui peut rendre dif-
ficile leur traitement sur la blockchain. Les systèmes de partage de DSE doivent être
capables de stocker et de traiter efficacement de grandes quantités de données pour être
utiles aux professionnels de la santé.
En outre, la réglementation gouvernementale est également un défi important pour les
systèmes de partage de DSE basés sur la blockchain [60]. Les lois sur la confidentialité des
données médicales varient d’un pays à l’autre et les développeurs doivent s’assurer que
leurs systèmes respectent les réglementations en vigueur. Les réglementations en matière
de protection des données peuvent également changer rapidement, ce qui rend difficile la
conformité à long terme.
Enfin, la sécurité est un défi majeur pour les systèmes de partage de DSE basés sur la
blockchain [60]. Les attaques de pirates informatiques peuvent compromettre la sécurité
des données et les développeurs doivent prendre des mesures pour protéger les informations
médicales stockées sur la blockchain.
En résumé, les systèmes de partage de DSE basés sur la blockchain ont le potentiel
de résoudre de nombreux problèmes dans le domaine de la santé, mais ils sont également
confrontés à des défis et des restrictions liés à la confidentialité des données, à la com-
plexité des données médicales, à la réglementation gouvernementale et à la sécurité. Les
développeurs doivent travailler à surmonter ces défis pour que les systèmes de partage de
DSE basés sur la blockchain soient efficaces et acceptés dans le domaine de la santé.
II.6 Délimitation du contexte de travail
Après avoir examiné la littérature concernant les concepts et les approches liés au
partage sécurisé des dossiers de santé électroniques (DSE) en utilisant la technologie blo-
ckchain, nous avons identifié les limites et les défis des solutions existantes. Dans notre
démarche de développement d’une plateforme de partage des dossiers médicaux, nous nous
sommes concentrés sur la mise en place d’une solution répondant aux critères importants
de notre plateforme. À cet égard, nous nous sommes intéressés à la solution proposée par
BEAS-IEFS [57], qui utilise l’IPFS comme support de stockage des DSE afin de résoudre
le problème de stockage dans la blockchain.
La sécurité de ces plateformes est essentielle pour garantir la confidentialité des pa-
41
tients et respecter les spécifications des données médicales. La méthode de re-chiffrement

proposée par Boumezbeur et al. [37] est la plus appropriée pour répondre aux probléma-
tiques de sécurité en utilisant des technologies de chiffrement symétrique et asymétrique.
De plus, la méthode BEAS-IEFS [57] est l’une des rares à implémenter des mécanismes
de recherche par mots-clés et de déchiffrement des DSE, ce qui est crucial pour notre
plateforme.
Par ailleurs, l’anonymisation et le contrôle d’accès des propriétaires des DSE (les pa-
tients) sont des critères très importants. Ces critères sont pris en compte par la méthode
MedRec [33], mais nous avons apporté des modifications à la façon dont ces méthodes
assurent ces critères afin d’améliorer les performances et la fonctionnalité de notre plate-
forme. Dans le prochain chapitre, nous détaillerons les méthodes choisies et leur mise en
œuvre pour construire une plateforme répondant à toutes les limitations existantes.
II.7 Conclusion
Dans ce chapitre, nous avons présenté la technologie blockchain ainsi que ses bénéfices,
avantages et défis. Nous avons également abordé les enjeux en matière de sécurité liés à
cette technologie et examiné son application dans le domaine du partage des DSE. Ensuite,
nous avons étudié plusieurs travaux dans ce domaine et réalisé une étude comparative pour
identifier les objectifs fonctionnels et les cibles de sécurité nécessaires pour concevoir une
architecture complète pour le système proposé, conformément aux exigences énoncées dans
ce chapitre. Dans le chapitre suivant, nous détaillons notre proposition pour répondre aux
besoins identifiés.
42
Chapitre III
CONCEPTION DE LA PLATEFORME
HEALTHTECH
EMP Chapitre III. Conception de la plateforme HealthTech
III.1 Introduction
Dans le but de répondre aux besoins croissants des institutions de santé, qui souhaitent
un partage sécurisé des dossiers de santé électroniques (DSE) entre les différents acteurs
impliqués, nous proposons une architecture centrée sur le patient et qui assure plusieurs
aspects essentiels de la sécurité, en particulier garantir la confidentialité des informations
médicales sensibles contenues dans les DSE.
En effet, notre objectif est de créer une plateforme qui offre toutes les fonctionnalités
nécessaires pour faciliter le partage des données entre les acteurs de santé. Cela inclut des
mécanismes de consentement clairs, des autorisations d’accès granulaires et des protocoles
de communication sécurisés pour prévenir tout accès non autorisé et assurer le contrôle
approprié des données. Notre travail vise à proposer une plateforme fiable, évolutif et
sécurisé, qui offre ses services aux différents intervenants.
La plateforme proposée, que nous avons dénommée ”HealthTech”, est conçu pour as-
surer un partage sécurisé des données de santé électroniques (DSE) basé sur la blockchain
Ethereum. Cette dernière garantit la sauvegarde des résumés des DSE et le contrôle d’ac-
cès aux DSE via les contrats intelligents. Notre travail contient également une application
web orientée vers les hôpitaux dans le but d’interagir avec la blockchain et de gérer et de
partager les DSE entre différentes organisations.
Nous présenterons dans ce chapitre les grandes lignes de la conception de notre pla-
teforme. En particulier, nous commençons par présenter l’architecture et ses composants
principaux tels que la blockchain, IPFS, l’autorité de santé et les centres de santé. Ensuite,
nous abordons le fonctionnement et l’interaction entre les différents composants. Enfin,
nous présenterons une application web destinée aux hôpitaux, qui représente le centre de
santé de notre plateforme et qui permet d’interagir avec elle et de gérer le dossier de santé
électronique selon des normes universelles.
III.2 Architecture de la plateforme
Comme le montre la Figure III.2, l’architecture proposée comporte quatre modules, à

savoir une autorité de santé, un système utilisateur (Hôpital), un réseau IPFS et un réseau
Blockchain. Ces modules combinés permettraient à notre plateforme de fonctionner.
III.2.1 Autorité de santé
Elle joue le rôle d’une institution de confiance capable de garantir l’authentification des
participants de la plateforme. Cette autorité est responsable du déploiement de l’ensemble
des contrats intelligents sur la blockchain, de la gestion des comptes des utilisateurs et de
45
Utilisateurs
pharmacie
Médecin
Hôpital
Lab
patient
(4.2) publier/consulter le DSE
(3) réponse à la demande

(4
.1
(2
)p
)d
ub
em
(1) inscription
lie
an
r/c
de
on
-p
su
ub
lte
lie
rl
e
r/c
ré
on
su
s
ul
m
te
é
r
autorité sanitaire smart contract
IPFS ADMIN BLOCKCHAIN
Superviser Superviser
Figure III.1 — Architecture de la plateforme
l’administration de l’IPFS.
En supervisant l’inscription des acteurs, l’autorité de santé vérifie l’identité et les qua-
lifications des utilisateurs, garantissant ainsi l’intégrité du réseau et la confiance des par-
ticipants. Elle joue un rôle de surveillance pour prévenir les activités frauduleuses ou non
autorisées, tout en s’assurant que les utilisateurs respectent les politiques et les réglemen-
tations de la plateforme.
Grâce à son rôle central dans la gestion des comptes blockchain et des nœuds IPFS,
ainsi que dans la supervision de l’inscription des acteurs, l’autorité de santé renforce la
confiance et la sécurité au sein de la plateforme de partage des DSE. Sa présence garantit
une gouvernance solide et efficace, favorisant ainsi un échange d’informations médicales
sécurisé et conforme aux normes de confidentialité.
III.2.2 Utilisateurs de la plateforme
Les acteurs principaux qui interagissent avec le système sont :
— Centre de santé : il s’agit d’un établissement dans lequel un professionnel de la santé

exerce ses activités. Cet établissement peut prendre diverses formes telles qu’un
hôpital, un cabinet médical, un laboratoire d’imagerie ou d’analyse, une compagnie
46
d’assurance maladie ou encore un institut de recherche médicale. Afin de présenter

efficacement notre architecture, nous avons développé un système de gestion des
hôpitaux (centres de santé) compatible avec notre plateforme. Ce système intègre
les fonctionnalités nécessaires à une gestion optimale des hôpitaux. Les détails de la
conception et du développement de ce système sont présentés dans la section III.4.
— Acteur de santé : c’est la personne qui représente les fournisseurs de services de

santé. Il interagit directement avec le patient pour lui fournir les services néces-
saires, qu’ils soient médicaux, paramédicaux ou autres. Il peut être un médecin, un
infirmier, un technicien de laboratoire, etc. L’acteur de santé doit obligatoirement
exercer dans une institution ou un centre de santé reconnus par les autorités du
pays.
— Patient : c’est l’individu qui sollicite les services proposés par le système de santé
tels que les soins médicaux, les soins infirmiers, l’aide aux personnes, etc.
III.2.3 Réseau IPFS
Dans la pratique, nous utilisons IPFS pour stocker les fichiers de dossiers médicaux
électroniques et nous publions les adresses de hachage invariables et permanentes des
fichiers DSE sur la blockchain en tant que clés de validation et index d’accès. Dans cette
étude, nous suggérons que les institutions médicales participent à la construction du réseau
IPFS. En d’autres termes, ce réseau est une sorte de système fédéral de serveurs de nœuds
appartenant à chaque institution médicale. Les institutions médicales contribuant aux
serveurs de nœuds ont le droit de demander les DSE stockés dans l’IPFS. Compte tenu
de la diversité des données DSE, nous suggérons que les fichiers de chaque DSE soient
regroupés en un seul fichier, par exemple, un fichier zip, avant d’être soumis à l’IPFS.
III.2.4 Réseau Blockchain
La Blockchain est une entité qui stocke les contrats intelligents, la signature DSE
et les clés cryptées, nous utilisons les contrats intelligents d’Ethereum pour créer des
représentations intelligentes des dossiers médicaux existants qui sont stockés dans des
nœuds individuels sur le réseau. Nous construisons les contrats pour contenir des méta-
données ou un résumé sur le DSE, la propriété de l’enregistrement, les autorisations et
l’intégrité des données. Le système dans sa conception utilise cinq différents contrats
intelligents (Pour plus de détail sur les contrats intelligents, voir l’annexe A) :
❖ Contrat intelligent “HealthAuthority”

Ce contrat offre la possibilité d’identifier, récupérer ou modifier le compte Ethereum
47
propriétaire des contrats intelligents (l’autorité de santé). Par défaut, le propriétaire

du contrat est celui qui l’a initialement déployé sur la blockchain. Ce contrat permet
également l’ajout de plusieurs comptes représentant des sous-autorités de santé. Ses
principales fonctions sont les suivantes :
— addAccount : Cette fonction prend en entrée une adresse blockchain et l’ajoute

à la liste des comptes représentant l’autorité de santé.
— rmAccount : Cette fonction reçoit une adresse et la supprime de la liste des

comptes de l’autorité de santé.
— checkHealthAuthority : Cette fonction prend en entrée une adresse et vérifie

si elle appartient à la liste des comptes de l’autorité de santé.
❖ Contrat intelligent “HealthCenter”

Ce contrat est responsable de la phase d’inscription des établissements de santé tels
que les hôpitaux, les laboratoires, etc. Il englobe les principales fonctions utilisées
exclusivement par l’autorité de santé (le propriétaire du contrat intelligent) pour
enregistrer les nouveaux centres dans la blockchain :
— addHealthCenter : Cette fonction permet d’ajouter de nouveaux centres de

santé au système. Les informations enregistrées dans la blockchain comprennent
l’identifiant, le nom du centre et l’adresse blockchain.
— rmHealthCenter : Cette fonction supprime le centre de santé en utilisant son

identifiant.
— checkHealthCenter : Cette fonction permet de vérifier les informations relatives

aux centres de santé.
❖ Contrat intelligent “HealthActor”

Ce contrat est responsable de la phase d’inscription des professionnels de santé tels
que les médecins, les chercheurs, etc. Il comprend les principales fonctions utilisées
exclusivement par l’autorité de santé pour ajouter ou supprimer les acteurs de santé
dans la blockchain :
— addHealthActor : Cette fonction permet d’ajouter de nouveaux acteurs de

santé au système (par exemple, des médecins, des pharmaciens). Les infor-
mations enregistrées dans la blockchain comprennent l’identifiant, le nom de
l’acteur, l’identifiant du centre d’appartenance, la clé publique et l’adresse blo-
ckchain.
— rmHealthActor : Cette fonction permet de supprimer des acteurs existants de

la plateforme.
48
— checkHealthActor : Cette fonction permet de vérifier l’existence d’un acteur à

partir de son identifiant ou de son adresse blockchain.
— getActorPublicKey : Cette fonction est utilisée par les utilisateurs de la pla-

teforme pour récupérer la clé publique de l’acteur concerné à partir de son
identifiant.
❖ Contrat intelligent “Patient”

Ce contrat est responsable de tous les traitements, manipulations et vérifications
effectués sur les patients et leurs dossiers de santé électroniques (DSE) au sein de
la plateforme. Il comprend les principales fonctions utilisées par les acteurs de santé
pour l’inscription des patients, ainsi que la demande de consultation ou de publica-
tion de DSE.
1. Fonctions d’inscription :
— addPatient : Ajoute un nouveau patient dans la plateforme par l’autorité.

Les informations enregistrées dans ce contrat comprennent l’identifiant,
le nom, l’adresse blockchain, la clé publique et l’adresse de l’instance du
contrat intelligent ”EHR” associée à ce patient.
— rmPatient : Supprime un patient.
— checkPatient : Vérifier l’existence d’un patient par l’identifiant ou l’adresse

blockchain.
— getPatientByIndex : Utilisée par les utilisateurs pour récupérer les infor-

mations du patient à partir de son identifiant.
2. Fonctions utilisées pour les demandes :
— sendRequest : Permet aux acteurs de santé d’envoyer une demande au

patient concernant son DSE. Elle prend en entrée l’identifiant du patient,
le type de demande (publication ou consultation) et l’identifiant du DSE.
— verifyAuthorization : Permet de vérifier l’état d’une demande par l’acteur

de santé.
— setResponse : Utilisée par le patient pour répondre à une demande.
— getRequestByIndex : Utilisée par les patients et les acteurs de santé pour

consulter les informations d’une demande dans la blockchain.
3. Fonctions utilisées pour les résumés de DSE :
— getEHR : Fournit les résumés des DSE aux médecins ou aux patients. Elle
reçoit en entrée l’identifiant du patient et du DSE.
49
— shareEHR : Utilisée par l’acteur de santé pour publier des DSE dans la
plateforme. Elle reçoit les informations nécessaires sur les DSE.
❖ Contrat intelligent “EHR”
Ce contrat est spécifique à un seul patient (chaque patient possède une instance du
contrat ”EHR”). Il est chargé de toutes les opérations relatives aux dossiers de santé
électroniques (DSE), telles que l’ajout, les requêtes et les autorisations concernant
le DSE du patient. Ce contrat ne peut être utilisé qu’à partir du contrat intelligent
”Patient”, donc toutes les fonctions de ce contrat sont utilisées par les fonctions du
contrat ”Patient” :
— addEHRAbstract : Permet d’ajouter des résumés de DSE associés au patient
propriétaire du contrat.
— getEHRAbstract : Cette fonction est utilisée uniquement par le propriétaire,
c’est-à-dire le patient, pour consulter son DSE.
— getEHRbyActor : Cette fonction est utilisée si un acteur souhaite consulter le
DSE d’un patient.
— setRequest : Cette fonction est utilisée par l’acteur de santé à partir du contrat
”Patient” pour ajouter des demandes associées à ce patient.
— setResponse : Cette fonction est utilisée par le patient pour répondre aux
demandes.
III.3 Fonctionnement de la plateforme
Après avoir présenté les différents composants de notre architecture dans la section
précédente, nous allons détailler dans cette section les interactions entre ces composants
ainsi que les procédures garantissant le bon fonctionnement de notre plateforme. Tout
d’abord, nous pouvons résumer le fonctionnement de notre plateforme à travers quatre
principales procédures : l’inscription auprès de l’autorité de santé, la demande d’autorisa-
tion effectuée par l’acteur de santé au patient, comprenant les deux types de publication
et de consultation. La troisième procédure concerne la publication des DSE dans la pla-
teforme par l’acteur de santé (par exemple, un médecin). La dernière procédure concerne
la consultation des DSE et ses différentes étapes. Les détails de chaque procédure seront
abordés dans les sections suivantes.
III.3.1 Inscription des participants
Nous distinguons trois types d’intervenants : le patient, le centre et l’acteur de santé.

L’autorité de santé est chargée de gérer séparément l’identité des intervenants afin d’éviter
50
toute collision potentielle lors de l’ajout de nouvelles entités au système.

La première partie de cette étape se déroule en mode Off-chain, où les intervenants
soumettent leurs demandes d’enregistrement en remplissant des formulaires contenant
leurs informations personnelles, professionnelles ainsi que les informations relatives au
rôle visé au sein de la plateforme. Cette demande est accompagnée du transfert du dossier
d’inscription comprenant des documents tels que l’acte de naissance, la carte d’identité
ou professionnelle, les diplômes, le statut administratif, etc.
La deuxième partie, qui concerne l’inscription et la gestion des intervenants dans la
blockchain, est exclusivement gérée par l’autorité de santé, la seule entité habilitée à
accepter ou refuser une demande d’enregistrement. Cela se fait après vérification du dossier
soumis par le demandeur.
III.3.2 Demande d’autorisation
Dans notre plateforme, le patient reçoit un DSE après son interaction avec l’acteur de
santé dont une copie de ce document est immédiatement stockée localement via le système
d’information du centre de santé. Afin de garantir la confidentialité des données médicales
du patient, il est recommandé de crypter le document avec une clé secrète du système du
centre de santé d’accueil avant de le stocker dans les bases de données dédiées. Seuls les
utilisateurs autorisés ont accès aux informations stockées. Pour permettre l’accès au DSE
du patient aux autres intervenants, notre système propose de publier le document dans le
réseau IPFS. Cette publication nécessite cependant une autorisation préalable du patient.
Une fois que le patient a interagi avec l’acteur de santé pour lui créer son DSE, ce dernier
lui demande d’autoriser la publication ou la consultation de son DSE. À cette fin, l’acteur
de santé utilise la fonction ”sendRequest” du contrat intelligent ”Patient” pour établir une
demande d’autorisation de publication ou de consultation du DSE. Cette demande inclut
l’identifiant du patient, le type de demande et, dans le cas d’une demande de consultation,
l’identifiant du DSE concerné. La Table. III.1 illustre la structure d’une demande dans la
blockchain et la Figure III.2 schématise les différentes vérifications et procédures (en cas
d’échec) nécessaires pour ajouter une nouvelle demande dans la blockchain.
Une fois créée, cette demande est soumise au patient concerné pour validation. La
Figure III.3 illustre les interactions entre les différentes entités impliquées dans la création
d’une demande et la réponse du patient. Comme le montre la partie gauche de la figure, le
médecin (demandeur) commence par identifier le DSE spécifique à consulter en effectuant
une recherche par mots-clés dans les résumés des DSE stockés dans la blockchain.
51
Attribut Description
RequestID L’identifiant de la demande.
ActorID L’identifiant de l’utilisateur de l’acteur de santé (médecin).
Pour enregistrer l’heure exacte à laquelle le patient répond à cette de-
Timestamp
mande.
RequestType Le type de la demande (publication ou consultation).
L’état de la demande initialement est ”PENDING”, puis il peut passer à
State
l’état ”ACCEPTED” ou ”REJECTED”.
La clé utilisée pour chiffrer le DSE dans l’IPFS. Lors de la création, ce
secretKey champ est vide, puis le patient le remplit avec la clé secrète chiffrée par
la clé publique du médecin.
L’adresse de fichier DSE dans IPFS. Ce champ est vide initialement, puis
ipfsAddress le patient le remplit avec l’adresse IPFS chiffrée par la clé publique du
médecin.
Table III.1 — Structure d’une demande stockée dans la blockchain.
Une fois que le DSE est identifié, une demande d’autorisation de consultation du DSE
est établie et adressée au patient concerné. Pour valider cette demande, le patient suit les
étapes suivantes :
1. Récupération du DSE concerné en utilisant la fonction ”getEHRByIndex” en four-

nissant l’identifiant du DSE.
Vérification de
Demande d'authorisation Non Signalement d'une anomalie
l'identité de l'acteur
de publication / consultation de santé à l'autorité de santé.
Oui
Informer l'acteur de santé : Non Vérification de

le patient n'existe pas. l'identité du patient
Oui
Informer l'acteur de santé : Oui La demande a Non Création de la demande et

la demande existe. déjà été réalisée. notification au patient.
Figure III.2 — Diagramme explicatif des vérifications requises pour l’accomplisse-

ment d’une demande.
52
2. Déchiffrement de la clé secrète et de l’adresse IPFS à l’aide de sa clé privée.
3. Obtention de la clé publique du médecin à partir de la blockchain en utilisant la

fonction ”getActorPubKey”.
4. Chiffrement de l’adresse IPFS et de la clé secrète avec la clé publique du médecin.
5. Validation de la demande d’autorisation de consultation en utilisant la fonction

”setResponse” du contrat intelligent ”Patient”. Le patient fournit l’identifiant de la
demande, la réponse (acceptation ou refus) et les deux valeurs ”IPFSAddress” et
”secretKey” chiffrées avec la clé publique de l’acteur de santé (médecin), en cas
d’acceptation. Ces valeurs seront utilisées ultérieurement par l’acteur de santé.
:Médecin :Blockchain :Patient
dispatch
getEHR(patient_id)
Identification du return
DSE
search(key_word)
sendRequest(patient_id, rType, ehr_id)
Creation d'une addRequest()

demande event(req)
getEHRByIndex(ehr_id)
return
Récupération du
DSE et de la clef getActorPubKey(actorID)
publique du
médécin return
encrypt(ipfsAddr,
secretKey)
setResponse(req_id, ipfsAddr,
secretKey, state)
Réponse event()
return
Figure III.3 — Diagramme de séquence pour la demande de consultation.
Dans notre proposition, l’autorisation a une période de validité d’un (1) jour. Cela per-
met d’accorder plus de temps à l’acteur de santé pour profiter davantage de l’autorisation
accordée à ce DSE. Une fois que la période de validité est écoulée, l’autorisation n’est plus
valable, et sa révocation est effectuée de manière systématique.
53
III.3.3 Publication des DSE
Après avoir reçu la notification d’autorisation de publication du DSE via la communi-

cation On-chain, l’acteur de santé commence la procédure de publication, la Figure III.4
illustre les différentes interactions entre les composants de la plateforme pour publier un
DSE, ainsi chaque étape est détaillée comme suit :
:Médecin :Blockchain :IPFS :Patient
dispatch
getPatientByIndex(p_id)
Obtient la clé
publique du
return
patient.
post(EHR)
Publier le DSE ipfsHashAddress
dans l'IPFS
encrypt(ipfsAddr,
Publier le sucretKey)
résumé du
addEHRAbstract()
DSE
event()
Figure III.4 — Diagramme de séquence pour la publication des DSE.
1. D’abord, l’acteur de santé récupère la clé publique du patient. Cela est réalisé en uti-
lisant la fonction ”getPatientByIndex” du contrat intelligent ”Patient” on lui donne
l’identifiant du patient (patientID), qui renvoie les informations du patient, y com-
pris sa clé publique.
2. Après cela, le fichier DSE est crypté à l’aide d’une clé secrète générée aléatoirement
en utilisant le chiffrement symétrique AES-256. Ce fichier crypté est ensuite envoyé
au réseau IPFS pour être publié. En retour de cette étape, l’acteur de santé reçoit
l’adresse de hachage du DSE.
3. Cette adresse de hachage et la clé secrète sont ensuite cryptées à l’aide de la clé
publique du patient. Ensuite, l’acteur de santé procède à la publication des données
relatives au DSE dans la blockchain en utilisant la fonction ”shareEHR” du contrat
intelligent ”Patient”, la structure de donner qui représente un DSE dans la blockchain
est illustrée dans la Table III.2.
4. Après l’achèvement de cette opération, le patient est informé de la publication de
son DSE grâce à une communication On-chain. De plus, la référence de ce DSE est
enregistrée dans la liste des DSE publiés, qui est visible dans son compte utilisateur.
54
Attribut Description
EHR ID L’identifiant de DSE.
Le titre du DSE récapitule brièvement le sujet global abordé (pour
Title
la recherche du DSE en utilisant des mots-clés).
L’identifiant utilisateur de l’acteur de santé (par exemple, un mé-
ActorID
decin).
Signature La signature du médecin sert à authentifier le résumé du DSE.
La clé utilisée pour crypter le DSE du patient avant de le stocker
SecretKey
dans l’IPFS.
L’adresse hashée du DSE dans IPFS, qui est cryptée et utilisée
ipfsAddress
comme index des fichiers DSE.
Table III.2 — Illustration d’un résumé de DSE.
III.3.4 Consultation des DSE
Pour garantir une consultation sécurisée des DSE, voici les étapes suivantes illustrées
dans la Figure III.5 :
1. Une fois l’autorisation de consultation obtenue, l’acteur vérifie cette autorisation en

utilisant la fonction ”verifyAuthorization” du contrat ”Patient”.
:Médecin :Blockchain :IPFS
dispatch
verifyAutorisation(req_id)
Vérification de
l'autorisation de return
consultation
getRequestByIndex(req_id)
Obtention de la
clé et de (ipfsAddr, sucretKey)
l'adresse IPFS
decrypt(ipfsAddr, sucretKey)
get(ipfsHashAddress)
Obtention du
DSE et EHR
déchiffrement
decrypt(EHR)
getActorPublicKey(actorID)
Vérification de public_key
l'intégrité
verify(hash, signature)
Figure III.5 — Diagramme de séquence pour la consultation des DSE.
55
2. Ensuite, l’utilisateur du DSE utilise la fonction ”getRequestByIndex” en mode On-

chain pour récupérer l’adresse IPFS du DSE et la clé de chiffrement. Ces informations
sont chiffrées avec la clé publique du demandeur (chiffrées par le patient lors de
l’acceptation de la demande).
3. Après le déchiffrement, l’adresse IPFS permet à l’utilisateur du DSE d’interroger le

réseau IPFS et de récupérer le DSE crypté. Une fois que le DSE crypté est reçu,
l’utilisateur du DSE initie le processus de déchiffrement.
4. Enfin, l’utilisateur du DSE vérifie l’intégrité du DSE en comparant le hachage du

DSE avec la signature existante dans le résumé du DSE. Pour cela, il utilise la clé
publique du médecin (celui qui a publié ce DSE), qui est obtenue en utilisant la
fonction ”getActorPublicKey” du contrat intelligent ”HealthActor”.
III.4 Réalisation d’une application pour les hôpitaux
Dans cette section, nous présentons les étapes de réalisation de notre application web
qui représente le centre de santé dans notre système. L’objectif est de vérifier les fonction-
nalités de notre système et de faciliter l’interaction entre les différents utilisateurs de la
plateforme. Nous commençons par la spécification des besoins de notre application, ainsi
que les besoins fonctionnels et non fonctionnels. Ensuite, nous présentons l’architecture
de l’application, la modélisation conceptuelle, ainsi que le diagramme de cas d’utilisation
qui permet d’illustrer et de définir le contexte et les exigences des parties essentielles de
notre système.
Dans notre démarche de conception, nous avons suivi la norme FHIR de HL7 pour éviter
les problèmes d’interopérabilité. Pour clarifier l’avantage d’utilisation de la blockchain,
celle-ci encapsule l’interopérabilité du système, car tous les acteurs interagissent avec
la blockchain et utilisent les mêmes fonctions. Nous avons échangé les données selon le
format JSON, qui est l’un des formats de la norme FHIR les plus utilisés et qui facilite la
structuration du DSE.
Le DSE est structuré selon l’implémentation de l’organisation Health Design Chal-
lenge 1 , qui a créé cette structuration pour contenir toutes les informations nécessaires
avec respect des nomenclatures existantes dans le domaine médical.
III.4.1 Spécification des besoins
Afin de mettre en place notre plateforme, nous avons identifié un ensemble de besoins
fonctionnels et non fonctionnels lors des étapes initiales. Dans cette section, nous allons
1. http://healthdesignchallenge.com/(consulté le 12/03/2023)
56
décrire ces besoins en détail.
III.4.1.1 Spécification des besoins fonctionnels
Notre application doit remplir des fonctionnalités qui assurent une gestion efficace de
ces composants. Ces fonctionnalités sont décrites sous forme d’un ensemble de besoins
fonctionnels. Les besoins que notre plateforme couvre sont divisés en deux types : les
besoins qui interagissent avec notre système, tels que les demandes d’autorisations, le
partage et la consultation des DSE, et des besoins supplémentaires utilisés localement
dans les hôpitaux pour une bonne utilisation de l’application. Il s’agit notamment de
l’authentification des utilisateurs, la gestion des profils (administrateur, médecin, employé
et patient), la gestion des rendez-vous et la gestion des dossiers de santé électroniques.
Nous allons détailler chacune de ces fonctionnalités dans la suite :
1. Authentification des utilisateurs : L’authentification des utilisateurs est l’un des

défis clés dans la gestion des données médicales. Il est important de s’assurer que
seules les personnes autorisées ont accès aux données médicales, afin de protéger la
confidentialité des patients.
2. Gestions de profils : La création de nouveaux comptes pour les différents utilisa-

teurs (administrateurs, médecins, patients et employés) dans l’application est géné-
ralement gérée par les administrateurs de chaque hôpital, en suivant le protocole
propre à chaque centre de santé.
3. Gestion des autorisations de consultations et de partage : Le patient est le res-

ponsable direct de ses données médicales. Si un médecin a besoin d’accéder à son
historique, il doit obtenir l’autorisation du patient. La gestion des autorisations est
gérée via la blockchain pour garantir la sécurité des données des patients. Les pa-
tients peuvent accéder à leurs propres données médicales et partager ces informations
avec des professionnels de santé de leur choix.
4. Gestion de dossier de santé électronique : La gestion de l’historique des patients

dans une blockchain consiste à stocker et à partager les informations de santé des
patients de manière sécurisée et transparente en utilisant la technologie blockchain.
Cela permet aux professionnels de la santé d’accéder aux informations de santé des
patients de manière rapide et efficace, ce qui facilite la coordination des soins et
améliore la qualité des soins.
Permets aussi de créer de nouveaux DSE pour les patients, avec un niveau de détail
et une implémentation conformes aux normes universelles.
5. Gestion des rendez-vous : Les patients peuvent prendre des rendez-vous qui sont
57
créés par les employés de chaque service. Les rendez-vous sont attachés à des méde-
cins spécifiques qui peuvent voir l’ensemble des rendez-vous créés et gérer l’état des
rendez-vous, qu’ils soient terminés ou non. Les patients peuvent également consulter
la liste des rendez-vous en attente et accéder à l’historique de leurs rendez-vous.
III.4.1.2 Spécification des besoins non fonctionnels
Les exigences non fonctionnelles sont toutes les exigences qui définissent des critères
pouvant être utilisés pour évaluer le fonctionnement d’un système. Dans ce qui suit, nous
allons présenter les besoins non fonctionnels intégrés dans notre plateforme.
1. Sécurité : L’application doit garantir la confidentialité et l’intégrité des données

médicales en utilisant des protocoles de chiffrement et d’authentification robustes.
Il est également important de mettre en place des mesures de sécurité pour protéger
contre les attaques de phishing et les piratages informatiques.
2. Interopérabilité : L’application doit être capable de s’intégrer facilement à d’autres

systèmes médicaux existants pour faciliter le partage des données médicales entre
les différents acteurs de la santé. Il est important de s’assurer que l’application est
conforme aux normes de l’industrie pour faciliter l’interopérabilité avec d’autres
systèmes.
3. Scalabilité : L’application doit être capable de gérer une croissance future de la base
de données médicales et de la population d’utilisateurs. Il est important de concevoir
l’application pour être évolutive pour répondre aux besoins futurs.
4. Disponibilité : L’application doit être disponible en tout temps pour les utilisateurs
autorisés pour accéder aux données médicales. Il est important de maintenir des
niveaux élevés de disponibilité pour garantir que les professionnels de santé peuvent
accéder aux informations de santé des patients en temps opportun.
5. Performance : L’application doit être capable de gérer efficacement de grandes quan-

tités de données médicales et de gérer les demandes de données en temps réel. Il
est important de maintenir des niveaux élevés de performance pour garantir que
les professionnels de santé peuvent accéder aux informations de santé des patients
rapidement et efficacement.
6. Fiabilité : L’application doit être capable de gérer des erreurs et des pannes de
manière efficace pour minimiser les temps d’arrêt et garantir la disponibilité des
données médicales. Il est important de concevoir l’application pour être fiable pour
garantir que les professionnels de santé peuvent accéder aux informations de santé
des patients en tout temps.
58
7. Facilité d’utilisation : L’application doit être intuitive et facile à utiliser pour les
professionnels de santé et les patients. Il est important de concevoir l’application
pour être simple d’utilisation pour garantir qu’elle est utilisée efficacement et qu’elle
améliore la qualité des soins.
III.4.2 Modélisation de l’application
La conception de notre application de partage de dossiers médicaux sur une blockchain

privée repose sur des normes de conception logicielle rigoureuses, visant à assurer une
utilisation optimale de la technologie blockchain en termes de scalabilité, de sécurité et
de performance. Notre objectif est de fournir un système robuste et fiable qui répond
aux besoins spécifiques des hôpitaux et garantit la confidentialité des données médicales
sensibles.
Pour atteindre ces objectifs, notre application est conçue avec une architecture mo-
dulaire et évolutive. Nous avons soigneusement étudié les aspects de scalabilité afin de
permettre une gestion efficace des dossiers médicaux.
En ce qui concerne les performances, nous avons optimisé notre application pour mi-
nimiser les temps de réponse et assurer une expérience utilisateur fluide. La conception
logicielle tient compte des exigences spécifiques du secteur médical, en permettant un
accès rapide et fiable aux dossiers médicaux.
Les étapes de conception et de développement sont plus détaillées dans l’annexe C.
III.4.2.1 Architecture de l’application
Dans notre application, nous avons délibérément opté pour une architecture orientée
service afin de maximiser sa flexibilité, sa scalabilité et sa maintenabilité. Cette approche
se traduit par une conception modulaire, où chaque fonctionnalité est encapsulée dans un
service indépendant. Cette architecture permet une séparation claire des responsabilités
et favorise la réutilisation des services à travers différents modules de l’application.
Grâce à cette approche, nous pouvons facilement ajouter de nouvelles fonctionnalités
en développant des services distincts et en les intégrant sans perturber le reste du système.
Cela nous permet également de faire évoluer notre application en distribuant les services
sur plusieurs serveurs, ce qui améliore les performances et la résilience en cas de pannes.
Pour garantir pleinement la réalisation de nos objectifs, nous avons mis en place un
écosystème d’API robuste qui facilite l’interconnexion entre le backend et le frontend de
notre application (voir la Table. III.3). Ces API jouent un rôle essentiel dans la transmis-
sion fluide des données et des fonctionnalités, permettant ainsi une expérience utilisateur
optimale.
59
API Méthodes
/login post
/logout post
/admin/<id>/ get - put - patch - delete
/admin/<id>/resetPassword/ post
/service/ get - post
/service/<id>/ get - put - patch - delete
/doctor get - post
/doctor/<id>/resetPassword/ post
/employee get - post
/employee/<id>/ get - put - patch - delete
/employee/<id>/resetPassword/ post
/patient get - post
/profile get
/hospital get - post
/appointment get - post
/appointment/<id> get - put - patch
/record/ get - post
/record/<id> get
Table III.3 — API de l’ensemble des fonctionnalités et de leurs méthodes.
Les API que nous avons développées offrent une interface claire et structurée, permet-
tant à la partie frontend d’accéder aux fonctionnalités et aux données du backend de
manière efficace et sécurisée. Chaque API est conçue pour répondre à des besoins spéci-
fiques, offrant des points d’accès définis pour les différentes opérations et les services de
notre application.
L’architecture de nos API conçue de manière à être évolutive et adaptable. Nous avons
adopté des normes et des protocoles modernes, en choisissant Representational State
Transfer (REST), afin d’assurer une intégration flexible et une communication efficace
entre le frontend et le backend. Cela nous permet de développer et de déployer de nou-
velles fonctionnalités rapidement, tout en maintenant stabilité et cohérence au sein de
notre application.
60
III.4.2.2 Diagrammes des cas d’utilisation
Le diagramme de cas d’utilisation est un outil crucial pour organiser les besoins et dé-
montrer les grandes fonctionnalités du système. Il présente le comportement du système du
point de vue de l’utilisateur. Notre application comporte quatre types d’acteurs clés : l’ad-
ministrateur, le médecin, l’employé et le patient, ainsi que d’autres acteurs secondaires tels
que la blockchain. La Figure III.6 montre comment l’application est modélisée en termes
de gestion des utilisateurs et des DSE, en utilisant un diagramme de cas d’utilisation.
Gestion
Gestion des
des
médecins
médecins
Gestion des Gestion

Gestion des
des
profils employes
employes
Gestion
Gestion des
des
Administrateur
<<include>> patients
patients
Voir les <<include>>
statistiques de
l'hopital
Gestion des
admins
Gestion des <<include>>
services et ces S'authentifier
composants
<<include>>
Voir Profil
<<include>>
<<include>>
Gestion
Gestion des
des
rendez-vous
rendez-vous
Employe
<<include>>
<<include>>
Voir liste des

médecins Blockchain
Partage de DSE
Voir liste des

employes <<extend>>
Accéder à
l'historique des soins
au
médicaux
tor
<<extend>>
isé
Au l'his
tor to
à
le
Gestion des
isé riqu
pa
Médecin
rta
l'a e
DSE des patient

ge
cc
ès
<<include>>
Voir profil
<<include>>
Voir l'historique
<<include>>
Voir les DSEs Patient
Voir les patiens Faire des Voir les rendez-
des patiens consultations vous
Figure III.6 — Diagramme des cas d’utilisation de l’application.
L’administrateur a un rôle crucial, notamment celui de gérer les différents profils de

l’application (création, modification et suppression), et il est responsable de la gestion des
61
composants du centre tels que les services et les laboratoires. Le médecin, quant à lui, est
responsable de la gestion des DSE en termes de création et de partage sur la blockchain. Il
y a également l’employé, dont l’objectif est de réaliser les tâches relatives à chaque service,
telles que la gestion des rendez-vous. Tout accès au dossier patient doit être autorisé par
le patient et vérifié par la communauté de la blockchain pour garantir la sécurité et la
confidentialité des données médicales.
III.4.2.3 Modélisation conceptuelle des données
Pour parvenir à une conception complète de notre application, nous présentons dans la
Figure III.7 la modélisation conceptuelle des données qui représente les différentes entités
de l’application ainsi que la structure du DSE. Le Modèle Conceptuel des Données (MCD)
a pour objectif d’écrire de manière formelle et abstraite les données qui seront utilisées
par le système d’information. Le MCD contient quatre tables représentant les différents
utilisateurs de l’application, tels que l’administrateur, l’employé, le médecin et le patient.
L’employé est en relation avec la table des rendez-vous, ce qui lui confère la responsabilité
de la création des rendez-vous. Chaque rendez-vous est lié à la fois à un médecin et à un
patient.
La table de consultation est une table essentielle qui représente le dossier de santé
électronique et permet la création d’un DSE conforme aux normes de standardisation.
Chaque consultation contient des informations essentielles telles que le titre, la date, et
est associée à la table du médecin et au service correspondant. Chaque dossier de santé
peut contenir un résumé de consultation comprenant un compte rendu qui peut inclure
les maladies, les médicaments, les allergies et les traitements. Il est également possible
d’ajouter des analyses de laboratoire. Le MCD contient d’autres tables supplémentaires
qui sont ajoutées pour assurer l’efficacité et une utilisation optimale de l’application.
62
EMP
allergie role AppartientE
nom Caractère long id_role <pi> Numérique <O> 0,n a
Employé 1,1
0,n reaction Caractère long description_role Caractère long variable
1,1
gravité Caractère long Identifiant_1 <pi> matricule_E <pi> Numérique <O> 0,n
... Identifiant_1 <pi>
1,1
AppartientES
1,n
contient_allergie AppartientSM Appartient
1,1 M Heritage_E_P Hopital
id_hopital <pi> Numérique <O>
1,n
Maladie 1,n nom_hopital Caractère long variable
adresse_hopital Caractère long variable
code_maladie <pi> Numérique <O> 0,n Service fax Numérique
Personne
lib_maladie Caractère long variable 0,n
code_service <pi> Numérique <O> nom Caractère long Identifiant_1 <pi>
Identifiant_1 <pi> 1,n ...
lib_service Caractère long prenom Caractère long
... Engendrer appartientMS
chef_service Caractère long numero_telephone Numérique 1,n
0,n Identifiant_1 <pi> photo Image
... date_de_naissance Date
contient_maladie
sexe Caractère long FaireE
date_inscription Date
0,n 0,n email Caractère long variable
password Caractère long variable
compte rendu
code_compte_rendu <pi> Numérique <O> Demander
description Caractère long variable 0,n
Identifiant_1 <pi>
... Heritage_Personne
0,n 1,1 1,1 1,1
0,n 0,n
Contient_m
Médecin RendezVous
Chapitre III. Conception de la plateforme HealthTech

Consultation matricule_M <pi> Numérique
1,1 code_rendezvous Numérique
contient_resume grade_scientifique Caractère long date_rendezvous Date
code_consult <pi> Numérique <O> 1,1 recevoir AppartientA
1,n date_consult Date 1,n Identifiant_1 <pi> 0,n lib_rendezvous Caractère long variable
Identifiant_1 <pi>
Médicament ...
code_medicament <pi> Numérique <O> 1,1 0,n 1,1 1,1 0,n 1,1
63
nom_medicament Caractère long variable

praticien
dose Réel résumé
quantité Numérique
description Caractère long variable contientFE
note Caractère long
concerne
Identifiant_1 <pi>
... 0,n
pour_m
0,n
Metier
code_metier Numérique
Analyses 1,n lib_metier Caractère long variable
composant <pi> Caractère long <O>

résultat Réel 0,n Patient
unité Caractère long variable matricule_P <pi> Numérique
norme Réel situationFamilliale Caractère long variable
Identifiant_1 <pi> taille Numérique
... poids Réel court
group_sanguin Caractère long pour_p
Identifiant_1 <pi> 0,n
habite a
Adresse
1,n 1,1
id_addr <pi> Numérique <O>
lib_addr Caractère long variable
wilaya Caractère long
region Caractère long
Identifiant_1 <pi>
...
Faire
Administreur
matricule_A <pi> Numérique 1,1
role_admin Caractère long
Identifiant_1 <pi> 0,n
1/1
Figure III.7 — Modèle conceptuel de données de l’application.

III.5 Conclusion
Le développement d’une plateforme pour le partage des dossiers médicaux sur une blo-
ckchain privée nécessite une architecture globale qui regroupe ses différentes composantes,
telles que décrit dans les chapitres I et II. Pour bien mener la réalisation de notre pla-
teforme, nous avons suivi des standards universels pour le développement de dossiers de
santé électronique afin de résoudre le problème d’interopérabilité. Ainsi, nous avons opté
pour un développement modulaire dans la plateforme pour les différents composants, et
nous avons utilisé des nouvelles technologies émergentes pour que la plateforme réponde
à nos besoins et permette une utilisation sécurisée des différentes fonctionnalités avec le
respect de la vie privée des patients.
Dans ce chapitre, nous avons donné les objectifs de notre travail, puis nous avons
détaillé l’architecture proposée qui répond aux besoins de notre plateforme. Nous avons,
dans un premier temps, présenté l’architecture et ses composants principaux tels que
la blockchain, IPFS, l’autorité de santé et les utilisateurs finaux. Nous avons, par la
suite, décrit son fonctionnement et la séquence d’événements qui la régissent. Enfin, pour
l’interaction avec notre plateforme proposée, nous avons présenté la conception et les
étapes de réalisation d’une application web orientée vers les hôpitaux, qui a pour but
d’interagir avec la plateforme pour le partage des dossiers médicaux.
64
Chapitre IV
RÉALISATION DE LA PLATEFORME
HEALTHTECH
EMP Chapitre IV. Réalisation de la plateforme HealthTech
IV.1 Introduction
La création d’une plateforme de partage de dossiers médicaux sur une blockchain pri-
vée est un défi complexe en raison des difficultés liées à la mise en œuvre d’un réseau
blockchain et IPFS, ainsi qu’à l’intégration de ces composantes dans l’application web
développée pour faciliter son utilisation par les utilisateurs finaux. Afin de concrétiser
les fonctionnalités proposées par notre conception, nous avons développé les principales
fonctionnalités de notre plateforme afin d’évaluer le travail réalisé dans le cadre de ce
projet.
Dans ce chapitre, nous présentons notre plateforme développée et ses fonctionnalités.
Tout d’abord, nous commençons par la présentation du réseau blockchain, expliquant les
étapes de sa mise en œuvre et toutes les technologies utilisées pour son déploiement. En-
suite, nous présentons le système de stockage IPFS. De plus, afin de tester pleinement
les différentes fonctionnalités de notre plateforme, nous présentons l’application web dé-
veloppée pour les hôpitaux, représentant un centre de santé que nous avons proposé dans
notre système. Enfin, nous terminons ce chapitre par une analyse des performances de
notre système.
IV.2 Mise en œuvre d’un réseau blockchain
Les réseaux blockchain sont des infrastructures décentralisées et sécurisées qui per-
mettent de stocker et de partager des données de manière transparente. La technologie
blockchain repose sur un réseau distribué de nœuds qui valident et enregistrent les tran-
sactions de manière chronologique dans des blocs. Chaque bloc est lié au précédent par
un processus de hachage, formant ainsi une chaı̂ne de blocs immuables.
Les réseaux blockchain offrent également des fonctionnalités avancées, telles que les
contrats intelligents. Ces contrats autonomes sont des programmes auto-exécutables qui
se lancent lorsque certaines conditions prédéfinies sont remplies. Ils permettent l’automa-
tisation des processus et l’élimination des intermédiaires, ce qui peut simplifier et accélérer
les transactions.
En ce qui concerne le choix de la blockchain, nous avons opté pour Ethereum en raison
de ses caractéristiques techniques, de ses propriétés de sécurité et des nombreuses pos-
sibilités qu’elle offre aux développeurs. Cela nous permet de satisfaire un grand nombre
d’exigences de sécurité liées à la conception du système proposé, notamment en assurant
le partage sécurisé des dossiers de santé électroniques entre les différents intervenants dans
un système global de e-santé.
67
IV.2.1 Outils et technologie utilisé
Dans cette partie, nous décrivons les outils logiciels et les technologies que nous avons
utilisées pour le développement et le déploiement du réseau blockchain.
IV.2.1.1 Blockchain Ethereum
Ethereum est une blockchain publique/privée et décentralisée qui offre bien plus qu’une
simple crypto-monnaie. Il s’agit d’une plateforme globale pour l’exécution de contrats in-
telligents, des applications décentralisées (dApps) et du développement de tokens numé-
riques. Avec Ethereum, les développeurs peuvent créer et déployer des contrats intelligents
qui automatisent les transactions et les interactions entre les parties sans avoir besoin d’un
intermédiaire.
- Langage de programmation Solidity : Solidity est un langage de programmation haut

niveau orienté objet pour implémenter des contrats intelligents. Les contrats intelligents
sont des programmes qui régissent le comportement des comptes dans l’état Ethereum.
- Machine virtuelle Ethereum : Dans l’univers d’Ethereum, il existe un seul ordinateur

canonique (appelé la Machine Virtuelle Ethereum, ou EVM) dont l’état est accepté par
tous les participants du réseau Ethereum. Chaque participant du réseau Ethereum (chaque
nœud Ethereum) conserve une copie de l’état de cet ordinateur. De plus, n’importe quel
participant peut diffuser une demande pour que cet ordinateur effectue un calcul arbitraire.
Lorsqu’une telle demande est diffusée, les autres participants du réseau vérifient, valident
et exécutent le calcul. Cette exécution provoque un changement d’état dans l’EVM, qui
est ensuite validé et propagé dans l’ensemble du réseau.
- Ganache Ganache est un simulateur de réseau blockchain largement utilisé dans l’éco-
système Ethereum pour le développement et les tests de contrats intelligents. Il fournit un
environnement local qui permet aux développeurs de créer des réseaux blockchain privés
pour simuler les fonctionnalités et le comportement d’un réseau Ethereum réel. Avec Ga-
nache, nous pouvons générer instantanément des adresses Ethereum, simuler des comptes
avec des soldes en Ether et déployer des contrats intelligents sur le réseau de simulation.
Ce simulateur offre une grande flexibilité en permettant de contrôler différents aspects du
réseau, tels que la gestion des transactions, les blocs minés et les événements.
Ganache facilite également le processus de débogage des contrats intelligents en four-
nissant des outils de surveillance de l’état du contrat, des journaux de débogage et une
interface utilisateur conviviale. Un autre avantage de Ganache est sa rapidité et sa légè-
68
reté, ce qui permet aux développeurs de tester et de déployer rapidement leurs contrats
intelligents sans avoir à attendre les temps de confirmation réels sur le réseau principal
Ethereum.
Figure IV.1 — Comptes blockchain fournis par le simulateur Ganache.
- Go-etheruem Lorsque nous exécutons notre propre nœud Ethereum, nous aurons la
possibilité d’utiliser cette blockchain de manière entièrement privée, autonome et décen-
tralisée. Cette approche nous offre un haut niveau de confiance, car nous serons en mesure
de vérifier de manière indépendante chaque aspect de l’utilisation d’Ethereum, garantis-
sant ainsi la sécurité et l’intégrité de notre plateforme. Grâce à des nœuds Geth personnel,
nous pouvons mettre en place une blockchain privée.
Geth offre une grande flexibilité en permettant aux utilisateurs de personnaliser leurs
paramètres réseau, tels que la vitesse de synchronisation, les niveaux de journalisation
et les stratégies de consensus. En tant que client bien établi et maintenu activement par
la communauté Ethereum, Geth est une option privilégiée pour les développeurs et les
utilisateurs qui souhaitent accéder et interagir avec le réseau Ethereum de manière fiable
et sécurisée. L’exécution d’un nœud Geth est illustrée dans la Figure. IV.2.
69
Figure IV.2 — Nœud Geth en pleine exécution.
IV.2.1.2 Docker
Docker est une plateforme open source qui permet aux développeurs de construire,
déployer, exécuter, mettre à jour et gérer des conteneurs : des composants normalisés et
exécutables qui combinent le code source de l’application avec les bibliothèques du système
d’exploitation (SE) et les dépendances nécessaires pour exécuter ce code dans n’importe
quel environnement.
Docker est également largement utilisé pour le déploiement de nœuds Blockchain et
IPFS. Il permet de créer des conteneurs qui contiennent tous les composants nécessaires
pour exécuter un nœud Blockchain ou IPFS. Les conteneurs Docker encapsulent tous les
composants requis pour exécuter ces nœuds, y compris les logiciels, les protocoles réseau
et les bibliothèques. En utilisant Docker, on peut facilement créer, distribuer et déployer
ces nœuds sur différentes machines ou clusters, permettant ainsi une mise en œuvre plus
efficace de ce système de stockage et de partage décentralisé de fichiers.
IV.2.1.3 Déploiement par RemixIDE
Remix est un environnement de développement intégré (IDE) largement utilisé dans

l’écosystème Ethereum pour la création et le déploiement de contrats intelligents. Cet ou-
til puissant offre une interface conviviale qui permet aux développeurs de coder, de tester
et de déployer leurs contrats intelligents de manière efficace. Avec Remix, les développeurs
peuvent écrire leurs contrats intelligents en langages de programmation tels que Solidity,
70
Vyper et Serpent, tout en bénéficiant d’une suite complète d’outils de développement (voir
la Figure. IV.3). L’IDE offre des fonctionnalités telles que la coloration syntaxique, l’au-
tocomplétion, la détection d’erreurs et la possibilité de déboguer les contrats intelligents.
Figure IV.3 — Déploiement et du test des comptes blockchain avec Remix.
Remix propose également un simulateur intégré qui permet aux développeurs de tes-
ter leurs contrats intelligents avant de les déployer sur la blockchain réelle. Une fois le
développement terminé, Remix facilite le déploiement des contrats intelligents sur diffé-
rents réseaux Ethereum, en offrant des options pour la configuration des paramètres de
déploiement et la gestion des adresses de contrat. En résumé, Remix est un outil essentiel
pour les développeurs Ethereum, offrant une expérience de développement fluide et des
fonctionnalités avancées pour la création et le déploiement de contrats intelligents.
IV.2.1.4 Déploiement par Truffle
Truffle est un framework de développement populaire et puissant spécifiquement conçu

pour faciliter le développement et le déploiement de contrats intelligents sur la blockchain
Ethereum. Il offre un ensemble complet d’outils et de fonctionnalités qui simplifient le
processus de création, de test et de déploiement des contrats intelligents. Avec Truffle, les
développeurs peuvent écrire leurs contrats intelligents en utilisant le langage de program-
mation Solidity, et bénéficier de fonctionnalités telles que la gestion des dépendances, la
71
compilation automatique, le déploiement simplifié des contrats et la migration des contrats

vers différents réseaux Ethereum.
Truffle fournit également un environnement de test intégré qui permet aux développeurs
de vérifier le bon fonctionnement de leurs contrats intelligents avant de les déployer. De
plus, Truffle facilite l’interaction avec les contrats intelligents via une console de dévelop-
pement en ligne de commande et offre des outils pour effectuer des tests unitaires et des
tests d’intégration.
IV.2.2 Déploiement de réseau blockchain
Pour présenter efficacement notre plateforme, nous avons élaboré un scénario (consultez
la Figure IV.4) qui implique trois centres de santé (hôpitaux). Dans un premier temps,
nous déploierons des nœuds blockchain (nœuds Ethereum) au sein de chaque hôpital à
l’aide du client Geth.
Hôpital 02
Hôpital 01 Hôpital 03
Figure IV.4 — Scénario de démonstration.
Afin de lancer le réseau blockchain, il est nécessaire de configurer initialement le ré-

seau à l’aide d’un fichier JSON. Ce fichier contient diverses configurations requises pour
le déploiement, telles que l’identifiant du réseau, les comptes et leurs soldes, la taille des
blocs, et surtout l’algorithme de consensus. Nous avons opté pour l’algorithme de preuve
d’autorité, qui présente des avantages tels qu’une faible consommation d’énergie. Il est
largement utilisé dans les réseaux blockchain privés. Dans cet algorithme, les nœuds au-
torisés à participer au processus de consensus (minage) sont préalablement définis dans le
fichier de configuration. La Table IV.2.2 présente les paramètres initiaux des trois nœuds
de notre scénario, comprenant d’abord la clé du nœud utilisée par le client Geth pour
construire l’identifiant du nœud dans le réseau, puis l’adresse du nœud (de minage) et le
72
solde initial de chaque compte.

Nœud Clef du nœud Adresse Balance
b0ac22adcad37213c7c565810a50f1772 0x7bd20cf7a890c8eac51
1 10000
291e7b0ce53fb73e7ec2a3c75bc13b5 34d834a47787a6f563fe1
3a4e2e1123664e58c30a7fbc6b320a55a 0xe36fdefdbba9776c5df
2 10000
4bafdfc8a042689a2a1c0f0e5ae1f16 2e569ff8cc0dc0fa4b83c
84c39b34f050c3a59b21e40646a4c163a 0x7bd20cf7a890c8eac51
3 10000
2d55efc928660b00b1038d2942d1fe4 34d834a47787a6f563fe1
Table IV.1 — Structure d’une demande stockée dans la blockchain.
La Figure IV.5 montre l’exécution du premier nœud dans le réseau blockchain. Le cadre
en jaune souligne l’identifiant de ce nœud.
Figure IV.5 — Lancement du premier nœud.
Ensuite, la Figure IV.6 présente le démarrage du deuxième nœud avec son identifiant
et son adresse blockchain.
Figure IV.6 — Mise en marche du deuxième nœud.
Enfin, La Figure IV.7 met en évidence l’exécution du troisième nœud, avec l’identifiant
et le compte blockchain affichés dans l’image.
Figure IV.7 — Lancement du troisième nœud.
Pour assurer la connectivité entre les différents nœuds, nous utiliserons la commande
”admin.peers” de Geth afin de visualiser les nœuds appartenant au même réseau.
73
IV.3 Mise en œuvre d’un réseau IPFS
Dans notre système, nous utilisons IPFS pour stocker des données structurées et cryp-
tées qui représentent, dans notre cas, les DSE. À des fins de démonstration, nous avons
installé le serveur IPFS appelé ”kubo (go-ipfs)” comme illustré dans la Figure. IV.10.
Figure IV.8 — Illustration du nœud IPFS en exécution.
Ainsi, chaque centre de données dispose d’un nœud IPFS qui lui permet de contribuer
avec ses ressources au processus de stockage des DSE. L’ajout des nœuds IPFS garantit
une disponibilité accrue des données sur la plateforme, renforçant ainsi considérablement
leur accessibilité.
Après l’installation d’un nœud IPFS, ce dernier contient une interface appelée WebUI
qui permet d’accéder à différentes fonctionnalités d’IPFS. L’interface WebUI affiche une
vue d’ensemble du nœud IPFS auquel nous sommes connecté. Nous pouvons y trouver
des informations telles que l’adresse ID du nœud, le nombre de blocs, la taille totale du
répertoire, etc. (voir Figure IV.9). IPFS, via son interface, permet d’explorer les fichiers,
de les télécharger et de les publier. Chaque opération nécessite l’utilisation d’un CID
(Content Identifier) pour le téléchargement ou la publication. De plus, l’interface WebUI
offre des fonctionnalités de gestion des paramètres. Nous pouvons configurer différentes
options telles que le stockage des données, les paramètres de routage, les paramètres de
sécurité, etc.
74
Figure IV.9 — Interface WebUI pour le statut d’un nœud IPFS
Dans notre travail, nous avons interagi avec les nœuds IPFS en utilisant des API
implémentées dans l’application web développée. Ainsi, cette opération est transparente
pour les utilisateurs finaux. Nous avons démontré l’utilisation d’IPFS dans le processus
de partage et de consultation, comme décrit dans la section suivant (IV.5).
Figure IV.10 — Interface WebUI pour la gestion des données dans un nœud IPFS.
IV.4 Prototype d’une application web pour l’autorité de santé
Nous avons développé un prototype d’une application web pour l’autorité de santé, qui
est une composante principale de notre système.
L’autorité de santé est responsable de la gestion des comptes dans la blockchain. L’ap-
plication contient 3 parties comme montré dans la Figure IV.11 : l’autorité de santé, les
acteurs de santé et les patients. Les deux dernières parties sont utilisées pour les tests
75
avant la création de l’application des hôpitaux.
Figure IV.11 — Interface web pour l’autorité de santé.
Après d’être connectée avec un compte blockchain de l’autorité qui est créée lors du
déploiement, cette dernière peut ajouter des centres de santé tels que les hôpitaux et les
laboratoires. L’autorité a besoin d’inclure l’identifiant du centre, le nom et l’adresse dans
la blockchain (voir la Figure IV.12).
Figure IV.12 — Interface web pour l’ajour d’un nouveau centre de santé.
Les acteurs de santé tels que les médecins sont également inscrits par l’autorité de santé.
Nous avons démontré le processus d’inscription dans la partie III.3.1. L’autorité remplit les
informations des acteurs, telles que l’identifiant, le nom, l’adresse blockchain et l’identifiant
du centre auquel ils appartiennent (voir figure IV.13).
76
Figure IV.13 — Interface pour l’ajout d’un nouveau médecin.
Si un patient souhaite s’inscrire dans la plateforme de partage des dossiers médicaux

afin de bénéficier de l’utilisation de son DSE par tous les autres acteurs de santé, il se
rend également à l’autorité de santé. Cette dernière vérifie et remplit les informations du
patient, comme le montre la Figure IV.14.
Figure IV.14 — Interface pour l’ajout d’un nouveau patient.
IV.5 Réalisation et test d’une application pour les hôpitaux
La réalisation d’une application web orientée aux hôpitaux pour le partage des dossiers
médicaux sur une blockchain privée est un travail complexe qui nécessite une étude minu-
tieuse des besoins et une conception soigneuse de l’architecture. Dans cette section, nous
présentons notre application web développée pour répondre à ces besoins. Nous avons
choisi des technologies performantes pour garantir la scalabilité et l’interopérabilité du
système afin de permettre à différents utilisateurs d’interagir avec les données médicales
stockées sur la blockchain de manière sécurisée.
Nous commençons par décrire l’environnement de travail, y compris les outils et techno-
logies utilisés. Ensuite, nous abordons le processus d’opérations blockchain pour présenter
le fonctionnement du système grâce à l’utilisation de contrats intelligents. Enfin, nous
présentons les interfaces graphiques permettant aux utilisateurs de naviguer et d’interagir
avec les données médicales stockées sur la blockchain.
77
IV.5.1 Outils logiciels exploités
Dans cette partie, nous décrivons l’ensemble des outils logiciels et des frameworks que
nous avons utilisés pour développer notre plateforme.
- NodeJs : Node.js est un framework open source de développement d’applications web

côté serveur. Il utilise le langage JavaScript pour exécuter des scripts côté serveur et peut
être utilisé pour développer différents types d’applications, y compris les applications
web, les applications de réseaux et les applications de ligne de commande. Node.js est
connu pour sa grande rapidité d’exécution, son évolutivité et son aptitude à gérer des
tâches asynchrones, ce qui en fait un outil populaire pour le développement d’applications
décentralisé.
- VueJs : Vue.js est un framework JavaScript (JS) open-source pour construire des inter-
faces utilisateur et des applications à une seule page. Il utilise une architecture model–view
basée sur des composants et un Document Object Model (DOM) virtuel, ce qui le rend
efficace et polyvalent pour construire des interfaces utilisateur dynamiques.
- Django : Django est un framework web open-source écrit en Python. Il est utilisé
pour construire la partie backend des applications web et est connu pour son approche ”à
batteries incluses”, ce qui signifie qu’il possède beaucoup de fonctionnalités intégrées pour
les tâches courantes de développement web telles que l’authentification des utilisateurs,
la gestion de la base de données. Il suit le modèle architectural modèle-vue-contrôleur
(MVC) et favorise le développement rapide et un design propre et pragmatique.
- Web3Js : Web3.js est une bibliothèque JavaScript pour interagir avec la blockchain
Ethereum. Elle permet aux développeurs d’interagir avec le réseau Ethereum, y compris
l’envoi et la réception d’Ether et l’interaction avec des contrats intelligents. Elle fournit une
API simple à utiliser pour les développeurs, ce qui facilite l’intégration de la fonctionnalité
de la blockchain dans les applications web.
- Axios : Axios est une bibliothèque JavaScript qui simplifie la réalisation de requêtes
HTTP depuis une application web. Elle fournit une API propre et facile à utiliser pour
effectuer des opérations asynchrones, telles que la récupération de données à partir d’un
API, l’envoi de données de formulaire ou le téléchargement de fichiers. Axios est construit
sur l’API XMLHttpRequest et elle est isomorphe donc elle peut fonctionner dans le navi-
gateur et serveur Node.js avec le même code source.
78
- SQLite : SQLite est un système de gestion de base de données relationnelle gratuit

et open-source conçu pour être léger et intégré à d’autres applications. Il garantit des
transactions conformes à l’ACID et prend en charge plusieurs plateformes, telles que
Windows, Linux et macOS.
- Metamask : MetaMask est une extension de navigateur populaire qui agit comme une
interface utilisateur pour interagir avec des applications décentralisées (dApps) basées sur
la technologie blockchain. Il s’agit essentiellement d’un portefeuille numérique qui permet
aux utilisateurs de gérer leurs actifs cryptographiques et d’effectuer des transactions en
toute sécurité.
MetaMask prend en charge différents réseaux blockchain tels qu’Ethereum et permet
aux utilisateurs de stocker et d’envoyer des tokens, de signer des transactions et d’in-
teragir avec des contrats intelligents. Il fournit également une fonctionnalité de gestion
des identités permettant aux utilisateurs de gérer plusieurs adresses et de connecter leurs
comptes à différents sites et dApps, la Figure. IV.15 illustre le processus d’importation
d’un compte dans MetaMask.
Figure IV.15 — Procédure d’importation d’un compte dans MetaMask.
IV.5.2 Présentation de l’application web
Nous discutons dans cette partie la mise en place d’une application de partage des
dossiers médicaux dans une blockchain privée. Nous présentons les différentes fonctionna-
lités de l’application offertes aux hôpitaux, qui permettent une utilisation intuitive de la
plateforme.
79
Nous divisons notre présentation des fonctionnalités en deux groupes. Nous commen-
çons par les fonctionnalités principales de notre système qui interagissent avec les différents
composants de celui-ci, tels que la blockchain et IPFS. Ensuite, nous présentons ensemble
les fonctionnalités supplémentaires que nous avons jugées nécessaires pour une utilisation
optimale de notre application.
IV.5.2.1 Fonctionnalités principales du système
Notre application contient un ensemble des fonctionnalités principales, telles que la

création de DSE, la connexion avec MetaMask, la gestion des autorisations, la publication
et le partage des DSEs, qui seront détaillées par la suite :
- Création d’un DSE

La création d’un dossier de santé électronique est une fonctionnalité principale de notre
plateforme. Le médecin, après avoir consulté l’historique d’un patient et compris son
état, a besoin de créer une nouvelle consultation. Nous avons facilité l’accès à la page de
création, le médecin peut y accéder en cliquant sur le bouton ”Créer un nouveau DSE”.
Ceci permet la redirection vers la page de création.
Dans cette page, le médecin peut voir les informations nécessaires du patient telles
que son nom, son prénom, son âge, son poids, sa taille, etc. dans la barre supérieure. La
structure du DSE suit les normes du domaine médical, comme détaillé dans le chapitre
précédent. Le DSE contient des champs obligatoires tels que le titre de la consultation, la
date et le résumé (voir la Figure. IV.16), Ainsi que des champs optionnels tels que l’ajout
de maladies, d’allergies, de médicaments et d’analyses, représentés par des boutons dans
l’interface. Chaque option contient un formulaire qui s’affiche lorsque l’utilisateur clique
sur un bouton correspondant.
Figure IV.16 — Interface web pour la création des DSE.
80
Après la création du DSE, il suffit de le sauvegarder en cliquant sur le bouton ”Sauve-

garder” pour qu’il soit ajouté à la base locale de l’hôpital et devienne accessible par les
autres médecins.
- Gestion des autorisations (partage et consultation)

L’accès au dossier de santé d’un patient nécessite une autorisation de ce dernier. Ainsi,
après que le médecin a fait la demande d’accès au dossier de santé ou une demande de
partage, le patient peut voir toutes les demandes comme représenté dans la Figure. IV.23.
Chaque demande est représentée par le nom du médecin qui a fait la demande, la date
de la demande et le type de demande (consultation ou partage). Le patient peut alors
accepter ou refuser la demande en question.
Figure IV.17 — Interface web pour les demandes d’accès au DSE.
- Publication des DSE

Après que le patient ait accepté la demande d’autorisation de partage, le médecin
peut partager les dossiers sauvegardés localement sur la blockchain, le partage nécessite
la validation de l’opération par l’utilisation de l’extension MetaMask comme représenté
dans la Figure. IV.18.
81
Figure IV.18 — Interface web montre le processus de partage d’un DSE.
Après le partage, les dossiers sont stockés dans IPFS de manière décentralisée et sont
identifiés par une adresse de hachage nommé en anglais Content Identifier (CID) qui est
sauvegardée dans les résumés de la blockchain, le processus de partage est montré dans
la Figure. IV.19.
Médecin Patient
1 - Envoyer une demande de
partage
2 - Accepter la demande
3 - Partager le DSE
4 - DSE
5 - Hachage d'adresse (CID)

6 - Sauvegarder
le résumé
IPFS
Blockchain
Figure IV.19 — Processus de partage d’un DSE.
82
Le stockage dans IPFS permet de maintenir la disponibilité des DSE (Dossiers de Santé
Électroniques) même en cas de panne de certains nœuds.
- Consultation des DSE

Dans le cas d’un nouveau patient qui n’a pas fait de consultations dans le centre
local ou lorsque le médecin a besoin de plus d’informations sur le patient, ce dernier a
besoin d’accéder à l’historique des patients qui est créé par les autres centres de santé. Le
médecin envoie une demande de consultation comme montre dans la Figure. IV.20, et si
le patient accepte la demande de médecin comme nous l’avons vu dans la Figure IV.23,
ce dernier peut consulter l’ensemble des dossiers de santé existants dans la blockchain
(voir la Figure. IV.27).
Figure IV.20 — Interface web montre la partie de demande d’une consultation.
L’accès aux dossiers de santé des patients se fait en deux étapes (voir la Figure. IV.21).
Tout d’abord, la récupération de l’ensemble des résumés des patients existant dans la blo-
ckchain, puis la récupération des DSE stockés dans l’IPFS en utilisant les CID sauvegardés
dans les résumées de la blockchain.
Il est important de noter que cette approche permet de garantir la sécurité et l’intégrité
des dossiers de santé, car les informations essentielles sont stockées dans la blockchain, tan-
dis que les données volumineuses sont conservées dans l’IPFS, assurant ainsi une gestion
efficace des dossiers médicaux.
83
Médecin Patient
1 - Envoyer une demande de
consultation
2 - Accepter la demande
3 - Consultation
8 - DSE
6-
En
és
vo
m ye
r le
su
ha
ré
7- (C chag
s
Ré
de
ID
és
cu ) ed
m
r
pé ' ad
de
su
rat res
an
ion
ré
se
em
du
de
-D
DS
er
E
4
oy
nv
-E
5
Blockchain
IPFS
Figure IV.21 — Processus de consultation d’un DSE.
IV.5.2.2 Fonctionnalités complémentaires du système
Pour optimiser l’utilisation de notre application, nous avons ajouté plusieurs fonction-
nalités complémentaires. Cela inclut la gestion des profils, permettant aux utilisateurs de
créer et gérer différents profils en fonction de leurs rôles. De plus, nous avons intégré la
consultation de l’historique local, offrant un accès rapide aux informations précédemment
consultées, telles que les DSE et autres éléments pertinents. Enfin, notre application pro-
pose un système de gestion des rendez-vous, permettant aux utilisateurs d’organiser et
de planifier des rendez-vous directement au sein de l’application. Les sections suivantes
fourniront une explication détaillée et une présentation complète de ces fonctionnalités
complémentaires.
Authentification des utilisateurs

Notre application protège les informations sensibles des patients en bloquant l’accès
aux utilisateurs non autorisés (voir Figure. IV.22).
84
Figure IV.22 — Processus d’authentification pour les différents utilisateurs de la

plateforme.
Seuls les utilisateurs avec des informations d’accès correctes peuvent utiliser les fonc-
tionnalités de notre plateforme. La Figure. IV.23 montre l’interface web pour accéder à
notre plateforme.
Figure IV.23 — Interface web pour l’authentification des utilisateurs.
85
- Gestions des profils

Notre application permet aux administrateurs d’effectuer les opérations Create, Read,
Update and Delete (CRUD) en ajoutant, modifiant ou supprimant un patient, un médecin
ou un employé à travers différentes pages. Par exemple, pour gérer les médecins, la liste
des médecins est affichée sur le côté gauche de la partie principale de la Figure. IV.24,
Avec un bouton qui affiche un formulaire pour insérer un nouveau médecin sur le côté
droit.
Figure IV.24 — Interface web pour la gestion des différents utilisateurs.
- Historique d’un patient

Notre application permet aux médecins d’avoir accès à l’ensemble des patients exis-
tants dans le but de manipuler leurs DSE. Après avoir choisi un patient parmi la liste
présentée dans la Figure. IV.25, le médecin peut cliquer sur la flèche pour accéder au DSE
correspondant.
Figure IV.25 — Interface web pour voir l’ensemble des patients.
86
La Figure. IV.26 représente l’ensemble des DSE créés localement dans l’hôpital, ils sont
définis par leur titre, leur date d’ajout et le service de consultation.
Une fois qu’un médecin a examiné l’importance d’un DSE, il peut le partager afin qu’il
soit accessible par les différents hôpitaux.
Figure IV.26 — Interface web pour voir les DSE local.
Ainsi, comme présenté dans la Figure. IV.27 le médecin peut voir l’ensemble des DSE
récupérés de la blockchain si le patient accepte leur demande de consultation. Donc, le
médecin peut accéder au DSE créé par différents hôpitaux pour mieux comprendre l’état
de santé du patient et son historique médical.
Figure IV.27 — Interface web pour voir les DSE global.
- Gestion des rendez-vous

Notre application permet la création des rendez-vous, qui est la tâche des employés de
87
chaque service. Après la demande d’un médecin, il crée un rendez-vous pour un patient
avec une date et une heure spécifiée. Le médecin peut également ajouter des notes sur
le rendez-vous. Après la création d’un rendez-vous, le médecin peut voir l’ensemble des
rendez-vous qui lui sont attachés et peut changer l’état d’un rendez-vous à ”Terminé” ou
”annulé”. Le patient peut également voir l’ensemble des rendez-vous avec les notes et l’état
qui leur sont attachés, ainsi que l’historique des rendez-vous créés.
IV.6 Conclusion
Le partage des dossiers médicaux entre les hôpitaux nécessite une plateforme qui
contient plusieurs composants pour toucher efficacement les différents critères. L’utili-
sation de la blockchain permet de garantir une grande sécurité, confidentialité et une
asymétrie de l’information. De plus, nous avons amélioré notre plateforme en utilisant un
stockage décentralisé avec l’utilisation de IPFS, ce qui permet d’assurer une disponibi-
lité élevée. Ces composants sont devenus des éléments cachés pour les utilisateurs finaux,
c’est pourquoi nous avons développé une application web pour les hôpitaux qui facilite
l’interaction avec les différents composants de notre système.
Dans ce chapitre, nous avons présenté les différentes étapes et les outils utilisés pour la
mise en œuvre de la blockchain et l’IPFS. À la fin, nous avons présenté l’interaction entre
les différents composants du système en utilisant l’application web, qui offre différentes
fonctionnalités développées spécifiquement pour les centres de santé, tels que les hôpitaux
dans notre cas.
88
Conclusion générale et perspectives
La technologie blockchain est une solution innovante pour résoudre de nombreux dé-
fis mondiaux. Le développement d’une plateforme de partage des dossiers médicaux sur
une blockchain privée nécessite d’assurer plusieurs fonctionnalités complexes pour bien
atteindre l’objectif et bénéficier de la blockchain. Plusieurs critères sont importants dans
le partage des dossiers médicaux, tels que la sécurité, la confidentialité, l’asymétrie de
l’information, etc.
D’après la littérature, plusieurs solutions ont été introduites dans le domaine de par-
tage des dossiers médicaux, mais restent incapables d’assurer les critères importants pour
le partage de données médicales. Une technique très récente que nous avons explorée dans
notre projet pour le stockage de données est IPFS, qui est un réseau de stockage permet-
tant de stocker les données de manière décentralisée et de garder une bonne gestion des
données médicales, cela garantit plusieurs critères tels que la disponibilité des données.
Dans notre projet de fin d’études, nous nous sommes intéressés au développement d’une
plateforme de partage des dossiers médicaux sur une blockchain privée et basée sur un
réseau de stockage décentralisé IPFS. Nous avons, pour cela, exploité les différents outils
matériels et logiciels existants pour mettre en œuvre une plateforme qui regroupe un
ensemble de fonctionnalités, parmi lesquelles le partage des dossiers médicaux entre les
centres et les prestataires de santé.
Notre travail est partagé en deux volets, notamment la mise en œuvre d’une architecture
globale qui contient la blockchain, le système de stockage, et l’autorité de santé d’un coté,
et de l’autre coté le développement d’une application web qui interagit avec les différents
composants de la plateforme et suit des standards universels pour le partage de dossiers
de santé électronique.
Le travail que nous avons réalisé a montré que le développement d’une plateforme de
partage des dossiers médicaux sur une blockchain privée est un processus assez complexe
vu les différentes spécifications et critères que la plateforme doit respecter. En effet, notre
plateforme suit une architecture modulaire qui se divise en 4 modules principaux à savoir
la blockchain, IPFS, l’autorité de santé et les centres médicaux tels que les hôpitaux qui
89
EMP Conclusion générale et perspectives
contiennent les utilisateurs finaux tels que les médecins et les patients. Pour le réseau blo-
ckchain, nous avons effectué le déploiement d’un réseau réel qui est basé sur la technologie
Ethereum et géré par une autorité de santé responsable du déploiement des contrats intel-
ligents qui gèrent le réseau blockchain et les inscriptions des différents utilisateurs. Nous
avons également déployé un réseau de stockage décentralisé IPFS avec un cryptage élevé
pour les données. IPFS garde les données confidentielles et sécurisées tout en assurant
leur disponibilité, même dans le cas d’une panne de quelques nœuds de stockage.
Le deuxième volet auquel nous nous sommes intéressés dans notre projet est le déve-
loppement d’une application web pour les hôpitaux qui gère la création et le partage des
dossiers de santé électronique selon des standards universels tels que FHIR et SNOMED.
Le médecin n’est pas capable de gérer les dossiers de santé électronique d’un patient si ce
dernier n’accepte pas les demandes d’autorisation de médecins, ce qui garantit la confi-
dentialité et la vie privée du patient. L’application contient d’autres fonctionnalités telles
que la gestion des utilisateurs et des services par l’administration, la gestion des rendez-
vous par les différents employés de chaque service et la gestion des dossiers de santé
électronique par les médecins. Cela facilite grandement l’utilisation de notre plateforme
et permet d’améliorer la qualité des soins et des recherches scientifiques.
Enfin, nous pensons que notre projet peut être amélioré de différentes manières. Nous
envisageons dans la future d’inclure d’autres volets tels que :
− Le développement d’une application mobile destinée aux patients afin de faciliter

les réponses aux demandes d’autorisation des médecins pour la consultation et le
partage.
− Le développement d’un système d’information complet pour l’autorité de santé qui

permettra l’inscription aux services de notre plateforme développée, ”HealthTech”,
en utilisant les pièces d’identification nationales.
− l’intégration de la technologie IPLD avec IPFS qui permet d’améliorer l’efficacité

et les performances des systèmes décentralisés en permettant un accès rapide et
efficace aux données distribuées, grâce à la capacité de créer des liens directs entre
les différents morceaux de données. Cela facilite la récupération et la manipulation
des informations, tout en réduisant les délais et la charge sur le réseau.
90
Bibliographie
[1] N. Menachemi and T. H. Collum, “Benefits and drawbacks of electronic health record
systems,” Risk management and healthcare policy, pp. 47–55, 2011.
[2] A. Hoerbst and E. Ammenwerth, “Electronic health records,” Methods of information

in medicine, vol. 49, no. 04, pp. 320–336, 2010.
[3] R. S. Evans, “Electronic health records : then, now, and in the future,” Yearbook of
medical informatics, vol. 25, no. S 01, pp. S48–S61, 2016.
[4] J. O. de la Republique Algerienne n°34, “Loi n° 18-07 relative à la protection des

personnes physiques dans le traitement des données à caractère personnel,” 2018-06-
10.
[5] L. G. at University of Washington Libraries, “Data resources in the health

sciences,” Jan, 18, 2023. https://guides.lib.uw.edu/hsl/data/findclin, acces-
sed : 07/05/2023.
[6] P. Schloeffel, “Electronic health record definition, scope and context. iso,” TC,
vol. 215, 2002.
[7] L. J. Kish and E. J. Topol, “Unpatients—why patients should own their medical
data,” Nature biotechnology, vol. 33, no. 9, pp. 921–924, 2015.
[8] J. Jin, G.-J. Ahn, H. Hu, M. J. Covington, and X. Zhang, “Patient-centric autho-
rization framework for sharing electronic health records,” in Proceedings of the 14th
ACM symposium on Access control models and technologies, pp. 125–134, 2009.
[9] A. L. Neves, A. W. Carter, L. Freise, L. Laranjo, A. Darzi, and E. K. Mayer, “Im-

pact of sharing electronic health records with patients on the quality and safety of
care : a systematic review and narrative synthesis protocol,” BMJ open, vol. 8, no. 8,
p. e020387, 2018.
[10] M. Quinn, J. Forman, M. Harrod, S. Winter, K. E. Fowler, S. L. Krein, A. Gupta,

S. Saint, H. Singh, and V. Chopra, “Electronic health records, communication, and
data sharing : challenges and opportunities for improving the diagnostic process,”
Diagnosis, vol. 6, no. 3, pp. 241–248, 2019.
91
EMP Bibliographie
[11] I. A. Amarouche, D. Benslimane, M. Barhamgi, M. Mrissa, and Z. Alimazighi, “Elec-

tronic health record data-as-a-services composition based on query rewriting,” Tran-
sactions on Large-Scale Data-and Knowledge-Centered Systems IV : Special Issue on
Database Systems for Biomedical Applications, pp. 95–123, 2011.
[12] R. Wodak, “Mediation between discourse and society : Assessing cognitive approaches
in cda,” Discourse studies, vol. 8, no. 1, pp. 179–190, 2006.
[13] D. Bender and K. Sartipi, “Hl7 fhir : An agile and restful approach to healthcare
information exchange,” in Proceedings of the 26th IEEE international symposium on
computer-based medical systems, pp. 326–331, IEEE, 2013.
[14] K. A. Stroetmann and V. N. Stroetmann, “Towards an interoperability framework

for a european e-health research area–locating the semantic interoperability domain,”
in EC Workshop on semantic interoperability, Brussels, Feb, pp. 14–15, 2005.
[15] R. Noumeir and B. Renaud, “Ihe cross-enterprise document sharing for imaging :
interoperability testing software,” Source code for biology and medicine, vol. 5, pp. 1–
15, 2010.
[16] C. Gaudet-Blavignac, V. Foufi, M. Bjelogrlic, and Lovis, “Use of the systematized

nomenclature of medicine clinical terms (snomed ct) for processing free text in health
care : systematic scoping review,” Journal of medical Internet research, vol. 23, no. 1,
p. e24594, 2021.
[17] S. Bhartiya, D. Mehrotra, and A. Girdhar, “Issues in achieving complete interopera-

bility while sharing electronic health records,” Procedia Computer Science, vol. 78,
pp. 192–198, 2016.
[18] H. Jin, Y. Luo, P. Li, and J. Mathew, “A review of secure and privacy-preserving
medical data sharing,” IEEE Access, vol. 7, pp. 61656–61669, 2019.
[19] A. AlJarullah and S. El-Masri, “A novel system architecture for the national integra-
tion of electronic health records : a semi-centralized approach,” Journal of medical
systems, vol. 37, pp. 1–20, 2013.
[20] S. S. Vellela, B. V. Reddy, K. K. Chaitanya, and M. V. Rao, “An integrated approach

to improve e-healthcare system using dynamic cloud computing platform,” in 2023
5th International Conference on Smart Systems and Inventive Technology (ICSSIT),
pp. 776–782, IEEE, 2023.
[21] M. Attaran, “Blockchain technology in healthcare : Challenges and opportunities,”

International Journal of Healthcare Management, vol. 15, no. 1, pp. 70–83, 2022.
92
EMP Bibliographie
[22] A. Jalal-Karim and W. Balachandran, “The optimal network model’s performance for
sharing electronic health record,” in 2008 IEEE International Multitopic Conference,
pp. 149–154, IEEE, 2008.
[23] D. Daglish and N. Archer, “Electronic personal health record systems : a brief review
of privacy, security, and architectural issues,” in 2009 world congress on privacy,
security, Trust and the Management of e-Business, pp. 110–120, IEEE, 2009.
[24] A. Ibrahim, B. Mahmood, and M. Singhal, “A secure framework for sharing electro-
nic health records over clouds,” in 2016 IEEE International Conference on Serious
Games and Applications for Health (SeGAH), pp. 1–8, IEEE, 2016.
[25] Y. Guo, M.-H. Kuo, and T. Sahama, “Cloud computing for healthcare research infor-
mation sharing,” in 4th IEEE international conference on cloud computing technology
and science proceedings, pp. 889–894, IEEE, 2012.
[26] K. M. Khan and Q. Malluhi, “Establishing trust in cloud computing,” IT professional,

vol. 12, no. 5, pp. 20–27, 2010.
[27] K. Ren, C. Wang, and Q. Wang, “Security challenges for the public cloud,” IEEE
Internet computing, vol. 16, no. 1, pp. 69–73, 2012.
[28] T. F.-M. Pasquier, J. Singh, D. Eyers, and J. Bacon, “Camflow : Managed data-
sharing for cloud services,” IEEE Transactions on Cloud Computing, vol. 5, no. 3,
pp. 472–484, 2015.
[29] J.-J. Yang, J.-Q. Li, and Y. Niu, “A hybrid solution for privacy preserving medical
data sharing in the cloud environment,” Future Generation computer systems, vol. 43,
pp. 74–86, 2015.
[30] A. Hajian, V. R. Prybutok, and H.-C. Chang, “An empirical study for blockchain-
based information sharing systems in electronic health records : A mediation pers-
pective,” Computers in Human Behavior, vol. 138, p. 107471, 2023.
[31] N. Chaudhary, “The blockchain : A futuristic approach to sustaina-

bility,” Nov 20, 2020. https://letsbekarmic.com/knowledgebase/
the-blockchain-a-futuristic-approach-to-sustainability/, accessed :
14/04/2023.
[32] R. Jabbar, N. Fetais, M. Krichen, and K. Barkaoui, “Blockchain technology for heal-
thcare : Enhancing shared electronic health record interoperability and integrity,” in
2020 IEEE International Conference on Informatics, IoT, and Enabling Technologies
(ICIoT), pp. 310–317, IEEE, 2020.
93
EMP Bibliographie
[33] A. Azaria, A. Ekblaw, T. Vieira, and A. Lippman, “Medrec : Using blockchain for me-
dical data access and permission management,” in 2016 2nd international conference
on open and big data (OBD), pp. 25–30, IEEE, 2016.
[34] H. Yang and B. Yang, “A blockchain-based approach to the secure sharing of health-
care data,” in Proceedings of the norwegian information security conference, pp. 100–
111, Nisk J Oslo, Norway, 2017.
[35] K. Fan, S. Wang, Y. Ren, H. Li, and Y. Yang, “Medblock : Efficient and secure
medical data sharing via blockchain,” Journal of medical systems, vol. 42, pp. 1–11,
2018.
[36] X. Liu, Z. Wang, C. Jin, F. Li, and G. Li, “A blockchain-based medical data sharing
and protection scheme,” IEEE Access, vol. 7, pp. 118943–118953, 2019.
[37] I. Boumezbeur, Zarour and Karim, “Privacy-preserving and access control for sharing
electronic health record using blockchain technology,” Acta Informatica Pragensia,
vol. 11, no. 1, pp. 105–122, 2022.
[38] S. Haber and W. S. Stornetta, How to time-stamp a digital document. Springer, 1991.
[39] S. Nakamoto, “Bitcoin : A peer-to-peer electronic cash system,” Decentralized business

review, p. 21260, 2008.
[40] D. Yermack, “Corporate governance and blockchains,” Review of finance, vol. 21,
no. 1, pp. 7–31, 2017.
[41] D. Puthal, N. Malik, S. P. Mohanty, E. Kougianos, and G. Das, “Everything you

wanted to know about the blockchain : Its promise, components, processes, and pro-
blems,” IEEE Consumer Electronics Magazine, vol. 7, no. 4, pp. 6–14, 2018.
[42] M. Raikwar, D. Gligoroski, and K. Kralevska, “Sok of used cryptography in block-

chain,” IEEE Access, vol. 7, pp. 148550–148575, 2019.
[43] S. Houben, Robby and Alexander, “Cryptocurrencies and blockchain,” Legal context
and implications for financial crime, money laundering and tax evasion, pp. 1–86,
2018.
[44] D. Yaga, P. Mell, N. Roby, and K. Scarfone, “Blockchain technology overview,” arXiv
preprint arXiv :1906.11078, 2019.
[45] D. Puthal, N. Malik, S. P. Mohanty, E. Kougianos, and C. Yang, “The blockchain as

a decentralized security framework [future directions],” IEEE Consumer Electronics
Magazine, vol. 7, no. 2, pp. 18–21, 2018.
[46] L. W. Cong and Z. He, “Blockchain disruption and smart contracts,” The Review of
Financial Studies, vol. 32, no. 5, pp. 1754–1797, 2019.
94
EMP Bibliographie
[47] J. Benet, “IPFS - Content Addressed, Versioned, P2P File System,” July 2014.
arXiv :1407.3561 [cs].
[48] D. C. Nguyen, P. N. Pathirana, M. Ding, and A. Seneviratne, “Blockchain for secure
ehrs sharing of mobile cloud based e-health systems,” IEEE access, vol. 7, pp. 66792–
66806, 2019.
[49] S. Kumar, A. K. Bharti, and R. Amin, “Decentralized secure storage of medical
records using blockchain and ipfs : A comparative analysis with future directions,”
Security and Privacy, vol. 4, no. 5, p. e162, 2021.
[50] Y. Chen, H. Li, K. Li, and J. Zhang, “An improved p2p file system scheme based
on ipfs and blockchain,” in 2017 IEEE International Conference on Big Data (Big
Data), pp. 2652–2657, IEEE, 2017.
[51] T. McGhin, K.-K. R. Choo, C. Z. Liu, and D. He, “Blockchain in healthcare appli-
cations : Research challenges and opportunities,” Journal of Network and Computer
Applications, vol. 135, pp. 62–75, 2019.
[52] D. V. Dimitrov, “Blockchain applications for healthcare data management,” Health-
care informatics research, vol. 25, no. 1, pp. 51–56, 2019.
[53] S. A. Abdullah Albeyatti and U. micheal, “Meddicalchain : The healthcare of tomor-
row,” vol. 12, MDPI AG, 2018.
[54] N. Nchinda, A. Cameron, K. Retzepi, and A. Lippman, “Medrec : a network for
personal information distribution,” in 2019 international conference on computing,
networking and communications (ICNC), pp. 637–641, IEEE, 2019.
[55] T. T. Thwin and S. Vasupongayya, “Blockchain-based access control model to pre-
serve privacy for personal health record systems,” Security and Communication Net-
works, vol. 2019, 2019.
[56] W. Ni, X. Huang, J. Zhang, and R. Yu,“Healchain : A decentralized data management
system for mobile healthcare using consortium blockchain,” in 2019 Chinese Control
Conference (CCC), pp. 6333–6338, IEEE, 2019.
[57] H. Li, X. Yang, H. Wang, W. Wei, and W. Xue, “A controllable secure blockchain-
based electronic healthcare records sharing scheme,” Journal of Healthcare Enginee-
ring, vol. 2022, 2022.
[58] Q. Xia, E. B. Sifah, A. Smahi, S. Amofa, and X. Zhang,“Bbds : Blockchain-based data
sharing for electronic medical records in cloud environments,” Information, vol. 8,
no. 2, p. 44, 2017.
[59] M. Reisman,“Ehrs : the challenge of making electronic data usable and interoperable,”
Pharmacy and Therapeutics, vol. 42, no. 9, p. 572, 2017.
95
EMP Bibliographie
[60] G. S. Birkhead, M. Klompas, and N. R. Shah, “Uses of electronic health records for
public health surveillance to advance public health,” Annual review of public health,
vol. 36, pp. 345–359, 2015.
96
Annexes
Le bon fonctionnement d’un système in-
formatique est conditionné par le choix
judicieux des différentes technologies et
des outils de travail appropriés. Dans
cette partie du travail, nous présentons
en détail la configuration et le dévelop-
pement de notre système proposé pour
le partage des dossiers médicaux au sein
d’une blockchain privée, afin d’assurer
la compréhension adéquate et la repro-
ductibilité du système.
EMP Annexe A. Contrats intelligents
A Contrats intelligents
Dans cette annexe, nous présentons le code Solidity des contrats déployés dans notre
plate-forme HealthTech.
Contrat intelligent ”HealthAuthority”
1 pragma solidity >=0.7.0 <0.9.0;

2 /* * @title HealthAuthority */
3 contract HealthAuthority {
4 // variable store all account in authority
5 // address [] authorities ;
6 uint256 public authCount = 0;
7 mapping ( uint = > address ) public authorities ;
8
9 constructor () {
10 authCount ++;
11 authorities [ authCount ] = msg . sender ;
12 }
13 // GETTERS
14 // modifier to check if caller is account in authorty
15 modifier onlyAuthority () {
16 ( uint index , bool exist ) = che ck Hea lt hAu tho ri ty ( msg . sender ) ;
17 require ( exist , " Caller have not permession " ) ;
18 _; }
19 function c he ckH eal th Aut ho rit y ( address _address ) view public returns
( uint , bool ) {
20 uint index = 0;
21 bool exist = false ;
22 for ( uint i = 1; i <= authCount ; i ++) {
23 if ( authorities [ i ] == _address ) {
24 exist = true ;
25 index = i ;
26 break ;
27 } }
28 return ( index , exist ) ;
29 }
30 // SETTERS
31 /* * @dev add new account to authority
32 @param _address address to added */
33 function addAccount ( address _address ) public onlyAuthority {
34 authCount ++;
35 authorities [ authCount ] = _address ;
98
36 }
37 /* * @dev remove account from authority
38 @param _address address to remove */
39 function rmAccount ( address _address ) public onlyAuthority {
40 ( uint index , bool exist ) = che ck Hea lt hAu tho ri ty ( _address ) ;
41 require ( exist == true , " center does not exist !! " ) ;
42
43 authorities [ index ] = authorities [ authCount ];
44 authCount - -;
45 } }
Contrat intelligent ”HealthCenter”
1 // SPDX - License - Identifier : GPL -3.0

3
4 import { HealthAuthority } from " ./ HealthAuthority . sol " ;
5
6 /* *
7 * @title HealthCenter
8 * @dev Implements center methods
9 */
10 contract HealthCenter {
11 HealthAuthority authority ; // associated authority
12 struct center {
13 uint id ;
14 string name ;
15 address addr ;
16 }
17 // array content all center
18 center [] centers ;
20 ( uint index , bool exist ) = authority . che ck Hea lt hAu th ori ty ( msg .
sender ) ;
22 _;
23 }
24 constructor ( address AuthorityAddress ) {
25 authority = HealthAuthority ( AuthorityAddress ) ;
26 }
27
28 function checkHealthCenter ( uint _id , address _address ) view public
returns ( uint , bool ) {
99
29 uint index = 0;
31 for ( uint i = 0; i < centers . length ; i ++) {
32 if ( centers [ i ]. id == _id || centers [ i ]. addr == _address ) {
33 exist = true ;
34 index = i ;
35 break ;
36 }
37 }
39 }
40 /* *
41 * ////////////////////////////////////////////////////////////
42 * PUBLIC METHODS FOR CONTRACT INTERFACE
43 * ////////////////////////////////////////////////////////////
44 */
45
46 function getNumberOfCenters () view public returns ( uint ) {
47 uint len = centers . length ;
48 return len ;
49 }
50
51 function getCenterByIndex ( uint _index ) view public returns ( uint ,
string memory , address ) {
52 require ( _index >=0 && _index < centers . length , " Wrong Index !! " ) ;
53 return ( centers [ _index ]. id , centers [ _index ]. name , centers [ _index
]. addr ) ;
54 }
55
56 function addHealthCenter ( uint _id , string memory _name , address
_account ) public onlyAuthority {
57 ( , bool exist ) = checkHealthCenter ( _id , _account ) ;
58 require ( exist == false , " center id or account already exist !! " ) ;
59
60 centers . push ( center ( _id , _name , _account ) ) ;
61 }
62
63 function rmHealthCenter ( uint _id ) public onlyAuthority {
64 ( uint index , bool exist ) = checkHealthCenter ( _id , address (0) ) ;
65 require ( exist == true , " center does not exist !! " ) ;
66
67 centers [ index ] = centers [ centers . length -1];
68 centers . pop () ;
100
69 }
70 }
Contrat intelligent ”HealthActor”

3
4 import { HealthCenter } from " ./ HealthCenter . sol " ;
5
6
7 /* *
8 * @title HealthActor
9 * @dev Implements actor methods
10 */
11 contract HealthActor is HealthCenter {
12
13 struct actor {
14 uint id ;
15 uint centerID ;
16 string name ;
17 address addr ;
18 string public_key ;
19 }
20
21 mapping ( uint = > actor ) public actors ;
22 uint256 public actorCount = 0; // pointer in the last element in the
map
23
24 constructor ( address authorityAddress ) HealthCenter ( authorityAddress
) {}
25
26 function char ( bytes1 b ) internal pure returns ( bytes1 c ) {
27 if ( uint8 ( b ) < 10) return bytes1 ( uint8 ( b ) + 0 x30 ) ;
28 else return bytes1 ( uint8 ( b ) + 0 x57 ) ;
29 }
30
31 function toAsciiString ( address x ) internal pure returns ( string
memory ) {
32 bytes memory s = new bytes (40) ;
33 for ( uint i = 0; i < 20; i ++) {
34 bytes1 b = bytes1 ( uint8 ( uint ( uint160 ( x ) ) / (2**(8*(19 - i ) ) )
));
101
35 bytes1 hi = bytes1 ( uint8 ( b ) / 16) ;

36 bytes1 lo = bytes1 ( uint8 ( b ) - 16 * uint8 ( hi ) ) ;
37 s [2* i ] = char ( hi ) ;
38 s [2* i +1] = char ( lo ) ;
39 }
40 return string ( s ) ;
41 }
42
43 /* *
44 * ////////////////////////////////////////////////////////////
45 * PUBLIC METHODS FOR CONTRACT INTERFACE
46 * ////////////////////////////////////////////////////////////
47 */
48
49 function addHealthActor ( uint _id , uint _centerID , string memory
_name , address _account , string memory _pKey ) public
onlyAuthority {
50 uint index = checkHealthActor ( _id , _account ) ;
51 require ( index == 0 , " Actor id or account already exist !! " ) ;
52
53 ( , bool centerExist ) = checkHealthCenter ( _centerID , address (0) )
;
54 require ( centerExist == true , " center does not exist exist !! " ) ;
55
56 actorCount ++;
57 actors [ actorCount ] = actor ( _id , _centerID , _name , _account ,
_pKey ) ;
58 }
59
60 function rmHealthActor ( uint _id ) public onlyAuthority {
61 uint index = checkHealthActor ( _id , address (0) ) ;
62 require ( index >0 , " Actor does not exist !! " ) ;
63
64 actors [ index ] = actors [ actorCount ];
65 actorCount - -;
66 }
67
68 // function to show if an actor exist
69 // exist : return index of actor
70 // n ’ exist pas : return 0
71 function checkHealthActor ( uint _id , address _address ) view public
returns ( uint ) {
72 uint index = 1;
102
73 for ( index ; index <= actorCount ; index ++) {

74 if ( actors [ index ]. id == _id || actors [ index ]. addr ==
_address ) {
75 return index ;
76 }
77 }
78 return 0;
79 }
80
81
82 // function should be call only inside solidity
83 function getActor ( address _address ) view public returns ( actor
memory ) {
84 uint index = checkHealthActor (0 , _address ) ;
85 require ( index >0 , string ( abi . encodePacked ( " Actor does not exist
!! " , toAsciiString ( _address ) ) ) ) ;
86
87 return actors [ index ];
88 }
89
90 // return actor and center name
91 function ge tA c to rA n dC e nt er N am e ( uint _actorID ) public view returns (
string memory , string memory ) {
92 // get actor name and center id
93 uint index = checkHealthActor ( _actorID , address (0) ) ;
94 actor memory tmp = actors [ index ];
95 // get center name
96 ( uint c_index , ) = checkHealthCenter ( tmp . centerID , address (0) ) ;
97 ( , string memory centerName ,) = getCenterByIndex ( c_index ) ;
98 return ( tmp . name , centerName ) ;
99 }
100
101 }
Contrat intelligent ”Patient”

3
4 import { EHR } from " ./ EHR . sol " ;
5 import { HealthAuthority } from " ./ HealthAuthority . sol " ;
6 import { HealthActor } from " ./ HealthActor . sol " ;
7
103
8
9 /* *
10 * @title Patient
11 * @dev Implements Patient methods
12 */
13 contract Patient {
14
15 HealthAuthority authority ;
16 HealthActor actor ;
17
18 struct patient {
19 uint id ;
20 string name ;
21 address addr ;
22 EHR ehr ;
23 string public_key ;
24 }
25 patient [] patients ;
26
28 ( uint index , bool exist ) = authority . ch eck Hea lt hAu th ori ty ( msg .
sender ) ;
30 _;
31 }
32
33 constructor ( address authorityAddress , address actorAddress ) {
34 authority = HealthAuthority ( authorityAddress ) ;
35 actor = HealthActor ( actorAddress ) ;
36 }
37
38 /* *
39 *
///////////////////////////////////////////////////////////////////////
40 * PUBLIC METHODS FOR PATIENT ( GETTERS )

41 *
///////////////////////////////////////////////////////////////////////
42 */
43 function checkPatient ( uint _id , address _address ) view public
returns ( uint , bool ) {
44 uint index = 0;
104

46 for ( uint i = 0; i < patients . length ; i ++) {
47 if ( patients [ i ]. id == _id || patients [ i ]. addr == _address ) {
48 exist = true ;
49 index = i ;
50 break ;
51 }
52 }
54 }
55
56 function getNumberOfPatient () public view returns ( uint ) {
57 return patients . length ;
58 }
59
60 function getPatientByIndex ( uint _index ) public view returns ( uint ,
string memory , address ) {
61 require ( _index >= 0 && _index < patients . length , " Wrong index !! "
);
62 return ( patients [ _index ]. id , patients [ _index ]. name , patients [
_index ]. addr ) ;
63 }
64
65 /* *
66 *
///////////////////////////////////////////////////////////////////////
67 * PUBLIC METHODS FOR REQEUST

68 *
///////////////////////////////////////////////////////////////////////
69 */
70 // //////// ONLY CALL BY PATIENT //////////
71 function getNumberOfRequest () public view returns ( uint256 ) {
72 ( uint index , bool exist ) = checkPatient (0 , msg . sender ) ;
73 require ( exist , " You are not a patient !! " ) ;
74 return patients [ index ]. ehr . getNumberOfRequest () ;
75 }
76 function getRequestByIndex ( uint256 _requestID ) public view returns (
string memory , uint256 , EHR . RequestType , EHR . RequestState , string
memory ) {
78 require ( exist , " You are not a patient !! " ) ;
105
79 // get a request : ( actorID , timestamp , rType , state )

80 ( uint actorID , uint256 timestamp , EHR . RequestType rType , EHR .
RequestState state ) = patients [ index ]. ehr . getRequestByIndex (
_requestID ) ;
81
82 ( string memory actorName , string memory centerName ) = actor .
g et Ac t or A nd Ce n te rN a me ( actorID ) ;
83
84 return ( actorName , timestamp , rType , state , centerName ) ;
85 }
86 /* *
87 * @dev Response to a request from associated patient .
88 * @param _requestID the request id
89 */
90 function setResponse ( uint _requestID , EHR . RequestState _newState )
public {
91 // check if this is trusted patient
93 require ( exist , " you are not a patient , permission denied !! " ) ;
94
95 // response to request
96 patients [ index ]. ehr . setResponse ( _requestID , _newState ) ;
97
98 // event to actor
99 }
100
101 // //////// ONLY CALL BY ACTOR //////////
102 function ver ifyAuth orizatio n ( uint _patientID , EHR . RequestType _type )
public view returns ( EHR . RequestState , uint ) {
103 ( uint index , bool exist ) = checkPatient ( _patientID , address (0 x0 )
);
104 require ( exist , " This patient does not exist !! " ) ;
105 // get actor id for checking respose
106 uint actor_id = actor . getActor ( msg . sender ) . id ;
107 return patients [ index ]. ehr . checkResponse ( actor_id , _type ) ;
108 }
109 /* *
110 * @dev Create a new request from an actor .
111 * @param _patientID this is a patient id
112 * @param _requestType the type of request CONSULT PUBLISH
113 */
114 function sendRequest ( uint _patientID , EHR . RequestType _requestType )
public returns ( bool ) {
106
115 // check if caller is actor

116 uint actorID = actor . getActor ( msg . sender ) . id ;
117
118 // check if patient exist
119 ( uint index , bool exist ) = checkPatient ( _patientID , address (0) ) ;
120 require ( exist , " Patient does not exist !! " ) ;
121
122 patients [ index ]. ehr . setRequest ( actorID , _requestType ) ;
123
124 // TODO : event to patient
125
126 return true ; // return the requestID
127 }
128
129
130 /* *
131 *
///////////////////////////////////////////////////////////////////////
132 * PUBLIC METHODS FOR EHR PURPOSE

133 *
///////////////////////////////////////////////////////////////////////
134 */
135
136 function getNbOfEHR ( uint _patientID ) public view returns ( uint256 ) {
137 ( uint index , bool exist ) = checkPatient ( _patientID , msg . sender ) ;
138 require ( exist , " This patient does not exist !! " ) ;
139 return patients [ index ]. ehr . ehrCount () ;
140 }
141
142 // test
143 function getEHR ( uint _ehrID , uint _patientID ) view public returns (
string memory , uint256 , string memory , string memory , string memory
, string memory , string memory ) {
144 // EHR = ( title , date , actorName , centerName , hash , ipfs ,
secretKey )
145
146 // // if the caller is patient
147 ( uint index , bool isPatient ) = checkPatient (0 , msg . sender ) ;
148 if ( isPatient ) {
149 EHR . EHRAbstract memory temp1 = patients [ index ]. ehr .
getEHRAbstract ( _ehrID ) ;
107
150 ( string memory actorName , string memory centerName ) = actor .

g et Ac t or A nd Ce n te rN a me ( temp1 . actorID ) ;
151 return ( temp1 . title , temp1 . date , actorName , centerName ,
temp1 . ehrHash , temp1 . ipfsHashAddress , temp1 . secretKey ) ;
152 }
153
154 // // if the caller is actor = >
156 ( index , isPatient ) = checkPatient ( _patientID , address (0) ) ;
157 require ( isPatient , " patient does not exist !! " ) ;
158 // check actor
160 // check the authorization
161 ( EHR . RequestState state , uint _requestID ) = patients [ index ]. ehr .
checkResponse ( actorID , EHR . RequestType . CONSULT ) ;
162 require ( state == EHR . RequestState . ACCEPTED , " Permission denied !!
please request patient for consulting ... " ) ;
163 // get the EHR
164 EHR . EHRAbstract memory temp = patients [ index ]. ehr . getEHRbyActor (
_requestID , actorID , _ehrID ) ;
165 ( string memory actorrName , string memory centerrName ) = actor .
g et Ac t or A nd Ce n te rN a me ( temp . actorID ) ;
166 return ( temp . title , temp . date , actorrName , centerrName , temp .
ehrHash , temp . ipfsHashAddress , temp . secretKey ) ;
167 }
168
169 // ///////////// ACTOR ONLY ///////////////
170
171 function shareEHR ( uint _patientID , uint _requestID , string memory
_title , string memory _hash , string memory _ipfsAddr , string
memory _secretKey ) public {
173 ( uint index , bool exist ) = checkPatient ( _patientID , address (0) ) ;
174 require ( exist , " patient does not exist !! " ) ;
175
176 // check if actor exist and get the actor id
178
179 patients [ index ]. ehr . addEHRAbstract ( _requestID , _title , actorID ,
_hash , _ipfsAddr , _secretKey ) ;
180 }
181 /* *
182 *
108
///////////////////////////////////////////////////////////////////////
183 * PUBLIC METHODS FOR REGISTRATION PURPOSE ( Authority only )

184 *
///////////////////////////////////////////////////////////////////////
185 */
186 function addPatient ( uint _id , string memory _name , address _account ,
string memory _pKey ) public onlyAuthority {
187 ( , bool exist ) = checkPatient ( _id , _account ) ;
188 require ( exist == false , " patient id or account already exist !! " ) ;
189
190 patients . push ( patient ( _id , _name , _account , new EHR () , _pKey ) ) ;
191 }
192
193 function rmPatient ( uint _id ) public onlyAuthority {
194 ( uint index , bool exist ) = checkPatient ( _id , address (0) ) ;
195 require ( exist == true , " patient does not exist !! " ) ;
196
197 patients [ index ] = patients [ patients . length -1];
198 patients . pop () ;
199 }
200 }
Contrat intelligent ”EHR”

3 /* *
4 * @title EHR
5 * @dev Implements EHR methods
6 */
7 contract EHR {
8 // request expired time in second
9 uint256 constant EXPIRED_TIME = 86400;
10 enum RequestType {
11 PUBLISH ,
12 CONSULT
13 }
14 enum RequestState {
15 ACCEPTED ,
16 REFUSED ,
17 PENDING ,
109
18 CANCELLED
19 }
20 struct request {
21 uint actorID ;
22 uint256 timestamp ;
23 RequestType rType ;
24 RequestState state ;
25 string ipfsAddress
26 string secretKey
27 }
28 request [] requests ;
29 enum EHRType {
30 examen ,
31 SCANNER
32 }
33 struct EHRAbstract {
34 // uint id ; index in the array of EHRAbstract
35 string title ;
36 uint256 date ;
37 uint actorID ;
38 string ehrHash ;
39 string ipfsHashAddress ;
40 string secretKey ;
41 }
42 // EHRAbstract [] ehrArray ;
43 mapping ( uint256 = > EHRAbstract ) public ehrArray ;
44 uint256 public ehrCount = 0;
45
46 constructor () {}
47
48
49 /* *
50 * /////////////////////////////////////////////////////////
51 * PUBLIC METHODS FOR REQUEST PURPOSE
52 * /////////////////////////////////////////////////////////
53 */
54 function c he ckE xpi re dRe qu est s () internal {
55 for ( uint i =0; i < requests . length ; i ++) {
56 if ( requests [ i ]. state == RequestState . PENDING ) {
57 uint256 currentTimestamp = block . timestamp ;
58 uint256 timeDifference = currentTimestamp - requests [ i ].
timestamp ;
59 if ( timeDifference > EXPIRED_TIME ) {
110
60 requests [ i ]. state = RequestState . CANCELLED ;

61 }
62 }
63 }
64 }
65
66 // #### for patient utilization ###
67 function getNumberOfRequest () public view returns ( uint ) {
68 // c hec kE xpi re dRe que st s () ;
69 return requests . length ;
70 }
71
72 function getRequestByIndex ( uint _index ) public view returns ( uint ,
uint256 , RequestType , RequestState ) {
73 require ( _index >= 0 && _index < requests . length , " WRONG INDEX
FOR REQUEST !! " ) ;
74 return ( requests [ _index ]. actorID , requests [ _index ]. timestamp ,
requests [ _index ]. rType , requests [ _index ]. state ) ;
75 }
76
77 function setResponse ( uint _requestID , RequestState _newState ) public
{
78 ( bool exist , ) = checkRequest ( _requestID ) ;
79 require ( exist , " Request does not exist !! " ) ;
80 requests [ _requestID ]. state = _newState ;
81 }
82
83 // ### for actor utilization ###
84 function setRequest ( uint _actorID , RequestType _type ) public returns
( uint ) {
85 uint index = requests . length ;
87 requests . push ( request ( _actorID , currentTimestamp , _type ,
RequestState . PENDING ) ) ;
88 return index ;
89 }
90
91 function checkResponse ( uint _actorID , RequestType _type ) public view
returns ( RequestState , uint ) {
93 uint i = requests . length ;
94 for ( i ; i >0; i - -) {
95 if ( requests [i -1]. actorID == _actorID && requests [i -1]. rType
111
== _type ) {
96 uint256 timeDifference = currentTimestamp - requests [i
-1]. timestamp ;
97 if ( timeDifference > EXPIRED_TIME ) { // CANCELLED
98 return ( RequestState . CANCELLED , 0) ;
99 } else {
100 return ( requests [i -1]. state , i -1) ;
101 }
102 }
103 }
104 return ( RequestState . CANCELLED , 0) ;
105 }
106
107 // ### for internal utilization ###
108 function checkRequest ( uint _requestID ) view public returns ( bool ,
bool ) {
110 uint256 timeDifference = currentTimestamp - requests [ _requestID
]. timestamp ;
111
112 if ( timeDifference > EXPIRED_TIME ) { // CANCELLED
113 return ( false , false ) ;
114 }
115 if ( requests [ _requestID ]. state == RequestState . ACCEPTED ) {
116 return ( true , true ) ;
117 }
118 return ( true , false ) ; // REFUSED OR PENDING
119 }
120 /* *
121 * /////////////////////////////////////////////////////////
122 * PUBLIC METHODS FOR EHR PURPOSE
123 * /////////////////////////////////////////////////////////
124 */
125
126 // // /// // /// // /// // /// FOR OWNER
127 function getEHRAbstract ( uint _ehrID ) view public returns (
EHRAbstract memory ) {
128 require ( _ehrID > 0 && _ehrID <= ehrCount , " EHR does not exist !!
");
129 return ehrArray [ _ehrID ];
130 }
131
132 // // /// // /// // /// // /// FOR ACTOR
112
133 function addEHRAbstract ( uint _requestID , string memory _title , uint

_actorID , string memory _hash , string memory _ipfsAddr , string
memory _secretKey ) public returns ( uint _ehrID ) {
134
135 // 1 - check the request
136 ( bool exist , bool accepted ) = checkRequest ( _requestID ) ;
137 require ( exist && accepted , " Request does not exist or does not
accepted !! " ) ;
138
139 // 2 - check if actor is the same in the request
140 require ( requests [ _requestID ]. actorID == _actorID , " permission
denied !! " ) ;
141
142 // 3 - check the type of request ( publish )
143 require ( requests [ _requestID ]. rType == RequestType . PUBLISH , "
permission denied !! " ) ;
144
145
146 // share the EHR
147 ehrCount ++;
148 ehrArray [ ehrCount ] = EHRAbstract ( _title , block . timestamp ,
_actorID , _hash , _ipfsAddr , _secretKey ) ;
149
150 return ehrCount ;
151 }
152
153 function getEHRbyActor ( uint _requestID , uint _actorID , uint _ehrID )
view public returns ( EHRAbstract memory ) {
154 // 1 - check the request
155 ( bool exist , bool accepted ) = checkRequest ( _requestID ) ;
156 require ( exist && accepted , " Request does not exist or does not
accepted !! " ) ;
157
158 // 2 - check if the same actor
159 require ( requests [ _requestID ]. actorID == _actorID , " permission
denied !! " ) ;
160
161 // 3 - check the type of request ( consult )
162 require ( requests [ _requestID ]. rType == RequestType . CONSULT , "
permission denied !! " ) ;
163
164 return getEHRAbstract ( _ehrID ) ;
165 }
113
EMP Annexe C. Application web pour les hopitaux
166 }
B Déploiement du réseau blockchain
La Figure B.1 présente le résultat de l’exécution de la commande ”admin.peers” qui

affiche l’ensemble des noeuds interconnectés.
Figure B.1 — Nœuds interconnectés du réseau blockchain.
114
C Application web pour les hopitaux
Nous avons dans cette partie bien détaillé la mise en œuvre de l’application web déve-
loppée.
C.1 Conception de l’application
Dans cette section, nous avons détaillé la conception de notre application web pour les
hôpitaux afin de bien comprendre la structure et le fonctionnement de l’application.
Diagramme de classe
Dans notre conception de l’application, nous avons créé le diagramme de classes, qui
est utilisé pour modéliser la structure des classes et les relations entre elles. Ils servent à
la fois pour la conception initiale de l’application en définissant les classes, leurs attributs
et leurs méthodes, ainsi que pour la modélisation des relations entre ces classes. Les
diagrammes de classes sont également utilisés comme documentation pour l’application,
offrant une vue d’ensemble de sa structure et facilitant la compréhension du code pour les
développeurs futurs. Ils sont également utiles pour la communication entre les membres
de l’équipe de développement et les parties prenantes, en fournissant une représentation
visuelle claire de l’architecture de l’application.
115
EMP
user
+ nom : String patient
+ prenom : String - matricule_P : Long
hopital + dateDeNaissance : Date - situationFamilliale : String
+ genre : String - numeroTel : Long
- id_hopital : Number + dateInscription : Date - adresse : Long
- nom_hopital : String + email : Long - photo : String
- adresse_hopital : Long + username : String - taille : Number
- fax : Long 0..* staff + authentification () : java.lang.Boolean - poids : Float
0..* - adresse : java.lang.Long ... - group sanguin : String
- photo : java.lang.Long - password : String
0..1 - password : java.lang.Long + voir_liste_autorisation () : java.lang.Object
- num_tel : java.lang.Long + repondre_autorisation () : java.lang.Boolean
+ voir_rendezvous () : java.lang.Object
+ voir_DSE () : java.lang.Object
...
1..1
médecin
- matricule_M : Long
- grade_scientifique : String
+ demande_consultation () : java.lang.Boolean
+ demande_partage () : java.lang.Boolean
admin + voir_DSE () : java.lang.Object
employe
- matricule_A : Number + partager_DSE () : java.lang.Object
+ voir_rendez-vous () : java.lang.Object - matricule_E : Long
- roleAdmin : String 1..*
+ voir_liste_medecins () : java.lang.Object + cree_rendezvous () : java.lang.Object
+ ajouter_user () : java.lang.Object + voir_liste_employees () : java.lang.Object 0..1 + voir_liste_medecins () : java.lang.Object
+ modifer_user () : java.lang.Object ... + voir_liste_patients () : java.lang.Object rendez_vous
+ supprimer_user () : java.lang.Boolean
... - code_rendezvous : int
+ voir_user () : java.lang.Object 1..*
+ ajouter_lab () : java.lang.Object - date_rendezvous : Date
+ supprimer_lab () : java.lang.Boolean - lib_rendezvous : Long
+ ajouter_composant () : java.lang.Object consultation
+ ajouter_medicaments () : java.lang.Object
- id_consultation : int
+ voir_statistique () : java.lang.Number traitement
... - titre : String 0..*
- date : Date - nom : int
- période : Date
- instructions : String
116
0..1 1..1 0..1 0..1
compte_rendu allergie
0..* 0..1
Annexe C. Application web pour les hopitaux

Analyses 0..* - nom : String
- réaction : String
- composant : int 0..*
- gravité : String
- résultat : Float
0..* 0..* - unité : String 0..1 0..1
- norme : int 0..*
service 0..* médicament

résumé - nom : String
- id_service : Number
- lib_service : String 1..1 - résumé : String maladie - dose : Float
0..*
- chef_service : String - quantité : int
- observation : String - note : String
- status : String
1/3
Figure C.1 — Diagramme de classe de l’application.

C.2 Développement de l’application
Dans ce paragraphe, nous avons représenté et expliqué les différents choix et technolo-
gies utilisés dans le développement de notre application web
Choix de la technologie du serveur
Le choix de Django comme serveur backend repose sur sa robustesse, sa productivité

et son architecture. Django est un framework backend mature, soutenu par une com-
munauté active de développeurs. Il offre une large gamme de fonctionnalités intégrées
qui permettent de développer rapidement des applications web complexes. L’architecture
MVC de Django facilite la séparation des préoccupations et la gestion du code. De plus,
Django dispose d’un ORM puissant pour interagir avec la base de données, garantissant
une manipulation facile et sécurisée des données et suit le principe du DRY (Don’t Repeat
Yourself), encourageant ainsi la réutilisation du code et la réduction des redondances. En
résumé, Django offre une combinaison idéale de fiabilité, de productivité et de facilité de
développement pour créer des applications web performantes.
Le choix de Node.js comme serveur dans le frontend, combiné à l’utilisation de Vite,
tout en ayant Django comme backend, permet de créer une connexion fluide entre les
deux à l’aide d’API. Les API (Application Programming Interfaces) sont des interfaces
de communication standardisées qui permettent au frontend et au backend de s’échanger
des données et de se coordonner. Dans ce contexte, On a utiliser Django pour développer
une API RESTful qui expose les fonctionnalités et les données du backend. Le frontend,
développé avec Node.js et Vite, peut ensuite consommer ces API pour récupérer les don-
nées nécessaires et envoyer des requêtes au backend. Cette approche permet de séparer
clairement la logique métier du backend et l’interface utilisateur du frontend, tout en faci-
litant la communication et l’échange de données entre les deux. En utilisant des API bien
conçues, vous pouvez assurer une interopérabilité efficace et une évolutivité de application,
permettant ainsi une expérience utilisateur fluide et réactive.
Architecture de l’API
ans notre développement de l’application, nous avons choisi l’architecture REST pour
la création des API, qui est utilisée par la partie frontend avec la bibliothèque Axios.
’API REST Framework de Django est une extension puissante qui facilite la création
d’API RESTful dans le backend. Elle fournit des fonctionnalités telles que la sérialisation
des données, la gestion des requêtes HTTP, la gestion des authentifications et des autori-
sations, ainsi que la définition des points d’entrée (endpoints) de l’API. Grâce à cette API,
117
vous pouvez définir les ressources et les opérations disponibles dans votre backend Django,
ce qui permet au frontend de communiquer avec le backend de manière standardisée.
D’un autre côté, Axios est une bibliothèque populaire de requêtes HTTP pour Vue.js.
Elle facilite l’envoi de requêtes depuis le frontend vers le backend, permettant ainsi de
consommer les API créées avec Django REST Framework. Axios prend en charge les
requêtes GET, POST, PUT, DELETE, et fournit des fonctionnalités avancées telles que
la gestion des en-têtes, des paramètres, des intercepteurs de requêtes et de réponses, ainsi
que la gestion des erreurs. Avec Axios, vous pouvez établir des connexions HTTP fiables
et flexibles entre le frontend Vue.js et l’API RESTful du backend Django.
En combinant l’API REST Framework de Django avec Axios de Vue.js, vous pou-
vez réaliser des opérations telles que la récupération de données à partir du backend, la
création, la mise à jour et la suppression de ressources, tout en respectant les principes
REST. Vous pouvez également gérer les autorisations et l’authentification en utilisant les
fonctionnalités fournies par l’API REST Framework et Axios.
Backend
Dans la partie backend, nous avons divisé notre projet en plusieurs modules en fonc-
tionnalité de notre application. Nous avons créé 3 modules principaux tels que ”Accounts”,
”Appointment” et ”Record” (voir la Fig. C.2, et nous avons utilisé quelques modules pré-
existants dans le projet Django. Cette division modulaire présente plusieurs avantages
tels que la maintenabilité du code, une meilleure réutilisation du code et une plus grande
flexibilité et évolutivité de l’application.
118
EMP
119
Annexe C. Application web pour les hopitaux

Figure C.2 — Diagramme représentatif de la partie backend de l’application.
Frontend
Pour le développement des interfaces de notre application on a utilisé le framework

VueJs, qui l’offre de nombreux avantages pour la création des interfaces web interactives
et modernes. Vue.js est un framework JavaScript progressif et flexible qui permet de
construire des applications web évolutives et réactives.
L’un des principaux atouts de Vue.js réside dans sa structure basée sur des composants.
Les composants sont les éléments de base de Vue.js et permettent de découper l’interface
utilisateur en parties autonomes et réutilisables. Chaque composant encapsule sa propre
logique, son style et son modèle de données, ce qui facilite la maintenance et la gestion
du code. Les composants Vue.js peuvent être imbriqués les uns dans les autres, formant
ainsi une structure hiérarchique qui reflète la structure de l’interface utilisateur.
Outre les composants, Vue.js propose également d’autres concepts clés pour structurer
une application. Le routeur Vue Router permet de gérer la navigation entre les différentes
pages ou vues de l’application. Il offre des fonctionnalités telles que la définition des routes,
la gestion des paramètres d’URL et la transition en douceur entre les vues.
En ce qui concerne la gestion de l’état de l’application, Vue.js propose Vuex. Vuex est
une bibliothèque de gestion d’état qui permet de centraliser et de gérer efficacement les
données partagées entre les composants. Il facilite la gestion de l’état global de l’applica-
tion, en permettant des modifications prévisibles et en simplifiant la communication entre
les composants.
Structure de notre projet frontend :
1 Nom de projet : H e a l t h A p p F r o n t
2 - . vscode
3 - public
4 - src
5 - assets
6 - auth
7 - components
8 - router
9 - store
10 - userPages
11 - views
12 - App . vue
13 - main . js
14 - . dockerignore
15 - . env
16 - . eslintrc . js
120
17 - . gitignore
18 - Dockerfile
19 - README . md
20 - index . html
21 - package . json
22 - vite . config . js
Code Source
Notre code source de la plateforme est dans GitHub en mode privé. Le projet est divisé
en 4 dépôts :
Dépôt de la blockchain et de l’autorité de santé :
https://github.com/Badro1859/EHR-SHARE-SYS
Dépôt de déploiement d’IPFS :

https://github.com/Badro1859/HealTech/tree/master/ipfs
Dépôt de la partie frontend :

https://github.com/MiilouDz/HealthAppFront
Dépôt de la partie backend :

https://github.com/Badro1859/HealTech/tree/master/backend-Django
Chaque projet contient un fichier Readme qui comprend l’ensemble des étapes pour
l’installation et le déploiement.
121
Résumé : L’accès à l’historique médical des patients est une chose très importante dans les
soins médicaux, pouvant sauver des vies ou causer des erreurs graves. Plusieurs technologies sont
utilisées pour répondre à ce besoin, permettant d’accéder à l’historique des patients, mais elles
présentent quelques défis importants tels que l’interopérabilité, l’asymétrie de l’information et
la confidentialité de la vie privée des patients.
Pour surmonter ces défis, nous avons développé, dans le cadre de ce projet, une plateforme de
partage des dossiers médicaux sur une blockchain privée. Cette plateforme permet aux différents
acteurs de santé d’accéder au dossier de santé électronique de manière totalement sécurisée et
fluide, tout en respectant les autorisations accordées par les patients, qui conservent un contrôle
total sur leurs DSE. Dans le but d’améliorer la qualité des soins tout en préservant la vie privée
des patients.
Mots-clés : Blockchain, Partage des données médicales, Confidentialité des données, dossier
de santé électronique, IPFS, Cryptographie.
Abstract :
Access to patient’s medical history is of utmost importance in medical care, as it can save
lives or lead to serious errors. Several technologies are used to address this need, enabling access
to patient histories, but they pose significant challenges such as interoperability, information
asymmetry, and patient privacy.
To overcome these challenges, we have developed, as part of this project, a platform for sharing
medical records on a private blockchain. This platform allows different healthcare stakeholders to
securely and seamlessly access electronic health records while respecting the permissions granted
by patients, who retain full control over their EHRs. The goal is to improve the quality of care
while preserving patient privacy.
Keywords : Blockchain, Medical Data Sharing, Electronic health record, Cryptographie, Data
privacy, IPFS.
: jÊÓ
¨ñ¯ð ©JÖßð h@ð P B@ Y® JK à @ áºÖß IJ k ,úæQÖÏ @ t'PAK é¯QªÓ @ Yg ø PðQåË@ áÓ , éJ jË@ éK A«QË@ ÈAm× ú¯
. .

à P@ñJË@ ÐY«ð ¯@ñJË@ ÐY« ÉJÓ HAK
Ym' ék. @ñK AîDºËð , ék. AmÌ '@ è Yë éJJ.ÊJË ÐYjJ HAJ
J®K èY« Yg. ñK . èQ¢k ZA¢k @
.úæQÖÏ @ éJ ñk ¡®kð HAÓñÊªÖ Ï @ ú¯
Ö Ï ( á»ñÊK
HCm . é»PA . ) ÉJºË@ éÊÊ éJ J® K úÎ« YÒJªK é JÓ QK ñ¢JK AJÔ¯ , HAK
. YjJË@ è Yë úÎ« I.ÊªJÊË

, éÊð éJÓ @ é®K Q¢. úGð QºËB @ éjË@
Ém. úÍ@ ÈññË@ éJ jË@ éK A«QË@ ÈAm.× ú¯ áÒJêÒÊË é JÖÏ @ è Yë iJK .úæQÖÏ @
ám' úÍ@ ¨ðQåÖÏ @ @ Yë ¬YîE . éJ Kð QºËB @ ÑîECm . ú¯ ÉÓA¾Ë@ ÕºjJËAK. àñ¢®Jm' áK YË@ úæQÖÏ @ à X@ úÎ« ZA JK. ½Ë Xð
.úæQÖÏ @ éJ ñk úÎ« A®mÌ '@ð éJ jË@ éK A«QË@ èXñk.
éJ ñk ,úGð QºËB @ éjË@
Ém. ,ÉJºË@ éÊÊ , éJ J.¢Ë@ HA Ó
KAJJ.Ë@ é»PA KAJJ.Ë@ éJ ñk : éJ kAJ®ÖÏ @ HAÒÊ¾Ë@
, HA

. IPFS , Q® Ë@ , HA KAJJ.Ë@

HealTech PFE 2022 2023

Transféré par

Droits d'auteur :

Formats disponibles

HealTech PFE 2022 2023

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HealTech PFE 2022 2023

Transféré par

Droits d'auteur :

Formats disponibles

MEMOIRE DE FIN D'ETUDES

Présenté pour l’obtention du diplôme d’Ingénieur d’Etat

FILIERE : Génie Informatique

SPECIALITE : Systèmes d'Information d'Aide à la Décision

Par : -EOC MADANI Mahmoud Bader Eddine

Développement d’une plateforme de partage des dossiers médicaux

Soutenu le 31-Mai-2023 devant le jury composé de :

Président : COL AMAROUCHE Idir Amine HCA/1°RM

Membre : CDT BENKHADDRA Ilyas IRD-DAT

Rapporteur Critique : CNE BOULAHIA Said Yacine EMP

Promoteur (s) : LtCol KENAZA Tayeb EMP

COL ZAIDI Abdelhalim EMP

Je souhaite également souligner la contribution précieuse de mon binôme, Bader Eddine,

Mahmoud Bader Eddine

Liste des figures xiii

Liste des tableaux xv

Liste des acronymes xvii

I Concepts fondamentaux sur le partage des dossiers médicaux 3

II Blockchain et gestion des dossiers médicaux 23

II.2.2 Éléments de la blockchain . . . . . . . . . . . . . . . . . . . . . . . 26

III Conception de la plateforme HealthTech 43

IV Réalisation de la plateforme HealthTech 65

IV.2 Mise en œuvre d’un réseau blockchain . . . . . . . . . . . . . . . . . . . . . 67

Conclusion générale et perspectives 89

I.1 Architecture centralisée de partage . . . . . . . . . . . . . . . . . . . . . . 15

II.1 Structure d’un bloc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

III.1 Architecture de la plateforme . . . . . . . . . . . . . . . . . . . . . . . . . 46

IV.1 Comptes blockchain fournis par le simulateur Ganache. . . . . . . . . . . 69

IV.11 Interface web pour l’autorité de santé. . . . . . . . . . . . . . . . . . . . . 76

I.1 Comparaison des caractéristiques des réseaux informatique, du cloud com-

II.1 Comparaison des plateformes de partage de DSE basé sur la blockchain . 38

III.1 Structure d’une demande stockée dans la blockchain. . . . . . . . . . . . . 52

IV.1 Structure d’une demande stockée dans la blockchain. . . . . . . . . . . . . 73

API Application Programming Interface

PoW Proof of Work

L’avènement récent de la technologie affecte toutes les parties de la vie humaine et

— Dans le chapitre II, nous introduisons la technologie de la blockchain et d’IPFS.

— Dans le chapitre III, nous décrivons l’architecture du système proposé en exami-

CONCEPTS FONDAMENTAUX SUR LE

I.2 Données médicales

données médicales et garantir leur utilisation responsable et éthique [4].

I.2.1 Différentes catégories de données médicales

Les données médicales peuvent être classées en différentes catégories en fonction de

3. Données de surveillance de la santé publique : Ces données sont collectées pour

I.2.2 Sources de données médicales

Administration de la santé : Les données administratives de santé sont des données

I.2.3 Caractéristiques des données médicales

médicaux, les résultats d’examens médicaux et les prescriptions [1].

Confidentialité : Les données médicales sont souvent sensibles et confidentielles, ce qui

Qualité : Les données médicales peuvent varier en termes de qualité et de précision, en

Disponibilité limitée : Certaines données médicales peuvent ne pas être accessibles en

I.3 Dossier de santé électronique (DSE)

I.3.1 Avantages de dossier de santé électronique

Certains des avantages fondamentaux associés aux dossiers de santé électroniques

— Clinical Decision Support (CDS)

— Computerized Physician Order Entry (CPOE)

— Health Information Exchange (HIE)

I.3.2 Défis de dossier de santé électronique

I.3.3 Standards des dossiers de santé électroniques