Vous êtes sur la page 1sur 80

1

Rsum
La gestion des informations au sein des organisations a connu une mutation fulgurante grce
lavnement des technologies de linformation et de la communication (TIC). Des secteurs comme
les grandes distributions, le secteur priv de manire gnrale, se sont trs tt dot de robustes
systmes dinformation (SI) leur permettant de grer et tirer profit de la valeur de linformation.
Cependant, le secteur public de la sant est en retard dans cette nouvelle tendance innovante des
TIC. Or, de grandes quantits dinformations sont produites quotidiennement par les activits
mdicales tels que les consultations, les comptes rendus dhospitalisation, les rapports danalyse
de laboratoire et de causes de dcs, etc. Ces informations sont consignes dans des documents
essentiellement textuels, des images et des dossiers dont le mode daccs et dexploitation se font
principalement de manire manuelle. Cest ainsi que nous proposons une mise en place dun
systme dinformation mdical national pour le Sngal (SIMENS) permettant de surmonter
toutes ces difficults. Au-del de la gestion des tches quotidiennes, nous proposons de dvelopper
dans ce projet un systme d'intgration de ces donnes mdicales une chelle suprieure pour
offrir une vue globale et des outils d'aide la dcision aux autorits sanitaires et politiques.
Le projet est ralis dans le cadre d'une collaboration entre l'Unit de Formation et de Recherche
(UFR) en Sciences Appliques et Technologie (SAT) - travers son Laboratoire d'Analyse
Numrique et d'Informatique (LANI) - et l'UFR des Sciences de la Sant (2S), toutes deux de
l'Universit Gaston Berger de Saint-Louis.


2


Ddicaces
Ce mmoire est ddicac nos trs chers parents et toutes les personnes qui nous sont chres.


3


Remerciements
A,
ALLAH, le TOUT Puissant qui nous a donn la sant et la force de terminer ce travail
Nos parents qui nous ont toujours encourags dans la qute du savoir et qui continuent de nous
soutenir dans les bons comme dans les mauvais moments
Nos encadreurs qui nont mnag aucun effort pour la russite de ce projet
Nos camarades de classe qui ont particip de prs ou de loin ce projet
Le personnel de lhpital de Saint-Louis pour leur disponibilit et aussi leur consentement nous
fournir les donnes ncessaires


4


Table des matires
AVANT-PROPOS ............................................................................................................................7
ACRONYMES .................................................................................................................................8
TABLE DES FIGURES ....................................................................................................................9
TABLE DES TABLEAUX .............................................................................................................. 10
II. INTRODUCTION ................................................................................................................... 11
III. MOTIVATIONS ET OBJECTIFS DU PROJET SIMENS ...................................................... 13
IV. ANALYSE ET SPECIFICATION DES BESOINS .................................................................. 13
1. METHODOLOGIE ADOPTEE POUR LANALYSE DU DOMAINE DETUDE .................. 14
2. PRESENTATION DU DOMAINE DETUDE ......................................................................... 14
2.1 Historique du domaine dtude ............................................................................................... 14
2.2 Description des acteurs et leurs rles ..................................................................................... 15
2.3 Description des services et leurs fonctions ............................................................................. 16
3. SPECIFICATION DETAILLEE DES BESOINS .................................................................... 17
3.1 Les besoins techniques ............................................................................................................ 17
3.2 Les besoins fonctionnels .......................................................................................................... 19
4. ETUDE DE LEXISTANT ...................................................................................................... 19
4.1 Sur le plan technique............................................................................................................... 19
4.2 Sur le plan fonctionnel ............................................................................................................ 20
5. RESULTATS DE LA PHASE DANALYSE ........................................................................... 22
V. ETAT DE LART DES SIH ..................................................................................................... 23
1. DEFINITION .......................................................................................................................... 23
2. PRINCIPAUX ENJEUX .......................................................................................................... 23
3. UN PANORAMA DES SYSTEMES DINFORMATION HOSPITALIERS EXISTANTS ...... 24
VI. DEFINITION DES SPECIFICATIONS FONCTIONNELLES DU SYSTEME ...................... 29
1. METHODOLOGIE ADOPTEE .............................................................................................. 29
2. LES COMPOSANTES FONCTIONNELLES DE SIMENS .................................................... 31
3. CONCEPTION DETAILLEE DES FONCTIONNALITES .................................................... 32
3.1. DIAGRAMME DES CAS DUTILISATIONS ....................................................................................... 32
5


3.2. DIAGRAMME DES SEQUENCES DES DIFFERENTES FONCTIONNALITES ......................................... 35
VII. CONCEPTION DE LARCHITECTURE DU SYSTEME ...................................................... 47
1. ARCHITECTURE SYSTEME ................................................................................................ 47
1.1 DEFINITION ................................................................................................................................ 47
1.2 TYPE DARCHITECTURE SYSTEME ............................................................................................ 47
2. DESCRIPTION DES COMPOSANTS DE SIMENS ............................................................... 49
3. MODELE ET SCHEMA DE LARCHITECTURE ................................................................. 51
3.1 DIAGRAMME DES FLUX DINFORMATION ENTRE LES SERVICES .................................................. 51
3.2 DIAGRAMME DINTERACTION ENTRE PATIENT ET LES DIFFERENTS SERVICES (CENTREE SUR LE
PATIENT).................................................................................................................................................. 53
4. STRATEGIES DE PERFORMANCE ET DE SECURITE DU RESEAU ................................ 55
VIII.CONCEPTION DE LARCHITECTURE DE LAPPLICATION .......................................... 56
1. ARCHITECTURE DE LAPPLICATION .............................................................................. 56
1.1. DEFINITION ................................................................................................................................. 56
1.2. LES DIFFERENTS TYPES DARCHITECTURES LOGICIELLES .......................................................... 57
2. ETUDE COMPARATIVE DES TECHNOLOGIES EXISTANTES ........................................ 62
2.1. LES FRAMEWORK ........................................................................................................................ 62
2.2. LES LANGAGES DE PROGRAMMATION: .................................................................................... 63
2.3. LES SYSTEMES DE GESTION DE BASE DE DONNEES : ............................................................... 65
2.4. LES ENVIRONNEMENTS DE DEVELOPPEMENT INTEGRE (EDI) .............................................. 66
3 CHOIX DES TECHNOLOGIES ET OUTILS POUR LE DEVELOPPEMENT ..................... 68
4 STRATEGIES DE PERFORMANCE ET DE SECURITE DE LAPPLICATION ................. 73
5 POLITIQUES DE CONFIDENTIALITE DES DONNEES DES PATIENTS .......................... 75
IX. CONCLUSION GENERALE .................................................................................................. 77
1. BILAN ..................................................................................................................................... 77
2. PROBLEMES RENCONTRES ............................................................................................... 77
3. RECOMMANDATIONS ......................................................................................................... 78
4. PERSPECTIVES ..................................................................................................................... 78
BIBLIOGRAPHIE ......................................................................................................................... 79

6



7


Avant-propos

Dans le cadre de la formation en DESS d'Ingnierie en Informatique et TIC, et dans le but
de mettre en pratique les formations reues jusque-l, un mmoire ayant trait au Systme
d'Information Hospitalier nous a t demand. Celui-ci nous permet non seulement de manifester
notre personnalit, de faire connatre au monde scientifique que nous existons et avons des
comptences exprimer, mais aussi et surtout de nous imprgner des ralits de la vie
socioprofessionnelle.
En effet, la rdaction du mmoire qui est inclus dans le programme du DESS a pour objectifs :
D'une part, de fournir aux tudiants la possibilit de mettre en uvre les connaissances
thoriques acquises tout au long de leur formation ;
d'autre part, de leur initier quant aux ralits du milieu professionnel.

L'tudiant aura donc la tche de rdiger un mmoire sur un problme informatique qu'il a
tudi et auquel il a essay de trouver une solution. En outre, il devra procder la soutenance de
celui-ci devant un jury pour attester du travail accompli.
Ce mmoire tout en ressemblant un dossier d'analyse n'en est pas un : il s'agira pour
l'tudiant d'expliquer la dmarche suivie pour rsoudre le problme qu'il a eu examiner d'o
l'objet de la rdaction du prsent mmoire.
Il sagit dans ce cas prcis de ltude du fonctionnement du milieu hospitalier pour faire
sortir ses diffrents besoins afin darriver mettre en uvre un systme dinformation rpondant
ces derniers et leur permettant damliorer leur condition de travail.


8


Acronymes
Sigles Significations
ANDS Agence Nationale de la Dmographie et des
Statistiques
CHRSL Centre Hospitalier Rgional de Saint-Louis
DHCP Dynamic Host Configuration Protocol
EDI Environnement de Dveloppement Intgr
FAI Fournisseur d'Accs Internet
HIDS Intrusion Detection System
IB Initiative Bamako
JSF Java Server Faces
MVC Modle Vue Contrleur
NIDS Network Intrusion Detection System
ONG Organisation Non Gouvernementale
SGBD Systme de Gestion de Base de Donnes
SIMENS Systme d'Information Mdical National pour
le Sngal
SIH Systme d'Information Hospitalier
SOA Service Oriented Architecture
TIC Technologies de l'Information et de la
Communication
UML Unified Modeling Langage


9


Table des figures
Figure 1. Architecture logicielle de Mediboard ............................................................................ 26
Figure 2. Architecture logicielle de GNU Health ......................................................................... 29
Figure 3. Le processus de dveloppement en Y ........................................................................... 30
Figure 4. Diagramme de cas d'utilisations du Systme mdical ................................................... 32
Figure 5. Diagramme de cas d'utilisations du Systme mdicotechnique .................................... 33
Figure 6. Diagramme de cas d'utilisations du Systme mdico-administratif .............................. 33
Figure 7. Diagramme de squence Authentification..................................................................... 35
Figure 8. Diagramme de squence Identifier un patient .............................................................. 37
Figure 9. Diagramme de squence Crer un dossier patient ........................................................ 39
Figure 10. Diagramme de squence Consulter un dossier mdical ............................................. 41
Figure 11. Diagramme de squence Faire un enregistrement mdical ........................................ 42
Figure 12. Diagramme de squence Faire une prescription mdicale ......................................... 44
Figure 13. Diagramme de squence Hospitaliser un patient ........................................................ 45
Figure 14. Architecture Client-Serveur......................................................................................... 48
Figure 15. Architecture Globale du systme centre sur l'application ......................................... 51
Figure 16 Diagramme de flux d'informations entre les services (1) ............................................ 52
Figure 17. Diagramme de flux d'informations entre les services (2) ............................................ 53
Figure 18. Flux d'informations centr sur le patient ..................................................................... 54
Figure 19. Schma de type 1 avec la prsence de plusieurs servlets ............................................ 58
Figure 20. Modle de type 2 avec une seule servlet ..................................................................... 58
Figure 21. Pourcentage d'utilisation des langages ...................................................................... 64
Figure 22. Pourcentage d'utilisation des langages serveur............................................................ 64



10


Table des tableaux
Tableau 1. Conception dtaille des fonctionnalits du systme ................................................................ 34
Tableau 2. Description Squence Authentification ..................................................................................... 36
Tableau 3. Description Squence Identifier patient .................................................................................... 38
Tableau 4. Description Squence Crer Dossier patient ............................................................................. 40
Tableau 5. Description Squence Consulter un dossier mdical ................................................................ 42
Tableau 6. Description Squence Faire un enregistrement mdical ........................................................... 43
Tableau 7. Description Squence Faire une prescription mdicale ............................................................ 45
Tableau 8. Description Squence Hospitaliser un patient ........................................................................... 46
Tableau 9 Les frameworks .......................................................................................................................... 63
Tableau 10 Tableau comparatif des SGBD ................................................................................................. 66
Tableau 11 Prsentation de quelques frameworks PHP .............................................................................. 70
Tableau 12 Prsentation de quelques navigateurs web ............................................................................... 71
Tableau 13 Prsentation de quelques IDEs ................................................................................................. 72


11


II. Introduction
Depuis trois dcennies, les processus de soins ne cessent de se complexifier. Ce qui a
conduit naturellement une subdivision des spcialits mdicales, avec comme effets
laugmentation des cots de prise en charge du patient, lappauvrissement de la relation mdecin
malade, la non matrise des processus thrapeutiques et une ncessit absolue de trouver un
meilleur moyen de rendre fluide les informations mdicales destination des professionnels de la
sant.
Aux USA, le National Committee on Vital and Health Statistics (NCVHS) estime que des
erreurs mdicales vitables reprsentent 12 15% des cots hospitaliers, que 80% des infirmires
font des erreurs de calcul de doses dans 10% des cas et 180000 dcs dus une thrapeutique
inadquate sont vitables par an (NCVHS. Testimony, June 23-24, 1999). Ainsi, les erreurs
mdicales causent 50'000 100'000 morts par an aux USA. Elles cotent 20 milliards de dollar
par an. Il y a plus de 1'000'000 derreurs mdicamenteuses observes par an aux USA, causant
7'000 morts dans les hpitaux [1].
En Suisse, un pays riche avec 26 ministres de la sant, on observe 3 5 morts par jour lis
aux erreurs mdicales.
Ces chiffres soulignent aujourdhui dans le monde de la sant deux types de constat :
La complexit de plus en plus croissante des processus de soins.
La limitation intrinsque de la capacit humaine traiter linformation [Miller 1956].

Dans ce contexte, les Technologies de lInformation et de la Communication (TIC)
semblent tre un vecteur favorisant la coordination des professionnels de la sant, loptimisation
des dpenses de sant par une bonne organisation des processus de soins, et la coopration troite
pour permettre une meilleure prise en charge des patients. Cest ainsi que lon assiste depuis une
dizaine dannes la mise en place dans toutes les socits occidentales des systmes
dinformations, en particulier hospitaliers, visant sintgrer dans le processus de soins pour
amliorer les prises en charge. Il faut noter que cette mise en place ne se fait pas sans difficults.

12


Quen est-il dans les pays en voie de dveloppement, tel que le Sngal? Il serait raliste
aujourdhui de rflchir une stratgie de mise en place dun modle de systmes dinformation
hospitaliers efficients dans ces pays, au lieu de chercher obtenir uniquement des statistiques
mdicales dont la fiabilit sera mise en question en labsence de mthodes et de moyens adapts.
La non-disponibilit des statistiques en temps opportun pour dcider efficacement et pour tre
ractif la situation est une plaie que les systmes dinformation hospitaliers en particulier doivent
contribuer gurir. Cest dire aussi quau moment o les pays dvelopps orientent de plus en plus
leurs systmes dinformation vers laide la dcision et au diagnostic entre autre activit mdicale,
il nexiste aucun systme dinformation informatis pour piloter la sant dans la plupart des rgions
en Afrique, c'est--dire mieux concentrer les efforts et les ressources vers les problmes de sant
pertinents grce des indicateurs fiables.

Contribuer llaboration dun modle et limplmentation dun systme dinformation
adapt lhpital en Afrique et notamment au Sngal, est lun des objectifs de ce projet.
Spcifiquement, nous nous proposons de mettre en place un systme dinformation mdical
national pour le Sngal (SIMENS) permettant de surmonter toutes ces difficults. Au-del de la
gestion des tches quotidiennes, nous allons dvelopper dans ce projet un systme d'intgration de
ces donnes mdicales une chelle suprieure pour offrir une vue globale et des outils d'aide la
dcision aux autorits sanitaires et politiques. Cette contribution vise, en effet, :
amliorer les processus de soins ;
mettre en place les moyens de lamlioration des pratiques lhpital ;
introduire les outils de la dmarche qualit ;
disposer des indicateurs de pilotage de la sant hospitalire.
Le travail prsent ici est structur squentiellement de la manire suivante :
motivations et objectifs du projet SIMENS ;
analyse et spcification des besoins ;
tat de lart des systmes dinformation hospitalier (SIH) ;
dfinition des spcifications fonctionnelles du systme ;
conception de larchitecture du systme ;
conception de larchitecture de lapplication ;
conclusion gnrale.
13


III. Motivations et objectifs du projet SIMENS
Le systme dinformation constitue un facteur non ngligeable dune meilleure gestion
hospitalire (notamment en termes de qualit de service rendu au patient).
C'est conscient de cela que le projet SIMENS a t mis sur pied, pour mette en uvre un
systme d'information mdicalis au niveau national. En effet, un tel systme permettra didentifier
de manire unique un patient sur le plan national travers son dossier mdical informatis et de
conserver de manire structure sur ordinateur toute sorte dinformations utiles recueillies pendant
les activits mdicales. Ces informations mdicales pourront tre partages confidentiellement
entre acteurs de la sant, et tre exploites pour des besoins dalerte, de prvention, de suivi et de
contrle de phnomnes pidmiologiques. La gestion de la confidentialit des donnes
personnelles des patients, la structuration de ces informations, la rapidit de leur intgration une
chelle suprieure et leur classification nosologique sont la cl de vote de la russite de ce projet.
Il sera galement indispensable de mmoriser les informations sur les tablissements de sant, le
personnel mdical notamment les spcialistes, les quipements matriels, la localisation
gographique, etc. pour des besoins de recherche dinformation.
L'objectif gnral du projet est donc de contribuer la gestion et la capitalisation de linformation
mdicale au Sngal. Les objectifs spcifiques sont de:
dvelopper un systme dinformation mdical national pour le Sngal;
dvelopper un systme dintgration de donnes mdicales et daide la prise de dcision
pour les autorits sanitaires et politiques.
IV. Analyse et spcification des besoins
Cette toute premire tape de notre processus de dveloppement consiste faire un premier
reprage des besoins fonctionnels en utilisant principalement du texte et des figures montrant le
fonctionnement du systme. Le but tant de cadrer le projet et d'identifier les entits externes qui
vont interagir avec le systme.
Nous commencerons par donner la mthode utiliser pour tudier le domaine dtude,
ensuite nous ferons une prsentation du domaine lui-mme. Puis une spcification dtaille des
14


besoins est faite, suivie dune tude de lexistant et enfin nous terminons par les rsultats de cette
phase danalyse.
Il est important de noter que dans cette premire phase du projet qui consiste mettre en
place un systme dinformation mdical national pour le Sngal, nous nous limiteront seulement
au niveau rgional. Ainsi cest un SIH qui sera mis en place et nous avons choisi lhpital rgional
de Saint-Louis comme centre daccueil.
1. Mthodologie adopte pour lanalyse du domaine
dtude
Notre analyse du domaine dtude cest fait sous forme dinterviews, de questionnaires et de
visites guides auprs du personnel dans les diffrents services mdicaux et du service
administratif de lhpital.
De ces enqutes ont dcoul un ensemble dinformations et de documents dcrivant le
fonctionnement des services de lhospitalier. Les ressources collectes ntant pas exhaustives,
nous avons quand mme pu en sortir les quelques anomalies dans le systme existant mais aussi
les besoins des diffrents acteurs en ce qui concerne la mise en place dun systme informatique
qui pourra les aider dans certaines tches quotidiennes.
2. Prsentation du domaine dtude
2.1 Historique du domaine dtude
Lhpital de Saint-Louis est hrit du systme colonial. En effet aprs linstallation
dfinitive des franais en 1659 sur lle de Saint-Louis, une ordonnance royale de 1681, est
lorigine de la construction des hpitaux dans les colonies franaises en gnral. Son article 6 est
lorigine de la cration de lHpital de Saint-Louis. Il ntait pas prvu dy admettre les
autochtones mais dy recevoir des officiers et soldats. Cest en 1903 quil devient un hpital lac.
En 1927, il y a eu une fusion entre lhpital militaire et lhospice civil qui se trouvait la pointe
Sud. Cest par la suite que lhpital militaire changea de nom pour devenir lhpital colonial en
1928. Avec lindpendance en 1960, la rgion sera rige en Unit Rgionale mdicale, lhpital
prend lappellation dHpital Rgional. Il englobe: Dagana, Podor et Matam. Cest en 1999 quil
devient une Centre Hospitalier Rgional avec la rforme hospitalire et depuis la loi 98-08 du 12
fvrier 1998 et par le dcret N 98-856 du 27 Aot 1998 le Centre Hospitalier Rgional de Saint-
Louis est devenu Etablissement Public de Sant (EPS) pour une prise en charge correcte des enjeux
de la rforme. En 2006, la cellule informatique a mis en place une application informatique
SENHOSPI pour le systme dinformation de gestion et mdicale et durant cette mme anne le
15


Centre dAccueil Polyvalent a t construit avec une chambre, sept suites une salle de confrence,
un bureau et un office.
Au 31 dcembre 2009, lhpital a une capacit daccueil de deux cent soixante-dix (270) lits dont
deux cent vingt-neuf (229) lits fonctionnels et il compte trois cent trente-cinq (335) agents dont
cent sept (107) agents tatiques rpartis dans les diffrents services [2].

Tout tablissement public de sant hospitalier doit assurer :
Une mission de service public: qui permet toutes les populations un accs quitable aux
soins de qualit ;
Une mission spcifique qui tourne autour :
o du traitement des malades et de la prvention de certaines maladies ;
o du dveloppement des Ressources Humaines par la formation ;
o de la recherche et de la vulgarisation de ses rsultats dans le domaine de la sant.
Ces Missions sont oprationnalises par des projets de service.
2.2 Description des acteurs et leurs rles

Nous allons identifier les diffrents acteurs et les fonctions quils peuvent effectuer :
Patient: consulter son dossier ou la date de son rendez-vous, acheter des mdicaments,
demander des renseignements;
Anesthsiste: faire des diagnostics, prescrire des mdicaments, fixer des rendez-vous, faire
une demande dexamen/analyse ou une radio, consulter le rsultat des examens dun patient
et le valider, faire hospitaliser un patient, consulter son courrier et son calendrier;
Mdecin: faire des diagnostics, prescrire des mdicaments, fixer des rendez-vous, faire une
demande dexamen/analyse ou une radio, consulter le rsultat des examens dun patient et
le valider, faire hospitaliser un patient, consulter son courrier et son calendrier;
Infirmier: suivre les prescriptions des mdecins, appliquer les soins aux patients
hospitaliss, surveillance et compte rendu de ltat du malade;
Laborantin: faire des analyses/examens et le valider, envoyer rsultats;
Chirurgien: consulter son calendrier dopration de la semaine, effectuer une opration;
Radiologue: faire une radio, envoyer rsultat;
Secrtaire mdicale: grer le calendrier des mdecins;
Pharmacien: vendre des mdicaments, faire une demande en cas datteinte de seuil de
stock;
Caissier: grer la facturation
Personnel administratif: grer les ressources de lhpital (personnel mdical,
financement, consommables, etc.);
16


Maintenancier: rparer les matriels dfectueux, effectuer une demande en cas de
manque;
rceptionniste: orienter les patients et les visiteurs;
informaticien: administrer le parc informatique et les applications;
archiviste: grer les archivages;
ambulancier: transporter les patients;
service mdico-lgal: conserver les morts;
dlgu de ltat civil: dclarer les naissances et les dcs.
2.3 Description des services et leurs fonctions
Lhpital compte en tout 36 services qui ont chacun une activit spcifique :
Pharmacie : distribution de mdicaments et consommables
Laboratoire : effectue des analyses
Radiologie : effectue des radios
Bloc opratoire : effectue des oprations
Ranimation : hospitalisation des malades tant dans le coma
Pdiatrie : consultation et hospitalisation des enfants gs d1mois 15ans
Urgences centralises : gre les urgences lexception des urgences obsttricales et
pdiatriques
Hmodialyse : traitement des patients atteints dinsuffisance rnale
Mdecine (I et IV) : traitement des pathologies infectieuses
Urologie : traitement des maladies des voies urinaires
Kinsithrapie : traitement des maladies darticulation
Ophtalmologie : traitement des maladies des yeux
Stomatologie : consultation et soins dentaires
Maternit : consultation et hospitalisation des femmes enceintes
Service administratif et finance
Service des soins infirmiers : gestion du personnel paramdical
Facturation : gestion des recettes de lhpital
Maintenance : maintenance prventive et corrective
Archivage : gestion des archives
ORL : consultation ORL (Oto-rhino-laryngologie)
Chirurgie Gnrale et Chirurgie Orthopdique : service dhospitalisation
Polyclinique : traitement de tout genre de maladie
Cardiologie : traitement de la maladie du cur
Psychiatrie : traitement des maladies mentales et troubles psychologiques
Consultation gnrale : consultation pour tout type de maladie
Service Informatique : gre les quipements installs et administre les applications
17


Contrleur de gestion : contrle des recettes et des dpenses
ACP : gre la comptabilit
Service Audite Interne : contrle les recouvrements et dpenses
Division Ressources Humaines : gre le personnel
Service Social : gre les cas sociaux
Service Logistique Qualit : gre lapprovisionnement de produits dentretien de bureau,
de la papeterie, consommables, etc.
Service Restauration : gre la restauration
Service Buanderie : gre tout ce qui est lessive
Service Appareillage Orthopdique : gre la rparation et la fabrication dappareils
permettant lintgration fonctionnelle comme les chaises roulantes, les bquilles, etc.
3. Spcification dtaille des besoins
C'est une tape primordiale au dbut de chaque dmarche de dveloppement logiciel. Elle est
un des rsultats de nos enqutes effectues au sein du CHRSL (services mdicaux et
administratifs). Son but est de veiller au dveloppement adquat du processus logiciel de notre
systme dinformation en accord avec les demandes des futurs utilisateurs. Sa finalit est la
description gnrale des fonctionnalits, les exigences de performance fonctionnelle et technique,
les politiques de scurit.
3.1 Les besoins techniques
Les besoins techniques portent sur les diffrents points suivants : le support de communication
au sein de lhpital, les matriels interconnects, le type de rseau, etc.
La communication du personnel sanitaire au sein de lhpital peut se passer par tlphone et par
courrier lectronique. De ces types de communication ressortent deux moyens : la tlphonie et
linternet. Cela se traduit par le besoin de la mise en place dun rseau intranet qui assure le partage
dinformation au niveau interne mais aussi un rseau extranet pour la communication avec
lextrieur travers lapplication. Le tlphone aussi peut tre utilis pour la communication entre
mdecins, entre mdecin et secrtaire, bref entre les services.
Par intranet on entend un rseau informatique interne qui fournit un accs scuris et contrlable
aux informations, bases de donnes et ressources dune organisation grce aux technologies
ouvertes de lInternet. Par consquent la mise en place dun intranet repose sur une varit de
technologies exploites sur Internet savoir les navigateurs, serveurs, coupe-feu et systmes de
protection par mot de passe. A limage du Web, un Intranet associe des ordinateurs excutant des
logiciels de navigation, des serveurs hbergeant diffrents types de contenus et un rseau reliant
lensemble.
18


Ce qui nous amne un autre point des besoins quest les matriels interconnects. Les
matriels qui doivent tre utiliss au niveau de chaque service avec un nombre suffisant sont des
ordinateurs PC qui serviront de postes clients. Ils peuvent tre des OS de systme Windows/Linux
avec des capacits moyens pour le disque et la RAM. Nous devons aussi mettre en place des
serveurs pour hberger le logiciel applicatif et rpondre aux diffrentes requtes. Ces serveurs
doivent avoir de grands espaces de disques pour pouvoir contenir les donnes mais aussi une
grande RAM pour assurer un temps de rponse acceptable. On choisit de prfrence des
processeurs Dual Core pour ces serveurs et les machines client. Ces matriels sont relis entre eux
par des cbles dans un rseau local Ethernet avec des concentrateurs(Hubs) et/ ou commutateurs
(Switch). On aura ventuellement besoin dimprimantes au niveau de certains postes et
ventuellement accessible travers le rseau mais aussi de modem pour laccs linternet.
Les applications concrtes de lIntranet sont nombreuses:
Fdrer laccs linformation dans lorganisation avec un outil indpendant des systmes
de stockage et dadministration des donnes ;
Cration de services en ligne lusage priv des acteurs ;
Mise en place de ressources permettant de renforcer lefficacit des collaborateurs
(sessions de formation et prsentations sous forme de vido numrises, journaux
lectroniques, dclarations et communications officielles, etc.) ;
Cration dapplications destines tre ensuite accessibles au travers dInternet ;
Constitution de rseaux au moyen doutils interactifs.
Dun autre ct il y a lextranet qui est un rseau qui utilise la technologie internet pour relier
une organisation ses partenaires. Alors que lintranet est uniquement accessible des personnes
de la mme entreprise ou de la mme organisation, un extranet gre plusieurs niveaux daccs pour
des acteurs extrieurs. Cependant, de mme que pour les intranets, le problme principal de
lextranet est la scurit. Mais cela se rgle facilement par lutilisation de firewall qui permet la
protection du rseau interne contre les intrusions du monde extrieur.
Les services offerts par lextranet sont:
La mise disposition dinformations sur lentreprise ;
La mise disposition dun annuaire du personnel ;
Accs aux documentations ;
Echanges de donnes entre collaborateurs ;
Etc.
Parmi les besoins, on peut encore citer lutilisation de routeurs pour filtrer le trafic et
ventuellement un FAI (Fournisseur dAccs Internet) en anglais ISP (Internet Service Provider).




19


3.2 Les besoins fonctionnels
Notre systme doit rpondre certaines exigences. Il doit pouvoir:
rcuprer les informations de chaque entit partir de son matricule pour mettre jour la
base des donnes de l'application ;
insrer des patients et d'autres entits et les orienter vers une salle d'un service particulier ;
modifier ou supprimer les informations d'un patient et des autres entits ;
imprimer des documents comme (bulletin d'admission, billet de salle, certificat de sjour,
dclaration de dcs, etc...) ;
calculer des statistiques: le nombre de nouveau-ns, le nombre de dcs, le nombre
d'accidents, nombre de lits libres, etc.
4. Etude de lexistant
4.1 Sur le plan technique

Lhpital compte au total trois rseaux : le rseau local, le rseau tlmdecine et le rseau
intranet gouvernemental. Il ny a pas de liaison entre ces trois rseaux, chacun fonctionne de
manire autonome.
Le rseau tlmdecine permet la connexion entre lhpital et lhpital Fann de Dakar ainsi
quavec les autres hpitaux qui se trouvent dans dautres localits. Cest un rseau qui est quip
dun routeur et de deux switches.
Le rseau intranet gouvernemental permet la liaison avec les autres structures de lEtat comme
le Ministre de la sant. Ces genres de rseaux sont mis en place pour coordonner les diffrents
tablissements de lEtat. Au niveau de lhpital, ce rseau est juste mis en place mais son
utilisation nest pas encore effectue.
Le rseau local est le rseau qui se trouve au sein de lhpital dans lequel sont interconnects
les diffrents ordinateurs. Ce rseau peut supporter jusqu plus de 200 postes. La topologie
physique est une topologie en toile et la topologie logique cest Ethernet. Les quipements
dinterconnexion sont des switches qui sont branchs en cascade. Il y a des switches actifs
(intelligents) et des switches passifs (non configurable). Tous les appareils sont relis par des
cbles de paires torsades. Dautre part, lhpital compte en tout deux serveurs et sont de marque
HP, ils ont des RAM de 1Go 2Go et des disques durs de 300Go ou au-del. Le systme
dexploitation de ces serveurs est Windows Server 2003 et le processeur est de 1Ghz ou 1.6Ghz.
Cependant il y a des ordinateurs qui sont utiliss comme des serveurs mais ne possdent pas les
caractristiques requises pour les serveurs.
20


Les ordinateurs clients qui sont pour le patrimoine de lhpital sont au nombre de 120 avec
sept portables mais le reste sont des ordinateurs personnels, ce sont les mdecins eux-mmes qui
les ont achets. Tous ces ordinateurs ont des systmes dexploitation qui sont soit Windows XP,
Vista ou Seven. Ils sont obtenus dhabitude sous forme de don venant des autres pays et plus
particulirement de la Chine ; ce qui fait quils peuvent tre de nimporte quelle marque et les
tailles en disque dur et en RAM peuvent varier. Ils ont des processeurs de 1 2Ghz et des RAM
qui peuvent aller jusqu 4Go. Les disques durs aussi sont de tailles diffrentes. Ces machines sont
des fixes (cran plat ou autre) et des portables, elles peuvent tre de la vieille gnration comme
aussi ceux sortis dernirement sur le march.
Lhpital a sa disposition un groupe lectrogne qui permet de faire fonctionner tous ses
appareils en cas de coupure. Cependant il prend quelques secondes avant de sallumer do
lutilisation des onduleurs au niveau de chaque appareil branch pour grer les risques.
Laccs linternet est possible grce un modem qui est obtenu de la SONATEL. Une
machine avec deux cartes rseau est utilise pour servir de passerelles. Elle est branche sur le
modem et sert de liaison entre le rseau local et lextrieur.
Le niveau de connaissance du personnel en informatique nest pas trs lev et pas le mme.
Les secrtaires savent seulement utiliser les logiciels quils manipulent sinon elles nont pas
dautres connaissances en informatique. Pour les mdecins aussi, certains savent manipuls plus
les outils informatiques que dautres. En bref, chacun a son propre niveau de connaissance. Cela
est peut-tre d quil ny a pas de formation en informatique donc chacun se dbrouille comme il
peut.
4.2 Sur le plan fonctionnel

Cette phase dtude nous a permis de classifier les diffrents services au sein du CRHSL.
Nous avons regroup les services en quatre blocs qui sont les suivants :

Service Mdicotechnique :
Pharmacie
Laboratoire
Radiologie
Bloc opratoire
Ranimation
Service Logistique
Maintenance
Buanderie
21


Appareillage Orthopdique
Logistique Qualit
Restauration
Service Informatique
Archivage
Service Orientation :
Scurit

Service Units de Soins :
Pdiatrie
Urgences centralises
Hmodialyse
Mdecine (I et IV)
Urologie
Kinsithrapie
Ophtalmologie
Stomatologie
ORL
Maternit
Chirurgie Gnrale et Chirurgie Orthopdique
Polyclinique
Cardiologie
Psychiatrie
Consultation gnrale

Service Administratif :
Service administratif et finance
Service des soins infirmiers
Facturation
Contrleur de gestion
ACP
Audite Interne
Division Ressources Humaines
Service Social
Il faut aussi noter toujours sur le plan fonctionnel quil existe une application nomme SENHOSPI
qui se trouve au niveau de la Laboratoire. Elle leur permet de faire leur tche quotidienne mme si
22


ce nest pas de manire optimale. Cette application leur permet entre autre de faire lenregistrement
des patients, limpression de rsultats des analyses, etc.
5. Rsultats de la phase danalyse
Pour dtecter les problmes existants, nous avons interrog le personnel de l'hpital rgional
de Saint-Louis lequel nous a cit quelques anomalies. Cependant, pour localiser leur source, nous
nous sommes mis en pratique avec lui et aprs une observation continuelle, nous avons pu recenser
les insuffisances suivantes :
Il existe un rel problme de communication entre les diffrentes entits du CHRSL. La
plupart des messages sont sous forme de circulaires, de lettres de service et le moment entre
la production dun communiqu et sa rception dans un service donn, cela peut prendre
du temps.
Le systme dinformation mdical existant est principalement centr sur le patient. La
plupart des tches passe par le patient. Ceci fait que lon perd quelques fois du temps pour
effectuer une tche.
La traabilit de linformation est trs difficile. Tous les documents sont en papiers, donc
les patients perdent souvent les documents qui leur sont remis. Ceci implique, quelques
fois que le corps mdical a des problmes pour savoir les antcdents des patients.
Linformation mdicale est essentiellement stocke sous forme papier. Ceci rend difficile
la sauvegarde des archives et des donnes collectes du fait que ce type de stockage est
souvent victime des intempries de la nature. Ainsi, le CHRSL ne dispose pas de banque
de donnes fiable sur les patients.
Le systme informatique en place nest utilis principalement que pour la facturation.
Les patients, les visiteurs ne disposent pas dun centre de renseignement et dorientation
qui permet de bien se mouvoir dans le CHRSL.
Nous constatons donc que ces problmes ralentissent considrablement lefficacit des
services destins aux patients. Nous proposons donc de mettre en place un systme dinformation
mdical capable de:
Planifier/ Optimiser efficacement les ressources.
Amliorer la qualit des soins.
Accrotre la productivit des intervenants (Corps mdical, administration, patients)
Nous proposons galement dexploiter et dadapter les rseaux existants pour permettre la prise en
charge de tous les moyens de communication. Ce qui rendra plus fluide le partage de linformation
au sein de lhpital et amliorera les conditions de travail du personnel.
23


V. Etat de lart des SIH
1. Dfinition

Le Systme dInformation Hospitalier (SIH) est un systme permettant un traitement intgr
de linformation, garantissant sa cohrence et son intgration. Linformation, une fois capture,
doit tre disponible en tous lieux, en tous temps, dans des dlais acceptables (dossiers mdicaux,
images,...), sous une forme paramtrable et ne doit pas faire lobjet de ressaisies. Elle doit tre
exprime dans une granulosit suffisamment fine pour tre utile et autoriser des agrgations
ainsi que des associations [3].
Le SIH est compos de deux domaines diffrents :
Les systmes de gestion (qui concernent la gestion des ressources humaines, les affaires
financires et conomiques, la logistique, les achats, mais galement toutes les activits
dites dintendance, savoir la gestion des repas, la gestion de la lingerie, etc.)
Les systmes relatifs la prise en charge du patient (prise en charge administrative,
mdicale et paramdicale) qui concernent le cur de mtier de lhpital : la production de
soins. Ces systmes comprennent toutes les informations ncessaires laccomplissement
des activits du processus de production des soins au patient, de son accueil sa sortie,
ainsi qu la bonne circulation des flux physiques qui servent directement cette production.
2. Principaux enjeux

Dans le cadre de notre dmarche tutore, la mise en place dun SIH permet damliorer
grandement la ralisation des tapes prcdentes qui ncessitent une exploitation des donnes du
terrain. Par consquent, les enjeux dun SIH sorientent autour de deux grands objectifs :
Lamlioration de la qualit des soins :
o Amlioration des communications
o Rduction des dlais dattente
o Matrise des consommables
o Aides la prise de dcision
o Amlioration des connaissances
24


La matrise des cots :
o Rduction des dures de sjours
o Rduction des tches administratives
o Rduction des temps de personnel.
3. Un panorama des Systmes dInformation Hospitaliers existants
3.1. Mediboard
3.1.1 Dfinition
Mediboard [5] est un systme web libre de gestion d'tablissement. Il se dfinit plus
prcisment comme un SIH (Systme d'Information Hospitalier), un PGI (Progiciel de Gestion
Intgr) adapt aux tablissements de sant de toute taille, du simple cabinet de praticien au centre
mdical multi-sites. Il est de plus en plus utilis travers le monde, en particulier la France dont
prs d'un demi-million de dossiers patient sont grs avec.
3.1.2 Fonctionnalits
Mediboard est un systme d'information hospitalier ddi la gestion du dossier patient, la
planification de l'activit de l'tablissement de sant et la gestion de l'activit clinique et librale
des praticiens.
Il fournit les modules suivants :
- Dossier patient administratif et mdical
o Gestion de lidentit des patients
o Moteur de recherche avanc incluant les rsultats proches phontiquement
o Gestion des sjours
o Accueil clinique : admissions et sorties des patients
o Cration de dossier par carte vitale
o Gestion des doublons de dossier
o Gnration de documents bass sur des modles : feuilles d'admissions,
consentements, fiches d'information, ordonnance
25


o Gestion lectronique de documents, tout format
o Gestion des antcdents, allergies
o Systmes d'alerte entre les professionnels de sant et le personnel d'tablissement
- Activits de l'tablissement de sant
o Planning des admissions/sorties du patient l'accueil
o Gestion bloc opratoire
o Planification de l'hospitalisation
o Dossier de soin et circuit du mdicament
o Gestion des repas
o Systme de gestion de la qualit / accrditation
o Vrification du codage des actes et pr-groupage pour exportation
o Tableau de bord de l'activit
- Activits des praticiens / librales
o Prise de rendez-vous de consultation
o Gestion de consultation mdicales, chirurgicales
o Gestion des consultations pr-anesthsiques
o Intgration de la tltransmission de FSE
o Production automatise de courriers, prescription et ordonnance, bas sur des
modles
o Tableaux de bord hebdomadaires et quotidiens
o Gestion comptable de l'activit librale
o Gestion comptable du cabinet mdical
- Activit clinique
o Fiche d'administration lectronique base sur des protocoles
o Planification des plages d'opration
o Planning du bloc opratoire
o Codage direct des actes CCAM en salle, pendant l'intervention
o Production automatis de compte-rendu d'intervention, bas sur modles
o Gestion des dossiers d'anesthsie
- Infrastructure
26


o Accs scuris
o Gestion multi-tablissement
o Gestion des utilisateurs par cabinet/fonction
o Administration avance des droits et permissions utilisateurs
o Traabilit des actions effectues dans le systme : historique par objet et par
utilisateur


Figure 1. Architecture logicielle de Mediboard

3.1.3 Installation
Mediboard peut tre install travers le systme Subversion depuis Sourceforge. Et pour cause,
il nexiste pas pour l'instant de release officiel et package.
Pour accder la toute dernire version de Mediboard, il suffit donc d'utiliser un client SVN avec
la commande suivante :
svn co https://mediboard.svn.sourceforge.net/svnroot/mediboard/trunk mediboard
27


Ensuite, un assistant d'installation web est disponible permettant de vous guider tout au
long de la configuration de votre systme. Cet assistant peut tre utilis depuis votre navigateur:
http://repertoire_racine_mediboard/install/.
3.2. GNU Health
3.2.1 Dfinition
GNU Health [6] est un progiciel libre dans le domaine de la sant, initi en 2008 par Luis Falcn
dans le cadre des activits de l'organisation non-gouvernementale GNU Solidario et officiellement
maintenu par son auteur pour le projet GNU depuis aot 2011. Il est dvelopp en Python et utilise
la plateforme applicative Tryton
1
. Le projet GNU Health s'est vu rcompens, en mars 2012, du
prix du logiciel libre 2011 pour les projets dintrt social. La Promotion de la sant et de la
prvention des maladies est au cur de la conception de GNU Health.
GNU Health propose des fonctionnalits qui couvrent trois aspects :
- un dossier mdical lectronique
- un systme dinformation hospitalier
- un systme dinformation mdical

3.2.2 Fonctionnalits
GNU Health utilise une approche modulaire avec diffrentes fonctionnalits qui peuvent tre
incluses pour rpondre aux besoins des structures de sant.


1
Tryton est une plate-forme applicative de haut-niveau, d'architecture trois tiers, sous licence GPL-3
1
,
crite en Python et utilisant PostgreSQL comme moteur de base de donnes. Cest un fork de TinyERP
(aujourd'hui appel OpenERP)
2
. Il fournit toutes les fonctionnalits ncessaires une plate-forme
applicative complte : persistance des donnes, modularit, gestion des utilisateurs (authentification,
contrle fins des accs aux donnes), workflow et rapports, services web et internationalisation.
Constituant ainsi une plate-forme applicative qui peut tre utilise dans un large ventail de situations.

28


Les modules actuels sont:
- Sant (Health) : Modle de donnes pour des objets tels que des patients, des valuations,
des centres de sant, les maladies, les rendez-vous, les vaccinations et les mdicaments.
- Pdiatrie (pediatrics) : Comprend des modles pour la nonatalogie, la pdiatrie et les
valuations psychosociales (Liste des symptmes pdiatrique - CFP).
- Gyncologie (Gynecology) : Gyncologie, obsttrique, mdecine prventive,
l'information prinatale et post-partum.
- Style de vie (Lifestyle) : L'exercice physique, rgime alimentaire, les toxicomanies,
l'Institut national de l'abus des drogues (NIDA), base de donnes de drogues rcratives,
les cotes Henningfield, la sexualit, les facteurs de risque, la scurit domicile, la scurit
des enfants.
- Gntique (Genetics): Risque hrditaire. Environ 4200 "gnes de maladie" de la NCBI /
GeneCards.
- Laboratoire (Lab): gestion des demandes, cration et valuation des analyses de
laboratoire. Interface avec le systme de gestion de l'information de laboratoire.
- Socio-conomique (Socioeconomics) : Education, occupation, condition de vie, milieu
hostile, travail et prostitution des enfants, entre autres.
- Patient (Inpatient): Hospitalisation du patient, affectation des lits, plans de soins et des
soins infirmiers.
- Chirurgie (Surgery): Check-list Pre-opratoire, procdures, Salle d'opration, Historique
chirurgical du patient.
- Facturation (invoice): Lien avec l'administration financire du centre de sant.
- Calendrier (Calendar) : Ajout des fonctionnalits pour la connexion avec un client
CalDAV, Gestion des rendez-vous.
- Calendrier Patient (Inpatient_calendar): Gestion des calendriers des patients pour la
gestion des hospitalisations et de la gestion des lits.
- QR codes (QR_codes) : Gestion des (QR) Codes pour identification
29




Figure 2. Architecture logicielle de GNU Health
VI. Dfinition des spcifications fonctionnelles du
systme
1. Mthodologie adopte

Le cycle de vie d'un logiciel, c'est dire les diffrentes phases de conception d'un systme
d'informations, doit tenir en compte autant les aspects techniques que communicationnels. Il passe
par l'emploi d'une dmarche qui s'appuie sur un langage de modlisation. Cette dmarche a pour
objectifs de matriser le droulement du projet et donner une meilleure visibilit lutilisateur sur
les rsultats obtenus. Il existe deux approches dans la conception d'un systme : fonctionnelle &
objet.
Dans la premire, le processus de dveloppement est caractris par un processus de type
squentiel organis en phases qui regroupent des tapes dcomposes en tches, la fin d'une
phase correspond la fin de ses tapes.
Dans la deuxime, le processus est itratif dont le dcoupage ne concide pas c'est- -dire
les activits (phases, tapes, tches) se droulent sur plusieurs dimensions.

30


Dans le cadre de notre tude nous avons opt pour l'approche par objet qui assure
l'volution du logiciel et la rutilisation des objets. Pour ce faire nous avons choisi un processus
de dveloppement nomm 2TUP 2 Track Unified Process qui propose le cycle de vie en Y
(voir Figure 3). Le processus 2TUP apporte une rponse aux contraintes de changement continuel
imposes aux systmes d'information de l'entreprise. En ce sens, il renforce le contrle sur les
capacits dvolution et de correction de tels systmes. 2 Track signifient littralement que le
processus suit deux chemins. Il s'agit des chemins fonctionnels et d'architecture technique ,
qui correspondent aux deux axes de changement imposs au systme informatique. Dans le cadre
de notre tude, nous nous intressons seulement dans cette section aux spcifications
fonctionnelles savoir la branche gauche du cycle en Y [7].


Figure 3. Le processus de dveloppement en Y
Nous avons choisi aussi le langage de modlisation UML qui se caractrise par le fait quil
soit un langage formel et normalis. Ses diagrammes vont nous permettre une meilleure
modlisation du systme durant tout le cycle.

Nous nous sommes bass aussi sur le nouveau Framework (Health Metrics Network
Framework [8]) propos par lOrganisation Mondiale de la Sant [9]. Ce Framework propose un
cadre de travail standard utilisable dans la mise en place de systme dinformations mdicales.


31


2. Les composantes fonctionnelles de SIMENS
La construction d'un systme d'information passe invitablement par l'analyse de l'existant.
Il s'agit ici de construire un SI qui va permettre d'viter les problmes cits plus hauts en ce qui
concerne la gestion des donnes sur le patient. Nous avons commenc par analyser ce qui dcoule
des spcifications des besoins qui est pour nous la partie la plus sensible du travail.
A partir de cette architecture, nous proposons les diffrentes composantes de notre systme
dinformation (SIMENS):
Un systme mdical :
Cest le systme de collection dinformations sur le patient en gnral. Ces sous-composants sont
:
Gestion du dossier mdical du patient
Informations personnelles (cf. dos administratif)
Antcdents mdicaux (chirurgies, maladies, allergies, examens effectus,
diagnostics & traitement prcdents.)
Traitements en cours
Gestion des Oprations chirurgicales
Oprations propratoires : consultation auprs de lanesthsiste
Programmation des oprations chirurgicales
Historique chirurgicale du patient
Gestions des salles dopration
Gestions des hospitalisations
Gestions des hospitalisations
Gestions des Lits
Plan des soins infirmiers pour le patient
Un systme mdico-technique
Gestion des Laboratoires
Gestion des demandes
Evaluation des analyses (Diagnostic et Transmission)
Gestion de limagerie mdicale (Radiologie)
Gestion des demandes
Evaluation (Diagnostic et Transmission)
Gestion de la pharmacie
Gestion du stock
Gestion des ventes (IB)

32


Un systme mdico-administratif
Gestion du dossier administratif du patient
Gestion de la facturation
Gestion des rendez-vous mdicaux
Gestion du personnel mdical
Gestion des naissances et des dcs
Gestion du courrier interne
3. Conception dtaille des fonctionnalits
3.1. Diagramme des cas dutilisations

Le diagramme des cas dutilisations dfinit un ensemble doprations dun systme ou dun sous-
systme tel quun utilisateur le voit de lextrieur. Il capture le comportement du systme. Cette vision
oriente utilisateur nous permet donc dexprimer les besoins des utilisateurs.
Nous prsentons SIMENS en trois diagrammes de cas dutilisation, suivant les sous composants que
nous avons :
3.1.1 Le Systme mdical

Figure 4. Diagramme de cas d'utilisations du Systme mdical
33


3.1.2 Le Systme mdico-technique


3.1.3 Le Systme mdico-administratif

Figure 5. Diagramme de cas d'utilisations du Systme mdicotechnique
Figure 6. Diagramme de cas d'utilisations du Systme mdico-administratif
34


Cette reprsentation dcrit de manire exhaustive une partie des exigences fonctionnelles
du systme. Nous prsentons ci-dessous un tableau rcapitulatif des spcifications fonctionnelles:
Domaine dactivits Processus/fonctionnalits Acteurs/Utilisateurs
Mdical Enregistrement/Cration dun dossier patient
Enregistrement dun processus particulier du
patient (traitement, consultation)
Suivi du plan de traitement et des prescriptions
Enregistrement des naissances
Enregistrement des dcs
Classification des maladies (rapport)
Mdecin, Infirmier
Chef de service
Surveillant de service
Secrtaire mdical
Chirurgie Programmer une opration
Consulter le calendrier des oprations
Chirurgien
Anesthsiste
Secrtaire mdical
Hospitalisations Hospitaliser un patient
Consulter/mettre jour la fiche dhospitalisation
dun patient
Suivre les recommandations du mdecin
Mdecin ,Infirmier
Chef de service
Surveillant de service
Secrtaire mdical
Laboratoire Collecte et Enregistrement des analyses/spcimen
(demande danalyses et stockages)
Dtermination des Rsultats
Association dun rsultat un patient
Validation des rsultats (Diagnostique)
Classification des maladies
Laborantin
Chef de Laboratoire
Pharmacie Surveillance du stock central et de la chaine de
distribution (destin lhpital)
Surveillance du stock des ventes
Suivi du plan de traitement et des prescriptions
Pharmacien
Ressources
Humaines
Enregistrement du personnel
Suivi du personnel mdical
Gestion des priorits (recrutements, formations)
Gestion de la paie
Directeur des
ressources humaines
Etat Civil Enregistrement des naissances
Enregistrement des dcs
Classification des naissances
Classification des dcs
Services administratif
hospitalier
Service de ltat civil
Finance Gestion de la facturation du patient
Gestion/Suivi du budget et des subventions
Service financier
Tableau 1. Conception dtaille des fonctionnalits du systme

35


3.2 Diagramme des squences des diffrentes fonctionnalits

La spcification des cas dutilisations du systme (diffrentes fonctionnalits) conduit
directement expliquer le fonctionnement de chacune delles. Les diagrammes de squences nous
permettent de voir, pour un cas dutilisations prcis, les diffrents messages changs entre acteurs
suivant un ordre chronologique.
Nous prsentons dans ce prsent rapport que les diagrammes de squences les plus significatifs
de notre systme dinformation.

3.2.1 Authentification



Figure 7. Diagramme de squence Authentification

36








Tableau 2. Description Squence Authentification




Nom diagramme
Authentification Version 0.1
Domaine fonctionnel Systme mdical
Rsum Afin daccder aux ressources de SIMENS, lutilisateur devra
dabord sidentifier
Acteurs Tous les acteurs
vt dclencheur Besoin dexcuter une tche quelconque dans SIMENS
Description Une interface d'authentification est prsente l'utilisateur. Celui-ci
saisit son identifiant ainsi que son mot de passe, puis valide. Il est
reconnu ainsi par le systme qui affiche la page demande.
Prconditions L'utilisateur doit disposer d'un identifiant ainsi qu'un mot de passe
Exceptions L'identifiant ne doit pas tre vide.
Le mot de passe ne doit pas tre vide. Il est compos de six
lettres et d'un chiffre au minimum
L'utilisateur doit entrer un identifiant et un mot de passe valides:
il doit y avoir une correspondance de l'identifiant et le mot de passe
entrs dans la base de donnes.
Post-conditions

Selon son rle et son niveau daccs, le systme charge la page
correspondante.
tape # Actions acteur (vt. Externe) Rponse systme
1. Lutilisateur saisit un
Identifiant et son mot de passe

2. vrifie lexistence de
lutilisateur
3. charge linterface de lutilisateur
4. FIN
Scnarios alternatifs
tape # Action alternative acteur Rponse alternative systme
1. Lutilisateur nexiste pas ou le
mot de passe est incorrect.
GOTO 1.
37







3.2.2 Identifier un patient


Nom diagramme Identifier le patient Version 0.1
Domaine fonctionnel Systme mdical
Rsum Avant de raliser une quelconque tche sur le patient, l'utilisateur,
en loccurrence le mdecin, est tenu de vrifier d'abord dans la
base de donnes si le patient en question s'y trouve.
Acteurs
Mdecin, Infirmier, Chef de service, Surveillant de service, Secrtaire
mdical
vt dclencheur Besoin dexcuter une tache quelconque concernant le patient
Description Une interface de recherche du patient est prsente au mdecin qui
saisit l'identifiant du patient puis valide. Ce dernier est ainsi
reconnu par le systme qui affiche l'ensemble des informations le
concernant
Prconditions E excuter la squence Authentification.
Exceptions Si l'identifiant n'existe pas dans la base de donnes, une
exception est leve.
Post-conditions Affichage des informations concernant le patient
Figure 8. Diagramme de squence Identifier un patient
38


tape # Actions acteur (vt. Externe) Rponse systme
1. Demande didentification
SIMENS: Lutilisateur saisit
l'identifiant du patient

2. vrifie lexistence du patient
4. FIN
Scnarios alternatifs
tape # Action alternative acteur Rponse alternative systme
1. Le patient nexiste pas ou
l'identifiant est incorrecte.
GOTO 1.

Tableau 3. Description Squence Identifier patient

3.2.3 Crer un dossier patient
39






Nom Crer dossier patient Version 0.1
Domaine
fonctionnel
Gestion mdicale
Rsum On cre un dossier patient pour la premire fois en saisissant les
donnes personnelles de base. Un nouveau patient est prsent avec un
dossier mdical
Acteurs Secrtaire mdical, Rceptionniste
vt dclencheur Un patient se prsente lhpital pour la premire fois
Figure 9. Diagramme de squence Crer un dossier patient
40


Description Une interface est prsente lutilisateur qui lui permet de saisir les
informations dindentification du nouveau patient (CNI, nom, prnoms,
etc.). Le systme vrifie si ce dernier nexiste pas dj, sinon il lui cre
un nouveau dossier. Lutilisateur peut ensuite complter le dossier avec
des informations complmentaires (dossier mdical si dj la
disposition du patient).
Prconditions Lagent est dj authentifi
Post-conditions

Un dossier du patient est cr dans le systme
Les donnes de base : identit, dossier mdical (mdecin
traitant, antcdents mdicaux si existant)
tape # Actions acteur (vt. Externe) Rponse systme
1. Lagent soumet le nom, prnom,
date et lieu de naissance et le CIN
ou le numro identifiant

2. valide les informations et vrifie
lexistence du dossier patient
3. cre un nouveau dossier patient
avec les donnes
4. Lagent saisit les infos
supplmentaires (adresse,
situation, antcdents mdicaux)

5. enregistre les donnes du patient
6. FIN
Scnarios alternatifs
tape # Actions alternative acteur Rponse alternative systme
2. Le patient existe dj, GOTO 6.
3. Informations saisies sont
incorrectes

Tableau 4. Description Squence Crer Dossier patient
3.2.4 Consulter un dossier mdical
41




Nom Consulter un dossier patient Version 0.1
Domaine fonctionnel Gestion mdicale
Rsum On accde un dossier patient par son numro didentification.
Cest un prrequis pour les autres fonctionnalits ddition ou de
consultation.
Acteurs Secrtaire mdical, Mdecin, Infirmier, Patient
vt dclencheur Besoin daccder au dossier patient
Description
Pr-conditions Lagent est dj authentifi
Post-conditions Le dossier du patient est charg
Le dossier prt en dition (en fonction de lutilisateur)
tape # Actions acteur (vt.
Externe)
Rponse systme
Figure 10. Diagramme de squence Consulter un dossier mdical
42


1.

Lagent saisit le numro
didentification

2. Le systme vrifie le numro
didentification
3. Le systme charge le dossier du
patient
4. FIN
Scnarios alternatifs
Step # Action alternative acteur Rponse alternative systme
2. Le numro didentification
nexiste pas, GOTO 1.

Tableau 5. Description Squence Consulter un dossier mdical
3.2.5 Faire un enregistrement mdical



Figure 11. Diagramme de squence Faire un enregistrement mdical
43


Nom Faire un enregistrement
mdical
Version 0.1
Domaine fonctionnel Gestion mdicale
Rsum Lagent veut enregistrer un acte mdical, il sagit : dune
consultation, un traitement effectu etc.
Acteurs Secrtaire mdical, Mdecin, Infirmier
vt dclencheur Besoin daccder au dossier patient
Description
Pr conditions Lagent est dj authentifi
Le dossier du patient est charg / prt en dition
Post conditions

Lacte mdical est enregistr dans le dossier du patient
tape # Actions acteur (vt.
Externe)
Rponse systme
1.

On saisit lenregistrement
mdical

2. Le systme les systmes enregistre les
donnes dans la base
3. Le systme affiche les informations
mises jour.
4. FIN
Scnarios alternatifs
tape # Action alternative
acteur
Rponse alternative systme

Tableau 6. Description Squence Faire un enregistrement mdical







44


3.2.6 Faire une prescription mdicale

Nom Faire une prescription
mdicale
Version 0.1
Domaine fonctionnel Gestion mdicale
Rsum Le mdecin veut enregistrer une prescription mdicale : une
ordonnance mdicale que le patient doit acheter.
Acteurs Mdecin
vt dclencheur Besoin daccder au dossier patient
Description
Pr conditions Lagent est dj authentifi
Le dossier du patient est charg / prt en dition
Post-conditions

Lordonnance est enregistre dans le dossier du patient
Lordonnance peut tre imprime par le mdecin,
linfirmier ou le secrtaire mdical
tape # Actions acteur (vt. Externe) Rponse systme

Figure 12. Diagramme de squence Faire une prescription mdicale
45


1.

On saisit lenregistrement mdical
(mdicaments prescrits)

2. Le systme enregistre les donnes
dans la base (date, le ID du mdecin
qui prescrit, les mdicaments).
3. Le systme affiche les informations
mises jour.
4. FIN
Scnarios alternatifs
tape # Action alternative acteur Rponse alternative systme

Tableau 7. Description Squence Faire une prescription mdicale

3.2.7 Hospitaliser un patient


Figure 13. Diagramme de squence Hospitaliser un patient
46


Nom Hospitaliser un patient Version 0.1
Domaine fonctionnel Gestion mdicale
Rsum Le mdecin veut hospitaliser un patient. Il vrifie dabord sil y a
une disponibilit de lit dans le service o il veut interner le patient.
Acteurs Mdecin
vt dclencheur Besoin dinterner un patient
Description
Pr conditions Lagent est dj authentifi
Le dossier du patient est charg / prt en dition
Post conditions

Une fiche dhospitalisation est cre pour le patient
tape # Actions acteur (vt. Externe) Rponse systme
1.

On vrifie la disponibilit de lit dans le
service

2. Le systme notifie de la disponibilit
de lit
3. On cre une fiche dhospitalisation
(Patient, date entre, date de sortie
prvue, infos supplmentaire)
.
4. Le systme enregistre la fiche dans le
dossier du patient
5. Si besoin est, on peut ajouter des
recommandations, un complment
dans la fiche dhospitalisation.

6. Le systme enregistre le message
7. FIN
Scnarios alternatifs
tape # Action alternative acteur Rponse alternative systme
2. Le service ne dispose pas de lit libre,
GOTO 7.

Tableau 8. Description Squence Hospitaliser un patient

47


VII. Conception de larchitecture du systme
1. Architecture systme
1.1 Dfinition
Une architecture de systme ou de l'architecture des systmes est le modle conceptuel qui
dfinit la structure , le comportement , plus les vues d'un systme. Elle est centre sur la
construction de modles dun systme car lon ne saurait raisonner et plus gnralement agir
sur un systme en cours de conception sans description de celui-ci.
Larchitecture des systmes spare typiquement les reprsentations dun systme en deux grandes
catgories qui structurent le rfrentiel de lingnieur, savoir :
Les exigences qui ne sont autres que des conditions logiques qui doivent toujours tre
satisfaites par le systme que lon veut construire (cahier des charges) ;
Les spcifications quon peut dfinir comme un ensemble non ambigu de descriptions du
systme que lon cherche raliser.
Larchitecture des systmes utilise aussi classiquement trois angles danalyse ou visions
qui structurent notamment ce rfrentiel de lingnieur, i.e. les exigences et les spcifications,
savoir :
La vision oprationnelle qui a pour but de dfinir le pourquoi du systme, autrement dit
de prciser ce quoi sert le systme en dcrivant le sur-systme du systme quest son
environnement ;
La vision fonctionnelle qui a pour objectif dexpliciter le fonctionnement logique du
systme ; ce quil fait indpendamment de la faon dont on le ralisera ;
La vision organique qui dfinit la faon dont le systme est concrtement ralis, i.e.
lorganisation et la dynamique de ses composants matriels, logiciels et humains.
Ces trois visions architecturales sont bien entendu replacer dans le contexte du processus de
modlisation systmique o larchitecte de systmes modlise son systme cible laide dun
mcanisme de concrtisation progressive consistant modliser successivement la dimension
oprationnelle, fonctionnelle et enfin organique de son systme 0.

1.2 Type darchitecture systme
Quand on parle darchitecture systme, on distingue principalement deux types. Il sagit du :
poste poste ou "gal gal" (en anglais peer to peer), dans lequel il n'y a pas
d'ordinateur central et chaque ordinateur a un rle similaire ;
"client/serveur", dans lequel un ordinateur central fournit des services rseaux aux
utilisateurs.
En effet, l'environnement client-serveur dsigne un mode de communication travers un
rseau entre plusieurs programmes ou logiciels : l'un, qualifi de client envoie des requtes et
48


l'autre ou les autres, qualifis de serveurs, attendent les requtes des clients et y rpondent. Par
extension, le client dsigne galement lordinateur sur lequel est excut le logiciel client, et le
serveur, l'ordinateur sur lequel est excut le logiciel serveur.
Ce type darchitecture peut prendre trois formes : larchitecture client/serveur classique ou
architecture 2 niveaux (client et serveur), larchitecture 3 niveaux ou 3 tier (client, serveur
dapplication et serveur de donnes) et larchitecture n niveaux qui est une gnralisation des 3
niveaux. Mais parmi les trois le plus utilis cest larchitecture 3 tiers.
Voici une reprsentation possible de ce type darchitecture qui dcompose la partie serveur en
deux : le serveur web qui hberge lapplication et le serveur de donnes qui stocke la base de
donnes.

Figure 14. Architecture Client-Serveur
Le client
Ici le client reprsente lordinateur dun utilisateur du systme. De manire gnrale, cet
ordinateur est muni dun logiciel client qui peut tre un navigateur. Son rle est denvoyer des
requtes au serveur. Dautres modules complmentaires (un interprteur) peuvent aussi tre
installs sur le client pour faciliter laffichage des pages web appeles.
49


Le serveur web
Le serveur web reprsente lordinateur sur lequel est installe lapplication ou le logiciel.
Gnralement le serveur est un ou des ordinateur(s) ddi(s) au logiciel serveur qu'ils abritent, et
dots de capacits suprieures celles des ordinateurs personnels en termes de puissance de calcul,
d'entres-sorties et de connexions rseau. Ils rpondent aux requtes des clients et leur fournissent
les informations dont ils ont besoin.
Le serveur de donnes
Le serveur de donnes hberge la base de donnes que lapplication utilise. Ces donnes
peuvent tre des donnes du systme proprement dit ou des donnes dautres systmes. Son rle
est de fournir lapplication les donnes quil stocke.
2. Description des composants de SIMENS
Le systme est compos de manire gnrale par les lments suivants : les acteurs (internes
et externes), les diffrents services, lapplication proprement dite et les infrastructures matrielles.
Les acteurs
On distingue les acteurs internes des acteurs externes.
On appelle les acteurs internes ceux qui sont internes au systme cest--dire travaillant au sein
mme de lhpital. Il sagit des mdecins, des infirmiers, des secrtaires, du personnel
administratif, des techniciens, des agents du service logistique et du personnel de scurit. Chacun
deux a un rle spcifique jouer dans le systme.
Sagissant des acteurs externes ce sont ceux qui ne sont pas dans lhpital mais
interviennent de manire indirecte dans le dveloppement de la structure. Ils peuvent intervenir au
niveau des soins comme par exemple le cas des mdecins appartenant dautres structures
sanitaires mais qui traitent des patients de lhpital. Ils peuvent aussi intervenir dune autre
manire comme dans le domaine du financement de lhpital, de la recherche, de la prvention,
de la sensibilisation, des tudes de cas dpidmie, de partenariat avec dautres structures pas
forcment du mme domaine, etc. ils sagissent du Ministre de la sant et de la prvention, des
structures de sant publique, de lANSD, des partenaires, des ONG pour le dveloppement du
secteur de la sant et de lamlioration de la qualit des soins, etc.
En outre on peut considrer le patient comme tant un acteur externe car faisant pas partie
des acteurs internes lhpital.
Dautre part il peut y avoir dautres acteurs qui sont matriels interagissant avec le
systme ; ils sont soit internes ou externes. Il sagit dautres systmes dinformation qui sont en
interaction avec notre systme ou bien des quipements biomdicaux qui utilisent lapplication.
50


Les services
Un service est une composante du systme dinformation. Lhpital rgional est constitu
de plusieurs services, chacun ayant une activit qui lui est propre. Cependant ces services peuvent
tre regroups en diffrentes classes. Les services constituant une classe ont des activits
similaires. Ainsi nous avons la classe des services de consultation, celle des services
dhospitalisation, celle des services administratifs, celle des services techniques et celle des
services logistiques.
Lapplication
Cest lapplication quon doit mettre en place pour la gestion quotidienne des activits des
services. Cette application doit rpondre aux besoins des diffrents acteurs cits. Elle doit
participer lamlioration de la qualit des soins des patients et centr principalement sur eux. Elle
doit aussi permettre une amlioration des activits de lhpital.
Les infrastructures matrielles
Il sagit des matriels interconnects au niveau de lhpital. Ce sont les ordinateurs
(ordinateurs de bureau, portables,), les serveurs (dapplication, base de donnes, messagerie,
), les concentrateurs, les commutateurs, les routeurs, les imprimantes, les onduleurs, un modem,
les installations tlphoniques, linstallation rseau (rseau cbl, sans fil), les quipements de
communication, ventuellement des scanners, etc.
Schma du systme centr sur lapplication
51




Figure 15. Architecture Globale du systme centre sur l'application
3. Modle et schma de larchitecture
3.1 Diagramme des flux dinformation entre les services
Ces deux figures reprsentent le diagramme des flux dinformation entre les diffrents services.
Dune part tant donn que les services sont trs nombreux et ne pouvant pas figur dans un seul
diagramme, nous les avons dpartag en deux par mesure de clart. Dautre part certains services
ne figurent pas dans les diagrammes parce que nayant pas beaucoup dinfluence en terme
dinteraction avec les autres services.
52



Figure 16 Diagramme de flux d'informations entre les services (1)
53




Figure 17. Diagramme de flux d'informations entre les services (2)
3.2 Diagramme dinteraction entre patient et les diffrents services (centre
sur le patient)
Nous avons pu ainsi faire une description architecturale du flux dinformations circulant
dans le centre hospitalier travers le patient.
54



Figure 18. Flux d'informations centr sur le patient

1. le patient demande des renseignements au niveau du service dorientation
2. en retour le patient est orient vers la facturation
3. il achte un ticket pour la consultation
4. en retour on lui fournit un reu
5. cette tape concerne la consultation et les diagnostics qui sont effectus sur le patient
6. aprs la consultation, le patient peut faire des examens ou analyses ou bien tre hospitalis
(intervention chirurgicale, surveillance ranimation)
7. retour des rsultats danalyses qui taient effectus dans ltape (6)
8. cette tape, le patient suit son traitement (achat de mdicaments,)
9. les dossiers des patients sont envoys larchivage aprs 1an.
10. Dans cette tape nous avons regroup tout ce qui touche au transport (ambulance,
morgue).



55


4. Stratgies de performance et de scurit du rseau
En effet, toute entreprise ouvrant son rseau sur le Net encourt effectivement de nombreux risques,
parmi lesquels:
laccs des personnes non-autorises aux informations ou au systme ;
des dommages causs, volontairement ou non, par un utilisateur ;
une attaque de virus ;
linscurit des changes de donnes ;
le bruitage intempestif par messages commerciaux, ou de toutes sortes
Plutt que davoir scuriser chaque ordinateur connect au rseau, la premire solution consiste
installer un firewall (traduction littrale: mur pare-feu) qui filtre tout trafic indsirable.
Aujourdhui le firewall est davantage un concept quun service rellement organis, aussi loffre
est trs varie, depuis de simples routeurs, qui filtrent des paquets TCP/IP, jusqu des stations de
travail bloquant tout le trafic, pour nenvoyer que des copies du trafic autoris. La seconde solution
consiste encrypter les informations changes sur le rseau.
Dautre part on peut citer comme mesure de scurit et stratgie de performance les points suivants
0:
Remplacer tous les quipements passifs par des quipements actifs pour diminuer le risque
dintrus ;
Selon les besoins en terme de bande passante et de dbit utiliser un systme de cblage
adquat ;
Prvoir lutilisation des imprimantes rseaux, o la configuration est gre par
ladministrateur rseau, et o lattribution daccs est selon le paramtre IP de limprimante
et non dun PC ;
Spcifier un local protg et bien amnag comme salle informatique et placer un
climatiseur dans le local o se trouve larmoire informatique ;
Pour viter les dgts qui peuvent tre caus par leau, il est conseill dutiliser des tubes
isols pour le cblage dalimentation, ainsi que pour le cblage rseaux ;
Pour viter les dgts qui peuvent tre caus par le feu, il faut viter le stockage de produits
inflammables dans le bureau ou se trouve le matriel informatique et vrifier rgulirement
les circuits lectriques ;
De mme pour les dgts dlectricit, il faut brancher les onduleurs avec tous les
quipements informatiques, afin de commander proprement lextinction de donnes en cas
de coupure de courant,
Pour ce qui est des systmes de fichiers au niveau des postes utilisateurs, il est plus
bnfique de rinstaller les postes en FAT par le systme de fichiers en NTFS qui garantit
une scurit au niveau des fichiers et dossiers ainsi quun cryptage de ces derniers ;
Il faut appliquer une sparation physique du rseau local en utilisant les commutateurs
entre les quipements interconnects selon le degr de confidentialit ;
56


Utiliser un serveur DHCP pour lattribution des adresses IP des stations de travail ;
Avoir au moins deux sessions pour chaque poste, une pour lutilisateur avec privilge
restreint de prfrence pour ne pas modifier la configuration initiale et la deuxime pour
ladministrateur qui est le seul pouvoir modifier les paramtres de base ;
Une authentification par Login et Mot de passe doit tre obligatoire. Ladministrateur doit
respecter les exigences de la stratgie de mot de passe savoir :
o Dure limite de la conservation de lhistorique
o Dure de vie maximale
o Dure de vie minimale
o Exigence de complexit
o Longueur min
o Cryptage
Adopter la squence de dmarrage Disque dur, Disquette/CDROM pour viter quun intrus
obtenant laccs physique dun poste puisse effectuer le lancement dun systme
dexploitation pour mener ces attaques ;
Il faut reconfigurer le programme antivirus convenablement pour quelques postes afin
davoir une protection fiable, une mise jour automatique et un scan rgulier ;
Implanter un systme de dtection dintrusion scuris comme le NIDS (Network
Intrusion Dtection System) ou HIDS (Host Intrusion Dtection System) ;
Bien administrer le partage et laccs aux fichiers en utilisant lannuaire Active directory
pour bien prserver les droits daccs et centraliser la gestion des ressources ;
La solution antivirale qui consiste installer un serveur antivirus sur le rseau, et de
dployer sur chaque machine le client associ. Une telle solution permet de centraliser la
tche dadministration : mise jour des fichiers de signature et dploiement
automatiquement sur les postes clients ;
Le serveur de mise jour : par exemple Microsoft software update services (SUS) qui
est un maillon essentiel dans la nouvelle politique de scurit de Microsoft.
VIII. Conception de larchitecture de lapplication
1. Architecture de lapplication
1.1. Dfinition
La dfinition de l'architecture, en fonction des besoins et objectifs d'une entreprise, est le
premier pas dans l'laboration d'une solution. Dans le monde des technologies de l'informatique et
des tlcommunications, le terme architecture dfinit la fois les directions prendre pour la
57


ralisation de projets court, moyen ou long terme, la structure gnrale des solutions mettre en
uvre ainsi que le cadre des travaux raliser.
De manire gnrale, on distingue les styles architecturaux suivants [12] :
Architecture en appels et retours ;
Architecture en couches ;
Architecture centre sur les donnes ;
Architecture en flots de donnes ;
Architecture oriente objet ;
Architecture orient agents ;
Architecture base de composants.
Ainsi tous les modles darchitecture existants appartiennent lune de ces styles ci-dessus. Mais
les plus reconnus sont les suivants :
larchitecture MVC (Modle-Vue-Contrleur) ;
larchitecture oriente services (SOA);
larchitecture multi-tiers (2-tiers, 3-tiers, n-tiers).
1.2. Les diffrents types darchitectures logicielles

1.2.1. Description du Modle MVC

Larchitecture MVC fait partie des modles darchitecture qui organise le code en sparant les
donnes de leur traitement et prsentation. On obtient ainsi trois parties fondamentales qui sont :
le modle, la vue et le contrleur.
o Le Modle reprsente les donnes de l'application gnralement stockes dans une base
de donnes ;
o la Vue correspond l'IHM (Interface Homme Machine) ;
o le Contrleur assure les changes entre la vue et le modle notamment grce des
composants mtiers.
En plus de diviser lapplication en trois types de composants, la conception MVC dfinit
aussi les interactions entre eux. On distingue le modle MVC de type 1 (figure1) du modle
MVC de type 2(figure2) qui est une volution du premier 0.

58



Figure 19. Schma de type 1 avec la prsence de plusieurs servlets

Dans ce modle, chaque requte est traite par un contrleur sous la forme d'une servlet.
Celle-ci traite la requte, fait appel aux lments du modle si ncessaire et redirige la requte vers
une JSP qui se charge de prsenter la rponse l'utilisateur.

Figure 20. Modle de type 2 avec une seule servlet
59


Le modle MVC 2 est donc une volution du modle 1 : une unique servlet fait office de
contrleur et gre toutes les requtes traiter en fonction d'un paramtrage gnralement sous la
forme d'un fichier au format XML.
Avantages du modle
Un avantage apport par ce modle est la clart de l'architecture qu'il impose. Cela simplifie la
tche du dveloppeur qui tenterait d'effectuer une maintenance ou une amlioration sur le projet.
En effet, la modification des traitements ne change en rien la vue. Par exemple on peut passer d'une
base de donnes de type SQL XML en changeant simplement les traitements d'interaction avec
la base, et les vues ne s'en trouvent pas affectes.
Ainsi, lutilisation de larchitecture MVC offre plusieurs avantages :
o Fiabilit ;
o Rutilisation et adaptabilit ;
o Cots de dveloppement et dvolution rduits ;
o Dploiement rapide ;
o Maintenance facilit.

1.2.2. Description de larchitecture 3 Tiers :

L'architecture 3-tier (de l'anglais tiers signifiant tage ou niveau) est un modle logique
d'architecture applicative qui vise sparer trs nettement trois couches logicielles au sein d'une
mme application ou systme, modliser et prsenter cette application comme un empilement de
trois couches, tages, niveaux ou strates dont le rle est clairement dfini [15]:
la prsentation des donnes (couche prsentation): correspondant l'affichage, la
restitution sur le poste de travail, le dialogue avec l'utilisateur ;
le traitement mtier des donnes (couche mtier): correspondant la mise en uvre de
l'ensemble des rgles de gestion et de la logique applicative ;
l'accs aux donnes persistantes (couche accs aux donnes) : correspondant aux donnes
qui sont destines tre conserves sur la dure, voire de manire dfinitive.
Dans cette approche, les couches communiquent entre elles au travers d'un modle d'change
, et chacune d'entre elles propose un ensemble de services rendus. Les services d'une couche sont
mis disposition de la couche suprieure. On s'interdit par consquent qu'une couche invoque les
services d'une couche plus basse que la couche immdiatement infrieure ou plus haute que la
couche immdiatement suprieure (chaque couche ne communique qu'avec ses voisins
immdiats).
Le rle de chacune des couches et leur interface de communication tant bien dfinis, les
fonctionnalits de chacune d'entre elles peuvent voluer sans induire de changement dans les autres
couches. Cependant, une nouvelle fonctionnalit de l'application peut avoir des rpercussions dans
plusieurs d'entre elles. Il est donc essentiel de dfinir un modle d'change assez souple, pour
permettre une maintenance aise de l'application.
60


En effet ce modle 3-tiers permet :
allgement du poste de travail client ;
prise en compte de lhtrognit des plates-formes (serveurs, clients, langages,) ;
une introduction de clients dits lgers ;
amlioration de la scurit des donnes avec une suppression du lien entre le client et les
donnes ;
rupture du lien de proprit exclusive entre application et donnes ;
meilleur rpartition de la charge entre diffrents serveurs dapplication.

1.2.3. Description de larchitecture Oriente Services :

Larchitecture oriente service (SOA) [16] est une forme d'architecture de mdiation qui est
un modle d'interaction applicative qui met en uvre des services (composants logiciels) :
avec une forte cohrence interne (par l'utilisation d'un format d'change pivot, le plus
souvent XML) ;
et des couplages externes lches (par l'utilisation d'une couche d'interface interoprable,
le plus souvent un service web WS).
Une architecture oriente service se conforme divers principes de gestion des services influenant
directement le comportement intrinsque dune solution logicielle et le style de sa conception :
Lencapsulation des services.
Le faible couplage des services avec la maintenance dune relation rduisant les
dpendances.
Le contrat de service adhrent un accord de communication, collectivement dfini avec
un ou plusieurs documents de description.
Labstraction des services dissimulant la logique du service lextrieur.
La rutilisation des services partageant la logique entre plusieurs services avec lintention
de promouvoir la rutilisation.
La composition des services.
Lautonomie des services.
Loptimisation des services.
La dcouverte des services depuis leur description extrieure.
En effet, elle reprsente un moyen technique dintgration des divers systmes dinformation
de lentreprise considrant chaque ressource informatique comme un service. Elle constitue une
solution logicielle distribue. Elle propose un mcanisme dchange de messages scuris entre
les systmes dinformations sous-jacents en employant des protocoles de communication
standardiss. Cette approche offre larchitecture une opportunit douverture sur un large ventail
de solution logicielle existante.
61


Le service en tant que tel consiste en une fonction ou fonctionnalit bien dfinie. Cest aussi
un composant autonome qui ne dpend daucun contexte ou service externe. Il respecte les
caractristiques suivantes :
Large granularit
Interface : un service peut implmenter plusieurs interfaces et aussi plusieurs services
peuvent implmenter une interface commune
Localisable
Instance unique
Couplage faible
Synchrone ou asynchrone.

Diffrences entre les architectures MVC, 3-Tier 0

L'architecture trois tiers est un modle en couches, c'est--dire, que chaque couche
communique seulement avec ses couches adjacentes (suprieures et infrieures) et le flux de
contrle traverse le systme de haut en bas; les couches suprieures contrlent les couches
infrieures, c'est--dire, que les couches suprieures sont toujours sources d'interaction (clients)
alors que les couches infrieures ne font que rpondre des requtes (serveurs).
Dans le modle MVC, il est gnralement admis que la vue puisse consulter directement
le modle (lecture) sans passer par le contrleur. Par contre, elle doit ncessairement passer par le
contrleur pour effectuer une modification (criture). Ici, le flux de contrle est invers par rapport
au modle en couche, le contrleur peut alors envoyer des requtes toutes les vues de manire
ce qu'elles se mettent jour.
La couche de prsentation du 3 tier permet donc d'tablir des rgles du type mettre jour
les vues concernant X si Y ou Z sont modifis . Mais ces rgles deviennent rapidement trop
nombreuses et ingrables si les relations logiques sont trop leves. Dans ce cas, un simple
rafrachissement des vues intervalle rgulier permet de surmonter aisment ce problme. Il s'agit
d'ailleurs de la solution la plus rpandue en architecture trois tiers, l'utilisation du MVC tant
moderne et encore marginale.

Les Types de Client [18]

Client lger
Le poste client accde une application situe sur un ordinateur dit serveur via une
interface et un navigateur Web. L'application fonctionne entirement sur le serveur, le poste client
reoit la rponse toute faite la demande (requte) qu'il a formule.



62


Client lourd
Le poste client doit comporter un systme d'exploitation capable d'excuter en local une
partie des traitements. Le traitement de la rponse la requte du client utilisateur va mettre en
uvre un travail combin entre l'ordinateur serveur et le poste client.

Client riche
Une interface graphique plus volue permet de mettre en uvre des fonctionnalits
comparables celles d'un client "lourd". Les traitements sont effectus majoritairement sur le
serveur, la rponse "semi-finie" tant envoye au poste client, o le client "riche" est capable de la
finaliser et de la prsenter.
Il est bon de noter que cette architecture 3-tiers est une gnralisation de celle du 2-tiers car elle
diffre de cette dernire par lajout de la couche mtier.
2. Etude comparative des technologies existantes
2.1. Les Framework

Un Framework est un ensemble d'outils et de composants logiciels organiss conformment
un plan d'architecture et des patterns, l'ensemble formant ou promouvant un squelette de
programme. Il est souvent fourni sous la forme d'une bibliothque logicielle, et accompagn du
plan de l'architecture cible du Framework.
Il permet de faciliter le travail des dveloppeurs et rduit les cots de construction et de
maintenance des programmes. Le contenu du Framework est dict par le type de programme et
larchitecture cible pour lequel il est construit.
On distingue quatre types de Framework [19]:
Framework d'infrastructure systme : pour dvelopper des systmes dexploitation, des
interfaces graphiques, des outils de communication ;
Framework d'intgration intergicielle : pour fdrer des applications htrognes ;
Framework d'entreprise : pour dvelopper des applications spcifiques au secteur
dactivits de lentreprise;
Framework de gestion de contenu : pour la cration, la collecte, le classement, le stockage,
et la publication de biens numriss.
Les principaux avantages de ces Framework sont la rutilisation de leur code, la
standardisation du cycle de vie du logiciel (spcification, dveloppement, maintenance, volution),
ils permettent de formaliser une architecture adapte au besoin de l'entreprise. Ils tirent parti de
l'exprience des dveloppements antrieurs.
63


Voici quelques exemples de Framework avec leurs architectures cibles ainsi que les langages
dans lesquels ils sont crits.

Tableau 9 Les frameworks
2.2. Les langages de programmation

Un langage de programmation est un langage informatique permettant un tre humain
d'crire un Programme (informatique) (le code source) destin tre excut par une machine,
gnralement un ordinateur. Le code source subit une transformation ou une valuation dans une
forme exploitable par la machine, ce qui permet d'obtenir un programme excutable. Les langages
permettent souvent de faire abstraction des mcanismes de bas niveau de la machine, de sorte que
le code source puisse reprsenter une solution telle que comprise ou conue par un tre humain.
(Wikipdia)
Les langages de programmation les plus populaires sont : Java, C#, C++, Delphi, Python, C,
VB.NET, VBA, Visual Basic 6, PHP, Javascript, WinDev, Ruby, PascalPerl.
Les langages prfrs pour la programmation sont [20]:
64



Figure 21. Pourcentage d'utilisation des langages


Les langages serveurs prfrs pour le web sont :

Figure 22. Pourcentage d'utilisation des langages serveur

De ce classement il ressort que les langages PHP et Java sont les plus utiliss dans les
dveloppements web.


65


2.3. les Systmes de Gestion de Base de Donnes

On distingue deux types de SGBD : ceux qui sont gratuits et ceux qui sont destins aux
professionnels. Ces derniers sont produits par des diteurs tablis depuis de longues dates alors
que les premiers rsultent du fruit de travail de communauts de dveloppeurs ou de nouvelles
socits.
Dans cette premire catgorie nous rangerons : MySQL, PostgreSQL, OpenIngres, Cloudscape et
bien d'autres.
Et la seconde catgorie concerne : DB2-UDB, Oracle, Sybase ASE et Microsoft SQL Server.
Sur le march on remarque quOracle occupe la premire place pour ce qui est des licences
commerciales avec une part de 45%, suivi de DB2 avec 21%, puis Microsoft SQL Server 19%,
ensuite Sybase avec 3.5% et Teradata 3.3%. Et dans le monde de lopen Source, MySQL prend le
devant, suivi de PostgreSQL et Ingres 0.
Mais le choix effectu sur ces diffrents SGBD doit prendre en compte les lments suivants :
la politique de lentreprise concernant ses fournisseurs ;
la politique scuritaire ;
le budget disposition ;
les comptences dj acquises en terme de dveloppement et d'administration, et au besoin
le prix de la formation ;
le systme d'exploitation hbergeant ;
les architectures logicielles et matrielles ;
etc.
Viendront ensuite les points tels que :
la richesse fonctionnelle du SGBD ;
les ressources (disques, mmoire, CPU, Transactions par secondes, nombre de connexions
simultanes) ;
l'attente quon a vis--vis du support technique ;
le type d'accs aux donnes (OLTP, dcisionnelle, Reporting, mixte) ;
etc.

Voici un tableau comparatif des diffrents SGBD [23]:


66




Tableau 10 Tableau comparatif des SGBD

2.4. Les Environnements de Dveloppement Intgr (EDI)

Un Environnement de Dveloppement Intgr, ou IDE 0 (Integrated Development
Environnements) est un outil pour faciliter la tche du programmeur dans la ralisation
d'applications ou l'criture de scripts. Les EDI ne doivent pas tre confondus avec les Framework
: ils ont vocation fournir un environnement de travail convivial et intgr (l'atelier) facilitant la
mise en uvre des bibliothques logicielles (l'outil proprement dit) offertes par les Framework.
Les EDI peuvent tre ddis un langage de programmation ou tre multi-langages. Dans le
second cas l'diteur adapte la coloration syntaxique au langage, en fonction de l'extension des
fichiers ou du choix de l'utilisateur. Un EDI comporte au moins:
Une interface graphique : elle permet notamment de slectionner les fichiers, dfinir les
options, lancer les oprations ;
Un diteur de code source ;
67


Un compilateur ;
Un diteur de liens ;
Un constructeur (outil make intgr). Il passe les commandes au compilateur et l'diteur
de lien avec les fichiers sources ou les modules objets en paramtres ;
Un outil de dbogage.

Les IDE gnralistes :
Eclipse : originellement un environnement ddi Java mais grce ses extensions il
permet de dvelopper avec un trs grand nombre de langages et technologies ;
Kdevelop : initialement ddi C++ et Qt, peut grer maintenant Java, Pascal, PHP, Perl,
Python, Ruby et dautres technologies ;
Microsoft Visual Studio : lorigine ddi C++ et Visual basic, est devenu
lenvironnement de rfrence de la plateforme .Net ;
NetBeans : le paquetage officiel inclut le support de C++, Ruby et PHP en plus des
technologies Java ;
PhpDesigner : gre tous les langages internet reconnus et regroupe les outils : html Tidy,
phpDocumentor, XDebug, SVN, etc.

Les IDE spcialiss :
C++ Builder : pour le langage C++
Delphi
Lazarus
Morfik WebOS AppsBuilder : pour application web et application pour PC
WinDev : pour application destine aux PC
4e Dimension : dveloppement et dploiement multiplateforme, intgration des web
services, de XML, ouverture vers Oracle, SQL, interaction avec Ajax, Web 2.0
Makefiles avec les systmes Linux
Emacs sur Linux
Etc.

Liste des IDE gratuits :

Net Bean. Applications Java, PHP, C++. Multiplateformes.
Eclipse. Multiplateformes, ralis en Java.
Kdevelop. Un EDI ddi aux applications en C++ pour l'environnement KDE. Linux.
Visual Studio Express. C++, C#, Basic. Windows.
Aptana. Pour raliser des Applications Web. (Windows/Mac/Linux).
XCode. For MacOs.
68


Dreamweaver
3 Choix des technologies et outils pour le dveloppement
Daprs ltude que nous avons effectue sur ltat de lart des technologies utiliser, nous
rangeons notre application dans le groupe des architectures base de composants. Ainsi nous
projetons dadopter une architecture Client-Serveur pour larchitecture du systme et une
architecture MVC pour lapplication en tant que telle.

Architecture du systme : Client-serveur 3-tiers

Nous adaptons larchitecture client-serveur pour plusieurs raisons :
Toutes les donnes sont centralises sur un seul serveur, ce qui simplifie les contrles de
scurit, l'administration, la mise jour des donnes et des logiciels.
La complexit du traitement et la puissance de calculs sont la charge du ou des serveurs,
les utilisateurs utilisent simplement un client lger sur un ordinateur terminal qui peut tre
simplifi au maximum.
Le modle nous garantit aussi un rseau volutif car il est possible de supprimer ou rajouter
des clients sans perturber le fonctionnement du rseau et sans modification majeure.

Architecture logicielle : le modle MVC:

Le Modle Vue Contrleur (MVC) est une architecture et une mthode de conception
pour le dveloppement d'applications logicielles qui spare le modle de donnes, l'interface
utilisateur et la logique de contrle.
Ce modle d'architecture impose la sparation entre les donnes, les traitements et la prsentation,
ce qui donne trois parties fondamentales dans l'application finale : le modle, la vue et le
contrleur.
Nous avons port notre choix darchitecture logicielle sur le modle MVC qui est plus adquate
pour grer les mises jour. Nous lavons aussi choisi du fait que :
MVC est un motif de conception logiciel souple, qui transforme une application en un
ensemble maintenable, modulaire et rapidement dvelopp.
La sparation de ses couches permet de faire des modifications sur une partie de
lapplication sans affecter les autres.

SGBD: Oracle Database

69


Nous suggrons le SGBD Oracle Database [27]. En effet Oracle est compatible avec les
systmes dexploitation Linux, Windows, Unix, MacOs.
Oracle est un SGBDR optimis pour de grandes bases de donnes. Il est efficace pour lutilisation
dun volume important de donnes (>200Go) et un grand nombre d'utilisateurs (>300).
Lutilisation dOracle Database nous garantit les avantages suivants:
Richesse fonctionnelle
Assistants performants via Oracle Manager Server, possibilit de grer en interne des
tches et des alarmes
Accs aux donnes systme via des vues, bien plus aisment manipulable que des
procdures stockes.
Architecture Multi-Gnrationnelle (MGA)
Services Web, support XML
Compression des donnes et des sauvegardes
Support technique extrmement riche et fourni
Prennit de l'diteur : avec plus de 40% de part de march, ce n'est pas demain qu'Oracle
disparatra.

Langage de programmation: PHP

De notre recherche il ressort deux types de langages : le langage Java et le langage PHP. Par
la suite notre choix sest port sur le langage PHP. Ce choix est motiv par les raisons suivantes:
Le PHP est l'origine un langage purement destin au web ;
Langage populaire do la facilit de trouver des informations sur le net partir des forums,
etc.
Langage facile matriser du fait de sa simplicit ;
Langage facile utiliser avec ses nombreux outils (Wamp Server, PHPEclipse, PHPEdit,
PHPDesigner, etc.) et Framework (Banshee, CakePHP, CakePHP2, CodeIgniter, Fat-Free,
Kohana, Jelix, Solar, Symfony, Yii, Zend Framework, Zend Framework2, etc.).
Avec la parution du PHP5 le langage supporte maintenant les concepts de la programmation-objet
ce qui l'ouvre des ralisations complexes structures et performantes.

Framework
Voici quelques Framework PHP [28]
70




Tableau 11 Prsentation de quelques frameworks PHP

Daprs ces rsultats le Framework PHP le plus utilis est Zend Framework. Notre choix est alors
tourn vers lui dautant plus que son architecture cible est le modle MVC et cest une technologie
libre.

Navigateurs
Nous avons dans le tableau suivant les principaux navigateurs utiliss ainsi que les
environnements sur lesquels ils marchent. Cependant notre but est que notre application marche
sur tous ces navigateurs prsents.
71



Tableau 12 Prsentation de quelques navigateurs web

Environnement de travail : Eclipse

Daprs ces rsultats, Eclipse est lEDI qui est le plus utilis pour le dveloppement web [29].
72




Tableau 13 Prsentation de quelques IDEs

Eclipse est un projet open source l'origine dvelopp par IBM pour ces futurs outils de
dveloppement. Le but est de fournir un outil modulaire capable non seulement de faire du
dveloppement en java mais aussi dans d'autres langages (PHP) et d'autres activits. Cette
polyvalence est lie au dveloppement de modules raliss par la communaut ou des entits
commerciales.
Sa spcificit tenant son architecture totalement dveloppe autour de la notion de plugin: toutes
les fonctionnalits de l'atelier logiciel doivent tre dveloppes en tant que plug-in bti autour de
l'IDE Eclipse Platform.
73


Eclipse recouvre cet effet tout un Framework de dveloppement logiciel fournissant des
briques logicielles. Cest la raison pour laquelle il est prsent dans la littrature tout autant comme
un IDE que comme un Framework.

Logiciel de gestion de versions : Subversion (SVN)
Probablement loutil le plus utilis lheure actuelle. Il est assez simple dutilisation, bien
quil ncessite comme tous les outils du mme type un certain temps dadaptation. Il a lavantage
dtre bien intgr Windows avec le programme TortoiseSVN , l o beaucoup dautres logiciels
sutilisent surtout en ligne de commande dans la console.
Eclipse permet lintgration de Subversion avec deux plugin au choix: Subversive et Subclipse.

Logiciel dintgration de code : Araxis Merge

Cest un outil qui permet de faire une comparaison de fichiers avec une grande prcision en
recherchant des changements ou des diffrences entre eux [30]. Il a :
une interface attrayante et intuitive ;
un grand nombre d'outils utiles pour vous permettre d'effectuer votre tche de la meilleure
faon possible ;
large gamme d'options ;
navigation par onglet ;
trs facile utiliser ;
analyse de virus.

4 Stratgies de performance et de scurit de lapplication

Toute application Web digne de son nom doit avoir une scurit assure de bout en bout en
couvrant lensemble de la solution, partant du principe quune chaine est aussi rsistante que son
maillon le plus faible. Tous les lments de la solution doivent tre pris en considration, depuis
l'utilisateur son poste de travail jusqu' la base de donnes. L'architecture de la solution de
scurit doit couvrir les lments suivants [31]:
authentification: la dtermination de l'identit de l'interlocuteur;
intgrit: l'assurance que l'information stocke ou transmise est inaltre;
confidentialit: la divulgation des informations des personnes ou des systmes;
autorisation: la permission de faire ou d'accder quelque chose;
non-rpudiation: la protection contre la ngation d'une action accomplie;
traabilit: la reconstitution d'vnements;
intrusion: les accs non autoriss;
74


protection physique: la protection contre le vol, les lments naturels (feu, dgts des
eaux, etc.);
gestion: la gestion des procdures de scurit, des ressources humaines et machines
impliques. Cette gestion concerne qui fait quoi, quand, comment et avec quelles
ressources.
Dautant plus que le systme dinformation qui doit tre mis en place est de type hospitalier, cette
scurit est vitale.

Pour identifier chaque utilisateur du systme il faut quil y ait des sessions spcifiques
chacun deux pour quon puisse dire que tel utilisateur a ralis telle chose telle date en utilisant
lapplication. Donc lauthentification doit tre obligatoire.
Pour ce qui est de lintgrit et la confidentialit des donnes, elles sont primordiales dans ce cas
prsent. La confidentialit est assure par la gestion des droits daccs certaines ressources. Ainsi
la dfinition des droits pour chaque type dacteur du systme est ncessaire.
Lintgrit des donnes doit aussi tre assure pour viter les cas daccidents dus la rception de
fausses informations. La responsabilit des acteurs doit tre dfinie pour quen cas de survenance
dvnements non dsireux que cette dernire soit engage. Pour y arriver il faut une bonne
traabilit de linformation mais aussi mettre en place certaines mesures qui devront intervenir
dans ces genres de situation.
Un autre point de la scurit qui est trs important est la lutte contre les intrusions. On recense
diffrentes sortes dattaque sur les applications web [32]:
Interprtation des URLs : attaque sur les parties composant lURL
Mauvais contrle des donnes entres par lutilisateur
Injection de code SQL : consquence directe de mauvais contrle des donnes entres
par lutilisateur
Attaques sur les identifiants de session
Cross Site Scripting consistant attaquer les utilisateurs plutt que lapplication elle-
mme
Autres attaques : dues la mauvaise gestion du contexte utilisateur, manque de
rauthentification, attaques rendus possible par les langages excuts ct client
Ces nombreuses attaques traversant les firewalls ont conduit plusieurs diteurs concevoir des
logiciels de protection des applications Web sintercalant entre Internet et le serveur Web
hbergeant lapplication. Ils agissent ainsi comme des reverse proxies
2
intelligents et
permettent de stopper certains types dattaques.


2
Les reverse proxies sont des filtres applicatifs http utiliss pour la protection dune application
web.
75


Il sagit en particulier des solutions suivantes :
InterDo de Kavado;
AppShield de Sanctum;
RealSentry dAxiliance.

Sagissant de la performance de lapplication cela doit relever de sa capacit rpondre aux
attentes des utilisateurs. Elle implique donc une disponibilit des donnes en temps rel. Pour que
cela puisse tre possible il faut que les serveurs soient quips de grandes capacits et tre en
nombre suffisants pour assurer les demandes. Lutilisation de logiciels au niveau des PC pour
allger le code, diminuer le dlai dattente et faciliter la prsentation doit aussi tre envisage.
Toujours dans ce cadre de performance de lapplication, il faut :
une mise jour effective des donnes en temps rel;
mises jour et sauvegardes des bases de donnes;
des solutions de back-up et solutions temporaires durant les pannes;
l'aide, la communication et la formation pour les utilisateurs;
de la documentation
un systme volutif qui sadapte avec les besoins des utilisateurs
5 Politiques de confidentialit des donnes des patients
Le respect de la vie prive des individus est un droit fondamental. Il exige de protger la
confidentialit des donnes personnelles de sant en toutes circonstances.
Cette confidentialit est couverte par le secret mdical.
Le secret mdical nest pas seulement prvu dans lintrt du patient. Il correspond un
intrt public qui est de garantir des relations de confiance entre le citoyen et le systme de sant.
Ce principe de confiance constitue une valeur fondamentale en soi.

Le patient est tenu davoir, de la part de son praticien professionnel, un dossier de patient
soigneusement tenu jour et conserv en lieu sr. A la demande du patient, le praticien
professionnel ajoute les documents fournis par le patient dans le dossier le concernant.

On propose que chaque patient dispose dune carte sanitaire qui permet son identification
de faon unique.






76


Les obligations du mdecin

Le mdecin peut se servir des dossiers mdicaux pour ses travaux scientifiques, condition
de ne faire paratre dans ses publications, aucun nom ni aucun dtail qui puisse permettre
lidentification des malades par des tiers.
Cette utilisation se fait sous la responsabilit du Chef de Service.
IL doit respecter strictement la confidentialit des donnes. Il ne doit consulter que les
donnes ncessaires lexercice de sa fonction. Il doit veiller la qualit et lexhaustivit des
donnes contenues dans le dossier mdical.
La gestion des droits daccs (cration, modification, validation) est centralise et base
sur une hirarchisation des fonctions selon les comptences et spcialisations de chacun ainsi que
sur une slection des donnes accessibles. La dfinition des droits daccs relve de la
responsabilit de la Direction mdicale.

Cependant le service informatique doit jouer un rle important pour la scurit de ces donnes :

Les Missions du Service informatique

Le Service informatique a pour mission de :
respecter les mmes principes que les utilisateurs. Mme sil y a possibilit daccder aux
donnes confidentielles dun dossier mdical, de par leur activit spcifique, ces donnes
seront cryptes.
mettre en uvre tous les moyens techniques ncessaires afin dassurer de faon permanente
:

La confidentialit des donnes :
Il se prmunit contre toute indiscrtion involontaire ou volontaire et contre toute utilisation
abusive.
Lintgrit des donnes :
Il se prmunit contre toute corruption fortuite ou dlibre.

La scurit physique des donnes
Il se prmunit contre toute perte accidentelle ou intentionnelle.

La traabilit des accs :
Lorsque lapplication le prvoit, il est en mesure dassurer la production dune liste exhaustive des
personnes ayant consult un dossier mdical ainsi que des types daccs aux donnes mdicales
en prcisant sil sagit de cration, modification, consultation, suppression, copie, impression.

Larchivage des donnes :
Il assure, avec des moyens technologiques, larchivage des donnes.

77


La protection des installations informatiques :
Celle-ci comprend par exemple :
o le contrle des voies daccs aux locaux o sont stockes les donnes
o la scurit physique du rseau et des serveurs de mme que des
o supports darchivages des donnes ;
o la protection maximale et actualise des donnes (concernant leur intgrit et
confidentialit) contre les attaques extrieures et intrieures.

La transmission des donnes mdicales vers lextrieur :
Il sassure que lenvoi des donnes lextrieur de lhpital seffectue selon les rgles imposes
par linstitution.
IX. Conclusion gnrale
1. Bilan
Le travail que nous avons prsent dans ce mmoire consistait mettre en place un modle
de SIH en prlude de son implmentation au niveau national, pour ainsi aboutir une utilisation
cohrente et large chelle des systmes dinformation hospitaliers dans nos pays en voie de
dveloppement notamment le Sngal. Pour atteindre ces objectifs nous avons tout dabord dcrit
les axes majeurs et piliers qui constituent un SIH. Se basant sur l'hpital rgional de Saint-Louis,
nous avons ensuite dfini les spcifications autant fonctionnelles que techniques d'un tel systme.
En ce qui concerne la conception, c'est la dmarche 2TUP qui a t la plus correspondante
notre cas en proposant d'analyser et de capter les besoins pour ensuite concevoir une solution sur
le plan technique et fonctionnel.
Dans un cadre plus personnel, nous pouvons dire que notre parcours pour la ralisation de ce
mmoire a t enrichissant. En effet, ce projet nous a permis d'effectuer beaucoup de recherches
mais surtout de mieux connatre l'environnement hospitalier. Il nous a galement apport de
nouvelles connaissances tant mthodiques, organisationnelles que techniques. Aussi, nous
esprons que ce mmoire, support physique du travail qui a t confi notre modeste comptence,
a respect les normes aussi bien dans la forme que dans le fond, et que sa ralisation entire pourra
satisfaire les utilisateurs.
2. Problmes rencontrs
Comme tout projet informatique, la mise en uvre de SIMENS ne sest pas ralise sans
difficult. Notre premier problme tait lacquisition dinformations. Dans certains services, le
personnel mdical restait retissant sur certaines informations quil devait nous transmettre.
Cependant dautres manifestaient leur consentement et leur approbation sur lapplication quon
devait mettre en place et nous avions notre disposition certains exemplaires des papiers utiliss
par les services dans leur fonctionnement. La seconde difficult tait la comprhension de certains
termes qui sont du jargon mdical. Etant des informaticiens de formation, il nous tait difficile de
78


comprendre exactement ce que les mdecins voulaient dire en employant certains termes. De plus
il tait un peu difficile dtudier linteraction qui existe entre les diffrents services car ils sont trs
nombreux et chacun avait besoin de lautre pour fonctionner correctement sauf quelques rares
services qui taient autonomes. Nous avons aussi constat que presque les mmes tches se
rptaient dans les services qui font les mmes activits comme consultation et hospitalisation; de
ce fait on pouvait les classer, ce qui rduira un peu le travail.
Dautres difficults qui taient lies au cadre du travail mais qui ntaient que temporaire, taient
le fait quon travaillait distance pendant les vacances car nous habitons dans des localits
diffrentes. Donc pour regrouper nos travaux il fallait se rencontrer sur Skype ce qui nest pas
facile dautant plus que tout le monde na pas le net. Pour ce qui est de lencadrement, nous navons
pas eu de problme parce que nos encadreurs nous suivaient dans notre travail et faisaient tout
pour nous envoyer les corrections temps. Les conditions aussi taient runies pour avoir un
environnement de travail correct. Nous avons des ordinateurs, une salle de connexion linternet,
deux machines pour servir de test, une imprimante et un vido projecteur.
3. Recommandations
Dune part, pour que la mise en uvre du projet SMENS soit effective, il faut que les
utilisateurs finaux eux mme soient impliqus et manifestent un besoin rel pour lapplication. Et
cela, commencer par le directeur de lhpital ainsi que tout le personnel paramdical; dautre
part, il faut des moyens daccompagnement pour que le projet soit une russite. Les diffrents
services doivent tre imprativement quips dordinateurs de grandes performances; le personnel
devrait tre form sur les diffrents outils informatiques. Il faudrait aussi augmenter le nombre de
serveurs.
En outre, il faut envisager de renforcer le personnel du service informatique pour suivre
et accompagner ce projet mais aussi prendre en charge les quipements qui sont en place.
4. Perspectives

Il sen suit aprs cette phase limplmentation des fonctionnalits de lapplication. Des
tests seront ensuite faits et nous pourrons passer linstallation de lapplication au sein de la
structure daccueil qui est lhpital rgional de Saint-Louis.
Il faut aussi envisager la formation du personnel mdical pour amliorer les comptences
informatiques permettant ainsi de leur faciliter lutilisation de lapplication.
De mme, nous projetons le dploiement de lapplication pour une intgration au niveau national.

79


Bibliographie
[1] BAGAYOKO, C. O. (2010). Mise en place dun Systme dInformation Hospitalier en Afrique.
Mise en place dun Systme dInformation Hospitalier en Afrique.
[2] CHRSL01 : www.hopital-saintlouis.sn
[3] SIHINSA01 : Les systmes dInformation : Dfinition et Enjeux
[4] http://systmh.insa-lyon.fr/pages_html/pages/page_syst_info1.1.html
[5] Mediboard : http://www.mediboard.org/public/tiki-index.php
[6] GNU Health: http://en.wikibooks.org/wiki/GNU_Health
[7] OCTO. (2002). Architectures de Systmes dInformation - Livre Blanc.
[8] WHO. (2008). Health Metrics Network Framework, The Case for a National Health Information
System Architecture ver. 1.4. World Health Organisation.
[9] WHO1. (2008). Guidance for the Health Information Systems (HIS) Strategic Planning Process.
World Health organisation. www.healthmetricsnetwork.org.
Architecture des systmes :
[10] http://www.enseignement.polytechnique.fr/informatique/chaire-systemes-complexes/-
Architecture-des-systemes-.html
Stratgies de performance et de scurit du rseau :
[11] http://pfmh.uvt.rnu.tn/579/1/Audit_et_S%C3%A9curit%C3%A9_Informatique_d%E2%80%99u
n_R%C3%A9seau_Local_.pdf
[12] Les Styles architecturaux : http://fr.wikipedia.org/wiki/Architecture_logicielle
Architecture MVC:
[13] http://fr.wikipedia.org/wiki/Mod%C3%A8le-vue-contr%C3%B4leur
[14] http://www.jmdoudoux.fr/java/dej/chap-frameworks.htm
[15] Architecture 3 tier: http://fr.wikipedia.org/wiki/Architecture_trois_tiers
[16] Architecture SOA: http://fr.wikipedia.org/wiki/Service_Oriented_Architecture
Comparaison 3 tier et MVC:
[17] http://fr.wikipedia.org/wiki/Mod%C3%A8le-Vue-Contr%C3%B4leur
[18] Type de client: http://fr.wikipedia.org/wiki/Client-serveur
[19] Les Framework: http://fr.wikipedia.org/wiki/Framework
[20] Schma langages de programmation : http://general.developpez.com/langages/
Les SGBD :
[21] http://ci.viadeo.com/fr/questions/repondre/?questionId=0021puev7pup0mvv
[22] http://fadace.developpez.com/sgbdcmp/
[23] Tableau comparatif des SGBD :
http://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_base_de_donn%C3%A9es
Les IDE :
[24] http://www.scriptol.fr/programmation/edi.php
[25] http://fr.wikipedia.org/wiki/Environnement_de_d%C3%A9veloppement_int%C3%A9gr%C3%A
9
[26] http://www.wikipedia.com/
80


[27] Oracle : http://fadace.developpez.com/sgbdcmp/
[28] Tableau des frameworks PHP : http://www.developpez.net/forums/d84784/php/bibliotheques-
frameworks/framework-php-utilisez-pourquoi/
Tableau des navigateurs :
[29] Tableau des EDI : http://www.developpez.net/forums/d1185657/webmasters-developpement-
web/outils/edi-utilisez-2012-developpement-web-pourquoi/
[30] Araxis Merge : http://french.eazel.com/lv/group/view/kl35971/Araxis_Merge.htm
[31] Scurit de larchitecture : http://www.awt.be/web/res/index.aspx?page=res,fr,fic,040,003
[32] Solutions des attaques : http://www.ouah.org/chambet.html

Vous aimerez peut-être aussi