Vous êtes sur la page 1sur 214

Université de Tunis Institut Supérieur de Gestion

Université de Tunis Institut Supérieur de Gestion Mémoire de maîtrise en Informatique Appliquée à la Gestion

Mémoire de maîtrise en Informatique Appliquée à la Gestion

Conception et Réalisation d’un logiciel de facturation pour une polyclinique privée

Manel BOUZID

Réalisé par :

Mohamed Anis BACHTOBJI

Encadré par :

Pr. Mohamed Salah GOUIDER

Année Universitaire 2002/2003

par : Mohamed Anis BACHTOBJI Encadré par : Pr. Mohamed Salah GOUIDER Année Universitaire 2002/2003 Polyclinique

Polyclinique Taoufik

A mes très chers parents

Pour tout l’amour dont vous m’avez entouré, pour tout ce que vous avez fait pour moi.

Je ferai de mon mieux pour rester un sujet de fierté à vos yeux avec l’espoir de ne jamais vous décevoir.

Que ce modeste travail, soit l’exaucement de vos veux tant formulés et de vos prières quotidiennes.

A mes très chers sœurs et frère

Vous occupez une place particulière dans mon cœur. Je vous dédie ce travail en vous souhaitant un avenir radieux, plein de bonheur et de succès.

A mes très chers amis

En souvenir de nos éclats de rire et des bons moments. En souvenir de tout ce qu’on a vécu ensemble. J’espère de tout mon cœur que notre amitié durera éternellement.

Manel.

A mes très chers parents

Je vous dois ce que je suis aujourd’hui grâce à votre amour, à votre patience et vos innombrables sacrifices.

Que ce modeste travail, soit pour vous une petite compensation et reconnaissance envers ce que vous avez fait d’incroyable pour moi.

Que dieu, le tout puissant, vous préserve et vous procure santé et longue vie afin que je puisse à mon tour vous combler.

A mes très chers sœurs et frères

Aucune dédicace ne serait exprimer assez profondément ce que je ressens envers vous.

Je vous dirais tout simplement, un grand merci, je vous aime.

A mes très chers amis

En témoignage de l’amitié sincère qui nous a liée et des bons moments passés ensemble. Je vous dédie ce travail en vous souhaitant un avenir radieux et plein de bonnes promesses.

Mohamed Anis.

A notre encadreur

Monsieur Mohamed Salah GOUIDER.

Nous vous remercions pour le grand honneur que vous nous avez fait en nous proposant le sujet de ce mémoire de fin d’étude.

Nous avons eu l’honneur et le privilège de travailler sous votre assistance et de profiter de vos qualités humaines, professionnelles et de votre grande expérience.

Vous nous avez guidé tout le long de ce travail dont vous avez mis à ur, l’élaboration avec l’amabilité et le dynamisme qui vous caractérisent.

Puisse ce modeste travail, vous satisfaire et témoigner de notre gratitude et connaissance pour l’aide et les conseils que vous nous avez prodigués, ainsi que pour le savoir que vous nous avez inculqué.

Mohamed Anis et Manel.

Avant-propos

A yant atteint la quatrième année de maîtrise en Informatique appliquée à la Gestion, un projet de fin d’étude nous est demandé d’accomplir. Notre choix s’est rapporté à concevoir et réaliser un produit logiciel.

Après de nombreuses recherches et demandes de stages, nous avons réussi à obtenir l’accord des responsables de la polyclinique Taoufik grâce à Mr. Guider, notre professeur et encadreur. Nous nous sommes trouvés dans un groupe de huit personnes, amenés à réaliser un logiciel de facturation, de gestion de pharmacie et de personnel :

tous les besoins informatiques d’une polyclinique à part la comptabilité. La répartition des tâches de chaque binôme s’est faite par module, c-à-d que

chaque binôme doit réaliser un module. Ceci dit, les modules doivent être

intégrés au sein d’un même système et réalisés avec les mêmes méthodes et outils. Nous avons plusieurs décisions à prendre en groupe surtout lorsqu’il s’agira de mettre en place la base de données et de concevoir les interfaces utilisateurs. Nous avons choisi nos outils d’une manière cohérente avec notre philosophie de travail. En effet, nous voulons que notre système soit ouvert, extensible, évolutif et ergonomique tout en gardant son efficacité. L’objectif de la direction, après notre départ, étant la mise en place du système en intranet et internet.

Sommaire

Introduction générale

1

Présentation de la polyclinique «Taoufik»

5

Chapitre I : La phase d’inception

8

I.1 - Contexte du système :

8

I.1.1- Circuit du dossier patient :

9

I.1.2-

La facture :

10

I.1.3 - Les conventions :

11

I.2 - Besoins fonctionnels et besoins non fonctionnels :

11

I.3- Cas d’utilisation initiaux :

13

-I-

I.3.1- Diagramme de cas d’utilisation initial:

14

I.3.2- Description détaillée des cas d’utilisation :

14

I.3.3- Priorité des cas d’utilisation :

17

I.4- Risques critiques :

17

I.5- Les interfaces utilisateurs :

18

I.6 – Analyse des cas d’utilisation prioritaires :

20

I.6.1- Analyse du cas d’utilisation « Créer un dossier patient » :

20

I.6.2- Analyse du cas d’utilisation « Créer un patient » :

23

I.6.3- Analyse du cas d’utilisation « Rechercher un patient » :

25

Conclusion :

27

Chapitre II : La phase d’elaboration

28

II.1 – Capture des besoins :

29

II.1.1- Modèle final de cas d’utilisation :

29

II.1.2- Description des cas d’utilisation :

31

II.2 – Analyse :

32

II.2.1- Analyse des cas d’utilisation secondaires :

32

II.2.1.1- Analyse du cas d’utilisation « Modifier un patient » :

32

II.2.1.2- Analyse du cas d’utilisation « Supprimer un patient » : 34

II.2.1.3- Analyse du cas d’utilisation « Modifier un dossier patient » :

36

II.2.1.4- Analyse du cas d’utilisation « Annuler un dossier patient » :

38

II.2.1.5- Analyse du cas d’utilisation « Rechercher un dossier patient » :

40

II.2.1.6- Analyse du cas d’utilisation « Passer une prestation à une facture patient » :

43

II.2.1.7- Analyse du cas d’utilisation « passer un produit à une facture patient » :

45

II.2.1.8- Analyse du cas d’utilisation « Editer facture patient » : 48

50

II.2.2- Analyse des nouveaux cas d’utilisation identifiés :

-II-

II.2.2.1- Analyse du cas d’utilisation « S’identifier » :

50

II.2.2.2- Analyse du cas d’utilisation « Paramétrer médecins » :

52

II.2.2.3 Analyse du cas d’utilisation « Paramétrer chambres » :

54

II.2.2.4- Analyse du cas d’utilisation « Paramétrer cuisine » :

56

II.2.2.5- Analyse du cas d’utilisation « Paramétrer prestations » :

58

II.2.2.6- Analyse du cas d’utilisation « Paramétrer conventions » :

60

II.2.2.7- Analyse du cas d’utilisation « Paramétrer fluides et appareillage » :

62

II.2.2.8- Analyse du cas d’utilisation « Paramétrer tarifs accompagnant » :

63

II.2.2.9- Analyse du cas d’utilisation « Enregistrer règlement » :

65

II.2.2.10- Analyse du cas d’utilisation « Passer un produit alimentaire à une facture

patient » :

67

II.2.2.11- Analyse du cas d’utilisation « Enregistrer accompagnant » :

69

II.2.2.12- Analyse du cas d’utilisation « Passer un fluide ou appareillage à une facture patient » :

71

II.3 – Conception :

73

II.3.1-Conception des cas d’utilisation prioritaires :

73

II.3.1.1- Conception du cas d’utilisation « Créer un dossier patient » :

73

II.3.1.2- Conception du cas d’utilisation « Créer un patient » :

76

II.3.1.3- Conception du cas d’utilisation « Rechercher un patient » :

76

II.3.2-Conception des cas d’utilisation secondaires :

83

II.3.2.1- Conception du cas d’utilisation « Modifier un patient » :

83

II.3.2.2- Conception du cas d’utilisation « Supprimer un patient » :

85

II.3.2.3- Conception du cas d’utilisation « Modifier un dossier patient » :

87

II.3.2.4- Conception du cas d’utilisation « Annuler un dossier patient » :

89

II.3.2.5- Conception du cas d’utilisation « Rechercher un dossier patient » :

91

II.3.2.6- Conception du cas d’utilisation « Passer une prestation à une facture patient » :

94

-III-

II.3.2.7- Conception du cas d’utilisation « Passer un produit à une facture patient » :

 

96

II.3.2.8- Conception du cas d’utilisation « Editer facture patient » :

99

II.4 – Implémentation:

102

II.4.1-Construction d’un schéma initial de la base de données :

102

II.4.1.1- Description et diagrammes des classes entités prioritaires:

102

II.4.1.2- Règles de passage d’un diagramme de classes à une base de données relationnelle:

104

II.4.1.3- Schéma initial de la base de données :

104

II.4.2-Implémentation des cas d’utilisation prioritaires :

106

II.5 – Test :

109

II.5.1-Test du cas d’utilisation « Créer patient » :

109

II.5.2-Test du cas d’utilisation « Rechercher patient » :

110

II.5.3-Test du cas d’utilisation « Créer dossier » :

110

Conclusion :

110

Chapitre III : La phase de construction

111

III.1 – Conception des nouveaux cas d’utilisation :

137

III.1.1- Conception de cas d’utilisation « S’identifier » :

112

III.1.2- Conception de cas d’utilisation « Paramétrer médecins » :

114

III.1.3- Conception de cas d’utilisation « Paramétrer chambres » :

116

III.1.4- Conception de cas d’utilisation « Paramétrer cuisine » :

118

III.1.5- Conception de cas d’utilisation « Paramétrer prestations » :

120

III.1.6- Conception de cas d’utilisation « Paramétrer conventions » :

122

III.1.7- Conception de cas d’utilisation « Paramétrer fluides et appareillage » :

124

III.1.8- Conception de cas d’utilisation « Paramétrer tarifs accompagnant » :

126

III.1.9- Conception de cas d’utilisation « Enregistrer règlement » :

128

-IV-

III.1.10- Conception de cas d’utilisation « Passer un produit alimentaire à une facture patient » :

130

III.1.11- Conception de cas d’utilisation « Enregistrer accompagnant » :

133

III.1.12- Conception de cas d’utilisation « Passer un fluide ou un appareillage à une facture patient » :

135

III.2 – Implémentation :

137

III.2.1- Construction du schéma final de la base de données :

137

III.2.1.1-Description et diagramme des classes entités importantes :

137

III.2.1.2-Schéma final de la base de données :

144

III.2.2- Architecture matérielle mise en place :

150

III.2.3- Implémentation des cas d’utilisation secondaires et nouveaux:

152

III.3 – Test :

154

III.3.1-Test du cas d’utilisation « Modifier un patient » :

154

III.3.2-Test du cas d’utilisation « Supprimer un patient » :

155

III.3.3-Test du cas d’utilisation « Editer facture patient » :

155

III.3.4-Test du cas d’utilisation « S’identifier » :

155

III.3.5-Test des cas d’utilisation de paramétrage :

155

III.3.6-Test des cas d’utilisation de passations des biens et des services :

156

III.3.7-Test du cas d’utilisation « Enregistrer accompagnant » :

156

Conclusion :

157

Chapitre IV : La phase de transition

158

Conclusion générale

160

Annexe (A) : Le processus unifié et UML

163

I - Unified Modeling Language :

164

I.1 – L’approche Orientée Objet :

164

I.2 – La notation UML :

168

-V-

II

– Le processus unifié :

171

Annexe (B) : Rational Rose, Java et Oracle

175

I – Rational Rose 98i :

174

II

– Oracle JDeveloper :

175

III – Oracle 9i :

180

Annexe (C) : Les interfaces utilisateurs

184

Glossaire

193

-VI-

Introduction Générale

C ette introduction fera l’objet d’une brève présentation de l’application que nous allons concevoir et réaliser, des outils et des méthodes choisis, suivi du plan général du processus de développement.

Notre tâche consiste à réaliser le module de facturation, intégré dans la totalité du système de gestion de la polyclinique. Bien que l’application semble un peu classique, nous ferons face à plusieurs difficultés surtout que les outils

d’implémentation utilisés ne sont pas faciles à manipuler. L’implémentation n’est pas la seule difficulté à surmonter, il faut savoir que la facturation au sein d’une polyclinique est beaucoup plus complexe et différente que celle dans une entreprise commerciale ou industrielle. En effet, dans ces

Projet de fin d’étude Introduction Générale 2 types d’entreprises, il s’agit toujours de passer un

Projet de fin d’étude

Introduction Générale

2
2

2

types d’entreprises, il s’agit toujours de passer un produit dans une facture client. Informatiquement parlant, on ne fait pas la distinction entre deux produits ou services d’une même entreprise, en l’occurrence entre un écran, une imprimante et un graveur s’il s’agit d’une entreprise de vente de matériel informatique, ou entre un carburateur, un amortisseur et des patins de freins, s’il s’agit d’une entreprise de vente de pièces auto. Dans un système de gestion d’une polyclinique, il faut distinguer entre « produits » : prestations, médicaments, usages uniques… car ils n’ont pas du tout les mêmes caractéristiques (attributs). En plus de cette ambiguïté, il faut gérer les conventions établies avec différentes organisations. Ces conventions agissent directement sur la facturation et le règlement. En fait, les deux clauses les plus importantes d’une convention portent sur la remise et la prise en charge. La remise agira sur la facturation puisque elle affectera les montants à payer, le taux de prise en charge touchera le dispatching du règlement, entre patient (employé) et organisation (employeur). Ceci dit, à ce stade du processus de conception, tout nous semble difficile et

dur à réaliser. C’est pour cela que notre choix s’est porté sur le Processus

Unifié.

En effet, le processus unifié est une solution de développement logiciel adapté à tous types de projets. Ses traits distinctifs tiennent en trois notions : piloté par les cas d’utilisation, centré sur l’architecture et itératif et incrémental (voir Annexe (A)). Le processus unifié répète un certain nombre de fois, une série de cycles constituant la construction d’une génération du système. Tout cycle se termine par la livraison d’une version du produit aux clients et se déroule suivant quatre phases : l’incubation, l’élaboration, la construction et la transition. Chacune de ces phases peut se dérouler en une ou plusieurs itérations.

Il faut noter que l’outil Rational Rose 98i nous aidera énormément à dessiner et

gérer les différents diagrammes UML.

Projet de fin d’étude Introduction Générale 3 En ce qui concerne l’implémentation, nous utiliserons JDeveloper

Projet de fin d’étude

Introduction Générale

3
3

3

En ce qui concerne l’implémentation, nous utiliserons JDeveloper, un outil

puissant, complet et intégré avec Oracle, notre système de gestion de bases de données. JDeveloper n’est pas le seul outil d’implémentation intégré avec Oracle, mais nous avons choisi de développer avec Java à cause de ses points forts :

Portabilité.

Appropriation au WEB.

Interfaces graphiques avancées (avec les bibliothèques graphiques Swing, AWT…) etc. Quant au système de gestion de base de données, nous avons eu recours à

Oracle9i, la solution convenable à un système si riche d’informations vu le très

grand nombre de patients qui consultent quotidiennement la polyclinique, et aussi du personnel qui y travaille (près de 400 employés). A part sa gestion impeccable d’une énorme quantité d’enregistrements, Oracle9i offre plusieurs services et outils qui sont plus détaillés dans l’annexe (B). Ayant présenté les outils et les méthodes adoptés, nous allons exposer maintenant le plan de conception. Notre œuvre se subdivisera en quatre principaux chapitres.

Dans le premier chapitre intitulé « Inception », nous commencerons par

comprendre le contexte du système, déterminer les principaux cas d’utilisation, énumérer les besoins fonctionnels et les besoins non fonctionnels, et dégager les risques critiques, pouvant nuire au bon déroulement du projet.

Puis, au sein de « L’élaboration », deuxième chapitre de ce travail, nous

tenterons d’approfondir la compréhension du système par un processus continu de collecte d’informations auprès des experts du domaine et d’arriver, à la fin de la phase, à obtenir une spécification, une analyse et une conception détaillées des cas d’utilisation. Nous avons jugé que cette phase est la plus importante car nous devons passer d’une architecture candidate, construite lors de la phase d’incubation, à une architecture stable.

Projet de fin d’étude Introduction Générale 4 Au niveau du troisième chapitre : « La

Projet de fin d’étude

Introduction Générale

4
4

4

Au niveau du troisième chapitre : « La construction », l’architecture étant stable,

le produit s’apparente alors à l’application, satisfaisant les exigences des utilisateurs.

Finalement, dans le dernier chapitre de ce mémoire : « la transition », nous

présenterons

comment

le

produit

est

mis

en

place

et

déployé

chez

la

polyclinique.

Présentation de la polyclinique « Taoufik »

<< La vie humaine mérite qu’on lui accorde plus de prix >>.

HABIB BOURGUIBA

(SFAX, le 4 juin 1961)

L

e projet de construction d’une clinique polyvalente à Tunis a été

soumis au Conseil d’Administration de la société Taoufik au mois de Janvier 1974. La concrétisation de l’idée eut lieu après six ans. Les

trois objectifs, à l’époque étaient de :

Projet de fin d’étude Présentation de la polyclinique 6 1- Participer, par l’émulation et la

Projet de fin d’étude

Présentation de la polyclinique

6
6

6

1- Participer, par l’émulation et la réalisation, à l’amélioration des techniques, méthodes et services hospitaliers et cliniques dans le pays. 2- Offrir aux médecins hospitalo-universitaires, dans le respect de la réglementation en vigueur, un instrument et une ambiance de travail en équipe, comparables aux meilleurs standards internationaux. 3- Répondre aux nouveaux besoins de la santé nés du développement touristique que connaît la Tunisie. Actuellement, la polyclinique Taoufik comporte sept niveaux :

Sous-Sol : principales installations domestiques, services généraux, chaufferie, unité de physiothérapie, unité de Radio-isotope.

Rez-de-chaussée : principales unités cliniques, moyens opératoires, salles de consultations, services de diagnostics, service de réception. Les services administratifs regroupent les bureaux affectés aux personnes suivantes : l’administrateur, le directeur administratif et financier, le caissier, l’économe, trois employés de bureau.

Premier étage : Maternité.

Deuxième étage : psychiatre.

Troisième étage : Chirurgie générale, Hôpital du jour, réanimation.

Quatrième étage : Cardiologie.

Cinquième étage : appartements de fonction et bureaux.

Dans ce qui suit, nous présentons une description brève des différents services et laboratoires de cette institution.

Urgences :différents services et laboratoires de cette institution. En principe, les cas considérés comme « urgences »

En principe, les cas considérés comme « urgences » sont les suivants :

Les maternités anticipées.

Les accidentés du travail.

Les accidentés de la route.

Les malades coronaires.

Unité de radiologie :du travail. • Les accidentés de la route. • Les malades coronaires. Cette unité comporte :

Cette unité comporte :

Un bureau.

Projet de fin d’étude Présentation de la polyclinique 7 • Une salle d’attente pour les

Projet de fin d’étude

Présentation de la polyclinique

7
7

7

Une salle d’attente pour les clients externes.

Une salle d’attente pour les malades internes.

Une salle de radiologie générale.

Une salle de radiologie spécialisée, radiographie incluse.

Un cabinet de développement des radios.

Les malades internes et les malades externes sont admis séparément.

Laboratoire d’Hématologie :internes et les malades externes sont admis séparément. • Réserve réfrigérée de sang. • Emplacement

Réserve réfrigérée de sang.

Emplacement d’attente des donneurs de sang.

Un bureau pour le technicien.

Deux salles avec lits de repos.

Laboratoire de Biochimie :pour le technicien. • Deux salles avec lits de repos. Laboratoire de Bactériologie : Salles de

Laboratoire de Bactériologie :Deux salles avec lits de repos. Laboratoire de Biochimie : Salles de consultations : Bloc opératoire

Salles de consultations :Laboratoire de Biochimie : Laboratoire de Bactériologie : Bloc opératoire : Cette société embauche aux environs

Bloc opératoire :: Laboratoire de Bactériologie : Salles de consultations : Cette société embauche aux environs de 400

Cette société embauche aux environs de 400 personnes réparties entre réceptionnistes, médecins, administrateurs, cuisiniers, secrétaires d’étage, anesthésistes, concierges, techniciens, infirmiers, femmes de ménage etc.

Chapitre (I)

La phase d’inception

L a phase d’inception consiste à comprendre le contexte du système. Il s’agit de déterminer les fonctionnalités et les acteurs les plus pertinents, de préciser les risques les plus critiques et d’identifier les

cas d’utilisation initiaux. Ceci dit, notre description va sembler trop détaillée

pour une première phase du processus, mais il faut signaler qu’un système préexiste, contenant les principales fonctionnalités.

I.1 - Contexte du système :

Pour concevoir et réaliser le système de facturation chez une polyclinique, il nous était indispensable de collecter les informations nécessaires auprès des spécialistes du domaine.

Projet de fin d’étude La phase d’inception 9 Après avoir structuré les informations collectées, nous

Projet de fin d’étude

La phase d’inception

9
9

9

Après avoir structuré les informations collectées, nous avons remarqué que presque tout, se déroule autour du dossier patient. Ainsi nous allons présenter le parcours du dossier depuis l’admission jusqu’à la sortie du patient, les composants d’une facture et les clauses d’une convention

I.1.1- Circuit du dossier patient :

1- Admission :

Le patient se présente à la réception de la polyclinique, et donne la lettre d’hospitalisation à la réceptionniste. Cette dernière vérifie le document, saisit une masse d’informations concernant le patient et lui affecte un numéro de chambre et un médecin :

cette opération s’intitule « Création d’un dossier patient ».

2-Passation des prestations 1 :

En s’installant dans l’étage approprié, le patient commence à consommer diverses prestations. Chaque consommation est accompagnée par une passation, à la facture du patient. Il faut noter que ces prestations ne sont pas toutes passées à un même étage, chaque prestation est passée au service où elle s’est faite (analyse, opération chirurgicale, imagerie…). On doit alors en conclure, que chaque secrétaire d’étage doit être capable de saisir la prestation convenable, à la facture du patient approprié.

3-Edition de la facture :

Lorsque le patient est prêt à quitter la polyclinique, il se présente à la caisse avec un bon de sortie signé par son médecin. Notre caissier (ou facturier) doit à son tour tamponner le bon (il signe que le règlement va être effectué), puis saisit le numéro de dossier de ce patient, et lance

1 C’est un service ou un bien offert par la polyclinique, une prestation peut être une analyse, une imagerie, une intervention chirurgicale, une exploration fonctionnelle, un repas….

Projet de fin d’étude La phase d’inception 10 l’édition de sa facture. Le montant de

Projet de fin d’étude

La phase d’inception

10
10

10

l’édition de sa facture. Le montant de la facture est composé des montants des types de prestations consommées ainsi que du montant de séjour.

4-Règlement :

Un patient peut être pris en charge ou ne pas l’être. Il peut être pris en charge à 100%, et payer uniquement les extras, une facture est générée automatiquement à l’organisation qui le prend en charge. Il peut être également pris en charge à un pourcentage inférieur à 100%. Dans ce cas, un dispatching aura lieu pour une facture patient et une facture organisation. Il faut noter que des remises sont possibles. Ces remises font les termes de

conventions entre la polyclinique et plusieurs organisations.

I.1.2- La facture :

« Une facture est une note détaillée des marchandises vendues, des

services exécutés » Bibliorom Larousse.

Cette définition ne nous met pas tout de suite dans le contexte, mais dès

que

respectivement, « médicaments et usages uniques » et « prestations », la définition s’éclaircit.

En effet, la facture est composée des lignes suivantes :

- Séjour : c’est le prix unitaire d’une nuitée, multiplié par le nombre de jours que le patient a passé dans la clinique. On ajoute à ceci, le montant d’un éventuel accompagnement.

- Bloc opératoire.

- Analyse.

- Imagerie.

- Réanimation.

- ECG : Electrocardiogramme.

- Pharmacie : l’ensemble des médicaments et usages uniques que le patient a consommés.

mots « marchandises » et « services », par

nous

remplaçons

les

- Projet de fin d’étude La phase d’inception 11 Fluide et appareillage : représente les

-

Projet de fin d’étude

La phase d’inception

11
11

11

Fluide et appareillage : représente les fluides 1 appareils utilisés par notre patient.

consommés et les

I.1.3 - Les conventions :

Une convention est une sorte de contrat, établi entre la polyclinique et une organisation. Une organisation peut être une entreprise ou même une ambassade. Voici les principaux clauses (ou articles) d’une convention :

- Admission du patient : dans cette clause, le responsable de recouvrement présente les conditions d’admission d’un patient (Documents et papiers nécessaires) ainsi que ses droits.

- Prise en charge : cette clause cite que les détails de la PEC 2 doivent être indiqués dans la lettre de PEC que le patient doit présenter. Ce document doit indiquer la nature des soins avec le taux de participation du patient aux frais, excepté les extras, les taxes et les droits de timbres.

- Frais d’hospitalisation : cette clause précise ce que comporte le prix d’une prestation. Par exemple, le prix d’une journée comprend le logement, l’éclairage, la climatisation, la télévision, le blanchissage du linge, la pension (trois repas et un goûter) et le service infirmier.

- Règlement : cette clause rappelle que le patient et l’organisation doivent respecter les taux de PEC, que le patient doit payer avant de quitter la polyclinique et que l’organisation doit régler sa facture dans un délai déterminé.

I.2 - Besoins fonctionnels et besoins non fonctionnels :

Le système dont la polyclinique veut se doter, doit être opérationnel, évolutif, convivial et offrant les informations nécessaires à temps réel.

1 Se dit d’un corps (liquide ou gaz) dont les molécules sont faiblement liées, et qui peut ainsi prendre la forme du vase qui le contient, Exemple : O 2 . Dans la polyclinique, on facture les fluides par jour ou par heure.

2 PEC : Prise en charge.

Projet de fin d’étude La phase d’inception 12 Pour ceci, le système à réaliser doit

Projet de fin d’étude

La phase d’inception

12
12

12

Pour ceci, le système à réaliser doit satisfaire les exigences de la totalité des utilisateurs. Nous présentons dans ce qui suit tous les besoins fonctionnels classés par acteur ainsi que les besoins non fonctionnels communs à tous ces acteurs.

Besoins fonctionnels :

Un acteur est une personne, un matériel ou un logiciel qui interagit avec le système dans le but de réaliser une plus value. Les acteurs en interaction avec notre système sont :

Le Responsable admission (réceptionniste).

La Secrétaire d’étage.

Le Facturier (caissier).

Le responsable admission (Réceptionniste):

- Création d’un dossier patient.

- Modification d’un dossier patient.

- Annulation d’un dossier patient.

- Création d’un patient.

- Modification des informations propres à un patient.

- Annulation d’un patient.

La secrétaire d’étage :

- Passer une prestation (analyse, radio, médicament, acte opératoire…) à une facture patient.

- Passer un produit (médicament ou usage unique) à une facture patient.

Le facturier :

- Calcul automatique du nombre de jours du séjour du patient.

- Génération de la facture patient - clinique.

- Génération de la facture patient - médecin.

- Editer la facture patient - clinique.

Projet de fin d’étude La phase d’inception 13 - Editer la facture patient - médecin.

Projet de fin d’étude

La phase d’inception

13
13

13

- Editer la facture patient - médecin.

Besoins non fonctionnels :

A part les besoins fondamentaux, notre futur système doit répondre aux critères suivants :

la rapidité de traitement : En effet, vu le nombre important des : En effet, vu le nombre important des

transactions quotidiennes, il est impérativement nécessaire que la durée d’exécution des traitements s’approche le plus possible du temps réel.

La performance : Un logiciel doit être avant tout performant c'est- : Un logiciel doit être avant tout performant c'est-

à-dire à travers ses fonctionnalités, répond à toutes les exigences des usagers d’une manière optimale.

la convivialité : Le futur logiciel doit être facile à utiliser. En effet, : Le futur logiciel doit être facile à utiliser. En effet,

les interfaces utilisateurs doivent être conviviales c'est-à-dire simples, ergonomiques et adaptées à l’utilisateur.

I.3- Cas d’utilisation initiaux :

Les cas d’utilisation initiaux traduisent les besoins capturés jusqu’à ce stade du processus. Comme nous avions indiqué auparavant, il est tout à fait normal dans notre cas, que le nombre de cas d’utilisations initiaux soit élevé car le système d’information n’est pas compliqué, et qu’en plus ce système est déjà informatisé. Il nous a suffi alors, de découvrir le système actuel, à la compagnie d’un agent de saisie pour dégager les fonctionnalités du système futur.

Projet de fin d’étude La phase d’inception 14 I.3.1- Diagramme de cas d’utilisation initial:

Projet de fin d’étude

La phase d’inception

14
14

14

I.3.1- Diagramme de cas d’utilisation initial:

14 I.3.1- Diagramme de cas d’utilisation initial: <<extend>> Créer un dossier patient Créer

<<extend>>

de cas d’utilisation initial: <<extend>> Créer un dossier patient Créer un patient
de cas d’utilisation initial: <<extend>> Créer un dossier patient Créer un patient
Créer un dossier patient Créer un patient <<extend>> Editer facture patient Caissier Rechercher un
Créer un dossier patient
Créer un patient
<<extend>>
Editer facture patient
Caissier
Rechercher un patient
<<include>>
<<include>>
Modifier un patient
Passer une prestation à une
facture patient
Secrétaire d'étage
Supprimer un patient
Passer un produit à une facture
patient
Réceptionniste
Rechercher un dossier patient
<<include>>
Modifier un dossier patient
<<include>>

Annuler un dossier patient

FigI.1 : Diagramme de cas d’utilisations initial.

I.3.2- Description détaillée des cas d’utilisation :

RECEPTIONNISTE :

initial. I.3.2- Description détaillée des cas d’utilisation : RECEPTIONNISTE : Créer un dossier patient :

Créer un dossier patient :

Projet de fin d’étude La phase d’inception 15 Cette opération est réalisée chaque fois qu’un

Projet de fin d’étude

La phase d’inception

15
15

15

Cette opération est réalisée chaque fois qu’un nouveau patient se présente (avec les documents nécessaires) à la réception pour être hospitalisé. L’agent saisi t un ensemble d’informations concernant le patient (par exemple le nom, le prénom, l’âge, l’adresse, la nationalité etc.). Il faut noter qu’une fois le dossier patient créé, une facture es t générée automatiquement avec des rubriques (séjour, analyse, imagerie etc.) nulles (c’est tout à fait normal, car le patient n’a rien consommé pour l’instant). Dorénavant, le montant d’une prestation, médicament,

fluide

convenable de la facture patient. L’intérêt est le fait que :

ture à l’heure

passé, sera ajouté automatiquement dans la rubrique

- L’utilisateur peut consulter d’une manière rapide la fac

actuelle, sans lancer une opération de calcul et de jointure coûteuse.

- Le temps de réponse d’une édition d’une facture sera rapide.

de réponse d’une édition d’une facture sera rapide. Modifier un dossier patient : Un dossier doit

Modifier un dossier patient :

Un dossier doit être modifiable, un utilisateur peut se tromper en communiquant les informations qui le concernent, la récupération de l’erreur est envisagée.

Annuler un dossier patient :concernent, la récupération de l’erreur est envisagée. Nous devons toujours offrir à l’utilisateur la

Nous devons toujours offrir à l’utilisateur la possibilité de la correction voire même de l’annulation. La réceptionniste a des contacts avec plusieurs types de patients, le cas le plus simple, c’est qu’un patient se présente pour être hospitalisé, un dossier qui lui correspond est créé, mais après quelques minutes il décide de s’en ailler sans se soigner.

minutes il décide de s’en ailler sans se soigner. Rechercher un dossier patient : Toute opération

Rechercher un dossier patient :

Toute opération de mise à jour (modification ou annulation) d’un dossier patient doit être précédée par une opération de recherche de ce

dossier. Le critère de recherche demandé est le numéro de dossier.

opération de recherche de ce dossier. Le critère de recherche demandé est le numéro de dossier

Créer un patient :

Projet de fin d’étude La phase d’inception 16 Lorsqu’un patient se présente à la clinique

Projet de fin d’étude

La phase d’inception

16
16

16

Lorsqu’un patient se présente à la clinique pour être hospitalisé, la récept ionniste doit vérifier tout d’abord s’il vient pour la première fois ou non. Dans le cas positif, elle doit créer un nouveau patient puis un nouveau dossier. Ceci dit, un pati ent peut avoir plusieurs dossiers patient et chaque sortie du patient s’accompagne d’un archivage de son dossier.

du patient s’accompagne d’un archivage de son dossier. Modifier un patient : Notre futur système doit

Modifier un patient :

Notre futur système doit garantir la possibilité de modifier les informations relatives à un patient quelconque.

Supprimer un patient :les informations relatives à un patient quelconque. Un patient peut se présenter à la réception avec

Un patient peut se présenter à la réception avec les pièces nécessaires pour son hospitalisation, mais annule sa demande au dernier moment. Dans ce cas, le patient doit être supprimé de la base de données car réellement, il n’a jamais consommé de prestations dans la polyclinique, il ne doit pas figurer dans notre système.

polyclinique, il ne doit pas figurer dans notre système. Rechercher un patient : Il s’agit d’une

Rechercher un patient :

Il s’agit d’une opération fondamentale au sein de notre futur système. En effet, la réceptionniste pourra rechercher un patient quelconque à n’importe quel moment aussi bien pour effectuer une mise à jour que pour lui créer un nouveau dossier.

SECRETAIRE D’ETAGE :

pour lui créer un nouveau dossier. SECRETAIRE D’ETAGE : Passer une prestation à une facture patient

Passer une prestation à une facture patient :

La

secrétaire

d’étage

enregistre

les

bons

de

prestations

que

les

infirmiers lui transmettent, pour la facture du patient concerné.

C’est l’opération la plus fréquente dans notre futur système.

la plus fréquente dans notre futur système . Passer un produit à une facture patient :

Passer un produit à une facture patient :

En fait, la secrétaire d’étage est responsable également de l’enregistrement des produits (médicament ou usage unique) consommés par le patient s’ils existent dans le petit stock de l’étage.

Projet de fin d’étude La phase d’inception 17 CAISSIER : Editer la facture patient :

Projet de fin d’étude

La phase d’inception

17
17

17

CAISSIER :

Projet de fin d’étude La phase d’inception 17 CAISSIER : Editer la facture patient : Lorsq

Editer la facture patient :

Lorsq

correspond doit être éditée par un simple clic du caissier (facturier).

ue le patient est prêt à sortir

de la clinique, la facture qui lui

I.3.3- Priorité des cas d’utilisation :

semble judicieux de répartir les cas

d’utilisation initiaux en des cas prioritaires et autres secondaires. En fait, nous considérons les cas d’utilisation « Créer un dossier patient », « Créer un patient », « Rechercher un patient » prioritaires, les autres cas d’utilisation sont secondaires. Nous avons adopté ce choix dans le but de minimiser au maximum le risque de la non maîtrise du langage du programmation et afin d’être conforme en plus, à la chronologie du circuit du dossier patient cité auparavant. En effet, ces c as d’utilisation sont assez simples à concevoir et à implémenter, ce qui nous aidera à découvrir le langage de programmation petit à petit.

I.4- Risques critiques :

Afin de faciliter notre travail, il nous

Avant de se lancer dans

risques, mettant en danger la réalisation du projet, afin de les atténuer le maximum possible. La détermination de ces risques est très importante, par exemple elle peut influencer la définition de l’ordre de priorité des cas

d’utilisation. En effet, si le langage de programmation présente un risque, nous aurons intérêt à commencer par le cas d’utilisation le plus simple. Nous faisons face à deux types de risques :

la conception, il faut déterminer les principaux

Risques non techniques :

o Délai de livraison : En effet, nous sommes contrariés par le

délai de dépôt du mémoire, fixé à trois mois du début de stage, et par l’ampleur de notre projet.

o Difficulté de l’extraction de s informations :

Projet de fin d’étude La phase d’inception 18 E n effet les employés de la

Projet de fin d’étude

La phase d’inception

18
18

18

E n effet les employés de la polyclinique n’acceptent pas souvent de nous livrer des informations. L’extraction de la bonne info rmation nous semble une tâche assez délicate.

Risques techniques :

o

La

non

maîtri se

du

langage

de

programmation :

L’implémentation avec un langage que nous ne maîtrisons pas, est un risque technique critique, surtout que le délai de livraison est relativement court.

o

L’ambiguïté du proc

essus unifié : En effet, le point fort du

processus unifié réside dans son ambiguïté car s’il est adaptable à divers types de projets, c’est parce que sa démarche est générique. Pour cela, nous sommes amenés à bien adapter le processus à notre projet.

I.5- Les interfaces utilisateurs :

Dans le but d’inciter l’utilisateur à n ous fournir une information efficace, nous adoptons la démarche du prototypage. Le prototypage motivent les employés à nous livrer des informations. Dans ce qui suit, nous présen tons quelques prototypes des interfaces usagers réalisées au cours de cette phase, mais il faut noter que les interfaces prototypes peuvent ne rien avoir avec les interfaces du futur système. D’aillers, elles sont construites avec un autre langage de programmation.

Projet de fin d’étude La phase d’inception 19 FigI.2 : Prototype de l’interface d’identification FigI.3

Projet de fin d’étude

La phase d’inception

19
19

19

Projet de fin d’étude La phase d’inception 19 FigI.2 : Prototype de l’interface d’identification FigI.3 :

FigI.2 : Prototype de l’interface d’identification

19 FigI.2 : Prototype de l’interface d’identification FigI.3 : Prototype de l’interface dossier patient

FigI.3 : Prototype de l’interface dossier patient

Projet de fin d’étude La phase d’inception 20 I.6 – Analyse des cas d’utilisation prioritaires

Projet de fin d’étude

La phase d’inception

20
20

20

I.6 – Analyse des cas d’utilisation prioritaires :

I.6.1- Analyse du cas d’utilisation « Créer un dossier patient » :

I.6.1.1- Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Créer un dossier patient » :

Modèle de cas d'utilisation

Modèle d’analyse

» : Modèle de cas d'utilisation Modèle d’analyse « trace » Créer un dossier Dossier Facture
« trace » Créer un dossier Dossier Facture C_dossier
« trace »
Créer un dossier
Dossier
Facture
C_dossier
« trace » Créer un dossier Dossier Facture C_dossier Réceptonniste Créer un dossier Interface dossier FigI.4

Réceptonniste

Créer un dossier

Dossier Facture C_dossier Réceptonniste Créer un dossier Interface dossier FigI.4 : Traçabilité entre le modèle

Interface dossier

FigI.4 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le

cas d’utilisation « Créer un dossier patient ».

I.6.1.2- : Diagramme de classes du modèle d’analyse pour le cas d’utilisation « Créer un dossier patient » :

Projet de fin d’étude La phase d’inception 21 R é c e p t o

Projet de fin d’étude

La phase d’inception

21
21

21

Projet de fin d’étude La phase d’inception 21 R é c e p t o n
Projet de fin d’étude La phase d’inception 21 R é c e p t o n
Projet de fin d’étude La phase d’inception 21 R é c e p t o n

Réceptonniste

Interface dossier

21 R é c e p t o n n i s t e Interface dossier
Dossier
Dossier
c e p t o n n i s t e Interface dossier Dossier C_dossier Facture

C_dossier

Facture

FigI.5 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation

« Créer un dossier patient ».

I.6.1.3- : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « Créer un dossier patient » :

Projet de fin d’étude La phase d’inception 22 1: afficher_ interface _dossier 2: interface_ dossier_

Projet de fin d’étude

La phase d’inception

22
22

22

1: afficher_ interface _dossier 2: interface_ dossier_ affichée 4: formulaire_ vierge_ affiché : Réceptonniste 3:
1: afficher_ interface _dossier
2: interface_ dossier_ affichée
4: formulaire_ vierge_ affiché
: Réceptonniste
3: clique_ bouton_Créer
: Interface dossier
5: saisir_ informations()
10: message_ visualisé
6: création ()
9: afficher _message_résultat ()
7: créer_ dossier ()
8: créer_ facture ()
: Dossier
: C_dossier

: Facture

FigI.6 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Créer un dossier patient ».

Le cas d’utilisation « créer un dossier patient » se déroule comme suit :

La réceptionniste demande la visualisation de son interface dossier (1), cette interface donnera à cet agent la possibilité de choisir entre ces trois opérations : « création », « modification » ou « annulation » (2). Dans notre cas, la réceptionniste clique sur le bouton « Créer » (3). Ce clic entraînera l’affichage d’un formulaire de saisie (4) et lui permettra de saisir la masse d’informations nécessaires pour créer un nouveau dossier patient (5). La création de ce dossier (7) est accompagnée d’une création de la facture patient correspondante (8). Jusque là, cette facture est vierge, et sa création est complètement transparente à la réceptionniste.

Projet de fin d’étude La phase d’inception 23 Cet agent est informé du succès ou

Projet de fin d’étude

La phase d’inception

23
23

23

Cet agent est informé du succès ou non de cette opération à travers un

message affiché sur son terminal (10).

I.6.2- Analyse du cas d’utilisation « Créer un patient » :

I.6.2.1- Traçabilité entre le modèle de cas d’utilisation et le modèle

d’analyse pour le cas d’utilisation « Créer un patient » :

Modèle de cas d'utilisation Modèle d’analyse « trace » Réceptonniste Créer un patient Créer un
Modèle de cas d'utilisation
Modèle d’analyse
« trace »
Réceptonniste
Créer un patient
Créer un patient
Interface patient
Patient
C_patient
FigI.7 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le
cas d’utilisation « Créer un patient ».
I.6.2.2- : Diagramme de classes du modèle d’analyse pour le cas
d’utilisation « Créer un patient » :
Interface patient
Réceptonniste
Patient
C_patient

FigI.8 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation

« Créer un patient ».

Projet de fin d’étude La phase d’inception 24 I.6.2.3- : Diagramme de collaboration du modèle

Projet de fin d’étude

La phase d’inception

24
24

24

I.6.2.3- : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « Créer un patient » :

1: afficher_ interface_ patient () 2: interface_ affichée 3: clique bouton_Créer : Réceptonniste 4: formulaire_
1: afficher_ interface_ patient ()
2: interface_ affichée
3: clique
bouton_Créer
: Réceptonniste
4: formulaire_ patient _vierge_ affiché : Interface patient
5: saisir_ informations()
9: message_ visualisé
6: création ()
8: afficher message_résultat ()
7: ajouter_patient()
: Patient
: C_patient

FigI.9 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Créer un patient ».

Lorsque le patient se présente avec une autorisation d’hospitalisation signé

par son médecin, la réceptionniste lui demande tout d’abord s’il vient pour la

première fois ou non.

S’il s’agit d’un nouveau patient, elle ajoute ce nouveau patient puis crée son

dossier. Sinon, elle le cherche dans la base de données, et lui crée un

nouveau dossier.

Afin de pouvoir créer un nouveau patient, la réceptionniste choisit l’opération

« créer » dans son interface patient (2). Elle procède ensuite à la saisie des

informations relatives à ce nouveau patient (5). Un message visualisé sur son

terminal lui informe de la réussite ou non de l’opération (9).

Projet de fin d’étude La phase d’inception 25 I.6.3- Analyse du cas d’utilisation « Rechercher

Projet de fin d’étude

La phase d’inception

25
25

25

I.6.3- Analyse du cas d’utilisation « Rechercher un patient » :

I.6.3.1- Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Rechercher un patient » :

Modèle de cas d'utilisation

Modèle d’analyse

« trace »
« trace »
de cas d'utilisation Modèle d’analyse « trace » Rechercher un patient Réceptonniste Rechercher un patient
Rechercher un patient
Rechercher un patient

Réceptonniste

Rechercher un patient

Patient

C_patient

Interface patient

FigI.10 : Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Rechercher un patient ».

I.6.3.2- : Diagramme de classes du modèle d’analyse pour le cas d’utilisation « Rechercher un patient » :

pour le cas d’utilisation « Rechercher un patient » : Réceptonniste Interface patient Patient C_patient FigI.11
pour le cas d’utilisation « Rechercher un patient » : Réceptonniste Interface patient Patient C_patient FigI.11

Réceptonniste

Interface patient

Rechercher un patient » : Réceptonniste Interface patient Patient C_patient FigI.11 : Diagramme de classes du
Rechercher un patient » : Réceptonniste Interface patient Patient C_patient FigI.11 : Diagramme de classes du
Rechercher un patient » : Réceptonniste Interface patient Patient C_patient FigI.11 : Diagramme de classes du

Patient

C_patient

FigI.11 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation

« Rechercher un patient ».

Projet de fin d’étude La phase d’inception 26 I.6.3.3- : Diagramme de collaboration du modèle

Projet de fin d’étude

La phase d’inception

26
26

26

I.6.3.3- : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « Rechercher un patient » :

- Scénario 1 : Recherche fructueuse.

1: afficher_ interface_ patient () 2: interface _affichée 3: clique_bouton_Rechercher 4: zone _de_ recherche_
1: afficher_ interface_ patient ()
2: interface _affichée
3: clique_bouton_Rechercher
4: zone _de_ recherche_ affichée
: Réceptonniste
: Interface patient
5: saisir _critère _de_ recherche ()
10: données_ visualisées
6: saisir_ variable_ de_ recherche ()
7: recherche ()
9: afficher _formulaire _correspondant ()
8: rechercher_ patient ()
: Patient
: C_patient

FigI.12 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Rechercher un patient ».

-Scénario1-

- Scénario 2 : Recherche non fructueuse.

1: afficher _interface_ patient () 2: interface_ affichée 3: clique_bouton _Rechercher () 4: zone –de-
1: afficher _interface_ patient ()
2: interface_ affichée
3: clique_bouton _Rechercher ()
4: zone –de- recherche- affichée
: Réceptonniste
: Interface patient
5: saisir _critère_recherche()
10: message _visualisé
6: saisir variable de recherche()
7: recherche ()
9: afficher_ message_erreur ()
8: rechercher_ patient()
: Patient
: C_patient

FigI.13 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Rechercher un patient ».

-Scénario2-

Projet de fin d’étude La phase d’inception 27 Lors de la création du dossier patient,

Projet de fin d’étude

La phase d’inception

27
27

27

Lors de la création du dossier patient, si le patient en question figure déjà dans notre base de données, la réceptionniste procède tout d’abord à sa recherche. Plusieurs critères de recherche sont possibles : code patient, nom, prénom, date de naissance… Elle doit choisir un critère de recherche (5) puis saisir la variable de recherche correspondante (6). On entend par variable de recherche, le code du patient recherché si le critère de recherche est le code patient, le nom du patient recherché si le critère est le nom …. Deux cas sont alors possibles : la recherche est soit fructueuse, soit défaillante. Un formulaire correspondant au patient recherché est alors visualisé sur l’écran de la réceptionniste (10) lors d’une recherche fructueuse (scénario1) sinon, un message d’erreur est alors affiché sur cet écran (10) (scénario2) .

Conclusion :

Ayant réalisé cette phase, nous avons réussi à répondre aux questions suivantes :

- Le projet vaut-il la peine d’être entrepris ?

- Quels sont les principaux utilisateurs de notre futur système ?

- Quelles fonctionnalités notre futur système doit-il offrir pour satisfaire les besoins des différents acteurs ? Ce qui nous a permis de passer à la phase d’élaboration, dans laquelle nous entamerons la capture de nouveaux besoins, l’analyse des cas d’utilisation secondaires et nouveaux, la conception des cas d’utilisation prioritaires et secondaires, l’implémentation des cas d’utilisation prioritaires et enfin leurs tests respectifs.

Chapitre (II)

La phase d’élaboration

A yant compris le contexte de notre système lors de la précédente phase, l’objectif maintenant est d’approfondir notre compréhension. En fait, nous sommes appelés à présenter :

une spécification des nouveaux besoins identifiés. un diagramme final de cas d’utilisation. une analyse des cas d’utilisation secondaires ainsi que des nouveaux cas identifiés. une conception des cas d’utilisation prioritaires et des cas d’utilisation secondaires.

Projet de fin d’étude La phase d’élaboration 29 une implémentation des cas d’utilisation prioritaires. II.1

Projet de fin d’étude

La phase d’élaboration

29
29

29

une implémentation des cas d’utilisation prioritaires.

II.1 – Capture des besoins :

La collecte d’informations est une activité très importante au sein du processus unifié. En effet, au fur et à mesure que nous avançons dans notre projet, des nouveaux besoins apparaissent, chaque besoin doit être analysé, conçu, implémenté et enfin testé.

Le paramétrage est l’une des fonctionnalités que nous avons capturées dans cette phase. Dans notre cas, il s’agit de paramétrer les tarifs des chambres, des types de prestations (analyse, radiologie, Opérations…), des produits alimentaires (cuisine) et des fluides et appareillages. Il s’agit aussi de saisir les conventions entre la polyclinique et diverses organisations. Une convention précise deux importants accords établis entre les deux membres :

- Les remises affectant les différentes rubriques d’une facture. Exemple :

15% sur analyse, 25% sur séjour ….

- Le taux de prise en charge : si le taux de PEC est de 25% par exemple, alors le patient paye 75% du montant de la facture, les 25% restantes, seront payées par l’organisation à laquelle il appartient.

II.1.1- Modèle final de cas d’utilisation :

Dans ce qui suit, nous illustrons le modèle final de cas d’utilisation :

Projet de fin d’étude La phase d’élaboration 30 <<extend>> Créer un dossier patient Créer un

Projet de fin d’étude

La phase d’élaboration

30
30

30

<<extend>> Créer un dossier patient Créer un patient
<<extend>>
Créer un dossier patient
Créer un patient

S'identifier

un dossier patient Créer un patient S'identifier Paramétrer médecins Paramétrer chambres

Paramétrer médecins

Paramétrer chambres <<include>> Paramétrer cuisine <<include>> paramétrer
Paramétrer chambres
<<include>>
Paramétrer cuisine
<<include>>
paramétrer prestations
<<include>>
<<include>>
Paramétrer conventions
<<include>>
Paramétrer fluide et appareill
<<include>>
<<include>>
<<include>>
<<include>> <<include>> <<extend>> Rechercher un patient
<<include>> <<include>> <<extend>> Rechercher un patient
<<extend>> Rechercher un patient <<include>> <<include>> Modifier un
<<extend>>
Rechercher un patient
<<include>>
<<include>>
Modifier un patient
<<include>>
Supprimer un patient
<<include>>
Rechercher un dossier patient
<<include>>
<<include>>
<<include>>
Modifier un dossier patient
Annuler un dossier patient
Editer facture patient
Caissier
Annuler un dossier patient Editer facture patient Caissier A dministrateu r Réceptionniste Paramétrer tarif

Administrateur

Réceptionniste

Paramétrer tarif accompagnant <<include>> Passer une prestation à une facture patient
Paramétrer tarif accompagnant
<<include>>
Passer une prestation à une
facture patient
<<include>>
Passer un produit à une facture
patient
Passer un produit alimentaire à
une facture patient
Enregistrer accompagnant

Passer un fluide ou appareill. à une facture

Secrétaire d'étage

Enregistrer réglement

FigII.1: modèle final de cas d’utilisation

Projet de fin d’étude La phase d’élaboration 31 II.1.2- Description des cas d’utilisation : La

Projet de fin d’étude

La phase d’élaboration

31
31

31

II.1.2- Description des cas d’utilisation :

La notion de sécurité est très importante au sein d’un système multi- utilisateurs. Pour cette raison, il est indispensable d’ajouter un cas d’utilisation « S’identifier ». Comme schématisé auparavant (FigII.1), tous les acteurs doivent s’identifier avant de réaliser n’importe quelle opération. Dans ce qui suit, nous présentons la description des nouveaux cas d’utilisation identifiés.

CAISSIER :

Une autre fonctionnalité s’ajoute pour le caissier, c’est l’enregistrement du règlement. Une fois le paiement de la facture patient est effectué, le caissier doit le signaler informatiquement.

ADMINISTRATEUR:

Il est responsable de :

la saisie des conventions avec les diverses organisations. La saisie des prestations (les tarifs des K - Opératoires, radiographie, bilans, explorations, ambulance…) avec une possibilité de mise à jour. La saisie des paramètres de la cuisine. La saisie des informations propres à chaque chambre (type, tarification…) ainsi qu’une possibilité de modification et/ou de suppression. La saisie des fluides et appareillages, ainsi que leurs tarifs. La saisie du tarif accompagnant.

SECRETAIRE D’ETAGE :

En plus des fonctionnalités citées au cours de la phase antérieure, cet agent doit pouvoir :

Passer un produit alimentaire à une facture patient. Enregistrer accompagnant.

Projet de fin d’étude La phase d’élaboration 32 Passer un fluide ou appareillage à une

Projet de fin d’étude

La phase d’élaboration

32
32

32

Passer un fluide ou appareillage à une facture patient.

II.2 Analyse :

II.2.1- Analyse des cas d’utilisation secondaires :

II.2.1.1- Analyse du cas d’utilisation « Modifier un patient » :

II.2.1.1.1-Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Modifier un patient » :

Modèle du cas d’utilisation

Modèle d’analyse

« trace» Modifier un patient Modifier un patient Réceptonniste Patient C_patient Interface patient
« trace»
Modifier un patient
Modifier un patient
Réceptonniste
Patient
C_patient
Interface patient

FigII.2 : Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Modifier un patient ».

II.2.1.1.2- Diagramme de classes du modèle d’analyse pour le cas

d’utilisation « Modifier un patient » :

Projet de fin d’étude La phase d’élaboration 33 R é c e p t o

Projet de fin d’étude

La phase d’élaboration

33
33

33

Projet de fin d’étude La phase d’élaboration 33 R é c e p t o n
Projet de fin d’étude La phase d’élaboration 33 R é c e p t o n
Projet de fin d’étude La phase d’élaboration 33 R é c e p t o n

Réceptonniste

Interface patient

33 R é c e p t o n n i s t e Interface patient
33 R é c e p t o n n i s t e Interface patient

Patient

C_patient

FigII.3 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation

« Modifier un patient ».

II.2.1.1.3- Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « Modifier un patient » :

1: afficher_ interface_ patient () 2: interface_ affichée 3: clique_bouton_ Modifier 4: formulaire_ correspondant_
1: afficher_ interface_ patient ()
2: interface_ affichée
3: clique_bouton_ Modifier
4: formulaire_ correspondant_ affiché : Interface patient
: Réceptonniste
5: modifier_ informations ()
9: message_ visualisé
6: modification ()
8: afficher_ message_résultat ()
7: modifier_ patient ()
: Patient
: C_patient

FigII.4 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Modifier un patient ».

NB : Ayant conçu un cas d’utilisation intitulé « Rechercher un patient », nous

n’avons pas intégré cette tâche dans le cas d’utilisation « Modifier un patient ». Cependant, il est important de signaler que la réceptionniste ne pourrait

Projet de fin d’étude La phase d’élaboration 34 modifier les informations propres à un patient

Projet de fin d’étude

La phase d’élaboration

34
34

34

modifier les informations propres à un patient qu’après avoir procédé à sa recherche. Cette remarque est également valable pour la suppression.

Ce cas d’utilisation se déroule ainsi :

La réceptionniste clique sur le bouton « Modifier » (3), puis, effectue les corrections adéquates (5). Un message visualisé sur son écran lui informe de déroulement ou non de cette opération (9).

II.2.1.2- Analyse du cas d’utilisation « Supprimer un patient » :

II.2.1.2.1-Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Supprimer un patient » :

Modèle du cas d’utilisation Modèle d’analyse « trace» Supprimer un patient Supprimer un patient
Modèle du cas d’utilisation
Modèle d’analyse
« trace»
Supprimer un patient
Supprimer un patient
Réceptonniste
C_patient
Interface patient
Patient

FigII.5 : Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Supprimer un patient ».

II.2.1.2.2- Diagramme de classes du modèle d’analyse pour le cas d’utilisation « Supprimer un patient » :

Projet de fin d’étude La phase d’élaboration 35 R é c e p t o

Projet de fin d’étude

La phase d’élaboration

35
35

35

Projet de fin d’étude La phase d’élaboration 35 R é c e p t o n
Projet de fin d’étude La phase d’élaboration 35 R é c e p t o n
Projet de fin d’étude La phase d’élaboration 35 R é c e p t o n

Réceptonniste

Interface patient

35 R é c e p t o n n i s t e Interface patient
35 R é c e p t o n n i s t e Interface patient

Patient

C_patient

FigII.6 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation

« Supprimer un patient ».

II.2.1.2.3- Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « Supprimer un patient » :

1: afficher_ interface_ patient ()

2: interface_ affichée

3: clique_bouton_Supprimer 4: formulaire _correspondant_ affiché : Réceptonniste : Interface patient 5:
3: clique_bouton_Supprimer
4: formulaire _correspondant_ affiché
: Réceptonniste
: Interface patient
5: confirmer_suppression ()
9: message_ visualisé
6: suppression ()
8: afficher_ message_résultat ()
7: supprimer_ patient()
: Patient
: C_patient

FigII.7 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Supprimer un patient ».

Projet de fin d’étude La phase d’élaboration 36 Lorsque la réceptionniste clique sur le bouton

Projet de fin d’étude

La phase d’élaboration

36
36

36

Lorsque la réceptionniste clique sur le bouton « Supprimer » (3), une boîte de dialogue s’affiche lui permettant de rechercher tout d’abord le patient à supprimer. Une fois ce dernier a été trouvé, elle confirme sa demande de suppression (5).

II.2.1.3- Analyse du cas d’utilisation « Modifier un dossier patient » :

II.2.1.3.1-Traçabilité entre le modèle du cas d’utilisation et le modèle

d’analyse pour le cas d’utilisation « Modifier un dossier patient » :

Modèle du cas d’utilisation

Modèle d’analyse

« trace» Modifier un dossier patient Réceptonniste Modifier un dossier patient Interface dossier Dossier C_dossier
« trace»
Modifier un dossier patient
Réceptonniste
Modifier un dossier patient
Interface dossier
Dossier
C_dossier

FigII.8 : Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le

cas d’utilisation « Modifier un dossier patient ».

II.2.1.3.2- Diagramme de classes du modèle d’analyse pour le cas

d’utilisation « Modifier un dossier patient » :

Projet de fin d’étude La phase d’élaboration 37 Réceptonniste I nterface dossier Dossier C_dossier FigII.9

Projet de fin d’étude

La phase d’élaboration

37
37

37

Projet de fin d’étude La phase d’élaboration 37 Réceptonniste I nterface dossier Dossier C_dossier FigII.9 :

Réceptonniste

I
I

nterface dossier

phase d’élaboration 37 Réceptonniste I nterface dossier Dossier C_dossier FigII.9 : Diagramme de classes du modèle
phase d’élaboration 37 Réceptonniste I nterface dossier Dossier C_dossier FigII.9 : Diagramme de classes du modèle

Dossier

C_dossier

FigII.9 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation

« Modifier un dossier patient ».

II.2.1.3.3- Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « Modifier un dossier patient » :

1: afficher_ interface_ dossier () 2: interface _dossier_ affiché 4: formulaire_ patient_affiché 3:
1: afficher_ interface_ dossier ()
2: interface _dossier_ affiché
4: formulaire_ patient_affiché
3: clique_bouton_Modifier
: Réceptonniste
: Interface dossier
9: message_ visualisé
5: modifier _informations ()
6: modification ()
8: afficher_ message_résultat ()
7: modifier_ dossier ()
: Dossier
: C_dossier

FigII.10 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Modifier un dossier patient ».

Projet de fin d’étude La phase d’élaboration 38 NB : Ayant conçu un cas d’utilisation

Projet de fin d’étude

La phase d’élaboration

38
38

38

NB : Ayant conçu un cas d’utilisation intitulé « Rechercher un dossier patient », nous

n’avons pas intégré cette tâche dans le cas d’utilisation «Modifier un dossier patient ». Cependant, il est important de signaler que la réceptionniste ne pourrait modifier les données d’un dossier patient qu’après avoir procédé à sa recherche. Cette remarque est également valable pour la suppression.

Pour que la réceptionniste puisse modifier des informations auparavant saisies, elle doit visualiser son « interface dossier » (1). Ensuite, elle clique sur le bouton « Modifier » (3). Le formulaire rempli correspondant au numéro de dossier à modifier, est visualisé sur le poste de la réceptionniste (4). Cette dernière procède aux changements adéquats (5). Et elle sera informée du bon accomplissement ou non de cette opération à travers un message (9).

II.2.1.4- Analyse du cas d’utilisation « Annuler un dossier patient » :

II.2.1.4.1- Traçabilité entre le modèle du cas d’utilisation et le modèle

d’analyse pour le cas d’utilisation « Annuler un dossier patient » :

Modèle du cas d’utilisation

Modèle d’analyse « trace » Annuler un dossier patient
Modèle d’analyse
« trace »
Annuler un dossier patient

C_dossier

Annulerr un dossier patient
Annulerr un dossier patient

Réceptonniste

Dossier

Interface dossier

FigII.11 : Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour

le cas d’utilisation « Annuler un dossier patient ».

Projet de fin d’étude La phase d’élaboration 39 II.2.1.4.2 -Diagram me de classes du modèle

Projet de fin d’étude

La phase d’élaboration

39
39

39

II.2.1.4.2 -Diagramme de classes du modèle d’analyse pour le cas d’utilisation « Annuler un dossier patient » :

Réceptonniste Interface dossier Dossier C_dossier FigII.12 : Diagramme de classes du modèle d’analyse pour le
Réceptonniste
Interface dossier
Dossier
C_dossier
FigII.12 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation
« Annuler un dossier patient ».
II.2.1.4.3 -Diagramme de collaboration du modèle d’analyse pour le cas
d’utilisation « Annuler un dossier patient » :
1: afficher_ interface_ dossier ()
2: interface _dossier_ affiché
3: clique_bouton_Annuler
: Réceptonniste
4: formulaire _correspondant_ affiché
: Interface dossier
5: comfirmer_ annulation ()
9: message_ visualisé
6: annulation ()
8: afficher_ message_résultat ()
7: annuler_dossier ()
: Dossier
: C_dossier

FigII.13 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Annuler un dossier patient ».

Projet de fin d’étude La phase d’élaboration 40 Après avoir visualisé son « interface dossier

Projet de fin d’étude

La phase d’élaboration

40
40

40

Après avoir visualisé son « interface dossier » (1), la réceptionniste clique sur le

bouton « Annuler » (3). Une boîte de dialogue s’affiche lui permettant de rechercher tout d’abord le dossier patient à annuler. Une fois ce dernier a été trouvé, elle confirme sa demande d’annulation (5).

L’agent sera informé du bon déroulement ou non de cette opération à travers

un message visualisé sur son écran (9). II.2.1.5- Analyse du cas d’utilisation « Rechercher un dossier patient » :

II.2.1.5.1- Traçabilité entre le modèle du cas d’utilisation et le modèle

d’analyse pour le cas d’utilisation « Rechercher un dossier patient » :

Modèle du cas d’utilisation

Modèle d’analyse

» : Modèle du cas d’utilisation Modèle d’analyse Réceptonniste « trace » Rechercher un dossier patient

Réceptonniste

« trace » Rechercher un dossier patient
« trace »
Rechercher un dossier patient

Dossier

« trace » Rechercher un dossier patient Dossier Rechercher un dossier patient C _ d o

Rechercher un dossier patient

C_dossier

Rechercher un dossier patient C _ d o s s i e r Interface dossier FigII.14

Interface dossier

FigII.14 : Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse

pour le cas d’utilisation « Rechercher un dossier patient ».

Projet de fin d’étude La phase d’élaboration 41 II.2.1.5.2-Diagramme de classe s du modèle d’analyse

Projet de fin d’étude

La phase d’élaboration

41
41

41

II.2.1.5.2-Diagramme de classes du modèle d’analyse pour le cas d’utilisation « Rechercher un dossier patient » :

cas d’utilisation « Rechercher un dossier patient » : Réceptonniste Interface dossier Dossier C_dossier FigII.15
cas d’utilisation « Rechercher un dossier patient » : Réceptonniste Interface dossier Dossier C_dossier FigII.15

Réceptonniste

Interface dossier

un dossier patient » : Réceptonniste Interface dossier Dossier C_dossier FigII.15 : Diagramme de classes du

Dossier

patient » : Réceptonniste Interface dossier Dossier C_dossier FigII.15 : Diagramme de classes du mo dèle

C_dossier

FigII.15 : Diagramme de classes du modèle d’analyse pour le cas

d’utilisation « Rechercher un dossier patient ».

II.2.1.5.3-Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « Rechercher un dossier patient » :

- Scénario 1 : Recherche fructueuse.

1: afficher_ interface_ dossier () 2: interface_ affichée 3: clique_ bouton_Rechercher 4: zone_ de_ recherhe_
1: afficher_ interface_ dossier ()
2: interface_ affichée
3: clique_ bouton_Rechercher
4: zone_ de_ recherhe_ affichée
: Réceptonniste
: Interface dossier
10: données_visualisées
5: saisir_ critère_ de_ recherche()
6: saisir_ variable_recherche()
7: recherche ()
9: afficher_ formulaire_correspondant ()
8: rechercher_ dossier ()
: Dossier
: C_dossier

FigII.16 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Rechercher un dossier patient ».

-Scénario1-

Projet de fin d’étude La phase d’élaboration 42 - Scénario 2 : Recherche non fructueuse.

Projet de fin d’étude

La phase d’élaboration

42
42

42

- Scénario 2 : Recherche non fructueuse.

1: afficher_ interface_dossier () 2: interface_affichée 3: clique_bouton_Rechercher 4: zone_ de _recherhe_ affichée
1: afficher_ interface_dossier ()
2: interface_affichée
3: clique_bouton_Rechercher
4: zone_ de _recherhe_ affichée
: Réceptonniste
: Interface dossier
10: message_ visualisé
5: saisir _critère_ de_ recherche()
6: saisir _variable_ de_ recherche()
7: recherche ()
9: afficher_ message_erreur ()
8: rechercher_dossier ()
: Dossier
: C_dossier

FigII.17 : Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Rechercher un dossier patient ».

-Scénario2-

Pour que la réceptionniste puisse rechercher un dossier patient, elle devra cliquer sur le bouton « Rechercher » (3), préciser le critère de recherche (5) ainsi que la variable de recherche (6). Dans notre cas le critère de recherche est soit le numéro du dossier, le nom du patient, son prénom…. Nous entendons par la variable de recherche le numéro du dossier du patient recherché, son nom …. Deux possibilités sont alors envisageables :

- Le succès de la recherche : dans ce cas le formulaire correspondant au dossier patient recherché est visualisé sur l’écran de la réceptionniste (10) (scénario1).

- L’échec de la recherche : un message d’erreur est affiché sur le poste de cet agent (10) (scénario2).

Projet de fin d’étude La phase d’élaboration 43 II.2.1.6- Analyse du cas d’utilis ation «

Projet de fin d’étude

La phase d’élaboration

43
43

43

II.2.1.6- Analyse du cas d’utilisation « Passer une prestation à une

facture patient » :

II.2.1.6.1- Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Passer une prestation à une facture

patient » :

Modèle du cas d’utilisation

Modèle d’analyse

« trace» Secrétaire d'étage Passer une prestation à une facture patient Passer une prestation à
« trace»
Secrétaire d'étage
Passer une prestation à une
facture patient
Passer une prestation à une
facture patient
Tarif
Facture
Ligne_prestation
C_facture
Interface facturation prestation

FigII.18: Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse

pour le cas d’utilisation « Passer une prestation à une facture patient ».

II.2.1.6.2-Diagramme de classes du modèle d’analyse pour le cas d’utilisation « Passer une prestation à une facture patient » :

Projet de fin d’étude La phase d’élaboration 44 S e c r é t a

Projet de fin d’étude

La phase d’élaboration

44
44

44

Projet de fin d’étude La phase d’élaboration 44 S e c r é t a i
Projet de fin d’étude La phase d’élaboration 44 S e c r é t a i
Projet de fin d’étude La phase d’élaboration 44 S e c r é t a i

Secrétaire d'étage

Interface facturation prestation

d ' é t a g e Interface facturation prestation Ligne_prestation Facture C_facture Tarif FigII.18 Bis
Ligne_prestation
Ligne_prestation

Facture

e Interface facturation prestation Ligne_prestation Facture C_facture Tarif FigII.18 Bis : Diagramme de classes du
C_facture Tarif
C_facture
Tarif

FigII.18 Bis : Diagramme de classes du modèle d’analyse pour le cas d’utilisation

« Passer une prestation à une facture patient ».

II.2.1.6.3-Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « Passer une prestation à une facture patient » :

Projet de fin d’étude La phase d’élaboration 45 2: interface_affichée 1: afficher_interface_facturation_prestation

Projet de fin d’étude

La phase d’élaboration

45
45

45

2: interface_affichée

1: afficher_interface_facturation_prestation ()

3: ajouter_prestation () 9: message_visualisé 4: ajout () 8: afficher_message_résultat () 5: ajouter_ prestation ()
3: ajouter_prestation ()
9: message_visualisé
4: ajout ()
8: afficher_message_résultat ()
5: ajouter_ prestation ()
8: afficher_message_résultat () 5: ajouter_ prestation () : Secrétaire : Interface facturation prestation

: Secrétaire

: Interface facturation prestation

d'étage

: Ligne_prestation : C_facture 7: mise_à_jour () 6: extraire_prix_u () : Facture
: Ligne_prestation
: C_facture
7: mise_à_jour ()
6: extraire_prix_u ()
: Facture

Tarif

FigII.19: Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Passer une prestation à une facture patient ».

La secrétaire d’étage demande la visualisation de « l’interface facturation

prestation » (1).

L’interface affichée lui permettra d’ajouter la prestation adéquate à la facture

du patient (3). Cette opération induit la mise à jour de l’entité

« Ligne_prestation ». Sachant le « nombre » de la prestation, nous devons

connaître le prix unitaire du coefficient de la prestation facturée (6). La rubrique

(type de la prestation) doit être mise à jour dans la facture (7)

Un message signalant le déroulement ou non de l’opération est visualisé sur le

poste de cet agent (9).

II.2.1.7- Analyse du cas d’utilisation « passer un produit à une

facture patient » :

Projet de fin d’étude La phase d’élaboration 46 II.2.1.7.1 -Traçabilité entre le modèle du cas

Projet de fin d’étude

La phase d’élaboration

46
46

46

II.2.1.7.1 -Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Passer un produit à une facture

patient » :

Modèle du cas d’utilisation

Modèle d’analyse

« trace » Passer un produit à patient une facture Secrétaire d'étage Passer un produit
« trace »
Passer un produit à
patient
une
facture
Secrétaire d'étage
Passer un produit à une facture
patient
Facture
Ligne_produit
C_facture
Interface facturation produit

FigII.20 : Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse

pour le cas d’utilisation « Passer un produit à une facture patient ».

II.2.1.7.2-Diagramme de classes du modèle d’analyse pour le cas d’utilisation « Passer un produit à une facture patient » :

Projet de fin d’étude La phase d’élaboration 47 Secrétaire d'étage Interface facturation produit

Projet de fin d’étude

La phase d’élaboration

47
47

47

Secrétaire d'étage Interface facturation produit Ligne_produit C_facture
Secrétaire d'étage
Interface facturation produit
Ligne_produit
C_facture

Facture

FigII.21 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation

« Passer un produit à une facture patient ».

II.2.1.7.3-Diagramme de collaboration du modèle d’analyse pour le cas

d’utilisation « Passer un produit à une facture patient » :

1: afficher_interface_facturation_produit ()

2: interface_affichée

() 2: interface_affichée 3: ajouter_produit () 8: message_visualisé 4: ajout ()
3: ajouter_produit () 8: message_visualisé 4: ajout () 7: afficher_message_résultat () 5: ajouter_ produit ()
3: ajouter_produit ()
8: message_visualisé
4: ajout ()
7: afficher_message_résultat ()
5: ajouter_ produit ()

: Secrétaire

d'étage

: Interface facturation produit

: Ligne_produit : C_facture 6: mise_à_jour ()
: Ligne_produit
: C_facture
6: mise_à_jour ()

: Facture

FigII.22: Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Passer un produit à une facture patient ».

Projet de fin d’étude La phase d’élaboration 48 Il est important de signaler qu’un produit

Projet de fin d’étude

La phase d’élaboration

48
48

48

Il est important de signaler qu’un produit peut être un médicament ou un usage unique. Ce cas d’utilisation se déroule comme suit :

La secrétaire d’étage demande l’affichage de « l’interface facturation produit » (1) lui permettant d’enregistrer la consommation d’un ou de plusieurs produits à une facture patient(3). Cette fonctionnalité s’accompagne d’une mise à jour de l’entité « Ligne_Produit », ainsi que le montant du type de la prestation en question dans l’entité « Facture ».

II.2.1.8- Analyse du cas d’utilisation « Editer facture patient » :

II.2.1.8.1-Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Editer facture patient » :

Modèle du cas d’utilisation

Modèle d’analyse

« trace» Editer la facture patient Catégorie_CH Séjour Facture C_facture Interface édition
« trace»
Editer la facture patient
Catégorie_CH
Séjour
Facture
C_facture
Interface édition

Dossier

Séjour Facture C_facture Interface édition Dossier Caissier Editer la facture patient FigII.23 : Traçabilité

Caissier

Facture C_facture Interface édition Dossier Caissier Editer la facture patient FigII.23 : Traçabilité entre le

Editer la facture patient

FigII.23 : Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Editer facture patient ».

II.2.1.8.2-Diagramme de classes du modèle d’analyse pour le cas d’utilisation « Editer facture patient » :

Projet de fin d’étude La phase d’élaboration 49 Caissier Interface édition Catégorie_CH Dossier Séjour

Projet de fin d’étude

La phase d’élaboration

49
49

49

Caissier Interface édition Catégorie_CH Dossier Séjour Facture C_facture
Caissier
Interface édition
Catégorie_CH
Dossier
Séjour
Facture
C_facture

FigII.24 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation

« Editer facture patient ».

II.2.1.8.3-Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « Editer facture patient » :

1: afficher_ interface_ édition ()

2: interface_édition_ affiché

interface_ édition () 2: interface_édition_ affiché : Caissier 3: clique_bouton_Editer_facture 4:

: Caissier

3: clique_bouton_Editer_facture

affiché : Caissier 3: clique_bouton_Editer_facture 4: saisir_numéro_facture_à_imprimer () 12: message_

4: saisir_numéro_facture_à_imprimer ()

12: message_ visualisé 5: imprimer_facture () :Catégorie_CH 7: extraire_prix () 8: extraire_date_entrée ()
12: message_ visualisé
5: imprimer_facture ()
:Catégorie_CH
7: extraire_prix ()
8: extraire_date_entrée ()
7: extraire_prix () 8: extraire_date_entrée () : Interface édition :Dossier 9: générer_ facture () 11:

: Interface édition

() 8: extraire_date_entrée () : Interface édition :Dossier 9: générer_ facture () 11: afficher_

:Dossier

9: générer_ facture ()

11: afficher_ résultat_impression ()

6: extraire_sejour ()

11: afficher_ résultat_impression () 6: extraire_sejour () 10: extraire_ facture () : Facture : C_facture :Séj
11: afficher_ résultat_impression () 6: extraire_sejour () 10: extraire_ facture () : Facture : C_facture :Séj
11: afficher_ résultat_impression () 6: extraire_sejour () 10: extraire_ facture () : Facture : C_facture :Séj

10: extraire_ facture ()

() 6: extraire_sejour () 10: extraire_ facture () : Facture : C_facture :Séj ou r FigII.25

: Facture

() 6: extraire_sejour () 10: extraire_ facture () : Facture : C_facture :Séj ou r FigII.25

: C_facture

:Séjour

FigII.25: Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation

« Editer facture patient ». Le cas d’utilisation « Editer facture patient » se déroule ainsi :

Projet de fin d’étude La phase d’élaboration 50 Le caissier demande la visualisation de son

Projet de fin d’étude

La phase d’élaboration

50
50

50

Le caissier demande la visualisation de son interface édition (1), puis clique sur le bouton « Editer facture » (3). Une boîte de dialogue s’affiche lui demandant de saisir le numéro de facture à imprimer (4). Mais avant l’impression, la facture doit être générée (5). En effet, toutes les rubriques sont déjà mises à jour sauf la rubrique « Séjour ». Alors on doit extraire le séjour du patient (6). Ensuite, les prix des chambres où a résidé le patient (7). Sachant la date de sortie (celle de l’édition de la facture), nous devons connaître la date d’entrée du patient (8) pour enfin calculer le montant du séjour du patient et donc générer la facture (9). Enfin, on extrait la facture (10) pour l’imprimer.

II.2.2- Analyse des nouveaux cas d’utilisation identifiés :

II.2.2.1- Analyse du cas d’utilisation « S’identifier » :

NB : L’acteur « Utilisateur » modélisé ci-dessous est générique c.-à-d. il englobe

tous les usagers de notre système.

II.2.2.1.1- Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « S’identifier » :

Projet de fin d’étude La phase d’élaboration 51 Modèle du cas d’utilisation Modèle d’analyse «

Projet de fin d’étude

La phase d’élaboration

51
51

51

Modèle du cas d’utilisation Modèle d’analyse « trace» Utilisateur S'identifier S'identifier Accès
Modèle du cas d’utilisation
Modèle d’analyse
« trace»
Utilisateur
S'identifier
S'identifier
Accès
C_identification
Interface identification
FigII.26 : Traçabilité entre le modèle du cas d’utilisation et le modèle
d’analyse pour le cas d’utilisation « S’identifier ».

II.2.2.1.2- Diagramme de classes du modèle d’analyse pour le cas d’utilisation « S’identifier » :

pour le cas d’utilisation « S’identifier » : U t i l i s a t
pour le cas d’utilisation « S’identifier » : U t i l i s a t

Utilisateur

Interface identification

: U t i l i s a t e u r Interface identification Accès C_identification
: U t i l i s a t e u r Interface identification Accès C_identification
: U t i l i s a t e u r Interface identification Accès C_identification

Accès

C_identification

FigII.27 : Diagramme de classes du modèle d’analyse pour le cas d’utilisation « S’identifier ».

Projet de fin d’étude La phase d’élaboration 52 II.2.2.1.3- Diagramme de collab oration du modèle

Projet de fin d’étude

La phase d’élaboration

52
52

52

II.2.2.1.3- Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation « S’identifier » :

1: afficher_interface_identification () 2: interface_affichée 8: message_visualisé : Utilisateur 3: saisir_nom_user
1: afficher_interface_identification ()
2: interface_affichée
8: message_visualisé
: Utilisateur
3: saisir_nom_user ()
: Interface identification
5: identification ()
4: saisir_mot_de_passe ()
7: afficher_message_résultat ()
6: identifier_utilisateur ()
: Accès
: C_identification

FigII.28: Diagramme de collaboration du modèle d’analyse pour le cas d’utilisation« Sidentifier ».

II.2.2.2- Analyse du cas d’utilisation « Paramétrer médecins » :

II.2.2.2.1- Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Paramétrer médecins » :

Projet de fin d’étude La phase d’élaboration 53 Modèle du cas d’utilisation Modèle d’analyse «

Projet de fin d’étude

La phase d’élaboration

53
53

53

Modèle du cas d’utilisation

Modèle d’analyse

« trace» Paramétrer médecins Paramétrer médecins C_param Médecin
« trace»
Paramétrer médecins
Paramétrer médecins
C_param
Médecin

Interface paramétrage

Administrateur

C_param Médecin Interface paramétrage A dministrateu r Interface paramétrage FigII.29 : Traçabilité entre le

Interface paramétrage

FigII.29 : Traçabilité entre le modèle du cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Paramétrer médecins ».

II.2.2.2.2- Diagramme de classes du modèle d’analyse pour le cas d’utilisation « Paramétrer médecins » :

Admini