1. Introduction:
Dans ce chapitre nous allons présenter la structure hospitalière étudiée et depuis laquelle nous avons Collecté nos informations afin de comprendre le fonctionnement d’un système d’information médicale « SIM ». Nous définirons par la suite le cahier des charges de notre application
2. Présentation l’hôpital étudié :
Établissement : « EPH » Ain Tedles.
Date de création : Mars 1986.
Téléphone :045226072.
Nom du directeur : Mme BougachoucheOudida.
phenix88
3. Supervision de contrôle de l’infrastructure des équipements :
3.1 État de l’infrastructure :
Hôpital officiel en mars 1986.
3.2 Infrastructure (vétuste) :
· Autre dénomination :Hopitale “BellatrècheAdjel”,de Ain Tedeles.catégorie”B”.
· Siège administration :Hopitale de Ain Tedeles.
· Adresse :EPH Ain Tedeles,citéamirabdelkader,Ain Tedeles,27200.
· Email :[email protected].
· Nombre de lits :240 lits.
3.3 Services extra muros :
· Les urgences médico-Chirurgicales (UMC) à « 0.2km » de l’hôpital.
· Les urgences médico-Pédiatriques à « 0.1 km » de l’hôpital.
· Les urgences médico-Orthopédiques à « 50 m » de l’hôpital.
· Les urgences médico-Digestives à « 120 m » de l’hôpital.
4. Présentation des types radio effectué dans l’hôpital:
Au cours de notre stage nous avons pu constater que les différentes radios effectuées dans l’établissement sont les suivantes :
· IRM
· Echographie.
· Scanner du crane.
· Mammographie.
· Scanner du Thorax.
· Radiographie de l’abdomen.
· Radiographie pulmonaire.
· Radiographie dentaire.
Nous avons inclus ces radios dans notre application.
5. Etude de l’existant:
L’hôpital Ain Tendelles utilise un logiciel nommé « PATIENT», la version utilisée « 2001 » pour les données avec logiciel « DICOM VIEWER » pour les opération des images son interface est datée, et il
contient plusieurs lacunes, notamment :
· L’absence d’historique des dossiers médicaux : Dès qu’un patient est libéré, son dossier est automatiquement supprimé, donc malgré l’informatisation du traitement des données lors de l’hospitalisation, le bénéfice est perdu si le patient est hospitalisé de nouveau.
· Absence de système de notification dans l’application : le médecin ne peut pas notifier les manipulateurs radios si une image n’est pas satisfaisante et qu’elle doit être refaite, le médecin ne peut également pas demander d’examen directement depuis l’application.
· L’absence de sécurité : L’absence d’identification au sein de l’application, en effet toutes les personnes qui ont accès au poste de travail peuvent accéder à l’application ainsi qu’aux dossiers des patients. Donc le secret médical des patients n’est absolument pas garanti. De plus, toutes personne (même hors personnel médical) peut modifier les données, ou modifier le diagnostic des patients, ce qui peut entrainer de graves conséquences pour les patients.
6. Objectifs du projet:
Nous avons défini les objectifs suivant lors de la réalisation de notre cahier des charges :
· Pour les médecins, faciliter et fluidifier l’accès aux données ainsi qu’aux images.
· Améliorer le suivi des patients sortants lors des prochaines hospitalisations (faciliter la consultation de leur historique).
· Réaliser une meilleure conservation des donnés médicales afin de pourvoir faire des études par la suite et avoir toutes sortes de statistiques.
· Prouver qu’il existe un moyen d’améliorer la gestion des images médicales.
· Améliorer la sécurité des dossiers médicaux des patients et ainsi pouvoir garantir le respect du secret médical.
· Etablir un control d’accès aux données des patients et sécuriser les mots de passe grâce au hashage afin d’augmenter la sécurité du système.
7. Analyse des besoins:
C’est la première étape de la conception. Elle consiste à analyser la situation pour tenir compte des contraintes, des risques et de tout autre élément pertinent et assurer un logiciel ou un processus répondant aux besoins du client.
7.1 Besoins fonctionnels :
Nous avons défini les besoins fonctionnels suivants pour notre application, elle doit permettre de :
S’identifier avec un nom d’utilisateur et un mots de passe.
Utiliser une fonction de hachage sur les mots de passe pour plus sécurité.
Ajouter, consulter, supprime, ou modifier un patient.
Ajouter ou supprimer des utilisateurs.
Utiliser l’algorithme AES pour crypter les images et les données.
Etablir un système de droits d’accès par catégorie d’utilisateur.
Créer et mettre à jour des dossiers patient.
Afficher l’historique des imageries du patient effectuées dans l’hôpital.
7.2 Besoins non fonctionnels :
Il s’agit des besoins qui caractérisent le système. Notre application doit répondre aux critères suivants :
· Ergonomie et souplesse : L’application doit offrir une interface conviviale et ergonomique exploitable par l’utilisateur en envisageant toutes les interactions possibles à l écran.
· Rapidité : L’application doit optimiser les traitements pour avoir un temps de génération de Schéma raisonnable.
· Efficacité : L’application doit être fonctionnelle indépendamment de toutes circonstances pouvant entourer l’utilisateur.
· Maintenabilité et scalabilité : Le code de l’application doit être lisible et compréhensible Afin d’assurer son état évolutif et extensible par rapport aux besoins de marché.
· La stabilité : L’application doit être très stable durant son exécution.
· La sécurité : Les données doivent être sécurises pour éviter toutes utilisation non permise.
· La comptabilité: L’application doit être compatible avec plusieurs types d’ordinateurs.
8. Identification des utilisateurs :
Nous avons dans notre application 4 catégories principales d’utilisateurs :
· Le Médecin: Il peut : consulter les images médicales des patients, établir des diagnostics, et notifier le manipulateur radio pour ajouter une nouvelle radio ou bien encore signaler que la qualité d’une image n’est pas satisfaisante et qu’elle doit être refaite.
· Le Manipulateur radio: Il peut : ajouter, supprimer ou modifié les images .il peut également ajouter un nouveau dossier patient ou encore établir un patient comme sortant après instruction du médecin.
· Le Super utilisateur (Administrateur du système) : Il peut : créer de nouveaux utilisateurs, débloquer un utilisateur bloqué à cause de plusieurs fausses tentatives de connexion, il peut également supprimer des utilisateurs.
· L’Agent de saisie :Il saisit les informations personnelles des patients hospitalisés, et peut établir également les patients sortant de l’hôpital (fin d’hospitalisation).
9. Conclusion:
Dans ce chapitre, nous avons présenté la structure hospitalière dans laquelle nous avons effectué notre Stage, ainsi que les besoins fonctionnelles de notre application. Dans le chapitre suivant, nous allons aborder la partie conception du logiciel.
CHAPITRE 02:
Conception générale
10. Introduction:
Au cours de ce chapitre, nous allons détailler la conception de notre système, nous avons utilisé la Méthode « UP » (que nous présenterons un peu plus loin dans ce chapitre) au cours de notre conception et nous allons à présent détailler les différents diagrammes UML de notre application.
12. Conception détaillée :
12.1 Le diagramme de classe :
12.2 Le diagramme de cas d’utilisation:
12.3 Le diagramme de flux de données:
12.4 Le diagramme de séquence:
13. Conclusion :
Nous nous sommes dans ce chapitre concentré sur la partie conception de notre projet, dans le chapitre suivant nous allons aborder la partie implémentation et présenter notre application à l’aide de plusieurs captures d’écran.
