Gestion d'un cabinet médical (mise en place d'un logiciel pour la gestion d'un cabinet médical)

Avants Propos

Dans le cadre d'achèvement des études du deuxième cycle en Informatique Appliquée à la Gestion, les étudiants sont appelés à préparer un mémoire de fin d'études.

Les étudiants peuvent concrétiser et améliorer leurs connaissances informatiques et théoriques récoltées durant les études universitaires par le développement d'un projet pratique pris du monde réel.

C'est ainsi que nous avons procédé à l'étude et la mise en oeuvre de l'application « GESTION D'UN CABINET MEDICAL ».

Listes des figures

Figure 1. Diagramme de collaboration « Système Métier » 9

Figure 2. Diagramme de cas d'utilisation Métier 11

Figure 3. Diagramme de classe (contexte statique du système) 16

Figure 4. Diagramme de collaboration du système 17

Figure 5. Diagramme de Séquence « Gestion et Suivi du Dossier Médical » 18

Figure 6. Diagramme de cas d'utilisation général de l'application 21

Figure 7. Diagramme de cas d'utilisation Gestion de CNAM et Suivi du dossier Médical 22

Figure 8. Diagramme de cas d'utilisation gestion de la CNAM 23

Figure 9. Diagramme de cas d'utilisation Gestion de Consultation 24

Figure 10. Diagramme de cas d'utilisation Gestion des Ordonnances 24

Figure 11. Diagramme de cas d'utilisation Gestion des Lettres aux Confrères 25

Figure 12. Diagramme de cas d'utilisation Gestion des Médicaments 25

Figure 13. Diagramme de cas d'utilisation l'interface secrétaire 26

Figure 14. Diagramme de cas d'utilisation gestion du fiche patient 26

Figure 15. Diagramme de cas d'utilisation gestion des Rendez-vous 27

Figure 16. Diagramme de cas d'utilisation gestion de la comptabilité 28

Figure 17. Architecture en Mode Deux Tiers 39

Figure 18. Diagramme de classe 50

Figure 19. Diagramme de séquence d'identification 51

Figure 20. Diagramme de séquence Enregistrement d'un Rendez-vous 52

Figure 21. Diagramme de séquence « Gestion de la comptabilité » 52

Figure 22. Diagramme de séquence « Gestion des confrères » 53

Figure 23. Conception des classes 56

Figure 24. Diagramme d'activité d'authentification 57

Figure 25. Diagramme d'activité gestion des rendez-vous 58

Figure 26. Diagramme d'activité gestion du fiche patient 59

Figure 27. Diagramme d'activité gestion et suivie du dossier médical 60

Figure 28. Fenêtre d authentification 69

Figure 29. Menu pour secrétaire 70

Figure 30. Interface gestion des patients 71

Figure 31. Interface gestion des rendez-vous 72

Figure 32. Interface gestion de la CNAM 73

Figure 33. Interface gestion de la comptabilité « Dépenses » 74

Figure 34. Interface gestion de la comptabilité « Recettes » 74

Figure 35. Interface gestion des rendez-vous « Nouveau RDV » 75

Figure 36. Menu principale pour Médecin 76

Figure 37. Interface Pour la Gestion et suivi du dossier médical (Inf. Méd.) 77

Figure 38. Interface Pour la Gestion des Médicaments 78

Sommaire

INTRODUCTION 1

CHAPITRE 1. MODELISATION DU METIER 3

Présentation 3

1.1. Définition de la mission 4

1.1.1. Présentation de l'application 7

1.1.2. Objectif à atteindre  8

1.2. Repérage du domaine 8

1.3 . Diagramme de cas d'utilisation métier 10

1.4. Critique de l'existant 11

1.5. Solutions  13

Conclusion 14

CHAPITRE 2. CAPTURE DES BESOINS 15

Présentation 15

2.1. Acteurs du système informatisé 15

2.2. Modèle de contexte du système informatisé 16

2.3. Elaboration de modèle des cas d'utilisation 18

2.3.1. Diagramme des cas d'utilisation 18

2.3.2. Description textuelle des cas d'utilisation 28

Conclusion 40

CHAPITRE 3. ANALYSE 41

Présentation 41

3.1. Construction du diagramme de classes 41

3.2. Développement du modèle dynamique 50

3.2.1. Construction des Diagrammes de séquence 51

Conclusion 53

CHAPITRE 4. CONCEPTION 54

Présentation 54

4.1. Environnement de réalisation 54

4.1.1. Environnement matériel 54

4.1.2. Environnement Logiciel 54

4.2. Conception des classes 55

4.3. Conception des schémas logiques et physique des données 60

4.4. Présentation des interfaces 68

Conclusion 78

CONCLUSION 79

BIBLIOGRAPHIE 81

Annexes 82

INTRODUCTION

La démarche médicale est fondée sur l'observation du malade. La mémoire du médecin était autrefois suffisante pour enregistrer les données relatives aux patients et servir l'exercice médical. Les données médicales étaient rassemblées sous forme d'articles médicaux, de registres à visée épidémiologique, nosologique et administrative, avec la multiplication des effets de l'environnement, de nos jours la bonne tenue d'un dossier exige des moyens informatiques.

L'automatisation du système d'information consiste à structurer et gérer un ensemble de données dont le but de les organiser et d'avoir des résultats rapides.

Dans ce cadre, nous sommes appelés à concevoir, développer et mettre en place un logiciel pour la gestion d'un cabinet médical pour le compte d'un médecin spécialiste en Chirurgie Orthopédique à Sfax

Le logiciel devrait mettre l'organisation et l'automatisation de la gestion d'un cabinet médical, afin d'augmenter la fiabilité, l'efficacité de l'effort humain et faciliter les tâches pénibles au sein du cabinet.

Notre application comprendra les fonctionnalités suivantes :

v Gestion et Suivi du Dossier Médical

v Gestion de la CNAM

v Gestion des Rendez-vous.

v Gestion du Fiche Patients.

v Gestion de la Comptabilité.

Le présent projet s'articule autour de Cinq chapitres qui sont présentés comme suit :

Ø Le premier chapitre est consacré à la modélisation du métier qui permet d'effectuer un premier repérage des besoins fonctionnels et opérationnels, en utilisant principalement le texte.

Ø Le deuxième chapitre définit les besoins fonctionnels et techniques pour le futur système.

Ø Le troisième chapitre décrit l'analyse spécifique de l'ensemble des scénarios du système. Il s'agit de l'analyse du domaine et de l'analyse de l'application.

Ø Le quatrième chapitre permet de concevoir, réaliser, et représenter graphiquement les activités des différentes interfaces du système.

CHAPITRE 1. MODELISATION DU METIER

Présentation

Ce chapitre va nous servir à poser les bases de la capture des besoins du système à réaliser.

Il consiste à effectuer un premier repérage des besoins fonctionnels et opérationnels.

1.1. Définition de la mission

Notre Mission dans le cadre de ce projet est de créer une application permettant de gérer le cabinet médical chirurgie orthopédiste il s'agit de définir les responsabilités de la gestion, mettre à jour les données, organiser des données collectées auprès du secrétariat afin de concevoir des fichiers de bases pour le Médecin ,  de renforcer le contrôle et la confrontation, assurer une meilleure gestion médicale et une cohérence de l'information et enfin faciliter le travail des responsables.

Notre application aura comme principale fonctionnalités :

v Gestion et Suivi du Dossier Médical (détaillé)

v Gestion de la CNAM (Caisse National Assurance Maladie).

v Gestion des Rendez-vous.

v Gestion du Fiche Patients.

v Gestion de la Comptabilité.

Gestion et Suivi du Dossier Médical

En commençant par la consultation, est l'activité principale du cabinet médical. Le patient qui s'adresse à un cabinet médical pour la première fois une visite en faisant consulter par le médecin.

Lorsque le médecin devient disponible, la secrétaire lui amène la fiche médicale descriptive du patient ainsi que son dossier médical. L'écoute attentive et patiente des propos du patient est un moment privilégiée de la consultation. L'entretien doit se dérouler dans la stricte intimité et confidentialité pour permettre au patient de s'exprimer clairement et sincèrement sur ses préoccupations.

Ensuite le médecin l'examine à l'aide de ses outils (Stéthoscope, Tensiomètre, Thermomètre...).

Le médecin rédige ensuite l'ordonnance qui contient les noms des médicaments, les doses et la durée de jour de prise.

Dans le cas où le médecin n'est pas sûr de son diagnostic, il peut demander au patient de faire des examens complémentaires (Bilan biologique ou Bilan radiologique), ou bien de le faire passer à un confrère spécialiste en lui rédigeant une lettre contenant les coordonnés et l'état de santé du patient.

A chaque consultation selon le cas, surtout l'état de santé du patient, si la consultation lui a causé un contretemps, et ou un empêchement de son activité le certificat sera utile pour la justification.

Enfin le patient peut demander un certificat médical qui peut être soit :

Ø Un certificat d'aptitude qui contient le nom, prénom, CIN, date de naissance, et la confirmation du médecin qu'il est apte ou non à exercer la fonction souhaitée.

Ø Un certificat médical de repos dans lequel sont mentionnés le nom, prénom et le nombre de jour de repos.

Ø Un certificat de dispense qui contient le nom, prénom et la période de dispense.

La tenue du dossier médical du malade est une obligation professionnelle pour identifier le patient, assurer un suivi précis de sa pathologie et son évolution. Le dossier médical est un document médico-légal justifiant la consultation et l'attitude thérapeutique qui en découle.

Le dossier médical doit être soigneusement gardé par le médecin dans une enceinte sûre, fermant à clef. Sa tenue relève de l'obligation du médecin au secret médical. Le dossier doit être archivé et gardé aussi longtemps que possible car un acte médical peut être remis en cause.

Le médecin gère aussi les visites des malades à domicile lorsqu'il s'agit d'un appel d'urgence.

Sinon en cas de visite de contrôle ou visite périodique d'un patient en maladie de longue durée, celle si sera programmée à un moment précis de la journée.

Concernant les visites en clinique des patients hospitalisés, la secrétaire les mentionne sur le planning de la journée du médecin.

Gestion de la CNAM

Pour la gestion de CNAM la préparation est faite par le médecin dont la procédure est :

Périodiquement, le médecin doit remplir un formulaire contenant les informations relatives aux consultations qu'il a réalisées.

Ce formulaire contient les informations suivantes :

Dates des soins, l'identifiant unique de l'assurée, l'identité du bénéficiaire (prénom, qualité, code APCI), acte effectué (code acte, cotation), montant total, ticket modérateur perçu de l'assuré, montant pour la charge de la CNAM  et code conventionnel du médecin traitant.

Ensuite, ce formulaire sera envoyé au bureau de la CNAM où s'effectuera la vérification pour le remboursement.

Gestion des rendez vous

Il peut être nécessaire d'organiser sa consultation sur rendez-vous si le besoin s'en fait sentir et le médecin se doit de les respecter scrupuleusement. Le cas échéant, ceci doit être signalé aux patients. Cependant il faut tenir compte des urgences qui ne peuvent souffrir aucune attente et admettre également la souplesse et la disponibilité requises.

La prise d'un RDV s'effectue directement ou par une communication téléphonique en donnant le nom, le prénom, la date et l'heure souhaitée, et selon la disponibilité du médecin, un RDV sera fixé.

La secrétaire est chargée de remplir les renseignements sur la fiche d'un patient (Nom, Prénom ....).

NB : D'après notre étude, chez la spécialiste chirurgien orthopédiste, il est très rare que les patients prennent des RDV, le patient se présente directement au cabinet et en passant directement la consultation.

Gestion du fiches du patients

Prise en charge des patients :

Dans tous les cas, le patient va attendre son rôle pour la consultation, soit dans la salle d'attente, soit dans la salle d'examen. Dans le cas d'une urgence, la secrétaire prévient immédiatement le médecin. En dehors de ces situations particulières, elle procédera à lui établir sa fiche dans laquelle elle mentionnera son nom, nom de jeune fille, prénom, date de naissance, sexe, téléphone, adresse, GSM, code CNAM et validité.

S'il s'agit d'un ancien patient, la secrétaire demande le nom, nom de jeune fille et prénom pour effectuer la recherche de sa fiche parmi les fiches médicales qui sont rangées par ordre alphabétique dans les boites d'archives, elle préparer, aussi son dossier médical contenant suivi précis de sa pathologique et son évolution.

Le dossier médical doit contenir nom, nom de jeune fille, prénom, âge, profession, adresse téléphone, code CNAM et validité.

L'observation médicale rédigée par le médecin doit comprendre les antécédents du patient qui sont :

-Soit médicaux (Ex : allergie a la pénicilline).

- Soit chirurgicaux (Ex : s'il y a eu une opération ou bien gynéco obstétricaux et les donnée de son terrain (poids, taille, constante, tares et allergies ...).

Ces données sont capitales pour les consultations ultérieures et toute thérapeutiques.

A chaque consultation un résumé de la nouvelle consultation et du traitement donné sera porté sur le dossier médical.

Gestion de la comptabilité

Sur le plan financier, le cabinet est géré comme une petite entreprise.

Pour les recettes : la nature de l'acte médical correspondant aux honoraires perçus doit être précisée dans le journal. Doivent également être portés sur le registre des recettes, la secrétaire encaisse le tarif de la visite en fonction du régime du patient.

Ø S'il s'agit du régime du médecin traitant, le client ne paye que 30% du tarif fixe.

Ø S'il s'agit du régime d'extraction des dépenses, le client paye le tarif complet et par la suite la CNAM lui remboursera ses dépenses.

Pour les dépenses : comme l'achat des médicaments (comprimes, piqûres....), le loyer du cabinet, toutes les factures (SONED, STEG, TELECOM...), achat de fournitures de nettoyages (javel, air fraiche...), la secrétaire garde toutes les pièces justificatives pour pouvoir prouver ses dépenses relatives à l'exercice de la profession.

Une bonne connaissance de sa comptabilité permet au médecin de s'acquitter de son obligation fiscale.

1.1.1. Présentation de l'application

Cette application que nous nous sommes proposé de développer pour la gestion de l'ensemble des activités existantes dans ce cabinet, doit permettre de répondre aux exigences de ce dit cabinet.

Pour le développement de cette application, nous avons jugé nécessaire d'utiliser les différents outils et méthodes qui sont les suivants :

Ø Pour la conception, nous utilisons UML (Unified Modeling Language) avec l'outil IBM Rational Rose Enterprise Edition V7.00.

Ø Pour la Programmation, nous utilisons Microsoft Visual Studio 2008 langage C#.

Ø Pour le traitement de texte, nous travaillons avec Microsoft Office 2007.

Ø Nous utilisons la base de données Microsoft SQL Serveur 2005.

1.1.2. Objectif à atteindre 

Dans le cadre de notre projet de fin d'études, il nous a été confié de faire l'étude du système informatique relatif à la gestion d'un cabinet médical, enfin de créer une application complète.

Pour cela, nous avons commencé par dégager un repérage du domaine, diagramme de cas d'utilisation métier, et une critique de l'existant.

1.2. Repérage du domaine

Ø Les activités de la secrétaire

La secrétaire a un rôle multiple dans le cabinet médical. Pendant l'absence du médecin, elle est seule et doit être en mesure de répondre à tout appel et de recevoir le patient qui se présente au cabinet. Elle doit, de ce fait, être digne de confiance et avoir une motivation toute particulière pour cette fonction qui nécessite un sens de la responsabilité et une attention consciencieuse.

Sa fonction première est l'accueil des patients. C'est une étape importante de la consultation qui doit se faire avec douceur et aménité en ayant toujours à l'esprit que le " patient " est un malade qui demande un soulagement. A ce stade, la secrétaire doit reconnaître le patient fatigué et s'empresser de l'installer, l'asseoir ou le coucher et, le cas échéant, reconnaître une urgence et prévenir immédiatement le médecin. En dehors de ces situations particulières, elle commencera par lui établir sa fiche s'il s'agit d'une première consultation, ou de préparer son dossier antérieur pour l'entrevue avec le médecin.

Ø Les activités du médecin

Son activité principale est de débuter avec des questions simples et tout en montrant la simplicité et une réassurance concernant l'état ou en quelque sorte la maladie en vue de rassurer le patient. En faisant la consultation, le Médecin dispose d'une fiche médicale déjà établie par la secrétaire.

Et pendant la consultation ou l'acte chirurgicale le médecin met à jour le dossier du malade spécifique.

Dans toutes ces activités la partie la plus importante est le suivi du Dossier Médical pour chaque patient, le médecin tient à jour un dossier qui englobe les données médicales de bases comme l'historique des interventions médicales subies par le patient, les médicaments qui lui on été prescrits, les résultats d'analyses diverses, mais aussi des données individuelles sensibles, telles que celle relatives à l'état physique de la personne, à ses antécédents familiaux, à ses habitudes de vie, y compris sa vie sexuelle, à sa situation sociale et économique , ainsi que des données de nature administrative : admission dans des établissements de santé, conditions d'assurance de la personne et d'autres données financières.

L'espace du domaine médical est assez large aussi important dans la mesure où l'on trouve une bonne coordination entre le médecin et la secrétaire ce qui doit être le cas pour pouvoir bien satisfaire les patients, il existe une multitude de relation entre ces trois acteurs.

Le diagramme de collaboration nécessite pour le repérage du domaine.

Qui décrit une relation contextuelle qui prend en charge l'interaction entre un jeu de participants. Un rôle est la description d'un participant. Contrairement à une classe structurée, une collaboration ne détient pas les instances liées à ses rôles.

Cette partie s'articule autour de trois volets :

Ø Identification des acteurs :

v Patient

v Autre Médecin

v CNAM

Ø Les limites du domaine (les activités de l'ensemble des acteurs cités)

Ø Les messages échangés entre ce domaine (boite noire) et les acteurs métier.

Les messages sont les seuls moyens de communication entre les objets. Ils sont donc Positionnés sur le lien entre deux objets et chiffrés par ordre selon les ensembles des mouvements entre les acteurs et le système.

Figure 1. Diagramme de collaboration « Système Métier »

Signification des Acteurs

Patient : Personne qui subit un traitement, une opération chirurgicale, etc.

Autre Médecin : Personne appartenant à une même profession ex. Médecin.

CNAM : Caisse Nationale d'Assurance Maladie en Tunisie.

Signification des notations 

1 : Un Patient arrivant dans le cabinet et demande un Rendez-vous.

2 : Confirmation de son Rendez-vous

3 : Il demande ensuite de faire une visite médicale/ ou une consultation

4 : Procédure de consultation en enregistrant les informations de consultation.

5 : Le patient peut aussi payer les frais de consultation

6 : Le système fait un encaissement des frais de consultation.

7 : Le patient demande un reçu

8 : Système imprime le reçu pour le patient.

9 : Patient peut aussi demander un certificat médical

10 : En suite le système lui fourni un certificat

11 : Si c'est le cas, le médecin peut aussi lui donné une lettre au confrère.

12 : Le médecin lui donne une ordonnance d'aller acheter

13 : Un autre médecin peut aussi envoyer une lettre au cabinet

14 : Médecin envoi une lettre d'accusation au confrère

15 : Un autre Médecin peut aussi envoyer des documents pour notre système etc.

16 : Le système envoi une lettre de réception de document

17 : Le système prépare et envoi les informations sur cabinet ou sur les patients à CNAM

18 : Le CNAM envoi des recommandations pour le cabinet.

19 : Le système envoi la liste des adhérent de CNAM

20 : Le CNAM rembourse les frais du cabinet en fonction des cette liste.

1.3. Diagramme de cas d'utilisation métier

Ensemble d'activités initié par un acteur métier et exécuté par le cabinet.

Cas d'utilisation stéréotypé ou (BUSINESS USE CASE) qui permet de représenter les travailleurs du métier et leurs rôles et les différents processus du métier et les liens entre eux. Ainsi pour chaque processus métier en précisant les flots d'événements de chacun et les activités qui le composent en tenant compte à des règles de gestion pour ces activités (dans le cadre de l'extension d'UML pour la modélisation métier).

Ø Le Domaine :

Le domaine d'étude, consiste à dégager les activités pour les acteurs interne sont :

§ Gestion et Suivi du Dossier Médical

§ Gestion de la CNAM

§ Gestion des Rendez-vous.

§ Gestion du Fiche Patients.

§ Gestion de la Comptabilité.

L'élaboration du domaine d'étude dépend en effet le choix des cas d'utilisation, des acteurs.

Ø L'Acteur des cas d'utilisation métier:

Personne appartenant à l'entreprise dont le travail aide à la réalisation d'un cas d'utilisation métier

Nous avons Médecin et Secrétaire pour notre système.

Figure 2. Diagramme de cas d'utilisation Métier

1.4. Critique de l'existant

Cette partie a pour but de dégager les insuffisances et les défaillances du système actuel. Relatif à la gestion d'un cabinet médical dont on peut citer :

Travaux manuels élevés, lourds et pénibles qui se présente d'une façon répétitive à savoir l'archivage, la mise en oeuvre et la consultation des fiches médicales.

Absence d'un moyen de recherche rapide : pour chercher une fiche, la secrétaire doit faire une recherche manuelle fiche par fiche par nom du patient, ce qui engendre une perte de temps même en cherchant est face au risque du quel les fiches peuvent se mélanger et surtout leurs contenus.

Processus très long avec probabilité de perte de documentation : puisqu'un dossier médical englobe un ensemble de documents tels que, fiche médicale, ordonnance et les feuilles qui contiennent les dates des RDV. Il est possible qu'un document qui appartient à un tel dossier soit rangé par erreur dans un autre dossier lors de l'organisation et le stockage dans les boites d'archives.

Absence de la notion de confidentialité à cause de non séparation entre fiche médicale et dossier médical : on remarque que la secrétaire peut accéder aux informations confidentielles du patient, or le respect du secret médical impose que seul le médecin peut consulter ce dossier.

La gestion des RDV, se fait d'une manière manuelle ce qui provoque un risque d'oubli ou chevauchement des RDV.

Encombrement et non clarté de la fiche médicale qui contient plusieurs informations à cause de sa petite taille, chose qui peut générer l'ajout ou la suppression parfois de certaines informations utiles.

La gestion des recettes et dépenses n'est pas bien définie, en effet, on remarque que la secrétaire a le droit de savoir tout sur l'état financier du cabinet, ce qui est en principe confidentiel au médecin seul.

La perte de temps qui est remarquable en cas d'augmentation du nombre des patients pour la consultation

La gestion des documents administratives tout à la longueur de la journée qui sont : la saisie des lettres, les recommandations, des certificats, ordonnances médicales encore a chaque fois lors d'élaboration des ordonnances, les médecins on tendance à regarder une listes des médicaments leurs nom, signification, effets etc. comme un memo (Vidal) .ce qui est tout a fait gênant a cause du temps et le nombre important des patients en attente.

1.5. Solutions 

Après avoir fait critique de l'existant et détecter les anomalies de la procédure actuelle, Une approche de solution qui consiste à concevoir et à développer une application qui facilitera les insuffisances et les défaillances énumérés précédemment. On propose alors de concevoir une nouvelle application permettant l'organisation et l'automatisation des tâches qui ne peuvent être exercées sans l'appui d'un réseau de communication pour diffuser les informations et les décisions entres le médecin et la secrétaire.

L'informatisation de la gestion du cabinet a des avantages certains et la simplification des tâches n'est plus à discuter tant pour le fichier des malades que pour la tenue d'une comptabilité simplifiée et du traitement de texte pour la correspondance et l'établissement d'ordonnances, de certificats médicaux ou autres :

Mettre en place un logiciel afin de gérer facilement chaque module à part, Implanter une base de données complète pour la gestion des RDV, fiches médicales, consultations médicales, dossiers médicaux, assurer une meilleure communication et cohérence de l'information.

Optimiser le temps d'accès aux différentes données, éviter les tâches pénibles et ennuyeuses.

Mettre en place une nouvelle circulation de l'information grâce à un réseau de communication pour diffuser les informations entre la secrétaire et le médecin.

Définir une bonne organisation des données collectées auprès de la secrétaire pour faciliter la recherche des documents, aider le médecin pour la prise de décision avec des supports informatisés à l'appui.

Mettre en place un système qui gère toute une liste des médicaments de façon détaillée et rapide pour avoir des informations telque la définition et les effets, quantité prise selon la maladie, etc.

Gérer les droits d'accès afin de permettre un accès sélectif aux différent menus et attribuer des responsabilités à chaque utilisateur : on doit assurer la séparation entre fiche médicale et dossier médical, la secrétaire ne peut pas accéder aux informations confidentielles et secrètes concernant les patients, seul le médecin peut consulter le dosser médical.

Donner beaucoup d'importance à l'interface Homme-machine et la simplifier au maximum à l'utilisateur de l'application.

Conclusion

La Modélisation du Métier permet donc de comprendre, d'analyser les différentes activités du cabinet médical et de dégager éventuellement des critiques pour pouvoir proposer des solutions et en construisant un modèle de l'organisation d'un cabinet médical enfin de créer une application.

La capture des besoins de cette application fera l'objet du chapitre suivant.

CHAPITRE 2. CAPTURE DES BESOINS

Présentation

Ce présent chapitre est de présenter un recueil des besoins fonctionnels et techniques envers le système (Les utilisateurs de notre système).

Les fonctionnalités et les techniques des besoins du système sont basés sur différents aspects, nous partons depuis les utilisateurs jusqu'au fonctionnement du système en passant par l'authentification, la base de données etc.

Besoins fonctionnels 

2.1. Acteurs du système informatisé

Définition :

On défini les différents acteurs du futur système et leurs rôles. En faisant le diagramme de classe. Les acteurs sont : (Médecin, Secrétaire et Aide Soignante).

Le diagramme de classes exprime la structure statique du système en termes de classes et de relations entre ces classes.

L'intérêt du diagramme de classe est de modéliser les entités du système d'information.

Le diagramme de classe permet de représenter l'ensemble des informations finalisées qui sont gérées par le domaine. Ces informations sont structurées, c'est-à-dire qu'elles ont regroupées dans des classes.

Cependant UML dispose d'un concept « Le Meta modèle UML » pour déterminer l'acteur du système avec une ressemblance légère de diagramme de classe ce qui nous donne Meta classe.

v Un acteur selon le concept méta classe (système informatisé) est :

Celui qui représente l'abstraction d'un rôle joué par des entités externes c'est-à-dire les utilisateurs, ou autre système etc.

L'activité d'un acteur sur le système est d'avoir la possibilité de consulter et/ou de modifier directement du système, en émettant et/ou en recevant des messages éventuellement porteurs de données.

v Et la représentation d'un acteur est sous forme de deux :

Ø Un acteur est représenté sous forme graphique dite du Stick man

Exemple :

Ø Un acteur est soit sous forme rectangulaire avec le mot clé « Actor ».

Exemple :



Le diagramme qui suit, permet de montrer de façon synthétique qu'il existe :

· On peut avoir une absence de secrétaire et sinon plusieurs secrétaires, dû à la suractivité.

· Un médecin pour gérer un cabinet sinon plusieurs vont travailler ensemble.

· Dans le but de d'aider le Médecin, on peut avoir une aide soignante.

Figure 3. Diagramme de classe (contexte statique du système)

2.2. Modèle de contexte du système informatisé

La modélisation de contexte du système est très importante et très utile dans la mesure où elle permet de comprendre le comportement de l'ensemble des acteurs(les objets) qui réagissent sur le système.

La mise en oeuvre de diagramme de collaboration est nécessaire, d'abord qu'est ce qu'un diagramme de collaboration ?

Un Diagramme de collaboration permet de mettre en évidence les interactions entre les différents objets. (Du système jusqu'aux utilisateurs).

En ce sens les diagrammes de collaboration montrent les interactions entre les objets, en insistant plus particulièrement sur la structure spatiale statique qui permet la mise en collaboration d'un groupe d'objets.

Dans ce cadre, pour l'analyse de ce diagramme collaboration il sera utilisé :

ü Une précision du contexte dans laquelle chaque objet évolue.

ü De mettre en évidence les dépendances entre les différents objets impliqués.

Figure 4. Diagramme de collaboration du système

NB : le [choix] peut être soit Consultation ou Rendez-vous, CNAM, ou Ordonnance, Certificat.

Figure 5. Diagramme de Séquence « Gestion et Suivi du Dossier Médical »

NB : Le médecin fait une recherche de la fiche du patient, et après la consultation du patient il remplit le reste du formulaire du dossier médical.

2.3. Elaboration de modèle des cas d'utilisation

Les modèles des cas d'utilisation permettent d'avoir une représentation de l'ensemble des fonctionnalités complètes du système.

Le modèle de cas d'utilisation comprend les acteurs, le système et les cas d'utilisation eux-mêmes. L'ensemble des fonctionnalités d'un système est déterminé en examinant les besoins fonctionnels de chaque acteur, exprimés sous forme de familles d'interactions dans les cas d'utilisation. Les acteurs se représentent sous la forme de petits personnages qui déclenche des cas d'utilisation ; ces derniers sont représentés par des cercles par le système

Cette section se compose de deux parties :

v Les Diagrammes des cas d'utilisation.

v Leurs descriptions textuelles des cas d'utilisation.

2.3.1. Diagramme des cas d'utilisation

Rappelons que les cas d'utilisation servent à exprimer les besoins fonctionnels des utilisateurs d'un système. D'autres types d'exigences peuvent être joints aux descriptions de cas d'utilisation, notamment les exigences non fonctionnelles qui ne sont pas prises en compte volontairement.

Qu'est-ce qu'un cas d'utilisation ?

Un cas d'utilisation (use case) représente un ensemble de séquences d'actions réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier.

Un cas d'utilisation modélise un service rendu par le système. Un cas d'utilisation concerne acteurs et ou système et apporte une valeur ajoutée « notable » à l'acteur concerné.

Chaque cas d'utilisation spécifie un comportement attendu du système considère comme un tout, sans imposer le modèle de réalisation de ce comportement. Il permet de décrire ce que le futur système devra faire, sans spécifier comment il le fera. Dans le cadre de la branche fonctionnelle, le cas d'utilisation doit mettre en valeur les interactions métier entre les acteurs et le système.

Dans ce chapitre « Capture des besoins », pourquoi avons-nous recours aux cas d'utilisation ?

ü Les cas d'utilisation permettent aux utilisateurs de structurer et d'articuler leurs désirs.

ü Ils les obligent à définir de manière dont ils voudraient interagir avec le système.

ü Ils favorisent la définition d'un cahier de charges qui reflète réellement les besoins même en absence d'un système à critiquer.

Nous allons procéder à l'automatisation du système informatique relatif à un cabinet médical.

Notre application aura comme principale fonctionnalités :

-Gestion et Suivi du Dossier Médical

-Gestion des CNAM

-Gestion des Rendez-vous.

-Gestion des Fiches patients.

-Gestion de la Comptabilité

Afin de détailler ces fonctionnalités, nous allons utiliser le diagramme de cas d'utilisation du langage de modélisation UML.

Nous allons procéder par les étapes suivantes :

Ø Identifications des acteurs.

Ø Identification des cas d'utilisation.

Ø Diagramme des cas d'utilisation

Identification des acteurs

Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel, ou autre système) qui interagit directement avec le système étudié, en échangeant de l'information (en entrée et en sortie). On trouve les acteurs en observant les utilisateurs directs du système, les responsables de la maintenance, ainsi que les autres systèmes qui interagissent avec lui.

Pour notre système, on peut distinguer deux acteurs principaux:

Ø Médecin

Ø Secrétaire

Identification des cas d'utilisation

Pour chacun des acteurs cités, notre application doit donc offrir un ensemble de fonctionnalités. Ces fonctionnalités sont classées par acteur selon le tableau suivant :

Utilisateur	Cas d'utilisation
Médecin	· Gestion et Suivi du Dossier Médical · Gestion des CNAM et certificats médicaux
Secrétaire	· Gestion des rendez-vous. · Gestion des fiches patientes. · Gestion de la comptabilité.

Cas d'utilisation général de l'application 

Figure 6. Diagramme de cas d'utilisation général de l'application

Remarque :

Toutes les fonctionnalités de la secrétaire sont faisables par le médecin puisqu'il peut accéder à toutes les rubriques du logiciel sans nécessité d'une authentification ce qui est impossible pour la secrétaire car elle ne peut pas accéder à certaines informations comme par exemples la gestion du dossier médical qui est confidentiel

Cas d'utilisation pour la gestion de CNAM et Suivi du Dossier Médical

Figure 7. Diagramme de cas d'utilisation Gestion de CNAM et Suivi du dossier Médical

Consultation :

La gestion des consultations et des dossiers médicaux s'effectue par le médecin et elle est constituée des informations secrètes et confidentielles du patient, elle englobe les différentes fonctionnalistes suivantes :

Gestion des consultations, gestion des antécédents, gestion des examens, gestion des ordonnances, Gestion des Médicaments, et certificats médicaux.

A chaque consultation un résumé de l'observation nouvelle et du traitement institué sera porté sur le dossier. C'est-à-dire un enregistrement pour toutes les informations relatives à un patient.

Certificats Médicaux :

Dans cette partie le médecin a besoin d'avoir quelques types des certificats notamment comme : certificat de repos, certificat médical, certificat d'inaptitude à la pratique de l'éducation physique etc.

La rédaction d'un certificat ne peut se faire qu'après un examen du malade et dans des termes mesurés et objectifs. De ces impératifs découlent la valeur des attestations des médecins et se qui sera conçu pour avoir des informations fiable et relative aux patients

Cas d'utilisation pour la gestion de la CNAM

Figure 8. Diagramme de cas d'utilisation gestion de la CNAM

La gestion de la CNAM et certificat médicaux sont établis par le médecin et les informations sont basées sur une justification concernant le trainement du patient et la CNAM. A chaque consultation si le patient dispose d'un abonnement CNAM, les informations seront ajoutées dans la fiche CNAM. C'est-à-dire un enregistrement pour toutes les informations (date de soins, identifient de l'assuré, prénom, qualité, code APCI, code acte, montant honoraire, etc.) relatives à un patient.

Le médecin a besoin par la suite d'une note d'honoraire pour être rembourser par CNAM.

Cas d'utilisation pour la gestion de la Consultation

Figure 9. Diagramme de cas d'utilisation Gestion de Consultation

Figure 10. Diagramme de cas d'utilisation Gestion des Ordonnances

Figure 11. Diagramme de cas d'utilisation Gestion des Lettres aux Confrères

Figure 12. Diagramme de cas d'utilisation Gestion des Médicaments

Les cas d'utilisation pour la secrétaire :

Figure 13. Diagramme de cas d'utilisation l'interface secrétaire

Cas d'utilisation pour la Gestion du fiche patient 

Figure 14.  Diagramme de cas d'utilisation gestion du fiche patient

A l'arrivée d'un patient au cabinet, la secrétaire le prend en charge :

- S'il s'agit d'un nouveau patient, une nouvelle fiche sera crée qui comporte toutes les informations nécessaires c'est-à-dire (nom, prénom, adresse, numéro de téléphone etc.).

- Si le patient présente un carnet jaune (CNAM), il paye 30% du tarif

- Dans le cas contraire il paye la totalité du tarif

NB. Dans notre cas le patient paye 35 Dinars tunisien.

- S'il s'agit d'un ancien patient, la secrétaire consulte sa fiche médicale et peut modifier quelques informations si c'est nécessaire.

Cas d'utilisation pour la gestion des rendez-vous

Figure 15. Diagramme de cas d'utilisation gestion des Rendez-vous

Ce diagramme de cas d'utilisation contient les opérations suivantes :

Ø Afficher la liste des rendez-vous

Ø Ajouter un rendez-vous

Ø Modifier rendez-vous

Ø Supprimer un rendez-vous

Cas d'utilisation pour la gestion de la comptabilité

Figure 16. Diagramme de cas d'utilisation gestion de la comptabilité

La gestion de la comptabilité est effectuée par la secrétaire, en effet, elle présente l'ensemble des dépenses et des recettes et aussi les impayés c'est-à-dire (les patients qui n'on pas payer ou il reste une partie de la somme pour le compte du cabinet.

2.3.2. Description textuelle des cas d'utilisation

Dans cette section, chaque cas d'utilisation sera décrit de façon exhaustive suivant le format présenté dans les diagrammes de cas d'utilisation précédents.

La description textuelle, pour faire quoi ?

Pour la documentation des cas d'utilisation(les scenarios), et aussi la description textuelle est indispensable, car elle seule permet de communiquer facilement et précisément avec les utilisateurs .Elle est l'occasion d'identifier le contexte d'exécution de l'un ou de l'autre des enchainements.

Cette partie est composée de deux :

ü Sommaire d'identification (titre, but, résumé, acteur).

ü Description de l'enchaînement (pré-condition, post-condition, scenario nominale, scenario alternative).

Titre : Cas d'utilisation concerné.

But : l'objectif de ce cas d'utilisation dans le système.

Résumé : c'est le résumé du contenu textuel

Pré-condition : se sont les conditions nécessaire pour déclencher les enchainements.

Post-condition : représente l'événement futur.

Scenario nominale : représente les événements produits par l'acteur et le système de la façon sans échec (sans erreur).

Scenario alternative : représente les événements après les erreurs produits par l'acteur et le système.

Description textuelle pour cas d'utilisation gestion des consultations (Médecin)

Sommaire d'identification

Titre : Gestion des consultations.

But : Permette au médecin de gérer les consultations et dossiers médicaux.

Résume : Gérer une fiche consultation. (Modification, Affichage, l'Ajout, Suppression)

Acteurs : Médecin.

Description de l'enchaînement

Pré condition : Présence d'un patient

Accès autorisé

Post condition: une nouvelle consultation sera enregistrée.

Scénario nominal :

1- Le médecin saisit le login et le mot de passe.

2- Le système vérifie le login et le mot de passe.

3- Le système affiche le menu du médecin.

4- Le médecin choisit «Gestion des consultations».

5- Le système affiche un formulaire

6- Le médecin saisit les informations.

7- Le système effectue un contrôle sur les champs obligatoires.

8- système effectue un contrôle sur les champs saisis.

9- Le système vérifie que tous les champs obligatoires sont complets.

10- Le système enregistre les informations.

11- Le système affiche un message de confirmation.

Scénario alternatif

1' : Erreur d'identification.

Le système affiche une erreur d'identification.

Le scénario reprend au point 1

2' : nature des champs saisie incorrecte.

L'enchaînement démarre au point 8.

8. Le système signale une erreur des champs saisis.

3' : Champs obligatoires vides.

L'enchaînement démarre au point 8

9. Le système signale l'existence des champs obligatoires vide.

11. Le système réaffiche le formulaire déjà remplis.

Le scénario reprend au point 5.

Description textuelle pour cas d'utilisation gestion des Ordonnances (Médecin)

Sommaire d'identification

Titre : Gestion des Ordonnances.

But : Permette au médecin de gérer les Ordonnances

Résume : Etablir une fiche d'ordonnance. (Modification, Affichage, l'Ajout, Suppression)

Acteurs : Médecin.

Description de l'enchaînement

Pré condition : Présence d'un patient

Accès autorisé

Post condition: une nouvelle ordonnance sera établie.

Scénario nominal :

1- Le médecin saisit le login et le mot de passe.

2- Le système vérifie le login et le mot de passe.

3- Le système affiche le menu du médecin.

4- Le médecin choisit «Gestion des Ordonnances».

5- Le système affiche un formulaire

6- Le médecin saisit les informations.

7- Le système effectue un contrôle sur les champs obligatoires.

8- système effectue un contrôle sur les champs saisis.

9- Le système vérifie que tous les champs obligatoires sont complets.

10- Le système enregistre les informations.

11- Le système affiche un message de confirmation.

Scénario alternatif

1' : Erreur d'identification.

Le système affiche une erreur d'identification.

Le scénario reprend au point 1

2' : nature des champs saisie incorrecte.

L'enchaînement démarre au point 8.

8. Le système signale une erreur des champs saisis.

3' : Champs obligatoires vides.

L'enchaînement démarre au point 8

9. Le système signale l'existence des champs obligatoires vide.

11. Le système réaffiche le formulaire déjà remplis.

Le scénario reprend au point 5.

Description textuelle pour cas d'utilisation gestion des lettres confrères (Médecin)

Sommaire d'identification

Titre : Gestion des lettres confrère.

But : Permette au médecin d'établir des lettres de confrère

Résume : Etablir une lettre confrère (Modification, Affichage, l'Ajout, Suppression)

Acteurs : Médecin.

Description de l'enchaînement

Pré condition : Présence d'un patient

Accès autorisé

Post condition: une nouvelle lettre sera établie.

Scénario nominal :

1- Le médecin saisit le login et le mot de passe.

2- Le système vérifie le login et le mot de passe.

3- Le système affiche le menu du médecin.

4- Le médecin choisit «Gestion des lettres confrère».

5- Le système affiche un formulaire

6- Le médecin saisit les informations.

7- Le système effectue un contrôle sur les champs obligatoires.

8- Le système effectue un contrôle sur les champs saisis.

9- Le système vérifie que tous les champs obligatoires sont complets.

10- Le système enregistre les informations.

11- Le système affiche un message de confirmation.

Scénario alternatif

1' : Erreur d'identification.

Le système affiche une erreur d'identification.

Le scénario reprend au point 1

2' : nature des champs saisie incorrecte.

L'enchaînement démarre au point 8.

8. Le système signale une erreur des champs saisis.

3' : Champs obligatoires vides.

L'enchaînement démarre au point 8

9. Le système signale l'existence des champs obligatoires vide.

11. Le système réaffiche le formulaire déjà remplis.

Le scénario reprend au point 5.

Description textuelle pour cas d'utilisation gestion des CNAM (Médecin)

Sommaire d'identification

Titre : Gestion des CNAM.

But : Permettre au médecin de regrouper l'information pour tous les patients qui ont une carte CNAM.

Résume : Le médecin rempli un formulaire (l'ajout, affichage, modification, suppression)

Acteurs : Médecin.

Description de l'enchaînement

Pré condition : Accès autorise

Post condition: une nouvelle fiche CNAM sera remplit.

Scénario nominal :

1- Le médecin saisit le login et le mot de passe.

2- Le système vérifie le login et le mot de passe.

3- Le système affiche le menu du médecin.

4- Le médecin choisit «Gestion CNAM ».

5- Le système affiche un formulaire

6- Le médecin saisit les informations.

7- Le système effectue un contrôle sur les champs saisis.

8- Le système vérifie que tous les champs obligatoires sont complets.

9- Le système enregistre les informations relatives à la fiche CNAM.

10- Le système affiche un message de confirmation.

Scénario alternatif :

1' : Erreur d'identification.

2. système affiche une erreur d'identification.

Le scénario reprend au point 1

2' : nature des champs saisie incorrecte.

L'enchaînement démarre au point 7.

7. Le système signale une erreur des champs saisis.

3' : Champs obligatoires vides.

L'enchaînement démarre au point 8

8. Le système signale l'existence des champs obligatoires vide.

10. Le système réaffiche le formulaire déjà remplis.

Le scénario reprend au point 5.

Description textuelle pour cas d'utilisation gestion des certificats médicaux (Médecin)

Sommaire d'identification

Titre : Gestion des certificats médicaux.

But : Permettre au médecin d'établir le certificat médical et par la suite donner au patient

Résume : Le médecin établi un certificat avec (l'ajout, affichage, modification, suppression)

Acteurs : Médecin.

Description de l'enchaînement

Pré condition : Accès autorise

Post condition: un nouveau certificat sera établit.

Scénario nominal :

1- Le médecin saisit le login et le mot de passe.

2- Le système vérifie le login et le mot de passe.

3- Le système affiche le menu du médecin.

4- Le médecin choisit «Gestion des certificats médicaux ».

5- Le système affiche un formulaire

6- Le médecin saisit les informations.

7- Le système effectue un contrôle sur les champs saisis.

8- Le système vérifie que tous les champs obligatoires sont complets.

9- Le système enregistre les informations relatives à un certificat.

10- Le système affiche un message de confirmation.

Scénario alternatif :

1' : Erreur d'identification.

2. système affiche une erreur d'identification.

Le scénario reprend au point 1

2' : nature des champs saisie incorrecte.

L'enchaînement démarre au point 7.

7. Le système signale une erreur des champs saisis.

3' : Champs obligatoires vides.

L'enchaînement démarre au point 8

8. Le système signale l'existence des champs obligatoires vide.

10. Le système réaffiche le formulaire déjà remplis.

Le scénario reprend au point 5.

Description textuelle pour cas d'utilisation gestion du Fiche patient (Secrétaire)

Sommaire d'identification

Titre : Gestion des fiches patientes.

But : pour avoir les informations des patients.

Résume : la secrétaire établie une fiche patiente, s'il s'agit d'un nouveau patient, sinon elle fera la mise à jour nécessaire. (l'ajout, affichage, modification, suppression)

Acteurs : secrétaire.

Description de l'enchaînement

Pré condition : Accès autorisé

Post condition: une nouvelle fiche patient sera mise à jour.

Scénario nominal :

1- La secrétaire saisit le login et le mot de passe.

2- Le système vérifie le login et le mot de passe.

3- Le système affiche le menu de la secrétaire.

4- La secrétaire choisit « Gestion fiche patient ».

5- Le système affiche un formulaire.

6- La secrétaire saisit les informations relatives au patient.

7- Le système effectue un contrôle sur les champs saisis.

8- Le système vérifie que tous les champs obligatoires sont complets.

9- Le système enregistre les informations relatives au patient.

10- Le système affiche un message de confirmation.

Scénario alternatif :

1' : Erreur d'identification.

2. Le système affiche une erreur d'identification.

Le scénario reprend au point 1.

2' : nature des champs saisie incorrecte.

L'enchaînement démarre au point 7.

7. Le système signale une erreur des champs saisis.

Le scénario nominal reprend au point 5.

3' : Champs obligatoires vides.

L'enchaînement démarre au point 8

8. Le système signale l'existence des champs obligatoires vide.

10. Le système réaffiche le formulaire déjà remplis.

Le scénario reprend au point 6.

Description textuelle pour cas d'utilisation gestion des Rendez-vous (Secrétaire)

Sommaire d'identification

Titre : Gestion des rendez-vous.

But : pour organiser la consultation

Résume : un patient arrive le secrétaire prend le rendez-vous. (l'ajout, affichage, modification, suppression)

Acteurs : secrétaire.

Description de l'enchaînement

Pré condition : Affecter un RDV.

Accès autorisé

Post condition: un nouveau rendez-vous sera enregistré

Scénario nominal :

1- La secrétaire saisit le login et le mot de passe.

2- Le système vérifie le login et le mot de passe.

3- Le système affiche le menu de la secrétaire.

4- La secrétaire choisit « Gestion des rendez-vous ».

5- Le système affiche un formulaire

6- La secrétaire saisit la date d'un rendez-vous voulu.

7- Le système affiche la liste des rendez-vous.

8- La secrétaire saisit un rendez-vous ayant une heure différente à celui des autres rendez-vous.

9- Le système vérifie que tous les champs obligatoires sont complets.

10- Le système enregistre les informations du nouveau rendez-vous.

11- Le système affiche un message de confirmation.

Scénario alternatif

1' : Erreur d'identification.

2. Le système affiche une erreur d'identification.

Le scénario reprend au point 1

2' : champ obligatoire vide.

L'enchaînement démarre au point 9

10. Le système signale l'existence des champs obligatoire vides.

11. Le système réaffiche le formulaire déjà remplis

Le scénario reprend au point 8

Description textuelle pour cas d'utilisation gestion des Recettes (Secrétaire)

Sommaire d'identification

Titre : Gestion des recettes.

But : pour contrôler le flux d'entrés.

Résume : permettre à la secrétaire d'enregistrer toutes les recettes du cabinet.

Acteurs : secrétaire.

Description de l'enchaînement

Pré condition : Accès autorisé

Post condition: toutes les recettes seront enregistrées.

Scénario nominal :

1-La secrétaire saisit le login et le mot de passe.

2-Le système vérifie le login et le mot de passe.

3-Le système affiche le menu de la secrétaire.

4-La secrétaire choisit « gestion de la caisse ».

- Puis La secrétaire choisit « gestion des recettes ».

5-Le système affiche un formulaire

6-La secrétaire saisit remplit un formulaire

7-Le système effectue un contrôle sur les champs saisis.

8-Le système vérifie que tous les champs obligatoires sont complets.

9-Le système enregistre les informations.

10-Le système affiche un message de confirmation.

Scénario alternatif :

1' : Erreur d'identification.

Le système affiche une erreur d'identification.

Le scénario reprend au point 1

2' : nature des champs saisie incorrecte.

L'enchaînement démarre au point 7.

7. Le système signale une erreur des champs saisis.

3' : Champs obligatoires vides.

L'enchaînement démarre au point 8

8. Le système signale l'existence des champs obligatoires vide.

10. Le système réaffiche le formulaire déjà remplis.

Le scénario reprend au point 5.

Description textuelle pour cas d'utilisation gestion des Dépenses (Secrétaire)

Sommaire d'identification

Titre : Gestion dépenses.

But : pour contrôler le flux de sortie.

Résume : permettre à la secrétaire d'enregistrer toutes les dépenses du cabinet

Acteurs : secrétaire.

Description de l'enchaînement

Pré condition : Accès autorisé

Post condition: toutes les dépenses seront enregistrées.

Scénario nominal :

1-La secrétaire saisit le login et le mot de passe.

2-Le système vérifie le login et le mot de passe.

3-Le système affiche le menu de la secrétaire.

4-La secrétaire choisit « Gestion de la caisse ».

- Puis La secrétaire choisit « Gestion des dépenses ».

5-Le système affiche un formulaire

6-La secrétaire saisit remplit un formulaire

7-Le système effectue un contrôle sur les champs saisis.

8-Le système vérifie que tous les champs obligatoires sont complets.

9-Le système enregistre les informations.

10-Le système affiche un message de confirmation.

Scénario alternatif :

1' : Erreur d'identification.

Le système affiche une erreur d'identification.

Le scénario reprend au point 1

2' : nature des champs saisie incorrecte.

L'enchaînement démarre au point 7.

7. Le système signale une erreur des champs saisis.

3' : Champs obligatoires vides.

L'enchaînement démarre au point 8

8. Le système signale l'existence des champs obligatoires vide.

10. Le système réaffiche le formulaire déjà remplis.

Le scénario reprend au point 5.

Description textuelle pour cas d'utilisation gestion des impayés (Secrétaire)

Sommaire d'identification

Titre : Gestion des impayés.

But : pour contrôler les flux non ajoutés dans la caisse

Résume : permettre à la secrétaire d'enregistrer tout les impayés.

Acteurs : secrétaire.

Description de l'enchaînement

Pré condition : Accès autorisé

Post condition: touts les impayés seront enregistrés.

Scénario nominal :

1-La secrétaire saisit le login et le mot de passe.

2-Le système vérifie le login et le mot de passe.

3-Le système affiche le menu de la secrétaire.

4-La secrétaire choisit « Gestion de la comptabilité ».

-Puis La secrétaire choisit « Gestion des Impayés».

5-Le système affiche un formulaire

6-La secrétaire saisit remplit un formulaire

7-Le système effectue un contrôle sur les champs saisis.

8-Le système vérifie que tous les champs obligatoires sont complets.

9-Le système enregistre les informations.

10-Le système affiche un message de confirmation.

Scénario alternatif :

1' : Erreur d'identification.

Le système affiche une erreur d'identification.

Le scénario reprend au point 1

2' : nature des champs saisie incorrecte.

L'enchaînement démarre au point 7.

7. Le système signale une erreur des champs saisis.

3' : Champs obligatoires vides.

L'enchaînement démarre au point 8

8. Le système signale l'existence des champs obligatoires vide.

10. Le système réaffiche le formulaire déjà remplis.

Le scénario reprend au point 5.

Besoins techniques :

Définition de l'architecture du système :

L'architecture est l'ensemble des décisions d'organisation du système logiciel qui défend les intérêts de son propriétaire final. Les intérêts s'expriment en termes d'exigences fonctionnelles, techniques et économiques. L'architecture y répond par l'intégration de plusieurs styles de développement informatique qu'elle adapte aux éléments logiciels d'un contexte existant.

Le propriétaire du système logiciel, par définition le maître d'ouvrage est au premier chef concerné par l'adéquation aux besoins des utilisateurs, la pertinence par rapport à l'organisation de l'entreprise, l'analyse de la valeur qui en résulte, et les qualités de maintenance et l'évolution du logiciel. C'est pourquoi l'architecture du logiciel décrit plusieurs axes de solution générique.

Les architectures client/serveur en tiers (2-tiers, 3-tiers ou tiers) concernent la capacité de monter en charge du système. Le style 2-tiers vise des applications départementales à nombre limité d'utilisateurs. Elles mettent généralement en jeu des clients et un serveur de base de données. Les styles 3-tiers ou tiers permettent l'évolution du nombre des utilisateurs par l'introduction d'un middleware qui distribue les services entre les clients et les serveurs.

CLIENT PROTOCOLE SERVEUR

Figure 17. : Architecture en Mode Deux Tiers

Les utilisateurs de notre application:

Le logiciel doit demander au démarrage une identification de l'utilisateur pour assurer la confidentialité et l'intégrité des données.

Le médecin et la secrétaire doivent pouvoir consulter et manipuler la liste des utilisateurs

(Eux-mêmes) qui seront identifiés par un identifiant et un mot de passe.

La base de données pour notre application :

Une base de données peut être définie selon plusieurs points de vue. Pour l'administrateur, c'est un ensemble de fichiers contenant des données organisées, qui doivent être sauvegardées, nettoyées, réorganisées, sécurisées...Pour l'utilisateur, c'est un espace, lui permettant d'enregistrer des informations et de les retrouver quand il en a besoin.

Le futur système qui offre à son utilisateur plusieurs fonctionnalités dont la consultation, l'enregistrement, la modification ou même la suppression de données relatives à la gestion d'un cabinet médical.

Le réseau pour la liaison entre poste secrétaire et poste Médecin :

Ce qui est nécessaire au fonctionnement du système, qui est primordial, permettant de connecter la machine du secrétaire et celle du médecin, avec la configuration des adresses IP et câble réseau pour le bon fonctionnement du système.

Conclusion

La capture des besoins est la partie pour comprendre les besoins permettant d'identifier et de décrire :

Les fonctionnalités d'un logiciel qui sont significatives pour ses utilisateurs (humains, matériels, logiciels) Permettant de décrire les interactions du logiciel.

En outre, techniquement, elle nous a donnée plus d'importance à la confidentialité et la sécurité des données en se servant des mots de passe et des codes d'accès aux données, et avec un maximum de contrôle au moment de la saisie des données et la sécurité de l'information par la définition des règles de contrôle.

Le chapitre suivant sera consacré à l'étude d'Analyse.

CHAPITRE 3. ANALYSE

Présentation

Le modèle d'analyse nous permet de faire une représentation transitoire entre l'expression des besoins d'une part et le modèle de conception d'autre part; le modèle d'analyse permet de reformuler les besoins sous une forme proche de ce que sera la conception et la réalisation mais tout en s'abstrayant de leurs contraintes techniques.

Le modèle d'analyse est la structure statique du modèle d'information idéal à fournir aux informaticiens en entrée de l'activité de conception qui, elle, est orientée en fonction des technologies de réalisation.

3.1. Construction du diagramme de classes

Définition :

Les diagrammes de classes expriment de manière générale la structure statique d'un système, en termes de classes et de relations entre ces classes. Une classe permet de décrire un ensemble d'objets (attributs et comportement), Le diagramme de classe est un modèle permettant de décrire de manière abstraite et générale les liens entre objets.

Une classe est composée de nom de la classe, des attributs, opérations.

Dans cette partie, nous allons présenter :

ü La liste des supports d'information

ü Dictionnaire de données

ü Diagramme des classes

La liste des supports d'information

Support	Informations
Dossier médical	- Dates maj. Dossier médical pour le patient. - Fiche Patient pour l'identité du patient. - Antécédents pour le patient. - CNAM si c'est le patient est abonné à CNAM. - Examens complémentaires pour le patient - Examens cliniques pour le patient (bilan radiologie, etc.) - Cause de consultation pour patient. - Diagnostic après la consultation.
Fiche patient	- Numéro de fiche pour patient. - Date création du fiche patient. - Nom de patient. - Nom de jeune fille du patient - Prénom de patient - Date de naissance de patient - Profession de patient - Adresse de patient - Téléphone de patient - Sexe de patient - Numéro matricule de CNAM - Type de CNAM - Validité CNAM - Code APCI
Ordonnance Médicale	- Numéro de l'ordonnance - Date ordonnance - Numéro du fiche patient. - Nom patient - Prénom patient - Numéro Matricule de CNAM - Nom de médicament - Dosage de médicament - Forme de médicament - Nombre de fois par jour. - Quantité prise
Demande APCI	- Numéro d'APCI - Nom du Docteur - Spécialité du docteur - Adresse de Cabinet Médical - Numéro de Téléphone du Cabinet - Code conventionnel du Docteur - Bénéficiaire (Le nom du patient) - Identifiant unique (CIN du patient) - Description de l'APCI - Code APCI.
Certificat Médical	- Code de certificat médical - Numéro de fiche du patient - Nom de patient - Prénom de patient - Date de naissance du patient - Nombre de jour de repos - Date de repos - Commentaire
Certificat médicale d'aptitude	- Code de certificat médical d'aptitude - Numéro de fiche du patient - Date de création - Nom de patient - Prénom de patient - Date de naissance du patient - CIN - Profession - Etat de sante - Commentaire
Lettre à un confrère	- Numéro de lettre - Date de création - Nom de patient - Prénom de patient - Nom de confrère - Prénom de confrère - Spécialité de confrère - Adresse de confère - Téléphone confrère - GSM Confrère - Etat de sante du patient

Dictionnaire des données 

Dans ce qui suit, on présente la liste des données par ordre alphabétique obtenue à partir de la liste des informations par support manipulés pour la gestion d'un cabinet médical :

Alphabet	N°	Désignation	Abréviation	Type
A	1	Adresse d'un confrère	ADR_CONF	Caractère
	2	Année d'une dépense	ANN_DEPEN	Date
	3	Adresse d'un patient	ADR_PAT	Caractère
	4	Adresse de cabinet	ADR_CAB	Caractère
B	5	Bénéficiaire (Nom d'un patient) pour la demande de l'APCI	BENEF	Caractère
C	6	Catre identité national d'un patient	CIN_PAT	Numérique
	7	Catégorie d'antécédent	CAT_ANT	Caractère
	8	Commentaire d'un certificat médical	COM_CER_MED	Caractère
	9	Commentaire d'une lettre aux confrères	COM_LET_CONF	Caractère
	10	Commentaire d'un certificat	COM_CER	Caractère
	11	Code conventionnel du Médecin	CODE_CON_DOC	Caractère
	12	Code d'un acte médical	CODE_ACTE_MED	Caractère
	13	Code d'un APCI	CODE_APCI	Numérique
D	14	Date d'une consultation	DAT_CONS	Date
	15	Diagnostic d'une consultation	DIAG_CONS	caractère
	16	Date d'un RDV	DAT_RDV	Date
	17	Date de naissance d'un patient	DAT_NAI_PAT	Date
	18	Date de validité de CNAM pour un patient	DAT_VAL_CNAM	Date
	19	Date d'une ordonnance	DAT_ORDO	Date
	20	Description d'un examen	DESC_EXAM	Caractère
	21	Dosage d'un médicament	DOSA_MEDT	Caractère
	22	Description d'un Antécédent	DESC_ANT	Caractère
	23	Date de repos d'un patient	DAT_REP_PAT	Date
	24	Date de création d'un certificat médical d'aptitude	DAT_CER_APT	Date
	25	Description d'un APCI	DESC_APCI	Caractère
	26	Date d'une lettre aux confrères	DAT_CONF	Date
	27	Date d'une recette	DAT_RECET	Date
	28	Date d'un mouvement dans totaux	DAT_TOTAUX	Date
	29	Date de création du fiche patient	DAT_FIC_PAT	Date
	30	Description de l'examen clinique	DESC_EXA_CLI	caractère
E	31	Etat d'un patient	ETAT_SAN_PAT	Caractère
F	32	Forme d'un médicament	FORM_MEDT	Caractère
H	33	Heure d'un RDV	HEURE_RDV	Date
M	34	Motif d'une consultation	MOTI_CONS	Caractère
	35	Minute d'un RDV	MIN_RDV	Date
	36	Motif d'une dépense	MOTI_DEPEN	Caractère
	37	Mois d'une dépense	MOIS_DEPEN	Caractère
	38	Montant d'une dépense	MONT_DEPEN	Numérique
	39	Mode de paiement d'une consultation	MODE_PAI_CONS	Caractère
	40	Montant d'une Suivie	MONT_APS_PAT	Numérique
	41	Montant resté d'une suivie	MONT_RS_PAT	Numérique
N	42	Numéro d'une fiche patient	NUM_FIC_PAT	Numérique
	43	Numéro d'une consultation	NUM_CONS	Numérique
	44	Numéro d'un RDV	NUM_RDV	Numérique
	45	Nom d'un patient	NOM_PAT	Caractère
	46	Nom de jeune fille d'un patient	NOM_FIL_PAT	Caractère
	47	Numéro matricule de CNAM d'un patient	NUM_MAT_PAT	Numérique
	48	Numéro d'une ordonnance	NUM_ORDO	Numérique
	49	Nom d'un médicament	NOM_MEDT	Caractère
	50	Nombre de fois de prise d'un médicament	NBR_FOIS_MEDT	Numérique
	51	Numéro d'un antécédent	NUM_ANT	Numérique
	52	Nombre de jours de repos	NBR_JR_REP	Numérique
	53	Numéro d'un APCI	NUM_APCI	Numérique
	54	Nom du Docteur	NOM_DOC	Caractère
	55	Nom de confrère	NOM_CONF	Caractère
	56	Numéro d'une lettre aux confères	NUM_LET_CONF	Numérique
	57	Numéro des totaux	NUM_TAUX	Numérique
	58	Numéro d'un Acte Médical	NUM_ACTE	Numérique
	59	Numéro d'un examen	NUM_EXAM	Numérique
	60	Numéro d'un certificat	NUM_CERT	Numérique
	61	Numéro d'une dépense	NUM_DEPEN	Numérique
	62	Numéro d'une Recette	NUM_RECET	Numérique
	63	Numéro d'un mouvement	NUM_MVT	Numérique
P	64	Prénom d'un patient	PREN_PAT	Caractère
	65	Photo (radio, scanner) d'un patient après examen	PHOT_COMP	Caractère
	66	Présence à un RDV	PRESENCE	Caractère
	67	Profession d'un patient	PROF_PAT	Caractère
	68	Poids d'un patient	POID_PAT	Numérique
	69	Périmètre d'un patient	PERI_PAT	Caractère
	70	Prénom d'un Confrère	PREN_CONF	Caractère
Q	71	Quantité prise d'un médicament	QUAN_MEDT	Numérique
R	72	Résultat d'un examen complémentaire	RES_EXAM_COMP	Caractère
S	73	Spécialité du Docteur	SPEC_DOC	Caractère
	74	Spécialité d'un Confrère	SPEC_CONF	Caractère
	75	Sexe (civilité) d'un patient	SEX_PAT	Caractère
T	76	Téléphone d'un patient	TEL_PAT	Numérique
	77	Type CNAM	TYPE_CNAM	Caractère
	78	Taille d'un patient	TAIL_PAT	Numérique
	79	Tension d'un patient	TENS_PAT	Numérique
	80	Téléphone de cabinet	TEL_CAB	Numérique
	81	Tarif d'une consultation	TARI_CONS	Numérique
	82	Total des sommes des recettes	TOT_REC	Numérique
	83	Tarif d'un acte	TARI_ACTE	Numérique
	84	Température d'un patient	TEMP_PAT	Numérique
V	85	Validité d'un RDV	VAL_RDV	Caractère

Description des classes 

Après une analyse de l'existant, nous avons dégagé les classes nécessaires pour une bonne gestion du cabinet médical.

Les classes sont :

N°	Nom des classes
1	Patient
2	CNAM
3	Ordonnance
4	Antécédents
5	Consultation
6	RDV
7	Lettre
8	Examen
9	Examcomplem
10	Examclin
11	Certificat
12	Certificat_apti
13	Certificat_med
14	Demande_APCI
15	Dépenses
16	Recettes
17	Impayés
18	MVT_caisse
19	ACTE




Description des associations

Cas description des associations porteuses des données 

Numéro	Association	Objets participants	Propriétés
01	Prescription	Médicament & Ordonnance	NBR_FOIS_MEDT ; QUAN_MEDT; FORM_MEDT

Cas description des associations non porteuses des données 

Numéro	Association	Classes participantes	Description
01	Assure	Patient, CNAM	Un patient est assuré par un seul code CNAM
02	Avoir_ANT	Patient, ANTECEDENT	Un patient peut avoir zéro ou plusieurs ANT
03	Consulte	Patient, consultation	Un patient peut effectuer une ou plusieurs consultations
04	Avoir_ORDO	Consultation, ordonnance	Une consultation il existe une seule ordonnance
05	Avoir_CERT	Consultation, certificat	Une consultation peut donner lieu zéro ou plusieurs certificats
06	enregistre	Consultation, examen	Une consolation peut nécessiter un ou plusieurs examens
07	Est_envoyé	CONSULTATION, LETTRE.	Lors d'une Consultation Une lettre est envoyée à un seul confrère
08	RDV_FIXE	RDV, consultation	Un RDV est fixé pour une consultation donnée
09	Donne_MVT	MVT_CAISSE, consultation	Une consultation est réglée à travers un MVT caisse

Diagramme de classe 

Le diagramme de classe exprime d'une manière générale la structure statique d'un système, en termes de classe et de relation entre ces classes.

Voici le diagramme de classe de notre système :

Figure 18.  Diagramme de classe

3.2. Développement du modèle dynamique

Cette partie va nous permettre d'illustrer les principaux concepts des diagrammes de séquence et d'états pour le point de vue dynamique.

3.2.1 Construction des Diagrammes de séquence

Définition

Le diagramme de séquence permet de représenter des collaborations entre des objets pour réaliser une fonctionnalité tout en mettent l'accent sur les relations temporelles. De nombreuses notations annexes permettent de préciser la nature des messages (Appel de procédures, simple signal, message répétitif ...) et les données véhiculées.

Toutes fois, ces diagrammes sont plus appropriés pour les applications critiques en temps réel, et aussi pour les applications de gestion.

Diagramme de séquence « Identification»

Figure 19. Diagramme de séquence d'identification

-La personne qui souhaite utiliser logiciel doit obligatoirement passer par l'étape de l'identification, en saisissant son login et mot de passe.

Diagramme de séquence « Enregistrement d'un RDV»

Figure 20. Diagramme de séquence Enregistrement d'un Rendez-vous

La secrétaire réalise la gestion des rendez-vous.

Diagramme de séquence « Gestion de la caisse »

Figure 21. Diagramme de séquence « Gestion de la comptabilité »

La secrétaire effectue le mouvement souhaité (encaissement ou décaissement).

Diagramme de séquence « Gestion des confrères»

Figure 22. Diagramme de séquence « Gestion des confrères »

Le remplissage des champs du formulaire est nécessaire pour la gestion des confrères.

Conclusion

Ce chapitre qui a été conçu pour l'Analyse de notre application, elle est la partie très importante pour bien maîtriser le sujet à étudier dans ce projet. Pour cela, on a bien détaillé quelques diagrammes de modélisation comme les diagrammes de classes et séquences.

Ensuite après avoir achevé la phase d'Analyse, nous avons recours au chapitre Conception.

CHAPITRE 4. CONCEPTION

Présentation

Pour bien mener notre application, nous avons choisi d'appliquer la méthodologie de conception orientée objet et nous allons utiliser UML (Unified Modeling Language) pour présenter nos différents modèles de conception. A ce stade, nous allons décrire l'environnement de réalisation, digramme de classes, diagrammes d'activités, la représentation graphique de la navigation des différentes interfaces, et la conception des schémas logiques et physique des données.

4.1. Environnement de réalisation

Dans cette partie, nous allons présenter :

Ø L'environnement matériel

Ø L'environnement logiciel

4.1.1. Environnement matériel

Au cours de la réalisation de cette application, nous avons utilisé le matériel suivant :

	Unité	Caractéristiques
Un micro-ordinateur	Processeur	Intel® Pentium® DUAL CPU
	Mémoire RAM	2040 Mo (2 GB)
	Disque dur	160 Go
	Ecran	15''

4.1.2. Environnement Logiciel

La réalisation de l'application a été développée avec les outils suivants :

Ø Microsoft Visuel Studio.NET 2008 : C'est un ensemble d'outils complet destiné à faciliter la génération d'applications bureautiques. Il permet non seulement de générer des applications bureautiques à hautes performances, mais aussi tirer parti des puissants outils de développement à base de composants que Visual Studio met à la disposition pour simplifier la conception, le développement et le déploiement de solutions d'entreprise en équipe.

Ø Le langage C# : C'est un langage orienté objet élégant et de type sécurisé qui permet aux développeurs de générer une large gamme d'applications sécurisées et fiables qui s'exécutent sur le .NET Framework. On peut utiliser C# pour créer, entre autres, des applications clientes Windows traditionnelles, des services Web XML, des composants distribués, des applications client-serveur et des applications de base de données. Microsoft Visual C# 2008 fournit un éditeur de code avancé et des concepteurs d'interfaces utilisateur pratiques.

Ø Microsoft SQL Server 2005 : c'est un SGBD (Système de Gestion de Base de Données).

Ø Système d'exploitation : Microsoft Windows 7.

Ø Microsoft WORD 2007 : pour le traitement de texte.

Ø Microsoft Power Point 2007 : pour la représentation du projet.

Ø IBM Rational Rose Enterprise Edition: est un puissant outil de conception de base de données avec lequel en peut présenter les différents modèles de conception.

4.2. Conception des classes

C'est une collection d'éléments de modèle statique, tels que des classes, des interfaces et leurs relations, connectés entre eux comme un graphe.

Il représente la description statique du système en intégrant dans chaque classe la partie dédiée aux données et celle consacrée aux traitements. C'est le diagramme pivot de l'ensemble de la modélisation d'un système.

ü Identification des classes :

Une classe est une description d'un groupe d'objets partageant un ensemble commun de propriétés (les attributs), de comportements (les opérations) et de relations avec d'autres objets (les associations et les agrégations).

ü Une classe contient :

Des attributs (ou champs, ou variables d'instances) : Les attributs d'une classe décrivent la structure de ses instances (les objets).

Des méthodes (ou opérations de la classe) : Les méthodes décrivent les opérations qui sont applicables aux instances de la classe.

ü Une agrégation :

Est une association correspondant à une relation qui lorsqu'elle est lue dans un sens signifie "est une partie de" et lorsqu'elle est lue dans l'autre sens elle signifie "est composé de".

v Diagrammes de classes



Figure 23.  Conception des classes

v Diagrammes d'activité

Le diagramme d'activités permet de décrire un flot de contrôle entre opérations. Il s'agit de décrire des enchaînements de fonctionnalités. Il complète donc les cas d'utilisation au niveau de l'analyse des besoins.

ï Les actions sont représentées par des rectangles aux coins arrondis.

ï Les transitions entre les actions sont représentées par des flèches.

ï Le diagramme comprend un point de départ et un ou plusieurs points d'arrivée.

ï Un événement peut accompagner la transition du point de départ seulement.

Diagramme d'activité d'identification

Figure 24. Diagramme d'activité d'authentification

v Diagramme d'activité « gestion des rendez-vous»

Figure 25.  Diagramme d'activité gestion des rendez-vous

v Diagramme d'activité «gestion  des fiches patient »

Figure 26. Diagramme d'activité gestion du fiche patient

v Diagramme d'activité« gestion des consultations et dossiers médicaux»

Figure 27.  Diagramme d'activité gestion et suivie du dossier médical

4.3. Conception des schémas logiques et physique des données

Cette partie consiste à transformer les objets du modèle de classes en relations. Une relation comporte un nom (qui correspondra au nom de la table dans SQL Serveur), des attributs (qui correspondent aux propriétés conceptuelles ou organisationnelles et correspondent au niveau physique aux champs de la table).

Durant la phase d'analyse, on a suivi comme processus de démarche orienté objet le processus de l'UML (Unified Modeling Langage) comme langage de modélisation.

Puisque nous allons implémenter notre base de données avec SQL serveur 2005, nous avons besoin de traduire certains objets pour qu'ils soient compatibles à un environnement relationnel. Pour cela et pour traduire notre modèle on peut procéder aux règles suivantes :

REGLE N°1 : Toute classe d'entités du diagramme entité/association est représentée par une relation dans le schéma relationnel équivalent. La clé de cette relation est l'identifiant de la classe d'entités correspondante.

Exemple :


Avec la transformation donc :



PATIENT ( NUM_FIC_PAT, CIN_PAT, DAT_FIV_PAT, NOM_PAT, .......CODE_APCI )

REGLE N°2 : Toute classe d'association est transformée en relation. La clé de cette relation est composée de tous les identifiants des entités participantes.

Exemple :



Au niveau implémentation on aura une relation de plus dont la clé est composée des deux clés des objets participants à cette relation. On aura donc :

MEDICAMENT ( CODE_MEDT, NOM_MEDT, DOSA_MEDT, PRESENTATION )

ORDONNANCE ( NUM_ORDO, DAT_ORDO )

PRESCRIPTION (CODE_MEDT , NUM_ORDO , NBR_FOIS_MEDT, QUANT_MEDT, FORM_MEDT )

REGLE N°3 (optimisation) : Toute classe d'associations reliée à une classe d'entités avec une cardinalité de type 0,1 ou 1,1 peut être fusionnée avec la classe d'entités. Dans ce cas on déplace les attributs de la classe d'associations vers ceux de la relation traduisant la classe d'entités.

REGLE N°4 Le modèle relationnel de base ne supporte pas le concept d'héritage.

L'héritage permet d'exprimer des propriétés communes à plusieurs classes.

Comment exprimer l'héritage ?

Classe mère : CERTIFICAT

Classe filles : CERTIFICAT_MED, CERTIFICAT_APT.



Toutefois, trois solutions existent pour implémenter un héritage.

* Solution 1 : Traduire la classe fille et mère par une seule relation correspond à la classe fille et Les attributs doivent être peu nombreux dans la classe mère

Exemple :

CERTIFICAT_MED ( NUM_CERT, COM_CERT, DAT_NAIS_PAT, NBR_JR_REP, DAT_REP_PAT ).

CERTIFICAT_APT ( NUM_CERT, COM_CERT, DAT_NAIS_PAT, NBR_JR_REP, DAT_REP_PAT, CIN_PAT, ETAT_SAN_PAT, DAT_CERT_APT, PROF_PAT).

*Solution 2 : Traduire la classe fille et mère par une seule relation correspondant à la classe mère en ajoutant un attribut indiquant le sous-type .Les attributs doivent être peu nombreux dans la classe fille Certains attributs seront non renseignés dans la relation

Exemple :

CERTIFICAT ( NUM_CERT, COM_CERT, TYPE, DAT_NAIS_PAT, NBR_JR_REP, CIN_PAT, DAT_REP_PAT, CIN_PAT, ETAT_SAN_PAT, DAT_CERT_APT, PROF_PAT ).

*Solution 3 :

- La classe mère correspond à une première relation

- La classe fille correspond à une seconde relation

-Les attributs de la classe fille sont répartis dans les 2 relations

-L'identité de l'objet est préservée en utilisant le même identifiant dans les 2 relations (et la même valeur d'identifiant pour les 2 filles)

Exemple :

CERTIFICAT ( NUM_CERT, COM_CERT, DAT_NAIS_PAT ).

CERTIFICAT_MED ( NUM_CERT, NBR_JR_REP, DAT_REP_PAT ).

CERTIFICAT_APT ( NUM_CERT, COM_CERT, DAT_NAIS_PAT, NBR_JR_REP, DAT_REP_PAT, CIN_PAT, ETAT_SAN_PAT, DAT_CERT_APT, PROF_PAT).

CERTIFICAT_APT ( NUM_CERT, CIN_PAT, ETAT_SAN_PAT, DAT_CERT_APT, PROF_PAT).

4.3.1. Construction des schémas logique des données brutes

CERTIFICAT ( NUM_CERT, COM_CERT, DAT_NAIS_PAT, NBR_JR_REP#, CIN_PAT# ).

PATIENT ( NUM_FIC_PAT, CIN_PAT, DAT_FIC_PAT, NOM_PAT, PREN_PAT, DAT_NAIS_PAT, PROF_PAT, ADRE_PAT, TEL_PAT, SEX_PAT, CODE_APCI, NUM_MAT_PAT#, NUM_ANT#, NUM_RDV# ).

EXAMEN ( NUM_EXAM, DESC_EXAM, TAILE_PAT#, RES_EXAM_COMP# ).

ORDONNANCE ( NUM_ORDO, DAT_ORDO )

MEDICAMENT ( CODE_MEDT, NOM_MEDT, DOSA_MEDT, PRESENTATION )

PRESCRIPTION ( NUM_ORDO, CODE_MEDT, NBR_FOIS_MEDT, QUAN_MEDT, FORM_MEDT ).

RDV (NUM_RDV, PRESENCE, DAT_RDV, HEUR_RDV, MIN_RDV, NUM_FIC_PAT#)

CONSULTATION ( NUM_CONS, NUM_FIC_PAT, DAT_CONS, MOTI_CONS, DIAG_CONS, NUM_ORDO#, NUM_MVT#, NUM_FIC_PAT#, NUM_ACTE#, NUM_APCI#, NUM_CERT#, NUM_LETT_CONF# ).

TYPE_MOUVEMENT ( TYPE_MVT, NUM_DEPEN#, TEL_PAT#, NUM_RECET# ).

DEPENSES ( NUM_DEPEN, ANN_DEPEN, MOIS_DEPEN, MOTIF_DEPEN, MONT_DEPEN ).

IMPAYES ( TEL_PAT, MONT_APS_PAT, DAT_IMP, MONT_PAT ) .

RECETTES ( NUM_RECET, DAT_RECET, TARI_CONS, MODE_PAI_CONS )

4.3.2. Construction des schémas physique des données.

Classe		Attribut		Méthode
N°	Nom		N°		champs		Type
1	Patient		42		NUM_FIC_PAT (*)		Numérique	AJOUTER ( ) AFFICHER ( ) MODIFIER ( ) IMPRIMER ( )
			6		CIN_PAT		Numérique
			29		DAT_FIC_PAT		Date
			45		NOM_PAT		Caractère
			64		PREN_PAT		Caractère
			17		DAT_NAI_PAT		Date
			67		PROF_PAT		Caractère
			3		ADR_PAT		Caractère
			76		TEL_PAT		Numérique
			75		SEX_PAT		Caractère
			13		CODE_APCI		Numérique
2	CNAM		47		NUM_MAT_PAT (*)		Numérique	AJOUTER ( ) AFFICHER ( ) MODIFIER ( ) IMPRIMER ( )
			77		TYPE_CNAM		Caractère
			18		DAT_VAL_CNAM		Date
3	Ordonnance		48		NUM_ORDO (*)		Numérique	ETABLIR ( ) AFFICHER ( ) IMPRIMER ( )
			19		DAT_ORDO		Date
			49		NOM_MEDT		Caractère
			21		DOSA_MEDT		Caractère
			32		FORM_MEDT		Caractère
			50		NBR_FOIS_MEDT		Numérique
			71		QUAN_MEDT		Numérique
4	Antécédents		51		NUM_ANT (*)		Numérique	AJOUTER ( ) MODIFIER ( )
			7		CAT_ANT		Caractère
			22		DESC_ANT		Caractère
5	Consultation		43		NUM_CONS (*)		Numérique	AJOUTER ( ) MODIFIER ( )
			14		DAT_CONS		Date
			34		MOTI_CONS		Caractère
			15		DIAG_CONS		caractère
6	RDV		44		NUM_RDV (*)		Numérique	AJOUTER ( ) AFFICHER ( ) MODIFIER ( ) SUPPRIMER ( )
			66		PRESENCE		Caractère
			16		DAT_RDV		Date
			33		HEURE_RDV		Date
			35		MIN_RDV		Date
			85		VAL_RDV		Caractère
7	Lettre		56		NUM_LET_CONF (*)		Numérique	AJOUTER ( ) AFFICHER ( ) MODIFIER ( ) IMPRIMER ( )
			26		DAT_CONF		Date
			55		NOM_CONF		Caractère
			70		PREN_CONF		Caractère
			74		SPEC_CONF		Caractère
			9		COM_LET_CONF		Caractère
			31		ETAT_SAN_PAT		Caractère
8	Examen		59		NUM_EXAM (*)		Numérique	AJOUTER ( ) MODIFIER ( ) IMPRIMER ( )
			20		DESC_EXAM		Caractère
9	Examcomplem		72		RES_EXAM_COMP(*)		Caractère
			65		PHOT_COMP		Caractère
10	Examclin		78		TAIL_PAT (*)		Numérique
			68		POID_PAT		Numérique
			79		TENS_PAT		Numérique
			69		PERI_PAT		Caractère
			84		TEMP_PAT		Numérique
11	Certificat		60		NUM_CERT (*)		Numérique	ETABLIR ( ) MODIFIER ( ) INPRIMER ( )
			10		COM_CER		Caractère
			17		DAT_NAI_PAT		Date
12	Certificat_apti		6		CIN_PAT (*)		Numérique	ETABLIR ( ) MODIFIER ( ) INPRIMER ( )
			24		DAT_CER_APT		Date
			31		ETAT_SAN_PAT		Caractère
			67		PROF_PAT		Caractère
13	Certificat_med		52		NBR_JR_REP (*)		Numérique	ETABLIR ( ) MODIFIER ( ) INPRIMER ( )
			23		DAT_REP_PAT		Date
14	Demande_APCI		53		NUM_APCI (*)		Numérique	ETABLIR ( ) MODIFIER ( ) INPRIMER ( )
			54		NOM_DOC		Caractère
			73		SPEC_DOC		Caractère
			80		TEL_CAB		Numérique
			11		CODE_CON_DOC		Caractère
			5		BENEF		Caractère
			47		NUM_MAT_PAT		Numérique
			25		DESC_APCI		Caractère
			13		CODE_APCI		Numérique
15	Dépenses		61		NUM_DEPEN (*)		Numérique	AJOUTER ( ) INPRIMER ( )
			2		ANN_DEPEN		Date
			37		MOIS_DEPEN		Caractère
			36		MOTI_DEPEN		Caractère
			38		MONT_DEPEN		Numérique
16	Recettes		62		NUM_RECET (*)		Numérique	AJOUTER ( ) INPRIMER ( )
			27		DAT_RECET		Date
			81		TARI_CONS		Numérique
			39		MODE_PAI_CONS		Caractère
17	Impayés		76		TEL_PAT (*)		Numérique	AJOUTER ( ) MODIFIER ( ) INPRIMER ( )
			40		MONT_APS_PAT		Numérique
			41		MONT_RS_PAT		Numérique
18	MVT_caisse		63		NUM_MVT (*)		Numérique
19	ACTE		58		NUM_ACTE (*)		Numérique	AJOUTER ( ) INPRIMER ( )
			12		CODE_ACTE_MED		Caractère
			83		TARI_ACTE		Numérique

Remarque :

Le modèle physique peut être confondu dans le modèle logique, selon les outils utilisés.

Le modèle physique peut aussi être défini comme étant l'ensemble des scripts SQL de création des objets dans la base de données.

4.4. Présentation des interfaces

Notre application de gestion D'un cabinet Médical sur mesure permet de gérer les consultations, les Rendez-vous, le dossier médical, etc. et d'offrir à l'utilisateur quelques accessoires à savoir la l'heure et la date actuelle, une calculatrice et un navigateur d'Internet. La multitude des taches que notre application est capable de faire engendrer un grand nombre de fenêtres. On va essayer de sélectionner quelques fenêtres qui nous paraissent importantes pour les intégrer dans le présent mémoire.

Interface authentification



Figure 28. Fenêtre d authentification

Description

C'est la première fenêtre qui s'affiche si on exécute l'application, toute personne qui veut bénéficier des services du logiciel doit s'authentifier avec un login et mot de passe. Cette page comporte aussi deux boutons dont le premier est « OK » qui permet l'accès à la fenêtre principale si le login et le mot de passe sont vrais. Si ces données sont fausses un message d'erreur s'affiche. Le deuxième bouton est « Annuler » pour annuler l'accès et quitter.

Espace  Secrétaire



Figure 29. Menu pour secrétaire

Description

Dans le cas où la connexion se fait par la secrétaire, l'accès est donné seulement aux rubriques : Gestion des rendez-vous, gestion des fiches du patient et gestion de la comptabilité.

Gestion des patients



Figure 30. Interface gestion des patients

Description

A l'arrivée d'un nouveau patient la secrétaire remplit une nouvelle fiche.



Figure 31. Interface gestion des rendez-vous

Description

La gestion des rendez-vous est une tâche essentielle de la secrétaire, celle-ci vérifie la disponibilité de la date demandée et par la suite elle ajoute un rendez-vous en saisissant les renseignements nécessaires (commentaire).



Figure 32. Interface gestion de la CNAM

Description

Le formulaire pour la gestion de la CNAM l'une des tâche très importante, les informations relatives aux patients disposant d'une carte CNAM pour le remboursement par la CNAM.

La gestion des exceptions

Dans notre domaine d'étude, on a essayé d'exploiter les fonctionnalités les plus avantageuses de C#, parmi lesquelles la gestion des exceptions et des erreurs qui représente la tâche primordiale dans la phase de test du logiciel.

Voici des exemples de messages qui peuvent rencontrer l'administrateur lors de l'utilisation de notre logiciel. Ces messages empêchent les erreurs de saisie, et guident l'utilisateur pour comprendre rapidement le fonctionnement de l'application.



Figure 33. Interface gestion de la comptabilité « Dépenses »

Description

Une exception a été déclenchée suite à une opération pour les dépenses, Message d'erreur pour le champ de montant, sa valeur n'est pas de type Numérique.



Figure 34. Interface gestion de la comptabilité « Recettes

Description

Une exception a été déclenchée suite à une opération pour les Recettes, Message d'erreur pour les champs de Tarif consultation et Mode de paiement ne sont pas remplis.



Figure 35. Interface gestion des rendez-vous « Nouveau RDV »

Description

Une exception a été déclenchée suite à une opération d'ajout d'un Rendez vous, Message d'erreur pour la Date et l'heure qui sont déjà réservées par le patient : sidi Med......

Espace  Médecin

Description

Dans le cas où la connexion a été établé fait pas le médecin, on remarque que son menu contient toutes les fonctionnalités, il peut accéder à n'importe quelle tâches.



Figure 36. Menu principale pour Médecin

Description

C'est la partie réservée au médecin, qui englobe toutes les fonctionnalités du système.



Figure 37. Interface Pour la Gestion et suivi du dossier médical (Inf. Méd.)

Description

La gestion suivie du dossier médical qui contient des informations sur le patient et qui facilite la consultation de médecin.

>

Figure 38. Interface Pour la Gestion des Médicaments

Description

La gestion des médicaments en mode recherche par Famille de médicament dont « ANTIDEPRESSEUR » suite à la recherche on a trouvé 3 médicaments.

Conclusion

Dans ce chapitre, nous avons présentés notre environnement de travail matériel et logiciel, les diagrammes de classes avec des schémas logiques et physiques des données ainsi que les principales interfaces de notre application avec leurs descriptions.

Grâce au schéma des relations, on connaît désormais les tables à créer pour l'application ainsi que les champs. Le dossier d'analyse ainsi réalisé va permettre de mettre en oeuvre une solution au niveau physique l'implantation de la structure de la base grâce au schéma logique des données relationnel.

CONCLUSION

Ce projet nous à permis d'avoir une approche complète du développement de logiciel et une bonne initiation au cycle complet du développement de logiciel, de la conception à la validation en passant par les différentes étapes incrémentales de codage et de tests et nous a appris aussi à concevoir une base de données complète.

La réalisation de notre application est à présent achevée, elle comporte les fonctionnalités suivantes :

v Gestion et Suivi du Dossier Médical

v Gestion de la CNAM

v Gestion des Rendez-vous.

v Gestion du Fiche Patients.

v Gestion de la Comptabilité.

Elle a comporté deux volets à savoir le volet conception et volet réalisation :

- Sur le plan conceptuel nous avons utilisée le langage UML que nous avons bien maitrisé à travers l'étude effectuée de l'application gestion du cabinet médical.

- Sur le plan pratique, cette application a été réalisé avec le Système de Gestion Bases de Données de Microsoft SQL serveur 2005, Visual Studio .NET comme environnement de développement et langage de programmation C#.

Nous avons donc eu l'opportunité d'approfondir nos connaissances que ce soit au plan scientifique ou personnel. Pour conclure, on a évalué les principaux avantages et les points forts du logiciel C# pour améliorer la gestion d'un cabinet médical.

Comme une autre expérience au niveau de l'application des concepts de langages, c'est normal de ne pas pouvoir éviter certains problèmes et difficultés au niveau de la modélisation conceptuelle et au niveau de l'implémentation et la programmation. Cependant, nous avons essayé de dégager les solutions les mieux adaptées à nos objectifs, nos contraintes et nos moyens disponibles. Ces solutions ne prétendent nullement être les meilleures, car en informatique, il n'y a pas de solution absolue.

II est à noté que cette application peut être améliorée, pour répondre aux besoins des autres spécialités plus appropriées, ainsi que le suivi de rapport d'activités des dossiers médicaux.

BIBLIOGRAPHIE

Les ouvrages

[Muller 03] Modélisation objet avec UML, P.-A. Muller, 2003, Eyrolles.

[Roques 03] UML en action. De l'analyse des besoins à la conception en Java, P. Roques, 2003, 2 ^e Edition Eyrolles.

[Roques 06] UML 2 par la pratique. Études de cas et exercices corrigés, P. Roques, 2006, 5 ^e Edition Eyrolles.

Les supports numériques

CD-ROM formation Access 2000, Microsoft.

CD-ROM formation Introduction à la Visual Studio 2008 .Net, Microsoft.

Les sites Internet consultés

[http://tahe.developpez.com/dotnet/csharp/], Langage C# 2008 : classes, interfaces, héritage, polymorphisme.

[ http://www.csharp.com], Notion de Programmation.

[http://www.supinfo-projects.com], Guide des étapes des projets informatiques

ANNEXE

1. Vue Générale sur UML

UML (Unified Modeling Language) a été proposé afin de standardiser les produits du développement (modèle, notations, diagrammes). Il est en effet très difficile de standardiser le processus de développement qui dépend des personnes, des applications, des cultures, etc.

UML se propose de créer un langage de modélisation utilisable à la fois par les humains (forme graphique) et les machines (syntaxe précise).

En effet UML repose sur deux ensembles de vues (i.e. Statique et Dynamique)

UML définit 9 diagrammes. Ceux-ci permettent de visualiser et de manipuler les éléments dits de « modélisation ». Chaque diagramme UML ci-dessous possède une structure précise.

Vue statique de l'UML

Diagramme de cas d'utilisation : représentation des fonctions du système du point de vue de l'utilisateur.

Diagramme de classe : représentation de la structure statique en termes de classe et de relations entre celles ci. L'intérêt du diagramme de classe est de modéliser les entités du système d'information.

Diagramme d'objet : C'est une instance du diagramme de classe, il représente la structure statique du système modélisé en montrant des objets et les liens entre eux (relations sémantique).

Diagramme de composant : il permet de décrire l'architecture physique et statique d'une application en termes de modules : fichiers sources, librairies, exécutables, etc.
Ils montrent la mise en oeuvre physique des modèles de la vue logique avec l'environnement de développement.

Vue Dynamique de l'UML

Diagramme d'activités : représentation du comportement d'un processus (méthode ou cas d'utilisation) en termes d'actions.

Diagramme de collaboration : représentation spatiale des objets, et des liens entre eux sous forme d'interactions. Il permet de mettre en évidence les dépendances entre les différents objets impliqués dans l'exécution d'un processus ou d'un cas d'utilisation.

Diagramme de déploiement : montre la disposition physique des matériels qui composent le système et la répartition des composants sur ces matériels.

Diagramme d'état de transition : représentation du comportement d'une classe en termes d'état.

Diagramme de séquence : représentation temporelle des objets et de leurs interactions. Il permet de documenter un cas d'utilisation ou il est utilisé pour un usage informatique en détaillant les différentes interactions entre les objets, la répartition des flots de données ainsi que les messages échangés (procédure, évènements).

En résume :

· UML est une notation, pas une méthode.

· UML est un langage de modélisation objet.

· UML convient pour toutes les méthodes objets

2. Vue générale sur le langage C# Sharp

Les applications .NET Framework reposent sur les services du Common Language Runtime et tirent profit de la bibliothèque de classes du .NET Framework et sont conçus pour faciliter la création, le déploiement et la gestion d'applications et de composants qui ciblent le .NET Framework. Cette section contient des informations détaillées sur ces outils.

Ø Langage C#

Comme la syntaxe C#, simple et très parlante, utilise moins de 90 mots clés, elle est facile à assimiler. La syntaxe de C# est facile à reconnaître à ses accolades si vous connaissez déjà les langages C, C++ ou Java. Si vous avez déjà développé dans un de ces langages, vous pouvez devenir très vite productif en C#.

En tant que langage orienté objet, C# prend en charge les concepts d'encapsulation, d'héritage et de polymorphisme.

Ø Crystal Report

Crystal Reports est un composant de Visual Studio depuis 1993 et constitue maintenant l'outil standard pour la création de rapports dans Visual Studio 2008. Fourni avec chaque copie de Visual Studio 2008, il est directement intégré dans l'environnement de développement.

Crystal Reports pour Visual Studio 2008 permet de créer des rapports au contenu interactif et soigneusement présenté dans l'environnement Windows. Avec Crystal Reports pour Visual Studio 2008, vous pouvez créer des rapports complexes de qualité professionnelle dans un programme d'interface utilisateur graphique.

3. Vue générale sur SQL Server 2005

Microsoft SQL (Structured Query Language) Server 2005 Édition Entreprise est un Système de Gestion de Base de Données et d'analyse conçue pour le développement des solutions de «Datawarehouse », d'applications métier et de commerce électronique.

Avantage :

ü Il est facile d'utilisation, possède un éditeur d'analyse assez puissant et didactique ;

ü Il assure la sécurité des données et des applications : il est efficace pour garantir l'intégrité des applications dans n'importe quel environnement réseau, grâce à une sécurité fondée sur les rôles et le chiffrage de fichiers et de réseaux ;

ü Il simplifie l'administration de la base de données Des fonctions de réglage et de maintenance automatiques permettent aux administrateurs de se focaliser sur d'autres tâches essentielles,

Inconvénients :

ü Il est propriétaire : Documentation complète fournie avec la licence ;

ü Son coût est élevé : c'est l'un des SGBD les plus chers sur le marché.