DEDICACE

À mes chers parents, pour leur patience, leur amour, leurs soutiens ainsi que leurs
encouragements

I
 REMERCIEMENTS

Après avoir rendu grâce à Dieu le Tout Puissant et le Miséricordieux, je tiens

à remercier vivement tous ceux qui, de près ou de loin ont participé à la rédaction de
ce mémoire. Je remercie plus particulièrement :

Prof. KONATE Adama, actuel Directeur Général de l’ESATIC, pour tous les efforts
faits pour notre réussite ;

Dr. SORO Etienne, Directeur de la Pédagogie et encadreur à l’ESATIC ;

Dr. MONSAN Vincent, Maître de conférences à l’Université Félix Houphouët Boigny,
pour avoir accepté d’être notre encadrant académique ;
Dr. BROU Pacôme, Enseignant Chercheur à l’ESATIC, pour avoir également accepté
d’être notre Co-encadrant académique ainsi que pour tous ses conseils et orientations
dans la réalisation du projet ;
M. KEITA Mahamadou, PDG de PORDES et ITConsult qui a permis la réalisation de
ce travail en m’ouvrant grandement les portes de sa société et tout le personnel pour
l’expérience enrichissante et pleine d’intérêt qu’ils m’ont fait vivre durant ma période
de stage ;
M. DANHO Yann, Responsable du service informatique et Développement
d’application, pour son suivi, ses conseils qui m’ont été très utiles ;
Mon adorable grand-père El Hadj KERE Idrissa qui m’a soutenu moralement et m’a
guidé par ses bénédictions et conseils toujours avisés ;
Tous nos camarades de promotion « IT04 » pour la solidarité et la collaboration durant
ces deux ans de formation ;

II
 AVANT-PROPOS

Ce mémoire rentre dans le cadre de l’obtention du diplôme de Master des

Systèmes d’Information et Génie Logiciel.

La réalisation de ce document est indispensable pour tout étudiant en 2ème année de

master à l’ESATIC en vue de la validation de la formation acquise. C’est une grande
phase de perfectionnement pour l’apprenant qui a pour objectif de faire ressortir son
esprit critique et de développer en lui des aptitudes professionnelles. Dans ce document
il sera question de faire l’étude et la mise en place d’un système d’information
hospitalier permettant d’améliorer la gestion administrative et médicale de l’ICA.

L’idée de cette étude est venue de la volonté d’assurer le bon fonctionnement du

système d’information des structures sanitaires afin d’améliorer leur condition de
travail en dématérialisant certains processus dans la prise en charge des malades qui
occasionnent des pertes de temps considérables. Ainsi, une solution intégrée pour
répondre à ces besoins a été proposée tout au long de ce mémoire.

Des difficultés n’ont pas manqué. L’une d’entre elle était la phase de recueil
d’information, car certains agents avaient du mal à bien expliquer leur travail ou à
exprimer leurs besoins. Aussi, le temps de réalisation du projet était court pour mieux
s’imprégner des fonctionnalités de certains automates afin d’établir une relation avec
notre solution.

III
 SOMMAIRE
INTRODUCTION
PREMIERE PARTIE : GENERALITES
CHAPITRE I : PRESENTATION DE L’ENTREPRISE D’ACCUEIL
I. HISTORIQUE
II. DOMAINES D’ACTIVITE
CHAPITRE II : PRESENTATION DU PROJET
I. DEFINITION DES TERMES
II. PRESENTATION DU CAHIER DE CHARGES
CHAPITRE III : ETUDE DE L’EXISTANT
DEUXIEME PARTIE : ANALYSE ET CONCEPTION
CHAPITRE IV : METHODE D’ANALYSE ET DE CONCEPTION
I. METHODES D’ANALYSE ET DE CONCEPTION D’UN SYSTEME
D’INFORMATION
II. UML (Unified Modeling Language)
CHAPITRE V : ANALYSE ET CONCEPTION DU SYSTEME
I. ANALYSE ET SPECIFICATION DES BESOINS
II. CONCEPTION DU SYSTEME
TROISIEME PARTIE : REALISATION DE LA SOLUTION
CHAPITRE VI : ENVIRONNEMENT DE TRAVAIL
I. ENVIRONNEMENT MATERIEL
II. ENVIRONNEMENT LOGICIEL
CHAPITRE VII : RESULTATS ET DISCUSSION
I. RESULTATS
II. DISCUSSIONS
CONCLUSION

IV
 SIGLES ET ABBREVIATIONS

API Application Programming Interface

BAFS Bureau des admissions et frais de séjour
BD Base de Données
CHR Centre Hospitalier Régional
CHU Centre Hospitalier Universitaire
CRUD Create Read Update Delete
DAO Data Access Object
HC Hospitalisation de chirurgie
HM Hospitalisation de Médicine
ICA Institut de cardiologie d’Abidjan
ITC International Technology Consult
IP Internet Protocol
MERISE Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise
MCC Modèle Conceptuel de la Communication
MCD Modèle Conceptuel des Données
MCT Modèle Conceptuel des Traitements
MOT Modèle Organisationnel des Traitements
MVC Modèle Vue Contrôleur
NPM Node Package manager
PGI Progiciel de Gestion Intégrée
PME Petite et Moyenne Entreprise
RDV Rendez-vous
SGBD Système de Gestion de Base de Données
SI Système d’Information
SIC Soins Intensifs Chirurgicaux
SIH Système d’Information Hospitalier
SIM Soins Intensifs Médicaux
UML Unified Modeling Langage
UP Unified Precess
USDP Unified Software Development Process

V
 LISTE DES FIGURES

Figure 1- système avec entrées sorties ......................................................................... 4

Figure 2-Les composantes d'un SIH [9] ....................................................................... 7
Figure 3- Les acteurs d’un SIH .................................................................................... 9
Figure 4- Cycle d'abstraction de conception des systèmes d'information [10] .......... 17
- Figure 5-Processus unifié : enchainements d'activités au cours du cycle de vie
[11] 19
Figure 6- Diagrammes UML [14] .............................................................................. 21
Figure 7- Diagramme des cas d'utilisation du module BAFS .................................... 28
Figure 8-Diagramme des cas d'utilisation du module "Gestion de rendez-vous de
consultation"............................................................................................................... 32
Figure 9- Diagramme des cas d'utilisation du module "gestion médicale" ................ 34
Figure 10- Diagramme des cas d'utilisation du module "gestion médico-technique" 37
Figure 11- Diagramme de séquence du cas d'utilisation "S'authentifier" .................. 40
Figure 12- Diagramme de séquence du cas d’utilisation "Créer un dossier patient" . 41
Figure 13- Diagrammes de séquence du cas d'utilisation "Prise des constantes" ...... 42
Figure 14- Diagramme de séquence du cas d’utilisation "Demande et consultation de
résultat d’examen"...................................................................................................... 43
Figure 15- Diagramme de classes du SIH .................................................................. 45
Figure 16-Architecture de l'application [18] .............................................................. 48
Figure 17- Architecture MVC .................................................................................... 50
Figure 18- icone starUML.......................................................................................... 51
Figure 19- icone de Mysql WORKBENCH............................................................... 52
Figure 20- Icone de VS Code ..................................................................................... 52
Figure 21-icone de MySQL ....................................................................................... 52
Figure 22- Interface d'authentification de l’application ............................................. 57
Figure 23- Menu principal d'un administrateur.......................................................... 58
Figure 24- Interface du module BAFS ....................................................................... 59
Figure 25- Formulaire de saisie d'une admission ....................................................... 60
Figure 26- Interface de demande RDV de consultation ............................................. 61
Figure 27- Interface du module de gestion médicale ................................................. 62
Figure 28-Fiche de surveillance médicale recto.......................................................... X
Figure 29- Fiche de surveillance médicale (verso) .................................................... XI
Figure 30- Fiche Comptable......................................................................................XII
Figure 31- Carnet de consultation médical ............................................................. XIII

VI
 LISTE DES TABLEAUX

Tableau 1 – Etat de l’’existant logiciel ...................................................................... 14

Tableau 2- Récapitulatif des différentes liaisons du diagramme des cas d'utilisation 27
Tableau 3- Description textuelle du cas d'utilisation "S'authentifier" ........................ 29
Tableau 4- Description textuelle du cas d'utilisation "Gérer les dossiers patients" ... 29
Tableau 5- Description textuelle du cas d'utilisation "Rechercher et visualiser une
information" ............................................................................................................... 30
Tableau 6- Description fonctionnelle du cas d'utilisation "Enregistrer une admission"
.................................................................................................................................... 31
Tableau 7- Description textuelle du cas d’utilisation " Gérer les encaissements de
facture" ....................................................................................................................... 31
Tableau 8- Description textuelle du cas d'utilisation "Planifier le programme des
médecins consultants" ................................................................................................ 33
Tableau 9- Description textuelle du cas d'utilisation “Enregistrer une demande de
consultation“ .............................................................................................................. 33
Tableau 10- Description textuelle du cas d’utilisation "Prise des constantes" .......... 35
Tableau 11- Description textuelle du cas d’utilisation " Consulter les résultats des
examens demandés" ................................................................................................... 36
Tableau 12- Description textuelle du cas d'utilisation "Enregistrer les résultats
d'examens" ................................................................................................................. 38
Tableau 13- Description textuelle du cas d’utilisation "Imprimer les résultats
d’examens" ................................................................................................................. 38
Tableau 14-Formalisme du diagramme de sequences ............................................... 39
Tableau 15- Formalisme utilisé dans un diagramme de classes [21] ......................... 44

VII
 INTRODUCTION
Depuis quelques années, avec l’évolution technologique, nombreuses structures
sanitaires ivoiriennes ont décidé d’informatiser leur système d’information afin de
faciliter sa gestion et de mieux s’appesantir sur leur activité première qui consiste à
soigner les malades. Cependant, cette automatisation se limite à la gestion
administrative (l’enregistrement et l’identification numérique des patients, la
facturation et la caisse) mettant en marge le traitement informatisé des données
médicales qui constituent un moyen rapide d’analyse et de facilitation dans la prise en
charge médicale des patients. En outre, selon une étude menée par Dr. K. Patrick Adon,
le système d’archivage numérique des données médicales et de gestion sanitaire en
Côte d’Ivoire semble quasi inexistant avec un faible taux d’implémentation en dessous
de 15% pour les CHU et CHR [1].

Le domaine hospitalier rassemble une infinité de services qui peuvent être regroupés
en deux grandes catégories, à savoir : les services administratifs et médicaux. Les
services médicaux en particulier produisent quotidiennement une quantité énorme de
données dont la gestion et la communication par le personnel médical à travers les
carnets de santé, les bulletins d’examens, les registres, … s’avèrent de plus en plus
complexes et engendre une perte de temps dans la prise en charge des patients. Ainsi
la mise en place d’un système d’information hospitalier adéquat pouvant gérer tant le
volet administratif que médical de nos centres de santé devient une nécessité.

Vu les avantages que pourraient apporter les Technologies de l’Information et de la

Communication (TIC) dans un milieu hospitalier en général et dans la
dématérialisation du dossier patient en particulier, l’Institut de Cardiologie d’Abidjan
en abrégé ICA dévoué à améliorer sa qualité de service à décider de faire appel à
l’entreprise ITCONSULT pour la mise en place d’un système d’information moderne
qui contribuera à l’atteinte de ses objectifs. D’où l’intérêt de notre sujet : « Etude et
mise en place d’un système d’information hospitalier (SIH) : cas de l’ICA ». Ce
système devra permettre la prise en charge informatisée du patient en partant de son
admission jusqu’à sa sortie. Ce sujet suscite les questions suivantes : dans quelle
mesure la numérisation du système d’information hospitalier pourrait-elle participer à

1
l’amélioration de la prise en charge médicale des patients ? Quelle démarche suivre
pour réaliser un tel projet ? Quelles sont les exigences d’un tel système ? Quels sont
les modules à implémenter pour gérer et optimiser l’ensemble des processus métiers ?

Pour répondre à ces questions, nous organisons notre étude en trois grandes parties. La
première partie sera dédiée à la présentation générale du projet avec une présentation
de la société d’accueil et ses domaines d’activité. Ensuite, la deuxième partie
s’articulera autour de l’analyse et la conception du système. Enfin, la troisième partie
portera sur la réalisation de la solution mettant en exergue les résultats obtenus.

2
PREMIERE PARTIE

GENERALITES
 CHAPITRE I : PRESENTATION DE L’ENTREPRISE
D’ACCUEIL

Dans ce chapitre, nous présentons l’historique et les domaines d’activité de la

structure d’accueil.

I. HISTORIQUE

Née de la volonté d’ingénieurs et techniciens ivoiriens ayant mené une longue partie
de leur carrière professionnelle dans divers domaines dont celui de l’assurance
maladie, INTERNATIONAL TECHNOLOGY CONSULT (ITConsult) a trouvé
sa vocation dans l’ingénierie des systèmes d’information, le conseil, la formation et
l’assistance en gestion.
Elle est basée au Plateau, au 5ème étage de l’Immeuble de la Chambre Nationale
d’Agriculture.
La compétence de son personnel lui a permis de développer une expertise dans
différents domaines.

II. DOMAINES D’ACTIVITE

ITConsult exerce principalement dans les domaines d’activité suivants :

▪ L’ingénierie de projets de santé et de micro-assurance santé ;

▪ Le Développement et l’Intégration de Solutions Informatiques pour la gestion
des Risques ;
▪ Le Conseil en Stratégie et Organisation des Systèmes de Gestion de Risques ;
▪ La Gestion de Régimes Mutuelles de Santé, Assurance Maladie Interne et
Contrats d’Assurance Maladie ;
▪ La conception, la réalisation et l’intégration de projets de gestion d’Assurance
Vie (Retraite et décès) et d’Assurance Maladie ;
▪ La digitalisation des données de grands groupes et de PME ;
▪ La mise en place d’environnements hyper-convergés dans un monde digital.

3
 CHAPITRE II : PRESENTATION DU PROJET

Dans ce chapitre, nous définissons les notions clés de notre projet afin de faciliter sa
compréhension et ensuite présentons le cahier de charges de notre projet.

I. DEFINITION DES TERMES

1. Définitions du système

Un système est un ensemble d’éléments qui interagissent entre eux dans un

environnement particulier en formant un tout. Il est donc le siège d’échanges et de
relations plus ou moins complexes, ses caractéristiques permettent de l’identifier en
tant qu’un objet unique. On le définit aussi comme étant la matérialisation d’une
correspondance entre un ensemble de variables d’entrée et un ensemble de variables
de sorties et sa réponse dépend de son état et de ses entrées, elle peut évoluer en
fonction du temps (figure 01) [2].

Entrées Sorties
S
Figure 1- système avec entrées sorties

Un système est une association d'éléments qui peuvent être matériels, logiciels ou bien
encore humains en interaction grâce à des flux d'énergie, d'information ou de matière,
qui remplissent une ou plusieurs fonctions.

2. Organisation

Une organisation est un ensemble d'éléments en interaction, regroupés au sein d'une

structure régulée, ayant un système de communication pour faciliter la circulation de
l'information, dans le but de répondre à des besoins et d'atteindre des objectifs
déterminés.

4
 3. Hôpital

Un hôpital est un établissement de soins où un personnel soignant peut prendre en

charge des personnes malades ou victimes de traumatismes trop complexes pour être
traités à domicile ou dans le cabinet de médecin [3]. L’hôpital réalise plusieurs services
à savoir ces services généraux (médecine générale, chirurgie, pharmacie, …), ces
services spécifiques (Laboratoires d’analyse biologique, établissement de transfusion
sanguine, …) et spécialisés (hôpitaux psychiatriques, sanatoriums, …),
l’enseignement (Hôpital disposant une faculté de médecine). Pour assurer ces
fonctions l’hôpital dispose de certaines ressources. En conséquence, l’hôpital est une
énorme machine sociale, économique et financière.

4. Organisation hospitalière

L’organisation hospitalière est une organisation qui est à la fois bureaucratique et

technocratique.

- Le monde médical : qui met en œuvre son savoir, ses compétences et sa

technologie au sein de petites unités de production (les services) ;
- Le monde administratif : qui organise et donne les moyens de fonctionnement
aux unités médicales en effectuant les contrôles budgétaires et en allouant les
ressources (personnels, finances) [4].

5. Le système d’information hospitalier (SIH)

a. Définition

Un Système d’Information Hospitalier (SIH) est un système d’information appliqué

aux métiers de la santé, et plus particulièrement aux établissements de santé. Le SIH
d’un centre hospitalier est constitué de l’ensemble des informations, de leurs règles de
circulation, de traitements nécessaires à son fonctionnement quotidien, à ses modes de
gestion et d’évaluation ainsi qu’à son processus de décision stratégique et rétribution
nécessaire à l’accomplissement de ses missions [5].

5
Le système d'information hospitalier est inséré dans l'organisation "hôpital" en
perpétuelle évolution; il est capable, selon des règles et modes opératoires prédéfinis,
d'acquérir des données, de les évaluer, de les traiter par des outils informatiques ou
organisationnels, de distribuer des informations contenant une forte valeur ajoutée à
tous les partenaires internes ou externes de l'établissement, collaborant à une œuvre
commune orientée vers un but spécifique, à savoir la prise en charge d'un patient et le
rétablissement de celui-ci [6].

En somme, un système d’information hospitalier permet de collecter les données à la

fois cliniques qu’administrative, de les valoriser enfin de les publier pour en faire
bénéficier l’ensemble afin d’atteindre les objectifs fixés.

b. Objectif

Le SIH est nécessaire au fonctionnement quotidien de l’hôpital et permet de faciliter

sa gestion, son évaluation et sa planification. Parmi les objectifs d’un SIH on a [7] :

- La conservation et l’échange des données ;

- La disponibilité de l’information ;
- L’amélioration de la qualité des soins ;
- Le partage de l’information ;
- Le gain de temps : diminution de la durée de séjour du patient ;
- La maitrise des coûts ;
- La réduction des erreurs.

6
 c. Composantes
Le SIH est composé essentiellement de trois modules : le système administratif, la
logistique et le système médical [7].

Administration et
Comptable
S

Système logistique
Système d’information
médico-technique

Figure 2-Les composantes d'un SIH [9]

• Le système administratif : Il comprend la paie, la facturation, les archives, le

transport, et la documentation, il permet l’admission des malades, la gestion de
leurs mouvements au sein de l’hôpital (lits, mutations entre les services) dite «
gestion opérationnelle », la sortie administrative des patients, la facturation
(frais de séjour) etc. Il compte plusieurs sous-systèmes [7] :
- Le sous-système comptable : Comprend la comptabilité des fournisseurs,
comptabilité clients (dans le cas de l’hôpital, il s’agit de la gestion
comptable des frais de séjour) ;
- Le sous-système de l’administration quotidienne de l’hôpital : S’intéresse
à la facturation, à la gestion du personnel, à la gestion des stocks et d’une
manière générale à la comptabilité.

• Le système logistique : Comprend l’ensemble des flux résultant des actions

médicales (prescriptions, résultats, transferts, archivages). Il met en jeu les
divers services cliniques et plateaux techniques de l’établissement pour
appuyer l’activité de l’équipe soignante ;
• Le système d’information médico-technique : Regroupe toutes les activités
des laboratoires de biologie, des services d’imagerie, la pharmacie, les services
de réanimation et les services de soins intensifs, etc. Il compose plusieurs sous-
systèmes :

7
 - Le sous-système d’action médicale : Concerne l’activité mise en œuvre par
l’équipe soignante pour répondre au problème de malade : l’information
recueillie sur le patient, la constitution et la consultation du dossier du
malade, les connaissances médicales, les processus de décision ;

- Le sous-système de planification hospitalière : À une vision plus

stratégique, il s’appuie sur l’analyse d’activité, ou les études de morbidité
hospitalière pour engager des décisions d’investissements structurels,
matériels et humains. Il est en rapport avec des entités extérieures (autorités
de tutelle, offre de soins environnante, état de santé de la population) ;

- Le sous-système de recherche et d’étude : Travaille sur des regroupements

de dossiers, à condition que ceux-ci aient été correctement constitués, à des
fins épidémiologiques ou d’évaluation de la qualité des soins, alimentant
en retour la connaissance médicale ou les sous-systèmes d’administration
et de planification.

Tous ces systèmes sont indépendants et sont d’une large part centrés sur le dossier
patient.

d. Environnement

L’hôpital dépend de plusieurs acteurs à savoir : Les patients, Les professionnel de la

santé, le personnel soignant, le personnel médico-technique, le personnel des services,
le personnel administratif [8]. En effet, on peut distinguer entre les acteurs extérieurs
et intérieurs du SIH :

- Les acteurs extérieurs se situent au niveau des organismes de tutelle mais

également des assurances, des industriels ou des médias ;
- Les acteurs intérieurs il s’agit des personnels de soins (médecins, personnels
infirmiers, paramédicaux, pharmaciens et biologistes, ingénieurs
biomédicaux, etc.) et les personnels administratifs et logistiques.

8
Ces acteurs sont présentés dans la figure 1.4

Figure 3- Les acteurs d’un SIH

II. PRESENTATION DU CAHIER DE CHARGES

1. Cadre général du projet

L’information est une ressource principale pour toute organisation, car elle est le centre
de toute activité et oriente les prises de décision. Dans le domaine médical, elle permet
entre autres de mieux connaître son sujet, orienter les soins, réduire les erreurs,
minimiser les coûts et de favoriser une prise en charge de qualité. En effet avec
l’avancé de la technologie, nombreuses structures sanitaires ont vu leur système
d’information amélioré à travers des solutions informatiques faisant ainsi leur bonheur.
A l’instar des hôpitaux modernes et certifiés qui ont un SIH informatisé, l’institut de
cardiologie d’Abidjan (ICA) dans sa démarche qualité est soucieux de la prise en
charge et la satisfaction de ses patients tout en maîtrisant les coûts et en optimisant
l’utilisation de ses ressources. C’est dans ce cadre que s’inscrit notre projet qui consiste
à mettre en place un SIH pour la prise en charge informatisée du patient au compte de
l’ICA.

9
 2. Objectifs

a. Objectif général

L’objectif principal de ce projet est de mettre en place un progiciel de gestion intégrée

(PGI) intégrant tous les processus métiers axés sur le parcours patient en partant de
son admission jusqu’à sa sortie. Ce système devra faciliter la gestion médicale et
administrative afin de fournir un service de qualité.

b. Objectifs spécifiques

Plusieurs objectifs spécifiques sont visés à travers ce projet. A savoir :

- Le recueil et l’étude des informations généralement traitées dans un système

hospitalier (son organisation, ces entités et processus métiers essentiels) ;
- La conception et réalisation d’une application web et mobile adaptée
permettant :
✓ La conservation et l’échange des données ;
✓ La gestion administrative du malade : l’admission des patients qui
consiste à la génération automatique de numéro de dossier et
d’admission, les demandes de prise en charge sociale, la facturation,
son séjour… ;
✓ La gestion médicale du malade : La dématérialisation du carnet médical
facilitant l’échange des données entre service sans déplacé un
document médical, les prescriptions et actes des médecins, la
consultation des résultats après réalisation d’examen ;
✓ La gestion centralisée des rendez-vous des consultations ;
✓ La disponibilité de l’information à tout lieu et consultable via un accès
sécurisé ;
✓ L’amélioration de la qualité des soins ;
✓ Réduire la surfacturation et les fraudes ;
✓ L’évaluation des pratiques professionnelles ;

10
 ✓ Le gain de temps et la maitrise des coûts : diminution de la durée de
séjour du patient ;
✓ La réduction des erreurs ;
✓ L’édition des états, la présentation des indicateurs et statistiques
détaillés.

1. Livrables attendus

Les livrables attendus compte tenu des objectifs définis sont :

- Une application web qui permettra de gérer le système d’information ;

- Une application mobile qui facilitera la saisie des données des opérations ;
- La mise en production en ligne de l’application en mode test pour une
première prise en main des utilisateurs finaux ;
- Un manuel d’utilisation de la solution ;
- La mise en production réelle de la solution dans tous les services et veiller à
l’assistance des utilisateurs ;
- Les mises à jour amélioratives du système.

11
CHAPITRE III : ETUDE DE L’EXISTANT

Dans ce chapitre, nous présenterons le système d’information actuel de la structure

hospitalière en décrivant son mode de fonction et son existant logiciel. Enfin nous
critiquerons ce système en montrant ces limites.

I. GESTION HOSPITALIERE

La plupart des structures sanitaires en Côte d’Ivoire voire en Afrique de l’Ouest

souffrent d’absence d’informatisation de leurs systèmes d’informations. Quand bien
même elles sont structurées et informatisées (le cas des structures sanitaires privées,
les établissements sanitaires de niveau tertiaire comme les centres hospitaliers et les
instituts spécialisés), cette automatisation ne se limite qu’à l’admission et la
facturation. En d’autres termes, ces systèmes prennent en compte la gestion
administrative et financière [1]. Ces systèmes n’automatisent pas totalement le
processus du parcours patient et mettent en marge la quasi-totalité des acteurs
médicaux qui génèrent une capacité énorme de données dans l’exécution de leurs
tâches quotidiennes. Ainsi, la gestion de l’information médicale qui représente le cœur
des systèmes hospitaliers n’est pas généralement prise en charge par ces outils
technologiques déjà en production.

1. Description du système de l’ICA

Le système d’information présent à l’ICA est décrit comme suit :

- L’ICA dispose de plusieurs services : l’administration, la consultation, les

urgences, la pharmacie, le laboratoire, l’imagerie, la kinésithérapie, les services
de soin (hospitalisation de médecin, de chirurgie, de cardio-pédiatrie, des soins
intensifs chirurgicaux et médicaux), le bloc opératoire… ;
- Les services Urgences et Consultation représentent les portes d’entrée du
système. A cette étape, le patient se fera enregistrer (si c’est un nouveau
patient) et disposera d’un numéro de dossier (juste un identifiant) qui n’a rien
avoir avec le dossier patient informatisé ;

12
- Les consultations se font sur rendez-vous selon un quota de nombre de
personnes à consulter par jour. Une consultation est soit publique (avec une
date de rendez-vous généralement éloignée compte tenu des rendez-vous en
attente) ou privée (avec une date de rendez-vous plus rapprochée, mais un coût
plus élevé). Le programme de consultation de chaque médecin est édité par
semaine ;

- Après consultation, le patient peut être hospitalisé pour une prise en charge
rapide en cas de nécessité ou recevoir des prescriptions ou ordonnances
externes pour des soins à domicile. Toutes ces informations seront notées dans
un carnet de santé physique acheté par le patient avant sa consultation. Le
carnet médical du patient présente de nombreux formulaires structurés par
rubrique permettant aux médecins de noter tous les actes et prescriptions
demandés ou réalisés. En effet, ce carnet retrace tout ce qui a été fait sur le
malade et est l’unique source d’information lors des consultations ;

- Une fois le patient hospitalisé aux urgences, toutes les prescriptions (examens
biologiques, imagerie, pharmacie et soins) qui lui sont réalisées sont notées sur
une fiche médicale du patient (voir annexe). Cette fiche d’ordre médical
permettra d’élaborer la facture du patient à sa sortie et constituera le dossier du
patient ;

- Quand la situation du patient nécessite des soins intensifs ou spécialisés, le

patient est muté dans l’un des services d’hospitalisation ou de soins intensifs :
SIM, SIC, HC, HM pour poursuivre les soins. Le transfert des patients des
urgences à un autre service est enregistré dans un registre physique permettant
de tracer le circuit du patient ;

- Tout patient transféré dans un service d’hospitalisation doit verser une

caution qui servira de frais de soins ;

13
 - Les résultats d’analyse du laboratoire sont saisis dans un fichier Excel afin
d’être imprimés et remis au patient. Ces résultats ne sont pas stockés
indéfiniment car ces fichiers seront supprimés après un certain temps.

2. Diagnostic de l’existant logiciel

Le système d’information de l’ICA est à moitié informatisé. En effet l’institut dispose

de trois 3 différents logiciels propriétaires pour faciliter sa gestion : Hospital,
BilanHospit et Archive pro. Les fonctionnalités de ces logiciels sont décrites dans le
tableau 1 ci-après.

Tableau 1 – Etat de l’’existant logiciel

Logiciels Fonctionnalités

Hospital Enregistrement des données administratives du

patients, saisie de demande de consultation,
Facturation des actes et la gestion de caisse.
BilanHospit Gestion des chambres et lits, Edition de facture
complète des hospitalisés.

Archive Pro Enregistrement des données servant d’analyse et

présentation des statistiques.

Hospital gère la demande des rendez-vous de consultation et la Facturation des actes

médico-techniques des patients externes (les examens biologiques, la radiologie, la
kinésie, …). BilanHospit s’occupe de la facturation des patients hospitalisés donc
interne. Du fait de la complexité des processus de facturation, ce logiciel présente de
nombreuses insuffisances entre autres la gestion des chambres, la facturation
automatique du temps d’occupation des lits amenant parfois les agents de facturation
à faire des opérations sur une calculatrice et ensuite renseigner les résultats obtenus
dans l’application, ce qui pourrait éventuellement occasionner des erreurs et des pertes
financières. Archive pro assure la génération des statistiques pour une analyse après
avoir saisies des données. Ces applications sont complètement indépendantes, ne
communique pas de données entre elles et n’ont pas la même structure logique. De

14
plus on constate dès lors que le système actuel prend seulement en compte
l’informatisation des données administratives et comptables.

II. CRITIQUES DU SYSTEME

Ce système comme expliqué ci-dessus aux points 1 et 2 gère de façon manuelle les
données médicales ou du dossier patient à travers les fiches, carnets et registres. En
cas d’absence ou d’égarement du carnet médical, il est impossible d’avoir de façon
rapide et automatique les informations médicales sur le patient : ses antécédents
médicaux, motif, ses diagnostics, ses traitements, ses ordonnances pharmacies, ses
examens biologiques, ses imageries et conclusions d’une hospitalisation ou
consultation passée. L’absence de ses données sur le patient ralentit la prise de décision
du médecin sur les traitements à prescrire et par ailleurs augmente le coût des soins
pour le patient car souvent obligé de refaire des examens déjà effectués.

Aussi la gestion globale des hospitalisations regroupant celle des salles et des lits
destinés aux hospitalisations, le transfert et la sortie des patients se font manuellement
en inscrivant dans des registres. Cela engendre une perte de temps considérable lors
de l’édition des factures internes dont le calcul se fait en fonction du nombre de jours
passé sur un lit et suscite une longue attente des patients.

Difficile de connaître les médecins, infirmiers et aide soignants qui sont intervenus
dans le traitement d’un malade donné.

Absence de liaison informatisée entre les services médico-techniques et les autres

services. En effet, les résultats des examens demandés ne sont pas directement
exploitables par les médecins à travers une application. Ces résultats sont récupérés
depuis le service d’analyse et transmis de manière physique au médecin par un agent.

Dans la partie suivante de notre travail, il sera question de faire une étude technique
du système.

15
 DEUXIEME PARTIE

ANALYSE ET CONCEPTION
 CHAPITRE IV : METHODE D’ANALYSE ET DE
CONCEPTION

Dans ce chapitre, nous présenterons les méthodes d’analyse les plus utilisées dans la
gestion de projet informatique ensuite opterons pour une méthode adéquate à notre
projet et enfin présenterons le langage UML qui sera utilisé pour la modélisation.

I. METHODES D’ANALYSE ET DE CONCEPTION D’UN

SYSTEME D’INFORMATION

Une méthode d'analyse et de conception a pour objectif de permettre de formaliser les

étapes préliminaires du développement d'un système afin de rendre ce développement
plus fidèle aux besoins du client. Pour ce faire, on part d'un énoncé informel (le besoin
tel qu'il est exprimé par le client, complété par des recherches d'informations auprès
des experts du domaine fonctionnel, comme par exemple les futurs utilisateurs d'un
logiciel), ainsi que de l'analyse de l'existant éventuel (c'est-à-dire la manière dont les
processus à traiter par le système se déroulent actuellement chez le client) [9].

Il existe plusieurs méthodes d’analyse et de conception d’un SI, les plus utiliser sont
présentées ci-dessous.

1. MERISE

MERISE est une méthode de conception, de développement et de réalisation de projets

informatiques. C’est une méthode essentiellement française et est le résultat des
travaux menés par René Colletti, Arnold Rochfeld et Hubert Tardieu dans les années
1970. Le but de cette méthode est d'arriver à concevoir un système d'information. La
méthode MERISE est systémique et est basée sur la séparation des données et des
traitements à effectuer en plusieurs modèles conceptuels et physiques.
La séparation des données et des traitements assure une longévité au modèle. Elle
fournit une démarche complète sur quatre niveaux (conceptuel, organisationnel,
logique et physique).

16
 a. Cycle d'abstraction de conception des systèmes d'information
La conception du système d'information se fait par étapes, afin d'aboutir à un système
d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à

Système d’information manuel

Expression des besoins

Modèle conceptuel

Modèle logique

Modèle physique

Système d’information automatisé

une chacune des étapes en prenant en compte les résultats de la phase précédente
comme présente la figure ci-dessous :

Figure 4- Cycle d'abstraction de conception des systèmes d'information [10]

L'expression des besoins est une étape consistant à définir ce que l'on attend du
système d'information automatisé, il faut pour cela :

- Faire l'inventaire des éléments nécessaires au système d'information ;

- Délimiter le système en s'informant auprès des futurs utilisateurs.

Cela va permettre de créer le MCC (Modèle conceptuel de la communication) qui

définit les flux d'informations à prendre en compte.

L'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données)
et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes
à prendre en compte.

17
Le modèle organisationnel consiste à définir le MOT (Modèle organisationnel des
traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial
et temporel).

Le modèle logique représente un choix logiciel pour le système d'information.

Le modèle physique reflète un choix matériel pour le système d'information.

2. Processus Unifié (PU) [11]

Le processus unifié (PU), ou « unified process (UP) » en anglais, ou « Unified

Software Development Process (USDP) » est une famille de méthodes
de développement de logiciels orientés objets. Il se caractérise par :

- Un pilotage par les cas d'utilisation ;

- Une démarche centrée sur l'architecture ;
- Une approche basée sur les modèles, et en particulier les modèles UML ;
- Une approche itérative et incrémentale visant en priorité à réduire les
incertitudes.

a. Cycle de vie des projets [11]

Le processus unifié est cyclique c’est-à-dire qu’un projet peut être revu et engendrer
un autre. En d’autre thème c’est une succession de projets partant d’un projet initial. Il
consiste à fournir d'abord une version viable d'un produit puis des versions publiables.
Chaque projet a un cycle de vie en quatre phases, chacune subdivisée en plusieurs
itérations (figure 5) :

- La phase de création ou de cadrage vise à définir le produit et les objectifs du

projet ;

- La phase d'élaboration vise à clarifier les exigences, à définir l'architecture du

produit et à en valider la faisabilité. Cette phase prévoit ainsi la mise en œuvre
d'une version exécutable constituée d'un squelette du système et démontrant les
principaux éléments architecturaux ;
- La phase de construction vise à construire et à mettre en œuvre le produit et les
livrables associés ;

18
- La phase de transition vise à livrer, diffuser ou déployer le produit de sorte qu'il
soit prêt à être utilisé. Cette phase inclut la formation des utilisateurs si nécessaire.

b. Enchainements d’activités

A chaque phase d’évolution du projet est mené un ensemble d’activités selon les
besoins du projet comme illustre la figure 5. Le processus unifié propose les
enchainements d'activités suivants :

- Exigences : recherche des acteurs et des cas d'utilisation, priorisation,

description des cas d'utilisation, prototypage de l'interface utilisateur, et
structuration du modèle des cas d’utilisation ;
- Analyse : analyse de l'architecture, analyse d'un cas d'utilisation, analyse d'une
classe, et analyse d'un package ;
- Conception : conception de l'architecture, conception d'un cas d'utilisation,
conception d'une classe, et conception d'un sous-système ;
- Mise en œuvre (implémentation) : implémentation de l'architecture,
intégration du système, implémentation d'un sous-système, implémentation
d'une classe, et exécution de tests unitaires ;
- Test : planification des tests, conception des tests, mise en œuvre des tests,
exécution des tests d'intégration, exécution de tests systèmes, et évaluation des
tests.

- Figure 5-Processus unifié : enchainements d'activités au cours du cycle de vie [11]

19
 3. Justification du choix de la méthode

Dans le cadre de cette étude, nous utiliserons la méthode du Processus Unified du fait
qu’elle est conçue pour gérer des systèmes complexes à base de composants. En effet,
cette méthode facilite l’étude des projets de développement de logiciels orientés objets
sous forme d’enchainement d’activités. En plus le processus unifié est cyclique, ce qui
est adapté au système évolutif comme un système hospitalier et fait un usage intensif
des modèles UML qui est un langage de référence dans la modélisation des projets
informatiques.

II. UML (Unified Modeling Language)

1. Présentation

UML du français langage de modélisation unifié se définit comme un langage de

modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier
et documenter des systèmes, esquisser des architectures logicielles, concevoir des
solutions et communiquer des points de vue et non une méthode (Roques, 2006).
Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson,
UML est à présent un standard défini par l’Object Management Group (OMG) [12].
En termes de formalise, UML est utilisé dans le cadre de ce projet.

2. Les diagrammes

La version 2.5 d’UML est composée de 14 diagrammes classés en trois (3) grandes
catégories comme le montre la figure 6 : les diagrammes structurels, les diagrammes
d’interaction et les diagrammes comportementaux [13].

20
 Figure 6- Diagrammes UML [14]

a. Diagrammes structurels ou statiques (Structure Diagrams)

Ces diagrammes regroupent le :

- Diagramme de classes (Class diagram) : il représente les classes intervenant
dans le système ainsi que les relations entre ces classes. C’est le diagramme le
plus important et le plus utilisé ;
- Diagramme d'objets (Object diagram) : il sert à représenter les instances de
classes (objets) et leurs liens à un instant donné ;
- Diagramme de paquetages (Package Diagram) : Il permet de structurer la
modélisation de systèmes complexes en décomposant le système en plusieurs
parties (paquetages). Chaque paquetage étant constitué des différents
diagrammes UML concernant la partie modélisée ;
- Diagramme de composants (Component diagram) : il permet de montrer les
composants du système (éléments logiciels), tels qu'ils sont mis en œuvre
(fichiers, bibliothèques, bases de données...) ;
- Diagramme de structure composite (Composite Structure Diagram) : il
permet de décrire sous forme de boîte blanche les relations entre composants
d'une classe ;

21
 - Diagramme de profils (profile diagram) : il fournit une représentation des
concepts utilisés dans la définition des profils (packages, stéréotypes ;
- Diagramme de déploiement (Deployment diagram) : il sert à représenter les
éléments matériels (ordinateurs, périphériques, réseaux, systèmes de
stockage...) et la manière dont les composants du système sont répartis sur ces
éléments matériels et interagissent entre eux.

b. Diagrammes comportementaux ou dynamique (Behavior

Diagram)

Ces diagrammes rassemblent le :

- Diagramme des cas d'utilisation (Use Case Diagram) : Il constitue la

première étape de l’analyse UML et consiste à modéliser les besoins des
utilisateurs, d’identifier les grandes fonctionnalités et les limites du système et
de représenter les interactions entre le système et ses utilisateurs ;
- Diagramme états-transitions (State Machine Diagram) : Montre comment
l’état du système ou de ses composants est modifié en fonction des différents
événements ;
- Diagramme d'activités (Activity Diagram) : Il permet de décrire sous forme
de flux ou d'enchaînement d'activités le comportement du système ou de ses
composants.

c. Diagrammes d'interaction (Interaction Diagram)

Ces diagrammes rassemblent le :

- Diagramme de séquences (Sequence Diagram) : Il permet de représenter les

échanges (messages, signaux, ...) entre les différents objets et acteurs du
système en fonction du temps ;
- Diagramme de communication (Communication Diagram) : C’est une
représentation simplifiée d'un diagramme de séquence, il se concentre sur les
échanges de messages entre les objets ;
- Diagramme global d'interaction (Interaction Overview Diagram) : Il permet
de décrire les enchaînements possibles entre les scénarios préalablement

22
 identifiés sous forme de diagrammes de séquences (variante du diagramme
d'activité) ;
- Diagramme de temps (Timing Diagram) : il permet de décrire les variations
d'une donnée au cours du temps.

23
CHAPITRE V : ANALYSE ET CONCEPTION DU SYSTEME

Ce chapitre vise à capter les besoins, identifier les rôles des utilisateurs et préparer le
plan de réalisation. Ainsi, nous allons commencer par l’analyse et spécification des
besoins en définissant les exigences fonctionnelles et non fonctionnelles du système à
mettre place et enfin nous passerons à sa conception.

I. ANALYSE ET SPECIFICATION DES BESOINS

L’analyse et la spécification des besoins sont des étapes primordiales de toute

démarche de développement logiciel. Leur but est de décrire sans ambiguïté le système
d’information à développer afin qu’il réponde aux exigences du cahier de charges.
Leur finalité est la description générale des besoins fonctionnels et non fonctionnels
liés au projet.

1. Analyse des besoins non fonctionnels

Les besoins non fonctionnels sont les besoins qui caractérisent le système. Ce sont des
besoins en matière de performance, de type de matériel ou le type de conception. Ces
besoins peuvent concerner les contraintes d'implémentation (langage de
programmation, type SGBD, de système d'exploitation…). Les besoins non
fonctionnels identifiés dans ce projet sont catégorisés et présentés ci-après.

• Sécurité :

Confidentialité : seules les personnes autorisées peuvent avoir accès aux informations
qui leur sont destinées (notions de droits ou permissions). Tout accès indésirable doit
être empêché ;

Authentification: les utilisateurs doivent disposer d’un identifiant et d’un mot de passe
pour s’authentifier. Cela permet de gérer les droits d'accès aux ressources concernées
et maintenir la confiance dans les relations d'échange ;

24
Intégrité : les données doivent être celles que l'on attend, et ne doivent pas être altérées
de façon fortuite, illicite ou malveillante. En clair, les éléments considérés doivent être
exacts et complets ;

Disponibilité : l'accès aux ressources du système d'information doit être permanent et

sans faille. Les services et ressources doivent être accessibles aux personnes autorisées
quand elles en ont besoin ;

La traçabilité ou preuve : garantie que les accès et tentatives d'accès aux éléments
considérés sont tracés et que ces traces sont conservées et exploitables ;

La non-répudiation et l'imputation : aucun utilisateur ne doit pouvoir contester les

opérations qu'il a réalisées dans le cadre de ses actions autorisées et aucun tiers ne doit
pouvoir s'attribuer les actions d'un autre utilisateur.

• La maintenance :

Le système doit être évolutif et facile à maintenir.

• La performance :

Haute disponibilité et tolérance aux pannes : le système devrait être disponible même
si on le pousse au-delà de ses performances habituelles c'est-à-dire qu'il faudrait un
accès quasi continu à ses fonctionnalités et données. Le système ne doit jamais être
indisponible ;

Temps de réponse des traitements du système : Le système doit être rapide en termes
de temps d’exécution et de réponse ;

Montée en charge : le système devrait pouvoir accepter un nombre important de

requêtes à un instant donné sans que cela n'affecte sa performance.

• La portabilité :

Le fonctionnement du système ne devrait pas dépendre du système d’exploitation dans

lequel il fonctionne.

• L’interopérabilité :

Le système devrait pouvoir communiquer et échanger avec d’autres applications.

• L’utilisabilité :

25
Le système devrait être ergonomie avec des interfaces intuitives (la police et taille
d’écriture, choix des couleurs, les images utilisées) et facile à utiliser. La compatibilité
avec la majorité des navigateurs web.

2. Analyse des besoins fonctionnels

Tout projet est réalisé afin de répondre à des besoins bien précis. Ces besoins sont
principalement d’ordre fonctionnel. Les besoins fonctionnels expriment une action que
doit effectuer le système en réponse à une demande. Cette étape de notre processus de
développement consiste à faire un repérage des besoins fonctionnels en utilisant le
formalisme UML. L’analyse fonctionnelle sera présentée par module de gestion.

a. Diagramme de cas d’utilisations

Le Diagramme de cas d’utilisation est le premier diagramme du modèle UML utilisé
pour la modélisation des besoins des utilisateurs. Les cas d’utilisations décrivent le
comportement du système étudié du point de vue de l’utilisateur, et décrivent les
possibilités d’interactions fonctionnelles entre le système et les acteurs, ils permettent
de définir les limites et les relations entre le système et son environnement. Il est
destiné à structurer les besoins des utilisateurs et les objectifs par rapport au système.
C’est donc l’image d’une fonctionnalité en réponse à la simulation d’un acteur
externe[15].

Le tableau 2 présente le formalisme des relations utilisées dans le digramme de cas

d’utilisation et donne leur signification.

26
Tableau 2- Récapitulatif des différentes liaisons du diagramme des cas d'utilisation [17]

Nom Représentation Signification

Association Lien entre un utilisateur et un cas
d’optimisation
Inclusion Le cas A est exécuté avant le cas B
A B
Extension Le cas A est une partie optionnelle du
A B cas B
Généralisation Indique que le cas B est une sous-
option du A
A B

• Analyse fonctionnelle du module « Bureau des admissions et frais de séjour

(BAFS) »

Dans ce module, les acteurs qui interagissent avec le système sont les agents de
facturation et les caissiers. La figure 7 présente le diagramme de cas d’utilisation du
volet administratif et financier du système.

27
Figure 7- Diagramme des cas d'utilisation du module BAFS

28
A titre d’exemple, quelques cas d’utilisation sont choisis et décrits pour présenter
l’interaction entre le système et l’acteur.

- Description textuelle du cas d’utilisation « S’authentifier »

Le cas d’utilisation « S’authentifier » est pareil dans tout le système et permet à

l’utilisateur d’accéder à différentes fonctionnalités qu’offre l’application.

Tableau 3- Description textuelle du cas d'utilisation "S'authentifier"

Acteur Tous les utilisateurs du système.

Préconditions Serveur disponible

Postconditions Utilisateur authentifié ou message d’interdiction d’accès

Scénario
nominal 1. L’utilisateur effectue une demande de connexion
2. Le système présente la page d’authentification
3. L’utilisateur saisit son login puis son mot de passe.et valide
4. Le système vérifie son existence dans la base de données
5. Le système renvoie le menu principal de l’utilisateur

Contraintes 2a. Les informations saisies ne sont pas dans la BD : retour au point 1

- Description textuelle du cas d’utilisation « Gérer les dossiers patients »

Tableau 4- Description textuelle du cas d'utilisation "Gérer les dossiers patients"

Acteur Agent de Facturation

Préconditions L’agent de facturation doit être authentifié

Postconditions Nouveau dossier enregistré

Scénario nominal 1. L’agent demande le formulaire de création de dossier

2. Le système affiche la page de création de dossier
3. L’agent de facturation fournit les informations nécessaires et
soumet le formulaire
4. Le système vérifie s’il existe déjà un dossier avec les mêmes
informations entrées
5. Le système enregistre le formulaire dans la BD et attribue un
numéro de dossier médical au patient.

29
 Contraintes 4.a. Les informations correspondent à une admission en cours : le
système affiche un message pour notifier l’utilisateur ensuite vide les
champs et retourne au point 2.

- Description textuelle du cas d’utilisation « Rechercher et Visualiser une admission

»

Le cas d’utilisation « Rechercher et visualiser une information » est une fonctionnalité

de base qui figure dans plusieurs modules du système. Il présente le même scénario
dans tous les modules et permet à l’utilisateur de rechercher rapidement une
information dans une liste en saisissant une ou plusieurs valeurs clé(e)s.

Tableau 5- Description textuelle du cas d'utilisation "Rechercher et visualiser une information"

Acteur Agent de Facturation

Préconditions L’agent de facturation doit être authentifié

Postcondition Visualiser plus en détail les informations d’une admission

s

Scénario 1. Le système affiche les menus dont l’utilisateur a les droits d’accès
nominal 2. L’agent de facturation demande la liste des admissions
3. Le système affiche la liste des admissions en cours de la base des
données
4. L’agent peut rechercher une admission en se basant sur les critères de
recherches proposés et la valeur cherchée
5. Le système filtre la liste et présente la ligne de l’admission recherchée
si celle-ci existe
6. L’agent de facturation peut sélectionner l’admission trouvée
7. Le système affiche le formulaire présentant les informations de
l’admission sélectionnée.

- Description textuelle du cas d’utilisation « Enregistrer une admission »

La fonctionnalité « Enregistrer ou ajouter » apparait lorsque l’utilisateur souhaite

enregistrer de nouvelles données dans le système et suit pratiquement le même
scénario nominal dans tous les modules du système.

30
 Tableau 6- Description fonctionnelle du cas d'utilisation "Enregistrer une admission"

Acteur Agent de Facturation

Préconditions L’agent de facturation doit être authentifié

Postconditions Une nouvelle admission est enregistrée

Scénario 6. L’agent demande le formulaire d’enregistrement d’une admission

nominal 7. Le système affiche la page d’enregistrement d’une admission
8. L’agent de facturation fournit les informations nécessaires et soumet
le formulaire
9. Le système vérifie si une admission en cours est rattachée ou non
aux informations entrées
10. Le système enregistre le formulaire dans la BD et attribue un
numéro d’admission au patient.

Contraintes 4.a. Les informations correspondent à une admission en cours : le

système affiche un message pour notifier l’utilisateur ensuite vide les
champs et retourne au point 2.

- Description textuelle du cas d’utilisation « Gérer les encaissements de facture »

Tableau 7- Description textuelle du cas d’utilisation " Gérer les encaissements de facture"

Acteur Caissier/Caissière

Préconditions L’utilisateur doit être authentifié

Le patient a une facture impayée ou en attente de paiement

Postconditions Facture patient réglée

Scénario 1. Le système affiche la liste des factures non soldées du jour

nominal 2. L’utilisateur saisie le numéro d’admission du patient
3. Le système affiche toutes les factures impayées du patient
4. L’utilisateur sélectionne la facture à régler et valide
5. Le système présente le formulaire de paiement de la facture
sélectionnée
6. L’utilisateur fournit les informations sur le paiement et
soumet le formulaire
7. Le système vérifie si les saisies obligatoires du formulaire
sont bien renseignées
8. Le système effectue le traitement d’enregistrement dans la
BD et présente la page d’impression du reçu de paiement

Contraintes 7.a. Information manquante ou format erroné : le système affiche un

message pour notifier l’utilisateur et retourne au point 5.

31
• Analyse fonctionnelle du module « Gestion de RDV »

Les acteurs intervenant dans ce module sont les agents d’accueil et le responsable des
consultations. La figure 8 illustre le diagramme de cas d’utilisation de cette gestion.

Figure 8-Diagramme des cas d'utilisation du module "Gestion de rendez-vous de consultation"

32
- Description textuelle du cas d’utilisation « Planifier le programme des médecins
consultants »

Tableau 8- Description textuelle du cas d'utilisation "Planifier le programme des médecins consultants"

Acteur Responsable des consultations

Préconditions L’utilisateur doit être authentifié

Post-conditions Programme des médecins planifier

Scénario 1. L’utilisateur demande la page de planification des programmes

nominal de consultation
2. Le système affiche le formulaire de planification
3. L’utilisateur sélectionne le médecin ensuite définit ces jours de
consultation et enfin soumet le formulaire
4. Le système vérifie si le programme soumis ne coïncide pas à
celui d’un autre médecin
5. Le système effectue le traitement d’enregistrement dans la BD

Contraintes 7.a. Si le programme coïncide, le système propose un autre jour et

retourne au point 3 pour validation.

- Description textuelle du cas d’utilisation « Enregistrer une demande de

consultation »

Tableau 9- Description textuelle du cas d'utilisation “Enregistrer une demande de consultation“

Acteur Responsable des consultations

Préconditions L’utilisateur doit être authentifié

Post- Rdv de consultation enregistré

conditions

Scénario 1. L’utilisateur sollicite la page du processus de demande de rdv

nominal consultation
2. Le système affiche le calendrier de consultation des médecins
dont le quota de consultation n’est pas atteint sur une période
donnée
3. L’utilisateur sélectionne un médecin enfin termine le processus
4. Le système enregistre la demande de consultation et incrémente
le nombre de rdv du médecin sélectionné

33
• Analyse fonctionnelle du module « gestion médicale »

La figure 9 montre le diagramme de cas d’utilisation de la gestion des données

médicales.

Figure 9- Diagramme des cas d'utilisation du module "gestion médicale"

34
- Description textuelle du cas d’utilisation « Prise des constantes »

La prise des constantes est l’une des premières tâches médicales avant toute décision
de soin. Cette fonctionnalité permet au corps médical de renseigner les données telles
que la tension artérielle, le pouls, la fréquence cardiaque, au moment de la consultation
ou de suivi d’un malade.

Tableau 10- Description textuelle du cas d’utilisation "Prise des constantes"

Acteur Personnel de soin

Préconditions L’utilisateur doit être authentifié

Le patient doit être sélectionné

Post conditions Prise des constantes enregistrée

Scénario 1. L’utilisateur demande le formulaire de saisie des constantes

nominal 2. Le système affiche la page de saisie des constantes
3. L’utilisateur saisie les données et soumet le formulaire
4. Le système vérifie le format des données saisies
5. Le système enregistre les constantes dans la BD

Contraintes 4.a. Format incorrect : le système affiche un message pour notifier

l’utilisateur ensuite vide les champs concernés et retourne au point 2.

35
- Description textuelle du cas d’utilisation « Consulter les résultats des examens
demandés »

Tableau 11- Description textuelle du cas d’utilisation " Consulter les résultats des examens demandés"

Acteur Médecin et infirmier

Préconditions L’utilisateur doit être authentifié

L’admission du patient doit être sélectionné

Post Résultat consulté ou message de notification

conditions

Scénario 1. L’utilisateur sollicite la liste des examens d’un patient

nominal 2. Le système affiche la page des examens du patient
3. L’utilisateur sélectionne un examen et demande l’interface des
résultats
4. Le système vérifie la disponibilité des résultats
5. Le système affiche les résultats de l’examen

Contraintes 4.a. Examen non réalisé : le système affiche un message pour notifier
l’utilisateur sur le statut de l’examen.

36
• Analyse fonctionnelle du module « gestion médico-technique »

La figure 10 présente le diagramme de cas d’utilisation de la gestion des données

médico-techniques.

Figure 10- Diagramme des cas d'utilisation du module "gestion médico-technique"

37
- Description textuelle du cas d’utilisation « Enregistrer les résultats d’examens »

Le tableau 12 illustre ce cas d’utilisation.

Tableau 12- Description textuelle du cas d'utilisation "Enregistrer les résultats d'examens"

Acteur Technicien laboratoire, technicien radiographie, technicien exploration

Préconditions L’utilisateur doit être authentifié

Le bulletin d’examen doit être réceptionné

Post conditions Résultat d’examen enregistré

Scénario 1. L’utilisateur demande la liste des examens d’un bulletin

nominal 2. Le système affiche les examens du bulletin demandé
3. L’utilisateur sélectionne un examen et demande la page de
traitement d’examen
4. Le système affiche l’interface de saisie des résultats d’examens
5. L’utilisateur fournit les résultats de l’examen et soumet le
formulaire
6. Le système effectue vérification des saisies
7. Le système enregistre les résultats dans la base de données

Contraintes 6.a. Format de champ incorrect : retour au point 5.

- Description textuelle du cas d’utilisation « Imprimer les résultats d’examens »

Tableau 13- Description textuelle du cas d’utilisation "Imprimer les résultats d’examens"

Acteur Technicien laboratoire, technicien radiographie, technicien exploration

Préconditions L’utilisateur doit être authentifié

Les résultats doivent être enregistrés

Post conditions Résultat d’examen imprimé

Scénario 1. L’utilisateur demande la liste des examens réalisés

nominal 2. Le système affiche les examens réalisés
3. L’utilisateur sélectionne un examen et demande la page
d’impression
4. Le système affiche la page d’impression d’examen

38
 II. CONCEPTION DU SYSTEME

1. Diagrammes de séquences

Le diagramme de séquence décrit les interactions entre un groupe d’objets en

montrant, de façon séquentielle, les envois de message qui interviennent entre les
objets. Le diagramme peut également montrer les flux de données échangées lors des
envois de message. [17]
Le tableau ci-dessous présente quelques symboles permettant d’effectuer des
interactions dans un diagramme de séquence :
Tableau 14-Formalisme du diagramme de sequences [17]

Symbole Signification

Envoi de message synchrone.

Nécessite une réponse avant la
poursuite des actions

Envoi de message asynchrone.

Poursuit les actions sans attendre de
réponse.

Réponse à un message envoyé.

Message réflexive. Lorsqu’un objet

s’envoi lui-même un message

Fragment alt: opérateur conditionnel

Les différentes alternatives sont
spécifiées dans des zones délimitées
par des pointillés.

Fragment ref: réutilisation d’élément

Un fragment ref permet d’indiquer la
réutilisation d’un diagramme de
séquences défini par ailleurs.

39
La représentation du diagramme de séquence peut se réaliser par cas d’utilisation en
considérant les différents scénarios associés.

• Diagramme de séquence du cas d’utilisation : « S’authentifier »

La figure 11 montre les interactions entre l’utilisateur et le système lors d’une

authentification.

Figure 11- Diagramme de séquence du cas d'utilisation "S'authentifier"

40
• Diagramme de séquence du cas d’utilisation « Créer un dossier patient »

La figure 12 présente les interactions entre l’acteur Agent du bureau des entrées et frais
de séjour (BAFS) et le système pour la réalisation de la fonctionnalité en spécialisation
"Créer un Dossier" de la fonctionnalité générique "Gérer les dossiers patients" par le
biais d’un diagramme de séquence d’UML.

Figure 12- Diagramme de séquence du cas d’utilisation "Créer un dossier patient"

41
• Diagramme de séquence du cas d’utilisation « Prise des constantes »

La figure 13 illustre les interactions entre le personnel de santé et le système lors de

l’enregistrement d’une prise de constance d’un patient. Cette fonctionnalité fait partie
du module « gestion médicale ».

Figure 13- Diagrammes de séquence du cas d'utilisation "Prise des constantes"

42
• Diagramme de séquence du cas d’utilisation « Demande et consultation de
résultat d’examen »

La figure 14 décrit les interactions entre le personnel de santé et le système lors d’un
enregistrement de bulletin d’examen d’un patient. Également montre les interactions
pour visualiser les résultats d’examen.

Figure 14- Diagramme de séquence du cas d’utilisation "Demande et consultation de résultat d’examen"

43
 2. Diagrammes de classes

Le diagramme de classe constitue l’un des pivots essentiels de la modélisation avec

UML. En effet, ce diagramme permet de donner la représentation statique du système
à développer et représente l’ensemble des informations analysées qui sont gérées par
le domaine. Cette représentation est centrée sur les concepts de classe et d’association.
Le tableau ci-dessous montre les formalismes utilisés dans un diagramme de classes.

Tableau 15- Formalisme utilisé dans un diagramme de classes [17]

Nom Représentation Signification

classe, -
Une classe est un type abstrait
attributs, caractérisé par des propriétés (attributs
méthodes et méthodes) communes à un
ensemble d’objets et permettant de
créer des objets ayant ces propriétés
- Les attributs sont des propriétés
caractéristiques de la classe
- Les méthodes sont des procédures
spécifiques à une classe
association Une association exprime une connexion
sémantique bidirectionnelle entre deux classes
multiplicité 1 ou 1..1 : exactement 1 Elle définit le nombre d’instances de
l’association pour une instance de la classe.
0..1: optionnel
0..* ou *: de 0 à
plusieurs
relation de Elle indique d’un objet d’un diagramme utilise
dépendance les services d’un autre objet.
agrégation Elle représente une association non
symétrique dans laquelle une des extrémités
joue un rôle prédominant par rapport à l’autre.
composition C’est un cas particulier de l’agrégation dans
laquelle la vie des composants est liée à celle
des agrégats.

généralisation Démarche ascendante, qui consiste à capturer

les particularités communes d’un ensemble
d’objets au sein d’une classe principale.

Les classes présentent dans ce système sont modélisées par le diagramme de classes
illustré par la Figure 15

44
Figure 15- Diagramme de classes du SIH

45
Description de quelques classes :
Ce diagramme est décrit comme suit :

Personne : est une classe de généralisation et renferme l’ensemble des attributs

nécessaires pour la définition d’une entité « Personne » ;

Patient, Médecin, Infirmier, Technicien : Représente respectivement l’ensemble des

patients, médecins, techniciens et infirmiers du système et ces classes héritent de la
classe personne ;

Compte : Regroupe l’ensemble des comptes utilisateurs permettant d’avoir un accès

au système ;

Assurance : l’ensemble des assurances pris en charge par la structure sanitaire ;

Service : Représente l’ensemble des services du système ;

Admission : Regroupe l’ensemble des patients admis ou présents dans un service

d’hospitalisation ;

DossierMedical : Regroupe l’ensemble des informations médicales (prestations,

résultats, interventions, sorties, ...) sur le patient ;

Antécédents, diagnostics, motifs, symptômes, intervention, constantes, … :

constituent les rubriques du dossier médical et représentent respectivement l’ensemble
des antécédents, diagnostics, motifs, symptômes, intervention, constantes, …

Facture : Représente l’ensemble des factures des patients suite à un service médical
administré. Une facture à un type et l’ensemble des types est représenté par la classe
type ;

Chambre, lit : Représente les chambres et lits d’un service d’hospitalisation ;

Acte : Représente l’ensemble des actions médicales. Un acte peut être une
prescription, une prestation, un soin, une consultation, un examen…

RdvConsultation : Regroupe l’ensemble des demandes de rendez-vous de

consultation des patients.

46
 TROISIEME PARTIE

REALISATION DE LA
SOLUTION
 CHAPITRE VI : ENVIRONNEMENT DE TRAVAIL

Ce chapitre aura pour objectif de présenter l’ensemble des outils et environnements

qui ont permis le développement de la plateforme. Nous présenterons également
l’architecture de notre application.

I. ENVIRONNEMENT MATERIEL

1. Outils matériels

Pour réaliser notre projet, nous avons utilisé trois ordinateurs ayant les mêmes
spécifications et deux smart phones Android. Les caractéristiques de ces appareils
sont :

✓ Quatre (4) ordinateurs portables HP ayant les spécifications suivantes :

• Processeur : Intel® Core™ i7-8550U CPU @ 1.80GHz 2.80GHz ;
• Mémoire RAM : 16.00 Go ;
• Disque dur : 1024 Go ;
• Système d’exploitation : Windows 10 Professionnel 64 bits installé sur deux (3)
ordinateurs et Linux (Ubuntu 20) sur un (1).

✓ Deux (2) smart phones ITEL ayant les caractéristiques suivantes :

• Ecran : 10 pouces avec une résolution de 1 920 x 1 200 ;
• Mémoire RAM: 3.00 Go ;
• Mémoire ROM: 32 Go ;
• Système d’exploitation : Android 8 Oreo.

2. Architecture matérielle

Notre application se présente sous la forme d’une architecture trois tiers ou ce qu’on
appelle également architecture à trois niveaux. L’architecture trois tiers est
l’application du modèle le plus général qui est le multi-tiers et c’est également une

47
extension du modèle Client/Serveur. Plus spécifiquement c’est une architecture
partagée entre :

• Un client : L’ordinateur demandeur de ressources, équipé d’une interface

utilisateur (généralement un navigateur web) chargé de la présentation ;
• Un serveur d’application : Chargé de fournir la ressource mais faisant appel à un
autre serveur ;
• Un serveur de base de données : Fournissant au serveur d’application les données
dont il a besoin.

Etant donné l’emploi massif du terme de l’architecture à 3 niveaux, celui-ci peut

parfois désigner aussi les architectures suivantes :

– Partage d’application entre client, serveur intermédiaire, et serveur d’entreprise ;

– Partage d’application entre client, serveur d’application, et serveur de base de

données de l’entreprise.

La figure 16 illustre l’architecture de notre application.

Serveur base de données

Serveur WEB (http)

Figure 16-Architecture de l'application [18]

Comme le montre la figure 16, notre solution se base sur deux serveurs :

48
 - Serveur de base de données – MySQL : MySQL est un serveur de bases de
données relationnelles SQL, très rapide, multi-thread1, robuste et multi-
utilisateurs. MySQL est un logiciel libre développé sous double licence GPL
(General Public License) et licence commerciale. Il est le serveur de base de
données le plus utilisé dans le monde. Il fonctionne sur beaucoup de plates-
formes différentes et il est accessible en utilisant plusieurs langages de
programmation ;
- Serveur HTTP - Apache : Apache HTTP Server est un serveur HTTP créé et
maintenu au sein de la fondation Apache. C’est le serveur HTTP le plus
populaire du World Wide Web.

3. Architecture applicative

L’architecture vise à ce que l’application soit la plus maintenable possible. Dans ce

cadre le Framework utilisé est orienté vers l’architecture MVC. Ce modèle
d’architecture impose la séparation entre les données, la présentation et les traitements,
ce qui donne trois parties fondamentales dans l’application finale : le modèle, la vue
et le contrôleur.

• Le Modèle : Présente le comportement de l’application : traitements des données,

interactions avec la base de données, etc.

• La Vue : Correspond à l’interface avec laquelle l’utilisateur interagit. Sa première

tâche est de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de
recevoir toutes les actions de l’utilisateur (clic de souris, bouton, ...).

• Le Contrôleur : Prend en charge la gestion des événements de synchronisation pour

mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de
l’utilisateur et enclenche les actions à effectuer.

1
Multi-thread : se dit d’un système ou programme pouvant gérer plusieurs processus à la fois.

49
La figure 7 présente le mécanisme de traitement dans une architecture MVC :

Requête 1 6 Réponse

Donnée CONTROLEUR
3
5 Présentation
API REST
2 4
MODELE
VUE
Demande Donnée

Figure 17- Architecture MVC

Les avantages de l’architecture MVC sont nombreux :

- Vitesse de création de pages ;

- Gain de temps de maintenance ;
- Simplicité de mise à jour ;
- Clarté de l’architecture qu’il impose grâce à la séparation des données de la vue et
du contrôleur.

4. Moyens de communication

a. Web services

Il s'agit d'une technologie permettant à des applications de dialoguer à distance

via Internet, et ceci indépendamment des plates-formes et des langages sur lesquelles
elles reposent. Ils s'appuient sur un ensemble de protocoles Internet très répandus
(XML, HTTP), afin de communiquer.

L’implémentation la plus couramment rencontrée dans ce type d’architectures

est SOAP (Simple Object Access Protocol), dont les concepts sont d’exposer des

50
traitements sur le réseau, au moyen du protocole HTTP, en utilisant le langage
XML[19].

b. API REST

Une API (Application Programming Interface) est une méthode par laquelle les
fournisseurs tiers peuvent écrire des programmes pouvant facilement interagir avec
d’autres programmes.

REST (Representational State Transfer) est un style d'architecture logicielle

définissant un ensemble de contraintes à utiliser pour créer des services web. Ils sont
principalement utilisés pour intégrer des applications et automatiser les processus. Les
API REST imitent la façon dont le web lui-même marche dans les échanges entre un
client et un serveur [20].

II. ENVIRONNEMENT LOGICIEL

Un ensemble d’outils logiciels sont utilisés pour mettre en place la solution proposée.
L’objectif de cette section est de faire une présentation de certains d’entre eux.

1. Outils de conception

✓ StarUML
StarUML est un outil robuste et complet spécialisé dans la
modélisation UML pratique dans le domaine du développement
d'applications. C’est un logiciel complet pour les utilisateurs aguerris
dans le développement d'applications.

Figure 18- icone starUML

51
 ✓ MySQL Workbench [21]
MySQL Workbench est un logiciel de gestion et d’administration de
bases de données MySQL. Cette application permet visuellement de
concevoir, modéliser et générer toutes les opérations de la gestion
d’une base de données.

Figure 19- icone de Mysql WORKBENCH

2. Outils de développement

✓ Visual Studio Code [22]

est un éditeur de code extensible développé par Microsoft pour Windows, Linux et
macOS. Les fonctionnalités incluent la prise en charge du débogage, la mise en
évidence de la syntaxe, la complétion intelligente du code, les snippets, la
refactorisation du code et Git intégré. Les utilisateurs peuvent installer
des extensions qui ajoutent des fonctionnalités supplémentaires. Il est
très adapté et facilite l’écriture des codes informatiques.

Figure 20- Icone de VS Code

✓ MySQL [21]

MySQL est un Système de Gestion de Base de Données (SGBD). Il fait partie des
logiciels de gestion de base de données les plus utilisés au monde, autant par le grand
public (application web principalement) que par des professionnels. Le couple
PHP/MySQL est très utilisé par les sites web proposé par la
majorité des hébergeurs.

Figure 21-icone de MySQL

52
 ✓ Node.js
Node.js est une plateforme logicielle libre en JavaScript orientée vers les applications
réseau événementielles hautement concurrentes qui doivent pouvoir monter en charge.
Dans notre projet, Node.js est installé afin de fournir un environnement qui permettra
la programmation des interfaces utilisateurs en javascript grâce à la version libre du
framework2 webix dénommée webix-jet dont l’utilisation des packages NPM3 est
primordiale.

✓ TortoiseSVN [23]

TortoiseSVN est un client open-source gratuit pour le système de contrôle de version

Subversion. C'est à dire TortoiseSVN gère des fichiers et des répertoires à travers le temps. Il
mémorise tout changement fait sur les fichiers et répertoires car les fichiers sont stockés dans
un référentiel central. C’est un système spécifiquement conçu pour gérer des arborescences de
code source et a beaucoup de fonctionnalités spécifiques au développement de logiciel.

✓ WAMPServer
Pour répondre à l’architecture matériel de notre projet dans la phase de développement, nous
avons utilisé WAMPServer qui est un environnement comprenant deux serveurs (Apache et
MySQL), un interpréteur de script (PHP), ainsi que phpMyAdmin pour l'administration Web
des bases MySQL.

3. Frameworks et langages de programmation

Un framework (ou infrastructure logicielle en français) est un ensemble d'outils et de

composants logiciels à la base d'un logiciel ou d'une application. Son objectif est de
simplifier et d'uniformiser le travail des développeurs. En général, un framework est associé
spécifiquement à un langage de script ou de programmation.

2
Framework : infrastructure de développement, cadre de travail
3
npm est le gestionnaire de paquets officiel de Node.js

53
 a. Frameworks

Pour la programmation de ce système, nous allons utiliser les frameworks Jelix pour
le côté back-end 4 (les traitements métiers) et Webix pour le côté Frond-end (les vues
ou interfaces)

✓ Jelix
Jelix est un framework PHP basé sur le design pattern MVC et DAO qui permet une
séparation logique du code. Le framework Jelix offre entre autres :

- Un ensemble d'API prenant en charge : l’accès aux données, moteur de

templates, générateurs de contenus, générateur de formulaires, CRUD5
générique, authentification, gestion de droits, etc ;
- Une structure modulaire et une organisation des fichiers rigoureuse ;
- Un respect du modèle MVC pour un découpage en couche du projet.

C’est un framework idéal pour la mise en place d’une application modulaire et robuste
tel qu’un système d’information hospitalier.

✓ Webix

Webix est un framework front-end6 basé sur du JavaScript, HTML5 et CSS3 pour le
développement d'applications Web monopages7, multiplateformes complexes et
dynamiques. Le framework est développé par la société d'externalisation informatique
XB Software et offre des widgets ou outils tout prêt pour la création des interfaces
utilisateurs intuitives.

4
Back-end : représente la partie cachée ou fait référence à la partie traitement ou service d’un
système
5
CRUD : acronyme pour create, read, update, delete.Iil désigne les opérations permettant la gestion
d'une collection d'éléments.
6
Front-end : représente la partie visible du système. Il fait référence à l’interface utilisateur.
7
Application web monopage: c'est une application qui interagit avec l'utilisateur en écrivant
dynamiquement la page courante plutôt que de charger de nouvelles pages entières depuis un serveur

54
 b. Langages de programmation et de description

✓ PHP :

PHP (HyperText Préprocesseur) est un langage de programmation interprété libre

principalement utilisé pour produire des pages Web dynamiques via un serveur HTTP,
mais pouvant également fonctionner comme n’importe quel langage interprété de
façon locale. PHP est un langage impératif disposant depuis la version 5 de
fonctionnalités de modèle objet complètes. Nous avons choisi PHP car il est simple à
mettre en place (niveau serveur) et plus facile à standardiser et à transporter d’une
application à une autre.

✓ JavaScript :

Javascript souvent abrégé en « JS », c’est un langage de script léger, orienté objet,

principalement connu comme le langage de script des pages web. Il s'occupe, en partie,
de rendre dynamique notre plateforme web notamment en permettant les interactions
entre l'utilisateur et celui-ci.

✓ HTML:

HTML est un langage de balisage conçu pour représenter les pages web. C'est lui qui
présente le contenu, qui est la clé de voûte de toute plateforme web.

✓ CSS:

CSS s'occupe d'habiller graphiquement notre plateforme web à travers des styles qui
décrivent la présentation des documents HTML.

55
 CHAPITRE VII : RESULTATS ET DISCUSSION

Dans ce chapitre, il s’agira de présenter les différents résultats obtenus après

l’implémentation des différents cas d’utilisation et processus identifiés dans la phase
d’analyse au moyen des captures d’écran.

I. RESULTATS
1. Présentation des modules implémentés

L’application est subdivisée en module et chaque module répond à une gestion bien
spécifique des activités que mènent quotidiennement le personnel des structures
sanitaires. Ainsi pour notre système d’information hospitalier, nous avons implémenté
les modules suivants :

- Bafs : ce module permet de créer un dossier, enregistrer une admission, de facturer

certains actes, valider et imprimer une facture complète ou provisoire, imprimer
les états de facturation ;
- AgentComptable : ce module permet d’encaisser une facture, imprimer un reçu de
paiement, voir et imprimer les états de caisse ;
- Medecin : ce module permet au médecin de saisir les informations médicales des
patients (motifs, diagnostics, traitements, ordonnances, examens…) ;
- Infirmier : ce module permet de visualiser les prescriptions des médecins et de les
réalisés, générer le numéro de stickage de prélèvement… ;
- Medico-technique : ce module permet de paramétrer et saisir les résultats d’un
examen biologique ;
- Informatique : ce module permet de paramétrer les données de base utiles à la
gestion ;
- Archive : ce module permet de gérer les carnets physiques dématérialisés ;
- Direction : ce module permet de superviser les statistiques et visualiser indicateurs
des services ;
- Logistique : ce module permet de gérer les chambres, de faire le transfert d’un
patient d’un service à un autre ;
- Consultation : ce module offre les fonctionnalités d’enregistrement de demande
de rendez-vous, de paramétrage des programmes de consultation.

56
 2. Présentation des interfaces utilisateurs

Ce volet présente quelques interfaces qui illustrent les différentes fonctionnalités de

notre système d’information hospitalier dénommé « OLYMPE ».

Pour faciliter l’exécution de l’application en évitant à l’utilisateur de saisir lui-même

l’adresse du serveur dans l’url, un raccourci pointant sur l’adresse IP du serveur est
créé sur le bureau de l’ordinateur.

✓ Authentification
Au lancement de notre application, une interface d’authentification démarre comme le
montre la figure 22.

Figure 22- Interface d'authentification de l’application

L’accès au système Olympe est protégé par un identifiant et un mot de passe

garantissant la sécurité et l’intégrité des données.

57
 ✓ Menu principal
Après l’authentification, l’utilisateur est redirigé directement vers le menu principal
qui affiche uniquement les modules dont l’utilisateur à les droits. Le figure 23 présente
le menu principal d’un compte administrateur.

Figure 23- Menu principal d'un administrateur

58
 ✓ Menu du module Bureau des Admissions et Frais Séjour

Cette interface (figure 24) présente la page d’accueil du module BAFS ainsi que les
opérations possibles que peuvent mener un agent de ce service sur une admission.

Figure 24- Interface du module BAFS

59
 ✓ Formulaire de saisie d’une admission

Cette interface présentée par la figure 25 permet à l’utilisateur de renseigner les

informations nécessaires du patient lors de l’enregistrement d’une admission.

Figure 25- Formulaire de saisie d'une admission

60
 ✓ Saisie de rendez-vous de consultation
Cette interface permet de fixer la date de rendez-vous de consultation d’un patient
selon le calendrier des médecins et le type de rendez-vous sollicité.

Figure 26- Interface de demande RDV de consultation

61
 ✓ Module de gestion médicale
Cette interface présente la page principale du module destiné aux médecins ainsi que
les fonctionnalités de ce module sous forme de menu positionné à droite de l’interface.
Précisément cette capture montre l’écran de saisie de prise des constantes.

Figure 27- Interface du module de gestion médicale

II. DISCUSSIONS

L’application étant actuellement en production à l’ICA, nous pouvons constater sa

bonne marche dans les différents services. En effet, lorsqu’un cas d’anomalie ou un
bug du système se présente, ce cas est rapidement corrigé et une mise à jour est
appliquée sur la version de production. Certaines suggestions et remarques des
utilisateurs ont été prises en compte et sont en cours développement.

1. Difficultés rencontrées

Tout au long du projet, nous avons rencontré quelques difficultés. Parmi ces
difficultés, nous pouvons citer :

62
 - L’identification des besoins des utilisateurs car ces derniers ont eu du mal à
formuler avec précision ce qu’ils veulent ou ont oublié d’expliquer certains cas
de figures du processus de prise en charge des patients pendant la phase des
interviews et de recueils d’information qui causent un problème lorsque ces
cas se présentent ;
- Une perte de temps de travail sur des fonctionnalités inutiles dû à une mauvaise
explication des processus métiers ;
- Un court délai de réalisation du projet ;
- La formation sur l’utilisation du logiciel de certains utilisateurs qui n’ont
aucune connaissance de base de l’utilisation d’un ordinateur ;
- Absence de pilote afin de permettre la communication entre les automates du
laboratoire et notre base de données.

2. Limites de la solution

Comme limite de notre solution, il faut noter l’absence d’interconnexion entre notre
système et les automates de réalisation des examens afin de transmettre de manière
automatique les résultats des examens dans la base de données de notre système. Pour
l’instant cette tâche se fait par saisie via une interface développée et paramétrable en
fonction de l’examen afin de réduire au maximum le taux d’erreur de saisie.

3. Axes d’amélioration

Comme axe d’amélioration, nous avons identifié :

✓ La mise en place de stratégies de sécurité du système et des données
Afin d’améliorer notre système, le volet de la sécurité reste important. Ainsi il est
nécessaire de se faire accompagner d’expert en sécurité de système d’information pour
élaborer et mettre en œuvre aussi bien une politique de sécurité et une politique de
reprise après désastre ;

✓ Le développement d’une version mobile

Bien vrai que l’application tourne sur le mobile via un navigateur, il serait meilleur de
développer une version mobile étant donné qu’actuellement presque tout le monde a
un smartphone. En plus pour un personnel de soin, il est plus facile et plus accessible
de manipuler une tablette que de manipuler une machine pour effectuer une prestation ;

63
 ✓ Mise en place d’un entrepôt de données pour l’analyse des données
Avec toutes ces données qui seront stockées pendant l’utilisation de la solution, il serait
judicieux d’étudier à un moment donné ces informations afin d’apporter des réponses
à certaines questions avec des preuves à l’appui. Avec une analyse de données, nous
pouvons savoir par exemple le comportement d’un ensemble de patient face à un
traitement, le nombre d’hypertendu artériel, etc. Pour se faire, il est nécessaire
d’utiliser les outils de l’analyse décisionnelle (Business Intelligence).

4. Evaluation du coût

Le calcul du coût du projet prend en compte le coût d’étude, de développement, de

déploiement et de la formation des utilisateurs. Les montants sont en Francs CFA.

DESIGNATION QUANTITE PRIX UNITAIRE TOTAL

Analyse et développement du système
3 ingénieurs stagiaires 180 J/h 14.000F/J 7.560.000
Visual Studio, WAMP, Jelix - Gratuit Gratuit
Modules du Framework Webix 1 120.000 120.000
Connexion Internet 6 mois 49.000F/mois 294.000
Ordinateur Portable 4 725.000 2.900.000
Tablette Android 2 82.000 164.000
Déploiement
Un serveur dédier 1 1.800.000 1.800.000
Ordinateur bureautique - - -
Tablette Android - - -
Formations
2 Formateurs 14 J/h 30.000F/J 840.000
Manuel d’utilisation - Gratuit Gratuit
MONTANT TOTAL 13.678.000
J/h : Jour (ouvré) par homme.

64
 CONCLUSION
Ce projet de fin d’études consistait à mettre en place un système d’information
hospitalier afin de permettre la prise en charge informatisée du patient et optimiser les
ressources de la structure.

La mise en place d’un tel système s’est faite en trois phases. La première phase de
notre projet avait pour but de comprendre le domaine hospitalier dans sa généralité.
Ensuite, nous sommes passés à l’analyse et conception de notre système en choisissant
comme méthode d’étude Unified Process (Processus Unifié). Ainsi nous avons défini
et modélisé les différents cas d’utilisation de notre système après une analyse de
l’existant qui nous a permis de spécifier les besoins fonctionnels et non fonctionnels.
La troisième et dernière phase consistait à réaliser la solution. En effet, nous avons
présenté notre environnement de travail, les différents outils, langages et procédés
utilisés pour l’implémentation du système ainsi que les modules développés.

Ce système pourra répondre aux besoins de l’ICA, car il a été développé en se basant
sur leur référentiel, leurs règles et données de gestion ainsi que leur présentation des
indicateurs et bilans. En effet cette solution présente une panoplie de fonctions qui
permet la gestion efficiente administrative et médicale des patients et va contribuer à
l’amélioration de la qualité de services offerts.

Ce thème que nous avons traité a été très enrichissant pour nous. En effet, il nous a
permis d’acquérir une meilleure connaissance du domaine des systèmes d’information
de santé. Nous avons pu nous confronter à la réalité du terrain dans le domaine de la
conception des applications orientées santé. Sur le plan professionnel, ce projet nous a
permis de découvrir de nouvelles approches de développement logiciel et également
de développer notre capacité de présentation de solution informatique.

La réalisation de ce projet s’est confrontée à quelques difficultés. Au niveau du recueil

d’information, certains agents avaient du mal à bien expliquer leur travail ou à
exprimer leurs besoins. Aussi, il était difficile d’avoir certaines données dites
confidentielles qui sont nécessaires à la compréhension du projet. Au niveau
technique, le délai de réalisation était court, ainsi, il a fallu rechercher des outils rapides
et efficaces pour l’implémentation des fonctionnalités. Il faut noter que le projet n’est
pas totalement fini, car il reste à développer la version mobile.

65
 BIBLIOGRAPHIE
[1] Adon (Patrick), 2011 « Numérisation du système d’information et de gestion
(SIG) des établissements sanitaires en Côte d’Ivoire », EDUCI, http://www.revues-
ufhb-ci.org/fichiers/FICHIR_ARTICLE_722.pdf , [en ligne], (consulté le 14/10/2020)
[2] BOUAMRANE, Souad Fatima Zohra. Système d’Information Hospitalier :
Admission et Planification des blocs opératoires. Mémoire de Magister, Informatique,
ORAN : Université d’Oran, faculté des sciences, 2010, p.11
[3] Didier Balsan, « Une typologie des établissements de soins publics et PSPH en
fonction de leur activité et de leur environnement », Document de travail, Drees, no
37, octobre 2003 (lire en ligne [archive] [PDF], consulté le 5 novembre 2020)
[4] BOUAMRANE, Souad Fatima Zohra. Système d’Information Hospitalier :
Admission et Planification des blocs opératoires. Mémoire de Magister, Informatique,
ORAN : Université d’Oran, faculté des sciences, 2010, p.14
[5] Circulaire ministérielle numéro 275 du 6 janvier 1989 du Ministère de la Santé
français, [en ligne],
https://www.atih.sante.fr/sites/default/files/public/content/990/Cir_6-1-89.pdf,
consulté le 18/09/2020
[6] Gérard Ponçon, Le management du système d’information hospitalier : la fin de la
dictature technologique, éditions de l’École Nationale de la Santé Publique, 2000
(ISBN 2-85952-786-9), p.25
[7] BOUAMRANE, Souad Fatima Zohra. Système d’Information Hospitalier :
Admission et Planification des blocs opératoires. Mémoire de Magister, Informatique,
ORAN : Université d’Oran, faculté des sciences, 2010, p.15-17
[8] DEGOULET, Patrice. Op.cit., p. 313.
[9] Wikipédia article, méthodes d’analyse et de conception, en ligne,
https://fr.wikipedia.org/wiki/M%C3%A9thodes_d%27analyse_et_de_conception#:~:
text=En%20ing%C3%A9nierie%2C%20une%20m%C3%A9thode%20d,fid%C3%A
8le%20aux%20besoins%20du%20client, consulté le 15/08/2020
[10] MERISE - Initiation à la conception de systèmes d'information,
https://web.maths.unsw.edu.au/~lafaye/CCM/merise/concintro.htm, en ligne,
consulté le 15/08/2020
[11] processus unifié,
https://fr.wikipedia.org/wiki/Processus_unifi%C3%A9#cite_note-:2-12, en ligne,
consulté le 15/08/2020

VIII
[12] Wikipedia, UML, https://fr.wikipedia.org/wiki/UML_(informatique), en
ligne, consulté le 16/08/2020
[13] Remi Manu, cours UML, http://remy-manu.no-
ip.biz/UML/Cours/coursUML1.pdf, en ligne, consulté le 16/08/2020
[14] how to develop an expert advisor using uml tools,
https://www.mql5.com/en/articles/widget/304, en ligne, consulté le 16/08/2020
[15] Laurent Audibert, UML 2 de l’apprentissage à la pratique (cours et
exercices), édition Ellipses, 2014.
[16] L. DEBRAUWER et F. Van der HEYDE : UML 2 : modélisation des objets.
TechNote (Nantes). Editions ENI, 2006.
[17] Diakité Soumaïla, Etude et conception d’une application de gestion de crédit-
bail : cas de la société x, mémoire de fin de cycle, système d’information et génie
logiciel, Abidjan, 2020.
[18] Dhouha MELKI, Mohamed Aziz CHETOUI. Conception et développement
d’une application de gestion de production et de maintenance. RAPPORT DE
STAGE DE FIN D’ETUDES, Informatique, UNIVERSITE TUNIS EL MANAR,
Systèmes Informatiques et Logiciels, 2015, p.32
[19] services web, http://igm.univ-
mlv.fr/~dr/XPOSE2004/woollams/definition.html, en ligne, consulté le 24/08/2020
[20] API REST, https://blog.linagora.com/developpement-et-exploitation-de-web-
services-rest/, consulté le 24/08/2020
[21] MYSQL, Mysql workbench, Visual database design,
https://www.mysql.fr/products/workbench/ , en ligne, Consulté le 01-10-2020.
[22] Visual Studio Code, https://fr.wikipedia.org/wiki/Visual_Studio_Code, en
ligne, Consulté le 03-10-2020.
[23] Tutoriel tortoiseSVN, https://fr.slideshare.net/Nwinslo/tutoriel-tortoise-
svn?from_action=save, en ligne, consulté le 01/10/2020

IX
 ANNEXES
Annexe 1 :

Figure 28-Fiche de surveillance médicale recto

X
Annexe 2 :

Figure 29- Fiche de surveillance médicale (verso)

XI
Annexe 3 :

Figure 30- Fiche Comptable

XII
Annexe 4 :

Figure 31- Carnet de consultation médical

XIII
 TABLE DES MATIERES
DEDICACE ............................................................................................................................. I
REMERCIEMENTS ............................................................................................................ II
AVANT-PROPOS ................................................................................................................ III
SOMMAIRE......................................................................................................................... IV
SIGLES ET ABBREVIATIONS ......................................................................................... V
LISTE DES FIGURES ........................................................................................................ VI
LISTE DES TABLEAUX .................................................................................................. VII
INTRODUCTION.................................................................................................................. 1
PREMIERE PARTIE : GENERALITES ............................................................................ 3
CHAPITRE I : PRESENTATION DE L’ENTREPRISE D’ACCUEIL .............................. 3
I. HISTORIQUE.......................................................................................................... 3
II. DOMAINES D’ACTIVITE ..................................................................................... 3
CHAPITRE II : PRESENTATION DU PROJET................................................................ 4
I. DEFINITION DES TERMES .................................................................................. 4
1. Définitions du système ......................................................................................... 4
2. Organisation ......................................................................................................... 4
3. Hôpital.................................................................................................................. 5
4. Organisation hospitalière ..................................................................................... 5
5. Le système d’information hospitalier (SIH) ........................................................ 5
a. Définition ......................................................................................................... 5
b. Objectif ............................................................................................................ 6
c. Composantes .................................................................................................... 7
d. Environnement ................................................................................................. 8
II. PRESENTATION DU CAHIER DE CHARGES ................................................... 9
1. Cadre général du projet ........................................................................................ 9
2. Objectifs ............................................................................................................. 10
a. Objectif général .............................................................................................. 10
b. Objectifs spécifiques ...................................................................................... 10
CHAPITRE III : ETUDE DE L’EXISTANT .................................................................... 12
I. GESTION HOSPITALIERE ................................................................................. 12
1. Description du système de l’ICA ....................................................................... 12
2. Diagnostic de l’existant logiciel ......................................................................... 14
II. CRITIQUES DU SYSTEME ................................................................................. 15
DEUXIEME PARTIE : ANALYSE ET CONCEPTION ................................................. 16
CHAPITRE IV : METHODE D’ANALYSE ET DE CONCEPTION .............................. 16

XIV
 I. METHODES D’ANALYSE ET DE CONCEPTION D’UN SYSTEME
D’INFORMATION ....................................................................................................... 16
1. MERISE ............................................................................................................. 16
a. Cycle d'abstraction de conception des systèmes d'information...................... 17
2. Processus Unifié (PU) [11] ................................................................................ 18
a. Cycle de vie des projets [11] .......................................................................... 18
b. Enchainements d’activités.............................................................................. 19
3. Justification du choix de la méthode .................................................................. 20
II. UML (Unified Modeling Language)...................................................................... 20
1. Présentation ........................................................................................................ 20
2. Les diagrammes ................................................................................................. 20
a. Diagrammes structurels ou statiques (Structure Diagrams) ........................... 21
b. Diagrammes comportementaux ou dynamique (Behavior Diagram) ............ 22
c. Diagrammes d'interaction (Interaction Diagram)........................................... 22
CHAPITRE V : ANALYSE ET CONCEPTION DU SYSTEME .................................... 24
I. ANALYSE ET SPECIFICATION DES BESOINS .............................................. 24
1. Analyse des besoins non fonctionnels................................................................ 24
2. Analyse des besoins fonctionnels....................................................................... 26
a. Diagramme de cas d’utilisations .................................................................... 26
II. CONCEPTION DU SYSTEME ............................................................................ 39
1. Diagrammes de séquences ................................................................................. 39
2. Diagrammes de classes ...................................................................................... 44
TROISIEME PARTIE : REALISATION DE LA SOLUTION ...................................... 47
CHAPITRE VI : ENVIRONNEMENT DE TRAVAIL .................................................... 47
I. ENVIRONNEMENT MATERIEL ........................................................................ 47
1. Outils matériels .................................................................................................. 47
2. Architecture matérielle ....................................................................................... 47
3. Architecture applicative ..................................................................................... 49
4. Moyens de communication ................................................................................ 50
a. Web services .................................................................................................. 50
b. API REST ...................................................................................................... 51
II. ENVIRONNEMENT LOGICIEL.......................................................................... 51
1. Outils de conception........................................................................................... 51
2. Outils de développement .................................................................................... 52
3. Frameworks et langages de programmation ...................................................... 53
a. Frameworks.................................................................................................... 54
b. Langages de programmation et de description............................................... 55
CHAPITRE VII : RESULTATS ET DISCUSSION ......................................................... 56

XV
 I. RESULTATS ......................................................................................................... 56
1. Présentation des modules implémentés .............................................................. 56
2. Présentation des interfaces utilisateurs............................................................... 57
II. DISCUSSIONS ...................................................................................................... 62
1. Difficultés rencontrées ....................................................................................... 62
2. Limites de la solution ......................................................................................... 63
3. Axes d’amélioration ........................................................................................... 63
4. Evaluation du coût ............................................................................................. 64
CONCLUSION .................................................................................................................... 65
BIBLIOGRAPHIE............................................................................................................ VIII
ANNEXES ............................................................................................................................. X
TABLE DES MATIERES ................................................................................................ XIV

XVI
 RESUME
Dans le domaine de la santé, l’information joue un rôle capital dans la prise en charge
médicale du patient. Cette prise en charge génère une quantité énorme d’informations
qui doivent être gérées. Les systèmes d’information hospitaliers intégrant la gestion
administrative et médicale du patient sont des solutions idoines pour mieux gérer ces
informations afin de participer à l’amélioration de la qualité de service des structures
sanitaires. Ce mémoire porte sur l’étude et la mise en œuvre d’un système
d’information pour le compte de l’Institut de cardiologie d’Abidjan. Ce système
d’information est composé de plusieurs modules intégrés et où l’information sur le
patient représente la base de données centrale. Pour se faire une étude sur le domaine
hospitalier a été mener pour s’imprégner de cette activité dans un premier temps.
Ensuite, nous avons utilisé Unified Process comme méthode d’étude et les diagrammes
UML pour la modélisation des spécifications fonctionnelles du système. Enfin, nous
avons développé et implémenté notre solution sur un environnement web.

Mots clé : sytème d’information hospitalier

ABSTRACT
In the field of health, information plays a vital role in the medical management of the
patient. This support generates an enormous amount of information that must be
managed. Hospital information systems integrating the administrative and medical
management of the patient are suitable solutions to better manage this information in
order to participate in improving the quality of service of health structures. This thesis
focuses on the study and implementation of an information system on behalf of the
Abidjan Heart Institute. This information system is composed of several integrated
modules and where patient information is the central database. To do so, a study on
the hospital sector was carried out to become familiar with this activity at first. Then
we used Unified Process as a study method and UML diagrams for modeling the
functional specifications of the system. Finally, we have developed and implemented
our solution on a web environment.

Keyword : Hospital information system

Ecole Supérieure Africaine des Technologies de l’Information et de la Communication

Zone 3, Km 4 Bd Marseille – 18 BP 1501 Abidjan 18 – www.esatic.ci
Mail : direction.esatic@esatic.ci