Medical openerp

90
Faculté des Sciences et Techniques B.P 549, Av.Abdelkarim Elkhattabi, Guéliz Marrakech Tél: (+212) 524 43 34 04 Fax: (+212) 524 43 31 70 Rapport du Projet de Fin d’Etudes Réalisé par : Mlle. khadija MASSKOUB En vue d’obtenir le Diplôme d’Ingénieur d’Etat Spécialité : Ingénierie en Réseaux informatiques et système d’information THEME : Encadré par : Entreprise : M. Mohamed AIT BABRAM, Encadrant à FSTG M. Abderrahmane ELKAFIL, Encadrant à l’Entreprise Mise en place d’un système d’information hospitalier intégré dans OpenERP « Module médical » UNIVERSITE CADI AYYAD FACULTE DES SCIENCES ET TECHNIQUES MARRAKECH Département d’informatique Filière IRISI Année universitaire 2010/2011

Transcript of Medical openerp

Page 1: Medical openerp

Faculté des Sciences et Techniques B.P 549, Av.Abdelkarim Elkhattabi, Guéliz Marrakech Tél: (+212) 524 43 34 04 Fax: (+212) 524 43 31 70

Rapport du Projet de Fin d’Etudes

Réalisé par :

Mlle. khadija MASSKOUB

En vue d’obtenir le Diplôme d’Ingénieur d’Etat

Spécialité : Ingénierie en Réseaux informatiques et système d’information THEME :

Encadré par : Entreprise :

M. Mohamed AIT BABRAM, Encadrant à FSTG M. Abderrahmane ELKAFIL, Encadrant à l’Entreprise

Mise en place d’un système d’information hospitalier intégré dans OpenERP

« Module médical »

UNIVERSITE CADI AYYAD FACULTE DES SCIENCES ET TECHNIQUES

MARRAKECH Département d’informatique

Filière IRISI Année universitaire 2010/2011

Page 2: Medical openerp

Rapport de stage PFE

2

Dédicaces

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ées et des bons moments passés ensemble. Je vous dédie ce travail en vous

souhaitant un avenir radieux et plein de bonnes promesses.

Page 3: Medical openerp

Rapport de stage PFE

3

Remerciements

Je tiens à remercier toute personne qui a aidé à acheminer à bon port le présent Projet de Fin d’Études.

Et bien que ça ne soit l’évidence qui le dicte, je tiens à rendre grâce à mes chers parents, mess sœurs et frères, à toute la famille qui n’a ménagé aucun effort pour m’épauler, me soutenir, m’encourager et m’aider à venir à terme de cet humble travail.

Qu’il me soit permis d’exprimer mes sincères remerciements à M. Abderrahmane ELKAFIL le Directeur associé de la société SYSTEMUM pour m’avoir accueilli afin d’ effectuer mon stage de fin d’étude.

Je tiens à remercier M. Mohamed AIT BABRAM, mon tuteur de stage qui m’a orienté tout au long de ce projet.

J’adresse avec tout le respect et l’estime que cela se doit de requérir, mes

remerciements au personnel de l’organisme d’accueil , M .rachid IBIZI et M.Abdelhadi RACHAD qui m’ont été d’un grand apport pratique quant à l’élaboration de mon Projet de Fin d’Études.

Que messieurs les membres de jury trouvent ici l’expression de nos reconnaissances pour avoir accepté de juger ce présent travail. Veuillez trouver ici le témoignage de mon respect le plus profond.

Enfin, je remercie chaleureusement mon responsable de formation M.said RAKRAK, ainsi que tout le corps professoral et administratif de la faculté des sciences et techniques de marrakech .

Merci à tous ceux qui ont contribué de prés ou de loin à la réalisation de ce travail, pour leurs conseils, leurs encouragements et leurs soutiens

Page 4: Medical openerp

Rapport de stage PFE

4

Liste des figures

Figure 1 : Principales activités de SYSTEMUM .............................................................................. 10 Figure 2 : Axes de changements imposés au système informatique .................................................. 14 Figure 3 : Processus en Y de la démarche 2TUP .............................................................................. 15 Figure 4 : Diagramme de Gantt ....................................................................................................... 16 Figure 5: Découpage du Système d’Information hospitalier (SIH) .................................................. 18 Figure 6 : Architecture technique des ERP [Fleur-Anne Blain] ........................................................ 23 Figure 7: Les modules de base d’un ERP [Fleur-Anne-Blain] ......................................................... 24 Figure 8 : Diagramme de cas d’utilisation gestion patient ............................................................... 37 Figure 9 : Diagramme de cas d’utilisation: gestion des chambres ................................................... 39 Figure 10 : Diagramme de cas d’utilisation gestion Rendez-vous .................................................... 40 Figure 11 : Diagramme de cas d’utilisation: gestion des examens médicaux .................................... 42 Figure 12 : Diagramme de cas d’utilisation: facturation ................................................................... 45 Figure 13 : Diagramme de cas d’utilisation: gestion utilisateurs ...................................................... 47 Figure 14: graphe comparatif des caractéristiques générales ............................................................ 50 Figure 15: graphe comparatif des ERP selon les domaines fonctionnels .......................................... 51 Figure 16 : Adéquation par rapport au secteur et la taille de l’entreprise .......................................... 53 Figure 17 : Aptitudes par fonctionnalités ......................................................................................... 54 Figure 18 : Architecture modulaire d’open ERP .............................................................................. 55 Figure 19: Architecture Client-Serveur d’open ERP ........................................................................ 56 Figure 20 : Structure d’un module OpenERP ................................................................................... 57 Figure 21: Diagramme de séquence : Authentification.................................................................... 57 Figure 22 : Diagramme de séquence Création nouveau dossier patient ............................................ 58 Figure 23: Diagramme de séquence Création de prescription de médicament .................................. 59 Figure 24 : Diagramme de séquence : gestion hospitalisation .......................................................... 61 Figure 25 : Diagramme de séquence : gestion RDV ......................................................................... 61 Figure 26 : Diagramme de séquence : gestion examen ..................................................................... 63 Figure 27: Diagramme de séquence : gestion chirurgie ................................................................... 64 Figure 28 : Diagramme d’état de transition : gestion patient ............................................................ 64 Figure 29: Diagramme d’état de transition : gestion personnel ........................................................ 65 Figure 30 : Diagramme d’activité : suivi de patient ......................................................................... 66 Figure 31 : Diagramme de classe globale ........................................................................................ 67

Page 5: Medical openerp

Rapport de stage PFE

5

Sommaire Dédicaces…………………………………………………………………………………………2

Remerciements…………………………………………………………………………………..3

Liste des figures………………………………………………………………………………….4

1. Contexte du stage…………………………………………………………………………….9

1.1. Présentation de l’organisme d’accueil ................................................................................9

1.2 Présentation du projet ......................................................................................................... 11

1.2.1 Problématiques.............................................................................................................. 11

1 .2.2 Objectifs ........................................................................................................................ 11

2.Conduite du projet: ..................................................................................................................... 12

2.1 Démarche adoptée : .............................................................................................................. 12

2.1.1Le processus 2TUP : ............................................................................................. 13

2.1.2UML (Unified Modeling Language) : ............................................................... 15

2.2 Planning du projet : ............................................................................................................ 15

3. Synthèse bibliographique………………………………………………………………..16

3.1 Introduction ........................................................................................................................... 16

3.2 Généralités : ........................................................................................................................... 16

3.2.1 Définition d’un hôpital : ..................................................................................... 16

3.2.2Définition d’un système d’information hospitalier SIH: ................................ 17

3.2.3 Objectifs du système d’information hospitalier(SIH) ................................... 17

3.3 Les composantes d’un SIH ................................................................................................... 17

3.4 Le Système d’Information de Gestion de l’Unité de Soins (SIGUS) .............................. 18

3.5 Architecture des SIH ............................................................................................................ 20

4. Présentation générale des ERP :…………………………………………………………..21

4.1. Définition : ........................................................................................................................... 21

4.2 Intérêts des ERP .................................................................................................................... 22

4.3 Architecture d’un ERP .......................................................................................................... 22

4.3.1 Architecture technique d’un ERP .................................................................. 22

4.3.2 Architecture fonctionnelle d’un ERP........................................................... 23

5. Capture des besoins fonctionnels………………………………………………………..25

5.1 Introduction .......................................................................................................................... 25

5.2 Etude comparative des logiciels pour la gestion médicale .............................................. 25

5.3 Elaboration de Cahier des charges fonctionnel ................................................................ 29

5.3 Analyse de système .............................................................................................................. 35

5.3.1 Identification des acteurs ............................................................................. 35

Page 6: Medical openerp

Rapport de stage PFE

6

5.3.2 Identification des cas d’utilisation .............................................................. 35

5.3.3 Description des cas d’utilisation ................................................................... 36

6. Capture des besoins techniques………………………………………………………….48

6.1 Benchmarking des ERP Open Source: ................................................................................ 48

6.2 Solution choisie pour l’implémentation de projet : ......................................................... 52

6.3 Présentation de l’OpenERP .................................................................................................. 52

6.3.1Profil général ....................................................................................................... 52

6.3.2 Avantages ............................................................................................................ 55

6.3.3 Architecture modulaire d’OpenERP ................................................................ 55

6.3.4Architecture technique d’ OpenERP ................................................................ 56

7. Analyse et Conception ............................................................................................................... 57

7.1 Développement du modèle dynamique ............................................................................. 57

7.1.1 Formalisation des scenarios ..................................................................................... 57

7.1.2 Diagramme d’état ...................................................................................................... 64

7.1.3 Diagramme d’activité ............................................................................................... 66

7.2 Développement du modèle statique ................................................................................... 67

7.2.1Diagramme de classe ................................................................................................. 67

8. Outils de réalisation et mise en œuvre ....................................................................................... 68

8.1 Choix des outils de développement et de modélisation ................................................ 68

8.2 Choix du SGBD postgresql ................................................................................................ 69

8.3 Linux ..................................................................................................................................... 69

8.4 Choix du langage de programmation ..................................................................... 70

8.4.1 Langage Python ......................................................................................................... 70

8.4.2 Langage XML ............................................................................................................. 71

9.Présentation du prototype réalisé ................................................................................................. 72

9.1 Présentation et description :............................................................................................... 72

9.2 Process du module : ............................................................................................................. 72

9.3 Configuration et Paramétrage du module medical .......................................................... 74

Conclusion………………………………………………………………………………………82

Références……………………………………………………………………………………….83

ANNEXE A : L’Open Source………………………………………………………………….84

ANNEXE B : Exemples de rapports générés par OpenERP………………………………87

ANNEXE C : Exemples d’arabisation d’interface……………………………………..........90

Page 7: Medical openerp

Rapport de stage PFE

7

Introduction générale

L'informatique ne cesse d'envahir les différents domaines des activités humaines.

Cela s'explique par son apport incontestable pour ceux qui l'utilisent. En effet, cet outil permet entre

autre l'automatisation des traitements, l'échange d'information soit en temps réel ou soit en différé, la

conservation des données, l'exécution rapide des tâches, etc. Ayant constaté qu'ils peuvent bénéficier

de ces avantages, les centres hospitaliers ont opté de ne pas se mettre en marge de ce processus

général d'informatisation. C'est ainsi que les systèmes d'information hospitaliers ont commencé à

voir le jour.

L’élaboration d’un système d’information nécessite de bien connaître les acteurs des processus et leurs besoins afin de leur fournir un outil qui y soit adapté. Lorsque les spécifications du futur outil ont été bien définies à la fois par les membres décisionnels et par les utilisateurs concernés il faut alors choisir entre deux options :

Un logiciel déjà existant : Achetez un logiciel commercialisé répondant aux besoins. Pour

cela il faut partir de spécifications et comparer les logiciels correspondant à ses spécifications. Cette comparaison doit être menée en étant attentif à ne pas être influencé par les publicités commerciales. Il est inutile de prendre un outil très perfectionné si les besoins restent plutôt simples.

Un produit sur mesure : vous engagez une équipe d’informaticiens qui réalisera un logiciel

unique adapté au besoin du client.

Aujourd’hui les logiciels présents sur le marché sont paramétrables afin de correspondre le mieux aux attentes initiales. Il est donc assez rare de devoir faire appel à un organisme de conception personnalisée.

L’idée c’est qu’il faut être capable de se comprendre, de travailler efficacement entre

commerciaux, techniciens, comptables et logisticiens d’une même entreprise pour optimiser le

fonctionnement global. Pour cela il faut un langage commun, des référentiels, des pratiques et des

modes de communications partagés. Les ERP (Enterprise Ressource Planning) ou encore en Français

les progiciels de gestion intégrés, constituent l’outil idéal pour une telle organisation de

l’entreprise.

Page 8: Medical openerp

Rapport de stage PFE

8

Pourtant traditionnellement les ERP étaient réservées aux grandes entreprises et à une élite

d’éditeurs. Dès lors, les Petites et Moyennes Entreprises (PME) n’avaient pas un accès ou alors se

contentaient de plus modestes logiciels de comptabilité et de gestion commerciale.

Pour rendre accessible les ERP aux PME, il a fallu d'abord réduire les coûts. Le logiciel libre a

alors permis de supprimer un intermédiaire (le distributeur), de diminuer les coûts de

développement grâce à la réutilisation de logiciels libres, et de réduire considérablement les coûts

commerciaux et marketing par la libre publication du logiciel.

Ce qui caractérise les ERP c’est qu’ils sont dotés de modules génériques et

paramétrables, avec un périmètre fonctionnel qui peut varier. Des modules tels que la comptabilité,

la gestion des ventes, des stocks, des projets, des ressources humaines…etc.

C’est dans ce cadre qu’intervient le travail que j’ai effectué durant 4 mois au sein de la

société SYSTEMUM intitulé "Mise en place d’un système d’information intégré dans OpenERP "

dans un contexte englobant le dossier médical informatisé, système d’information hospitalier, et qui

mettra à la disposition de SYSTEMUM et de ces clients un module fiable bien documentée et

paramétrable et totalement intégré dans OpenERP.

Pour mener à bien notre étude, nous avons organisé notre rapport selon l’architecture suivante :

Présentation de la société SYSTEMUM et ces principaux secteurs d’activité. Présentation générale des systèmes d’information dans les établissements de santé à savoir : le

Système d’Information Hospitalier, Le Système d’Information de Santé, le système d’Information de Gestion de l’Unité de Soins. Il présente aussi les concepts du dossier médical informatisé, les objectifs et les contraintes liées à l’informatisation de ce dernier.

Méthode et conduite du projet : nous avons adoptée la démarche 2TUP dans la conception des systèmes d’information qui nous accompagnera tout au long du projet

Captures des besoins fonctionnels : focalisation sur le métier des utilisateurs.et obtenir une idée de ce que va réaliser le système en terme de métier.

Captures des besoins techniques : recenser toutes les contraintes sur les choix de dimensionnant et la conception du système. elle fait le point sur l’architecture des ERP et notamment OpenERP qui est nécessaire pour la mise en place de notre module.

Analyse et conception : Il présente le nouveau système selon les deux axes : statique et dynamique.

Outils de réalisation et mise en œuvre. Il présente une illustration du prototype réalisé ainsi

que les outils adaptés pour la réalisation du projet.

Page 9: Medical openerp

Rapport de stage PFE

9

1. Contexte du stage

1.1. Présentation de l’organisme d’accueil

SYSTEMUM est une Société de Services en Logiciels Libres (SSLL) qui accompagne les entreprises et institutions dans le choix de solutions open source ainsi que dans l'intégration, le développement, l'adaptation aux besoins spécifiques, la maintenance et le support. Afin de bénéficier des meilleures solutions libres dans la gestion des systèmes d'information.

SYSTEMUM a développé une expertise sur OPENERP depuis 2006 (premier partenaire officiel OPENERP au MAROC en 2007) et a contribué à faire connaître cet ERP open source au MAROC à travers plusieurs déploiements réussis dans les PME marocaine et des conférences dans les universités et adapte celui-ci à la législation marocaine et aux besoins spécifiques des entreprises.

Prestations et services

SYSTEMUM offre une large palette de prestations et de services basés sur des composants libres adaptés aux systèmes et aux réseaux des clients. La principale tâche de cette société est d’offrir des solutions sur mesure, en matière de formation et d’assistance, concernant les problématiques relevant des systèmes d’informations, moyennant des outils libres.

La gamme de services de SYSTEMUM est articulée autour de quatre axes majeurs qui permettent d'accompagner les clients durant toutes les phases d'un projet afin d'en assurer sa réussite.

Support

En plus des offres de formations. La société propose aux équipes dédiées au développement, des prestations de support d’aide à la maintenance, afin de réduire le temps de résolution des interrogations ou des difficultés que les entreprises pourraient rencontrer lors de la mise en œuvre de certains logiciels.

Conseil

SYSTEMUM possède une équipe formée de consultants techniques et fonctionnels qui assure soit dans le cadre de projets, soit en amont, des missions de conseil dans les domaines suivants: gestion de contenu, travail collaboratif, dématérialisation des procédures, migration vers le libre, architecture et dimensionnement d'applications basées sur open ERP…etc.

Développement

Il constitue le cœur métier de SYSTEMUM et comprend le développement sur la base de logiciels libres, de portails collaboratifs internet ou intranet, avec des composantes de publication web, de travail collaboratif, de gestion électronique de documents et de workflow.

Page 10: Medical openerp

Rapport de stage PFE

10

Formation

L’offre des formations, techniques et fonctionnelles, permet d'accompagner les organisations qui disposent d’équipes opérationnelles capables de mener à bien des projets. Ces formations peuvent être établies sous forme de transferts de compétences, en phases avals des projets.

Secteurs d’activités :

De part les multiples projets que SYSTEMUM a mené, elle a acquis un savoir faire susceptible de lui permettre l’implantation de logiciels libres dans les différents secteurs :

Enterprise Ressource Planning (ERP)

En français Progiciels de Gestion Intégré (PGI). SYSTEMUM est le partenaire officiel de l’ERP open source Open ERP au Maghreb depuis 2006. Elle adapte celui-ci à la législation marocaine et aux besoins spécifiques des entreprises.

Customer Relationship Management (CRM)

SYSTEMUM propose l’offre SUGARCRM qui permet la gestion de la relation client.

Intranet des entreprises et gestion des contenus

Création d’identités visuelles et sites internet institutionnels et e-Commerce.

La solution proposée est VERTUMART qui une solution libre de e-commerce

(commerce électronique) qui s'appuie sur le gestionnaire contenu Joomla.

Gestion électronique des documents

Il s’agit d’un système informatisé d'acquisition, classement, stockage, archivage des documents. La solution proposée est ALFRESCO.

Figure 1 : Principales activités de SYSTEMUM

Page 11: Medical openerp

Rapport de stage PFE

11

1.2 Présentation du projet

1.2.1 Problématiques

Les établissements médicaux sont des organismes un peu complexes associant plusieurs types d’unités et gère plusieurs services et des activités hospitalières. Vu le nombre important de dossiers médicaux archivés ainsi que leur nature (dossier papier), l’établissement rencontre plusieurs difficultés dans la gestion de ces dossiers, à savoir :

Problème de rédaction : Les zones de rédaction sont mal estimées (petites ou mal disposées),

ce qui handicape l’inscription des différentes informations administratives ou médicales.

Problème d’archivage : La salle d’archivage est assez limitée pour contenir un tel nombre de dossiers. Ainsi, le mauvais archivage de ces derniers accentue le temps de recherche d’un dossier médical et cause parfois des pertes ou des duplications des dossiers médicaux.

Problème d’exploitation : La nature papier des dossiers médicaux (lisibilité difficile,

recherche séquentielle…) ainsi que leur nombre important rendent toute exploitation de l’information difficile (établissement de la synthèse d’un dossier médical, édition des statistiques, les études épidémiologiques, le suivi des protocoles de vaccination).

Problème de communication : Etant donné que le dossier médical est partagé entre plusieurs

acteurs (médecins, infirmiers), la communication des informations entre ces derniers est parfois très difficile (lenteur).

Problème de redondance : Une partie des informations inscrites dans les dossiers médicaux

est dupliquée dans différents registres d’activité quotidienne. Cette redondance sert à faciliter l’activité administrative ou l’activité du contrôle Cependant, cette redondance augmente le taux d’erreur ainsi que la ainsi que la perte de temps considérable dans la tenue de ces registres.

1 .2.2 Objectifs

Notre projet a pour objectif d’améliorer le fonctionnement de tous établissements de type médical et faciliter l’admission, le suivi et la sortie des patients, En intégrant les données médicales et administratives afin d'y remédier à tous ces problèmes, on peut assigner à notre étude les objectifs suivants :

Rapidité dans l'établissement des différents documents. Facilité de la recherche et l'accès aux informations. Stockage des informations sur des supports informatiques ce qui assurera leur sécurité. Gain de temps. Automatiser les taches qui se traitent manuellement. Proposer une bonne codification.

Page 12: Medical openerp

Rapport de stage PFE

12

2. Conduite du projet:

2.1 Démarche adoptée :

Le développement d’un système d’information requiert une démarche. Cette démarche est organisée en un ensemble d’étapes à suivre. Chaque étape a ses propres particularités et produit un résultat significatif pour l’étape suivante. Pour chaque étape du processus de développement, il existe un ou plusieurs modèles qui décrivent la cible de l’étape en cours. La modélisation est un outil majeur de communication entre les différents intervenants au sein du projet, depuis les utilisateurs jusqu’aux développeurs. Son but est de faciliter la compréhension, l’étude et la maîtrise du système à étudier. La modélisation permet aussi de faciliter la traçabilité du système, à savoir de partir d’un de ses éléments et de suivre ses interactions et ses liens avec d’autres parties du modèle. Après la définition du contexte et de la problématique de notre étude ainsi que les objectifs assignés, nous expliquerons dans cette partie la démarche adoptée pour la résolution des problèmes évoqués afin d’atteindre les objectifs suscités. Afin de mener à bien notre projet et structurer notre étude, nous avons adoptée une démarche spécialisée dans la conception des systèmes d’information qui nous accompagnera tout au long du projet. Celle-ci est basée sur le langage UML et est connue sous le nom : processus 2TUP « 2 Track Unified Process »

Nous avons opté pour l’approche objet pour les avantages suivants : La stabilité de la modélisation par rapport aux entités du monde réel, la construction itérative facilitée par le couplage faible entre composants, la possibilité de réutiliser des éléments d’un développement à un autre, la simplicité du modèle qui fait appel à seulement cinq concepts fondateurs (les objets, les messages, les classes, la généralisation et le polymorphisme) pour exprimer de manière

uniforme l’analyse, la conception et la réalisation d’une application informatique.

Nous avons choisi UML pour ses points forts: UML est un langage formel et normalisé : Il permet un gain de précision, de stabilité et

encourage l'utilisation d'outils.

UML est un support de communication performant : Il cadre l'analyse et facilite la compréhension de représentations abstraites complexes. De plus, son caractère polyvalent et sa souplesse en font un langage universel.

Pour justifier notre choix qui s’est porté sur une méthodologie UP, nous présentons une petite comparaison des méthodologies UP et la méthode Merise:

Page 13: Medical openerp

Rapport de stage PFE

13

UP MERISE

Cycle de vie itératif et incrémental Méthode générique

Séquentiel

Tableau 1 : Comparaison entre les méthodologies UP et Merise

Dans une démarche traditionnelle, le processus de développement était caractérisé par : Un processus de type séquentiel : développement organisé en phases qui regroupent des

étapes, Les niveaux de découpage coïncident : la fin d’une phase correspond à la conclusion de ses

étapes, qui elles mêmes se terminent avec l’accomplissement des tâches qui les composent. Dans une approche objet tout change : Le processus est de type itératif ; Les découpages ne coïncident pas : les activités (tâches, phases, étapes, etc…) se déroulent

dans plusieurs dimensions.

La maîtrise des processus de développement implique une organisation et un suivi des activités : c’est ce à quoi s’attachent les différentes méthodes qui s’appuient sur l’utilisation du langage UML pour modéliser un système d’information. Bien que chaque processus UP présente des inconvénients, tous conviendraient au développement de notre système par leurs communs avantages, à savoir :

Faciliter la compréhension graduelle du problème, Permettre l’identification et la prise en charge précoce des risques de tous types. Suivre un rythme accéléré en travaillant efficacement vers les objectifs clairs et à court terme. Centrer le processus sur les besoins des utilisateurs, facteur clé de succès du projet. Aboutir à un système dont l’architecture favorise son évolutivité et la réutilisation de ses

composants.

Cependant, notre choix s’est porté sur le processus 2TUP car il apporte une réponse aux contraintes de changements continuels imposés aux systèmes d’information. En ce sens, il renforce le contrôle sur les capacités d’évolution et de correction de tels systèmes.

2.1.1 Le processus 2TUP :

2TUP est un processus UP (processus unifie). Le processus 2TUP apporte une réponse aux contraintes de

changement continuel imposées aux systèmes d’information de l’entreprise. En ce sens, il renforce le contrôle sur les capacités d’évolution et de correction de tels systèmes. « 2 Track » signifie littéralement que le processus suit deux chemins. Il s’agit des chemins « fonctionnels » et « d’architecture technique », qui correspondent aux deux axes des changements imposées au système informatique.

Page 14: Medical openerp

Rapport de stage PFE

14

Figure 2 : Axes de changements imposés au système informatique

Le processus 2TUP apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’information de l’entreprise.

Ce processus suit deux chemins.

Architecture fonctionnelle Architecture technique

L’axe fonctionnel comporte : Capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier

des utilisateurs. Elle qualifie au plus tôt le risque de produire un système inadapté aux utilisateurs.

Analyse, qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir une idée de ce que va réaliser le système en terme de métier.

L’axe technique, quant à lui, comporte : Capture des besoins techniques, qui recense toutes les contraintes et les choix

dimensionnant la conception du système.

Conception générique, qui définit ensuite les composants nécessaires à la conception de l’architecture technique. Elle a pour objectif d’uniformiser et de réutiliser les mêmes mécanismes pour tout un système. L’architecture technique construit le squelette du système informatique et écarte la plupart des risques du niveau technique.

Conception préliminaire, qui représente une étape délicate, car elle intègre le modèle

d’analyse fonctionnelle dans l’architecture technique de manière à tracer la cartographie des composants du système à développer.

Conception détaillée, qui étudie ensuite comment réaliser chaque composant.

Codage, qui produit ses composants et teste au fur et à mesure les unités de code réalisées. Recette, qui consiste enfin à valider les fonctionnalités du système développé.

La figure suivante illustre les différentes étapes de cette démarche:

Système d’information d’entreprise

Contraintes

Fonctionnelles

Contraintes

Techniques

Page 15: Medical openerp

Rapport de stage PFE

15

Figure 3: Processus en Y de la démarche 2TUP

2.1.2 UML (Unified Modeling Language) :

Définition :

UML se définit comme un langage de modélisation graphique et textuel destine comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue. UML unifie est a la fois les notations et les concepts orientes objet. Il ne s’agit pas d’une simple notation, mais les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au même titre que les mots d’un langage. UML a une dimension symbolique et ouvre une nouvelle voie d’échange de visions systémiques précises

Ce langage est certes issu du développement logiciel mais pourrait être applique à toute science fondée sur la description d’un système. Dans l’immédiat, UML intéresse fortement les spécialistes de l’ingénierie système.

2.2 Planning du projet :

La conduite d’un tel projet est relativement complexe si on ne suit pas une démarche et une méthodologie et un planning bien défini à l’avance. Ainsi, le projet a été décomposé en plusieurs phases, à la fin de chaque phase des livrables sont réalisées pour indiquer l’état d’avancement du projet.

Ci-dessous le diagramme de GANTT qui illustre le planning effectif du projet :

Page 16: Medical openerp

Rapport de stage PFE

16

Figure 4 : Diagramme de Gantt 3. Synthèse bibliographique

3.1 Introduction

Le système d’information coordonne grâce à l’information les activités de l’organisation, et lui permet ainsi d’atteindre ses objectifs. Il est le véhicule de communication de l’organisation. Il représente l’ensemble des ressources (humaines, matérielles et logicielles) organisées pour collecter, stocker, traiter et communiquer les informations au sein de l’organisation.

L’hôpital est une organisation un peu complexe associant plusieurs types d’unités (unités de

soins, unités médico-techniques,….) avec des fonctions distinctes et une certaine autonomie. Cependant, il ne peut fonctionner correctement que s’il existe une communication et une coopération entre ses unités afin de traiter au mieux les patients. C’est au système d’information hospitalier d’assurer cette tâche de coordination entre les différentes unités de l’hôpital.

3.2 Généralités :

3.2.1 Définition d’un hôpital :

Un hôpital est un établissement de santé dont la mission essentielle de soigner et si possible de guérir les malades. Pour accomplir ses missions, l’hôpital dispose d’un certain nombre de ressources humaines, matérielles et logicielles. L’Hôpital est en effet une fédération de sous-systèmes fonctionnellement distincts mais non disjoints. Ces sous systèmes peuvent se présenter ainsi : Le sous-système médical : Concerne l’activité mise en place par l’équipe soignante pour

répondre aux besoins des patients. Le sous-système logistique : Comprend l’ensemble des flux résultant des activités médicales

: prescriptions, résultats, transferts, archivage...

Page 17: Medical openerp

Rapport de stage PFE

17

Le sous-système étude et recherche : Travaille sur des regroupements de dossiers afin d’apprécier et d’améliorer la qualité des soins dispensés. Outre, il alimente les sous-systèmes planification et administration

Le sous-système administration : C’est le sous-système de l’hôpital qui s’intéresse à la facturation, à la gestion du personnel, à la gestion des stocks et à la comptabilité d’une manière générale.

Le sous-système planification : Il s’appuie sur les activités ou les études de morbidité hospitalière pour engager des décisions d’investissements structurels, matériels et humains. C’est le sous-système qui est en interaction avec l’extérieur (autorités et autres établissements de santé).

3.2.2 Définition d’un système d’information hospitalier SIH:

Le système d’information hospitalier (SIH) est un ensemble d’éléments en interaction ayant pour objectif de produire, traiter et fournir des informations nécessaires à l’activité hospitalière. C’est un système d’information appliqué aux métiers de la santé, et plus particulièrement aux établissements de santé. Il est constitué de l’ensemble des informations et traitements nécessaires à l’accomplissement des missions de l’établissement. Le SIH est l’une des composantes du Système d’Information de Santé (SIS). Les principaux établissements de santé pouvant mettre en place un SIH sont : Les hôpitaux. Les cliniques. Les centres d’analyses. Les centres de soins. Les cabinets médicaux.

3.2.3 Objectifs du système d’information hospitalier(SIH)

Les deux objectifs principaux d’un SIH sont : L’amélioration de la qualité des soins : Amélioration de la communication, réduction des

délais, aide à la prise de décision. La maîtrise des coûts : Réduction des durées de séjours, réduction des tâches

administratives, diminution du personnel. La réussite du SIH dépend essentiellement de trois facteurs importants : Une analyse approfondie du système d’information de l’hôpital. Une stratégie logicielle et matérielle adaptée. Estimation juste des ressources nécessaires.

3.3 Les composantes d’un SIH

Le système d’information hospitalier est divisé en 3 sous-systèmes : Le sous-système médico-administratif : Ce sous-système assure trois fonctions principales,

qui sont à savoir : La gestion des patients : admission des malades pour hospitalisation, gestion de leurs

mouvements au sein de l’hôpital (lits, mutations entre services), la sortie administrative des patients, les frais de séjour.

Page 18: Medical openerp

Rapport de stage PFE

18

La gestion financière et comptable : comptabilité des fournisseurs, comptabilité des clients (dans le cas de l’hôpital les frais de séjour), gestion des immobilisations.

La gestion du patrimoine : gestion des approvisionnements et des stocks magasin, gestion des stocks de médicaments, gestion du stock des dispositifs médicaux et des ligatures.

Le sous-système médical : Le sous système médical est considéré comme le coeur du SIH autour duquel s’organisent les deux autres sous systèmes. Il est composé de l’ensemble des unités de soins dans lesquelles se déroule la plus grande partie de l’activité médicale de l’hôpital (prescriptions, comptes rendus, soins infirmiers, visites médicales,…).

Le sous-système médico-technique : Le sous-système médico-technique comprend au sens large tous les plateaux d’examens (laboratoires d’analyse, centres d’imagerie médicale, centres d’explorations fonctionnelles...).

Figure 5 Découpage du Système d’Information hospitalier (SIH)

3.4 Le Système d’Information de Gestion de l’Unité de Soins (SIGUS)

3.4.1 Définition de l’unité de soins

L'unité de soins est le lieu où est élaborée une stratégie pour soigner les malades, mise en œuvre par une équipe soignante, sous une responsabilité définie, en consommant des moyens internes et externes et susceptible de fournir des prestations à d'autres unités. Cette définition montre bien que l'unité de soins est une structure complexe.

3.4.2 Les principaux acteurs dans l’unité de soins

On peut distinguer quatre catégories principales d’acteurs dans l’unité de soins: Le patient : C’est autour duquel est centrée toute l’activité des autres acteurs.

Actes médicaux Pathologie Morbidité Épidémiologie

Pharmacie Laboratoire Imagerie médicale

Gestion des patients Gestion financière et

comptable Gestion du patrimoine

Sous-système Médico Administratif

Sous-système médical

Sous-système Médico- Technique

Page 19: Medical openerp

Rapport de stage PFE

19

Le personnel médical : Il est constitué de l’ensemble des médecins qui ont un double rôle à savoir : L'élaboration des stratégies diagnostiques et thérapeutiques. Le suivi des patients. La recherche et l’enseignement.

Le personnel paramédical : Il est constitué essentiellement des infirmiers. Ils ont un rôle délégué par le médecin pour réaliser la prescription et les soins médicaux.

Le personnel administratif : Il est essentiellement représenté par les secrétaires médicales et aussi des médecins qui ont des missions plutôt administratives que médicales. Ils assurent la gestion de ressources, la communication interne et externe, l’évaluation de l’activité médicale etc.

3.4.3 Les pôles d’intérêt de l’informatisation des unités de soins:

Les différentes études menées ces dernières années ont montré l’existence de trois pôles d’intérêt pour l’informatisation de l’unité de soins :

Le dossier médical. La communication avec les services médico-techniques. La planification des soins.

Le dossier médical :

Toute l'activité de l'unité de soins est organisée autour du patient. Le dossier médical constitue véritablement le point central du SIGU. Ce dossier n'apparaît à un acteur de l'unité de soins que sous l'angle des besoins de sa tâche au sein de l'organisation. Chaque acteur ne sera donc concerné que par certaines informations du dossier patient. Ces informations constitueront pour lui une représentation pertinente de la réalité.

La communication avec les services médico-techniques :

Les services médico-techniques représentent, par la nature et le volume de leurs échanges avec

les unités de soins, le type de partenaire le plus important de celles-ci. La communication avec les services médico-techniques a été identifiée comme le second pôle de l'informatisation des unités de soins. Donc la prise en compte des standards et normes de communication sera privilégiée dans cette partie.

La planification des soins

La planification des soins constitue le troisième pôle de l'informatisation des unités de soins. Elle se situe à mi-chemin entre les deux premiers pôles car elle doit être comprise comme l'articulation entre deux préoccupations complémentaires :

La prévision des actions médicales qui prend en compte les éléments du dossier du patient, tels que: la prescription médicale, la prescription des actes infirmiers.

L’exécution des actions de soins qui met en jeu la communication avec les services médico- techniques.

Page 20: Medical openerp

Rapport de stage PFE

20

3.4.4 Le dossier médical dans l’unité de soins :

Définition d’un dossier médical :

Le dossier médical d'une personne est un ensemble de documents qui retracent l'histoire d'une maladie ou de l'ensemble des épisodes ayant affecté la santé de cette personne. Ces documents (lettres, comptes-rendus, résultats de laboratoire, film radiologique, ...) sont regroupés dans un dossier, une chemise, un classeur détenu par le médecin et/ou le service hospitalier ou la clinique.

Définition d’un dossier médical informatisé :

Le dossier médical informatisé est la mise en mémoire des données et des documents nécessaires à la prise en charge du patient. Ces données sont de natures diverses : images, sons, textes, données structurées et multi-sources : unités de soins, unités médicotechniques,….

Objectifs de l’informatisation du dossier médical:

L’informatisation du dossier médical permet d’atteindre les objectifs suivants :

Améliorer le stockage, la disponibilité et la communication des informations. Améliorer la lisibilité des informations. Permettre une saisie unique et un partage de l’information. Mettre en évidence l’évolutivité des informations. Rendre comparable les informations d’un patient à un autre. Intégrer les données d’origines diverses ou de natures hétérogènes (signaux, image). Faciliter l’emploi de système d’aide à la décision. Aide au regroupement des données. Faciliter la formation du personnel médical et paramédical. Améliorer la protection et la confidentialité des données.

3.5 Architecture des SIH

3.5.1 Les SIH centralisés :

Le SIH est un système centralisé en étoile mis en place dans les années 70. Cette architecture comprend un ordinateur principal et des périphériques reliés en étoile. Le principe de cette architecture est que l’information est saisie une fois (principe de non redondance), stockée en un point unique de la base de données mais accessible de n’importe quel point du réseau (principe de partage). C’est cette approche qui est le plus souvent commercialisé dans les systèmes dits « clé en main ». Cette approche a trouvé sa réussite dans les hôpitaux de petite taille (300-400 lits) et à vocation de recherche peu développé.

Avantages Inconvénients

Système intégré centré sur le patient. Mise en service et maintenance facile des modules applicatifs Contrôle facile du système Système clé en main

Coûts de maintenance élevée Évolution non progressive. Prise en compte partielle des besoins des utilisateurs Standardisation élevée

Page 21: Medical openerp

Rapport de stage PFE

21

3.5.2 Les SIH départementaux :

Consiste en l’achat des différentes structures de l’hôpital d’applications spécialisées. Les unités

médico-techniques ont été les premières à être informatisées après les services administratifs. L’informatisation des unités de soins est beaucoup plus complexe car la demande médicale varie d’un service à un autre et même à l’intérieur d’un service. Cette approche est utilisée dans plusieurs institutions hospitalières à composante universitaire très forte.

Avantages Inconvénients

Meilleurs adaptation des produits à la demande des utilisateurs. Dissociation du matériel et du logiciel Investissement progressif Applications multi-hospitalières

Redondance de l'information Difficulté de maintenir l'intégrité et la cohérence de l'information Coût élevé de l'intégration en l'absence de standards de communication

3.7.1. Les SIH distribués :

L’idée de cette approche est de combiner les avantages des deux premières architectures. Les applications sont réparties sur plusieurs processeurs de traitement suivant une architecture client/ serveur (serveur d’identité, serveur de messagerie, serveur de résultats, serveur de données cliniques) . La complexité de cette approche c’est qu’elle nécessite plusieurs niveaux d’intégration : architecture matérielle, logiciels adaptés, réseaux. Elle nécessite aussi une communication entre les applications en utilisant des normes. Internet peut être considéré comme un système distribué qui a fait son apparition dans le domaine hospitalier sous forme d’un intranet.

4. Présentation générale des ERP :

Les ERP sont des logiciels qui permettent la gestion de tout le métier d’une entreprise. Ils assurent une vision transversale du système d’information.

4.1. Définition : Il existe deux possibilités pour définir un ERP. Soit on considère son utilisation et on parle

alors de définition fonctionnelle, soit on considère son élaboration et on parle alors de définition architecturale. La définition fonctionnelle consiste à inventorier les fonctions proposées par le progiciel. On considère généralement que dans un ERP, au moins trois des fonctions suivantes sont réunies : Ventes, Achats, Production, Logistique, Comptabilité, Ressources Humaines, Qualité. A cela, il faut ajouter des applications périphériques telles que le SAV (service après-vente), la SFAO (suivi de fabrication assisté par ordinateur), mais aussi des besoins de plus en plus croissants en terme de gestion documentaire, de partage des connaissances et de traçabilité.

La définition architecturale considère l’ERP comme la colonne vertébrale des applications informatiques de l’entreprise. Le cœur d’un ERP fournisseur, définition et découpage de l’organisation (site de production, point de vente …). C’est à partir de ce référentiel et de bases de données communes que fonctionnent toutes les applications de l’ERP. Cette définition met en avant les changements organisationnels induits par la mise en place d’un ERP (définition des articles, organisation de la gestion des référentiels clients…).

Page 22: Medical openerp

Rapport de stage PFE

22

4.2 Intérêts des ERP

Les différentes études, enquêtes et ouvrages qui ont été réalisés aux USA et en France sur la

mise en œuvre des ERP ont permis de mettre en avant les axes les plus fréquents d’amélioration cités par les entreprises pour justifier de leur investissement dans un ERP. Ce sont :

Au niveau de l’ensemble des fonctions de l’entreprise un pilotage par des indicateurs et une meilleure connaissance des structures de coûts.

Au niveau des ventes, un accroissement du nombre d’offre qui doit permettre de générer des revenus complémentaires.

Au niveau financier l’optimisation des fonds propres, par exemple, une diminution des stocks et une amélioration des délais de paiement.

Au niveau des achats une optimisation des conditions d’achat par une meilleure capacité à négocier, avec une diminution des temps d‘approvisionnement.

Au niveau de la production, la maîtrise des coûts de production et des niveaux de stock pour accroître la productivité et la réactivité.

Au niveau de la communication entre les différents services de l’entreprise une meilleure circulation des informations par l’existence d’une base unique.

A la différence des grandes entreprises, les PME n’ont pas besoin d’une couverture fonctionnelle complète, ou n’en ont pas les moyens. Selon ses besoins "métiers", une PME utilisera une ou quelques fonctions de l’ERP intensivement. Les PME n’ont à leur disposition ni les compétences internes ni les délais et budgets des grands groupes où il est possible de détacher des personnes pour s’occuper de l’intégration d’une nouvelle solution. Le défi prioritaire des ERP dédiés aux PME est de proposer un produit rapidement paramétrable et personnalisable aux besoins "métiers" de l’entreprise.

L’avenir des ERP passe par le respect des standards qui s’imposent aujourd’hui en informatique. L’enjeu est de permettre à tous les logiciels développés dans des environnements et des langages différents de pouvoir échanger des informations. Cette interopérabilité permettra l’intégration de plus en plus prononcée des systèmes d’information au sein de l’entreprise et entre les entreprises. Les éditeurs travaillent également à augmenter la qualité des interfaces ainsi qu’à diminuer les coûts de maintenance liés aux innovations technologiques (exemple : passage de Windows 2000 à Windows XP).

4.3 Architecture d’un ERP

4.3.1 Architecture technique d’un ERP

Les ERP présentent une structure informatique de type « client/serveur » à trois niveaux :

Le niveau « Présentation » : il constitue l'interface utilisateur.

Le niveau « Applications » : il correspond aux fonctions de traitement de l'information.

Le niveau « Base de données » : il gère les grands volumes de données que l'entreprise conserve.

De plus, les ERP sont compatible pack Office, en particulier pour PowerPoint et Excel. Ils sont aussi adaptés à des outils de reporting.

Page 23: Medical openerp

Rapport de stage PFE

23

Les ERP peuvent travailler dans des environnements hétérogènes en ce qui concerne les matériels et les logiciels de base : l'entreprise peut choisir les fournisseurs des matériels, des gestionnaires de bases de données et des systèmes d'information.

La figure suivante illustre l’architecture technique d’un ERP :

Figure 6 : Architecture technique des ERP [Fleur-Anne Blain]

4.3.2 Architecture fonctionnelle d’un ERP

Un ERP est un ensemble dont toutes les parties fonctionnent les unes avec les autres d'où l'ergonomie et l'unicité des informations et donc la cohérence du SI.

Un ERP est modulaire dans le sens où il est possible de n'avoir qu'une ou plusieurs applications en même temps, ou peu à peu. Les applications modulaires telles que les ERP permettent d'être sûr de la compatibilité des modules entre eux, ils s'imbriquent comme des blocs de Lego et fonctionnent ensemble (pas de vérification de compatibilité à effectuer).

Voici un exemple d'architecture modulaire qui tend à représenter tous les ERP :

Page 24: Medical openerp

Rapport de stage PFE

24

Figure 7: Les modules de base d’un ERP [Fleur-Anne-Blain] Dans la suite je présenterai les principaux modules couverts par un ERP.

a. Le module comptabilité Il s'agit au moins de la comptabilité analytique qui s'appuie éventuellement sur une

infrastructure de business intelligence embarquée par l'ERP. Certains ERP gèrent aussi la comptabilité générale française, mais à l'heure actuelle leur mise en oeuvre correcte nécessite encore des paramétrages assez intenses. Néanmoins, un pont comptable d'export d'écritures peut être mis en place pour utiliser une gestion comptable abordable mais éprouvée tout en conservant les outils d'analyse, de facturation et de gestion commerciale de l'ERP open source.

b. Le module achats Le module d'achat permet de gérer les transactions d'achat et écritures comptables associées,

mais aussi les approvisionnements selon des politiques à paramétrer et/ou selon le calcul des besoins déterminés par la gestion de production.

c. Le module ventes Ecritures comptables des ventes, mais aussi : règles de pricing, devis, factures, paiements, etc.

Certains ERP, vont aussi très loin dans le CRM (Customer Relation Management) ou GRC (Gestion de la Relation Client). Dans certains cas, l'ERP peut intégrer une plateforme d'e-commerce native. Mais plus généralement l'ERP disposera de web services et/ou des connecteurs SQL permettant d'interfacer des logiciels d'e-commerce standard. Parfois encore, les ERP s'interfacent nativement avec des solutions de ventes en caisse POS (Point Of Sale) ou encore Point de Vente en français.

d. Le module ressources humaines

Le périmètre du module ressources humaines peut varier de la gestion des emplois du temps, au recrutement, en passant par la gestion de la paie. A noter que les modules de paie sont très rares à cause du morcellement législatif d'une part et de la mise en jeu de données très confidentielles d'autre part.

Page 25: Medical openerp

Rapport de stage PFE

25

e. Le module CRM

Le CRM (Customer Relationship Management, gestion de la relation client) a pour but de créer et d’entretenir une relation mutuellement bénéfique entre une entreprise et ses clients. Dans ce mode de relations commerciales, l'entreprise s'attache la fidélité du client en lui offrant une qualité de service qu'il ne trouverait pas ailleurs. Ainsi, la plupart des ERP intègrent un module CRM permettant d'améliorer la relation client/entreprise. Ce module couvre en général la gestion des événements clients, la planification des tâches, la gestion des opportunités des ventes et des achats, etc.

Il reste à noter qu’un ERP a l’avantage d’être extensible vis-à-vis d’autres fonctionnalités. Ainsi chaque entreprise a le choix entre intégrer un module qui lui est utile ou de le développer, en interne ou en externe.

5. Capture des besoins fonctionnels

5.1 Introduction

Avant de spécifier les besoins il est nécessaire de réaliser une étude de l’existant. L’étude de l’existant est une étape clé dans la réalisation de n’importe quelle application informatique, quelque soit le domaine concerné. Il s’agit d’une étude permettant de comprendre la problématique du projet et de détecter les avantages et inconvénients des solutions proposées actuellement sur le marché afin d’en profiter pour réalisation de notre projet.

5.2 Etude comparative des logiciels pour la gestion médicale

Dans cette partie, nous allons essayer de faire une étude comparative des logiciels qui existent au marché, cette étude permettra à :

S’inspirer des expériences similaires à notre projet et qui ont été déjà réalisées. Cette inspiration sera concrétisée dans l’outil qu’on devra réaliser

Localiser notre système par rapport aux systèmes déjà existants. Préciser ce que notre application doit faire.

Plusieurs applications Open Source ou propriétaire existent aujourd’hui dans le domaine des systèmes d’informations hospitaliers. On a choisi parmi ces logiciels :

MEDIMUST :

MédiMust : est un ensemble de solutions qui assure avec clarté la gestion complète du cabinet médical, quelle que soit sa taille et quelles que soient sa ou ses spécialités.

Il prend en charge les tâches les plus variées : la recherche des fiches de la journée, leur classement, l'édition automatique des courriers et comptes-rendus, l'enregistrement des consultations et l'impression des ordonnances, la gestion quotidienne des recettes et annuelle de la comptabilité...

Les demandes de bilans, l'édition du courrier, les recettes d'un patient sont accessibles directement, en n'importe quel point du programme par quelques icones explicites et commentées. L'accès à une autre fiche patient est possible en permanence sans perdre la saisie en cours.

Il est édité par la société Mustinfo, société de création de logiciel propriétaire médecin et de logiciel vétérinaire.

Page 26: Medical openerp

Rapport de stage PFE

26

OSOFT

OSOFT est un logiciel de gestion complète d’un hôpital ou clinique dédié au médecin généraliste ou spécialisé , développé et commercé par la société Medibase qui réalise des missions d'audit et de conseil sur les systèmes d'information médicale auprès des établissements de santé en France.

OSOFT couvre la totalité du dossier médical. Allant du premier contact avec un patient pour une consultation jusqu’à sa sortie de l’établissement, en passant par la phase de production d’informations médicales et l’ordonnance, l’annonce d’hospitalisation et attribution des ressources, lit et bloc, ainsi que la prescription et l’organisation des soins. Les différents modules et fonctions d’OSOFT accompagnent tout au long de suivi des patients.

Il est présent à toutes les étapes du cheminement d'un patient hospitalisé, de la consultation à la sortie de l'établissement notamment à travers :

- la consultation initiale

- l'affectation des ressources au patient au travers de la planification des lits et des blocs

- la consultation d'anesthésie

- la prescription de médicaments avant ou pendant le séjour du patient

- l'accès aux prescriptions par la pharmacie et l'émission des avis pharmaceutiques

- la fonction de messagerie intégrée à la prise en charge des patients

- l'accueil du patient dans le service (évaluation, pancarte, devenir, activités, soins, transmissions,...)

- l'organisation transversale des activités de service

MEDIBOARD :

Mediboard est un système web open source de gestion d'établissement de santé. Il se définit plus précisément comme la partie logicielle d'un système d'information hospitalier, c'est-à-dire un progiciel de gestion intégré adapté aux établissements de santé de toute taille, du simple cabinet de praticien au centre médical multi site. C’est un système d'information hospitalier dédié à la gestion du dossier patient, la planification de l'activité de l'établissement de santé et la gestion de l'activité clinique et libérale des praticiens.

Il est initialement conçu comme un pont entre les dossiers médicaux gérés par les praticiens, notamment dans le cadre de leur activité libérale au sein des cabinets médicaux, et le dossier patient administratif utilisé par les établissements dans un cadre plus organisationnel et financier. Ce pont prend la forme du dossier administratif et médical, complété tout au long du parcours du patient, des points de vue complémentaires de l'établissement et des équipes médicales.

Page 27: Medical openerp

Rapport de stage PFE

27

GMEDCINE :

Gmédecine est un Logiciel Hospitalier , son Système Expert - Une équipe de concepteurs, de développeurs, de formateurs regroupée sous la bannière de Gmédecine qui est appuyée sur des professionnels de la santé pour créer un système expert, susceptible de gérer les dossiers des patients au sein des structures hospitalières il est à la fois :

Un outil de la démarche d’Accréditation par ses fonctionnalités d’enregistrement, traitement, analyse, accessibilité et traçabilité des données patient.

Un guide de l'Accréditation par ses potentialités de moyen permanent d’information et de formation des professionnels de santé.

Polydis :

Le logiciel polydis fournit par HopitalWeb qui développe des modules logiciels de gestion pour établissement de santé : hôpital, clinique, polyclinique. L'ensemble constitue un ERP nommé Polydis. Polydis autorise : le dossier patient informatisé, la dispensation nominative des médicaments et offre une complète traçabilité des actes, soins et de la stérilisation. Articulé autour du dossier patient informatisé et intégrant le dossier de soins informatisé, la dispensation nominative des médicaments, un dossier diététique patient, l'enregistrement des actes et soins médicaux, infirmiers et de la stérilisation, PolyDIS offre la traçabilité recherchée par tous dans le monde de la santé.

Page 28: Medical openerp

Rapport de stage PFE

28

Elixir :

Elixir est le fruit d'une collaboration étroite entre une équipe de développeurs en informatique et des médecins dans le but de réaliser une solution professionnelle et complète pour la gestion de cabinet médical. Elixir est le premier logiciel de gestion de cabinet médical totalement GRATUIT pour tout médecin tunisien, ainsi toutes les fonctionnalités du logiciel Elixir et les mises à jour sont gratuites.

Les fonctionnalités d’Elixir :

Elixir permet de gérer vos patients, leurs consultations (les examens cliniques, les bilans biologiques et radiologiques, les ordonnances...). Et aussi, il vous permet de gérer votre archive médical, ainsi que vos rendez-vous et vos courriers.

Module medical:

Le module médical d’OpenERP se veut un enregistrement de données médicales électroniques centralisées et un système d’informations hospitalières, destiné au service des institutions sanitaires et hospitalières.

Le noyau de base offre les fonctionnalités suivantes : le calendrier des agendas des unités de soins, la fiche administrative des patients, le formulaire de consultation, la délivrance des ordonnances.

OpenERP reprend à l’écran l’identité du patient, ses antécédents généraux et ses allergies, son groupe sanguin, la liste des consultations, la liste des ordonnances etc.

Types des logiciels :

logiciel propriétaire Open source Médimust

Gmedecine osoft

Chimed

Mediboard Polydis Exilir Module medical

Page 29: Medical openerp

Rapport de stage PFE

29

Tableau comparatif :

Module medical

Medimust Gmedecine Osoft Chimed médiboard Polydis Exilir

Gestion des patients

Admission -

Hospitalisation des patients

- - - - -

Gestion de dossier médical

facturation - - - - - Gestion des

personnels - - - - -

Gestion de stock - - - - - - Gestion des RDV Gestion des consultations

- - - - - -

Gestion de laboratoire

Imagerie Messagerie -

Gestion de la pharmacie

- - - - - -

Gestion des actes médicaux

- - - - -

Administration d’accès au système

- - -

Gestion des chambres

- - -

D’après cette étude comparative entre ces logiciels, on a pu extraire les différentes fonctionnalités qui va être réalisé au niveau de notre future système ce qui conduit à élaborer le cahier des charges suivant :

5.3 Elaboration de Cahier des charges fonctionnel Il s’agit de la toute première étape du processus de développement et vise à effectuer un premier repérage des besoins fonctionnels et opérationnels du système à modéliser. Elle consiste essentiellement, à réaliser un cahier des charges des différents besoins et souhaits exprimés par les futurs utilisateurs du système et d’en déduire les principaux acteurs du système ainsi que les messages échangés.

Page 30: Medical openerp

Rapport de stage PFE

30

La gestion des patients :

Dossier administratif

Création d'un Dossier administratif :

Cette fonction permettra de créer le dossier d'un patient lors de sa première visite, les données peuvent êtres complétés ultérieurement et sont toujours modifiables. Ce dossier contient : Le Nom, le Prénom, le sexe, La Date de naissance, l'adresse, le code postal, la ville, La situation familiale, la profession, les N° de téléphone….

Renseignements administratifs: Le Nom de l'assuré et son Prénom si différent du patient. Le N° d'affiliation à une caisse d'assurance maladie ou n° Carte Nationale d'Identité pour les patients ne disposant pas de couverture sociale. Le nom de la Mutuelle et sa date de fin de droits. Le N° du centre de caisse d'assurance maladie dont le patient dépend. Accès / modification d'un Dossier administratif :

Cette fonction permet de rechercher et d'accéder au dossier administratif d’un patient ainsi que le modifier ou le compléter si nécessaire.

Suppression d'un Dossier Administratif : En cas de mauvaise manipulation, cette fonction permet de supprimer le dossier administratif d'un patient après confirmation.

Dossier médical

Création d'un dossier médical :

Pour créer un dossier médical le patient doit avoir au préalable un dossier administratif. Ainsi, le système permettra de créer un dossier médical pour un patient déterminé. Le dossier médical est constitué de plusieurs onglets définis ci-dessous:

Antécédents et diagnostics : toutes les données liées aux antécédents médicaux du patient et

à ses diagnostics permettront de rendre état du passé médical l'état de santé du patient. Consultation et observations médicales : les remarques pertinentes au sujet de l'évolution du

patient permettent l'actualisation permanente de l'état général du patient. Bilans et suivis: les résultats des analyses et les bilans de santé constitueront un historique de

la vie médicale du patient. Régime suivi : inclut le point de vue diététique, en relation avec le dossier médical. L´équipe

de diététique gère l´organisation des repas servis aux patients, en collaboration avec l´équipe de la cuisine, elle établit des régimes spécifiques en fonction des pathologies.

Accès/ Modification d'un dossier médical :

Le système permet d'accéder à un dossier médical et de le modifier en y ajoutant des données complémentaires ou de changer les informations existantes. On pourra notamment modifier le régime prescrit pour un patient lors de son séjour.

Page 31: Medical openerp

Rapport de stage PFE

31

Enregistrer un dossier médical : Cette fonction permet d'enregistrer les informations contenues dans le dossier médical.

Supprimer un dossier médical :

En cas de mauvaise manipulation engendrant un doublant, cette fonction permet de supprimer le dossier médical d'un patient. Une confirmation est demandée.

La gestion des admissions (hospitalisation)

Le module Admission consiste à suivre l’épisode d’hospitalisation d’un patient depuis son arrivée à l’hôpital jusqu'à sa sortie

Elle vise essentiellement à :

Gérer les informations médico-administratives du patient.La prise en charge des éléments d’une admission d’un patient (régime, service, médecin, motif D’admission, qualité du malade, …)

La prise en charge des affectations des malades aux chambres et lits

La recherche des admissions par nom, prénom, service, médecin traitant, …

Gestion et planning du personnel médical :

Création du personnel :

Cette fonction permettra de créer le personnel médical de la clinique afin de pouvoir gérer le planning général et faciliter la prise de RDV des patients. On devra pour cela entrer les informations suivantes : Nom, Service (chirurgie, pédiatrie…), Fonction (médecin, infirmière…) Modification du personnel :

On pourra grâce à cette fonction modifier les données liés au personnel préalablement crée.

Suppression du personnel :

A la suite d’une erreur concernant les données du personnel d’une retraite ou d’un transfert à une autre clinique, le système permettra de supprimer la fiche qui lui correspond, après une demande de confirmation.

Gestion de la pharmacie et de stock:

Ce module permet de gérer l'ensemble des données nécessaires concernant les produits administrés aux patients séjournant dans l’établissement.

Les produits pharmaceutiques sont exclusivement réservés aux patients admis en clinique. Ils sont exclusivement prescrits par des médecins et administrés par le personnel soignant.

Page 32: Medical openerp

Rapport de stage PFE

32

Ajouter un médicament :

L’application permet d'ajouter un médicament dans la banque de donnée en saisissant la description relative au médicament ci dessous: (Nom, Dosage, Nature, Type, Posologie…..) Rechercher un médicament :

L’application permet la recherche d'un médicament. La recherche est effectuée par la saisie d'une de ses caractéristiques citées ci dessus. Supprimer un médicament :

L’application effectue la suppression d'un médicament donné par la personne autorisée. Une confirmation est demandée. Signaler un produit en fin de stock :

L’application permet notamment de prévenir l'utilisateur quant à la diminution du stock relatif au produit. Gestion de laboratoire :

Ce module doit gérer les fonctions du laboratoire il intègre : Recherche des résultats d’un patient :

L’application permet de chercher les résultats en entrant le nom et le prénom et elle affiche les résultats. Recevoir les demandes d’examen :

Lors de consultation si le médecin a besoin d’un examen, il envoi un demande d’examen au laboratoire avec tous les informations concernant le patient. Enregistrer les demandes :

Lorsque le laboratoire reçoit les demandes l’application lui permet d’enregistrer ces demandes avec la date du demande et le nom du médecin puis le nom du laborantin qui va faire l’analyse. Editer les résultats :

Après l’analyse l’application permet aux laborantins d’enregistrer les résultats les édités. Gestion des chambres :

Ajout d'une chambre : Cette fonction permettra de rajouter une chambre ainsi que toutes ses caractéristiques. (N° de la chambre, Numéro d'étage, Code d'accès à la chambre, Type de la chambre (Individuelle / Double), Numéro de téléphone, État d'occupation, Soins particuliers (appareils médicaux spéciaux ...), Service (pédiatrie, maternelle ...)

Page 33: Medical openerp

Rapport de stage PFE

33

Suppression d'une chambre : L’application permet de supprimer de la base des données les informations d'une chambre.

Modification d'une chambre : Cette fonction permet, dans la base de données, de faire des modifications sur une chambre.

Consultation des chambres : L’application permet, en saisissant le numéro de la chambre, d'afficher toutes les autres caractéristiques citées ci-dessus.

L'occupation des chambres : L’application permet de visualiser ou d'enregistrer les chambres occupées par les patients, en entrant le numéro de la chambre. Voici les informations qui en découleront: (Nom et Prénom du patient, Date d'entrée du patient, Type de chambre occupée par le patient (Individuelle / Double), Numéro d'étage, Un lien vers le dossier médical du patient) Gestion des droits d'accès :

Création d’utilisateurs

Cette fonction permet de créer les différentes fiches du personnel habilité à utiliser le système. Il suffit de saisir dans le module les données correspondant à l'identification de l'utilisateur concerné

o Nom o Fonction (médecin, infirmier...) o Login o Mot de passe

Modification : Le système permet de modifier toutes les donnés relatives à l'utilisateur. Suppression : le système permet également de supprimer un utilisateur dans le cas où il n'est

plus habilité à utiliser l'application. Création de groupes d'utilisateurs : Le système permet de créer un groupe selon la fonction

de l'utilisateur et de spécifier les droits d'accès pour chaque groupe. Modification : cette fonction permet de modifier les droits d'accès d'un groupe. Suppression : Le système permettra de supprimer un groupe d'utilisateur préalablement crée.

Gestion des rendez-vous

Les services chargés de l’accueil et des admissions organisent et assurent la gestion des rendez-vous en fonction des disponibilités des praticiens consultants et en fonction du volume des demandes de rendez-vous.

Le nombre exact des patients admis par séance devra être déterminé en fonction du nombre des praticiens consultants, de la spécialité et de la durée de la séance. Le nombre ainsi fixé devient impératif aussi bien pour les praticiens consultants que pour le service d'accueil à la consultation chargé de délivrer les rendez-vous.

Création d’un rendez-vous : Cette fonction permet de fixer un rendez-vous selon le choix du patient et les disponibilités qui se présentent après une recherche dans les horaires disponibles de l’agenda.

Page 34: Medical openerp

Rapport de stage PFE

34

Modification d’un rendez-vous :

L’application permet de modifier un rendez-vous de l'agenda (l'heure, la date, l'objet...). Le système retournera automatiquement les périodes disponibles Suppression d’un rendez-vous :

Cette fonction permet avec une simple clique de supprimer un rendez-vous. Gestion des lits :

Ajouter modifier les caractéristique de lit Cette fonction permettra de rajouter ou modifier les informations d’un lit ainsi que toutes ses caractéristiques. (N° de la chambre, Numéro d'étage, Code d'accès au lit, Numéro de téléphone, État d'occupation, Soins particuliers (appareils médicaux spéciaux ...), Service (pédiatrie, maternelle ...) Consultation de la liste des lits :

L’application permet, en saisissant le numéro de la chambre, d'afficher toutes les autres caractéristiques citées ci-dessus. L'occupation des lits :

L’application permet de visualiser ou d'enregistrer les chambres occupées par les patients, en entrant le numéro de la chambre. Voici les informations qui en découleront: (Nom et Prénom du patient, Date d'entrée du patient, Type de chambre occupée par le patient (Individuelle / Double), Numéro d'étage, Un lien vers le dossier médical du patient) Facturation, Tarification et paiement:

Sauf disposition légale spécifique, toute prestation fournie par l’hôpital doit faire l’objet d’une facturation et d’une mise en paiement par le malade ou un tiers payant.

La facture étant établie conformément à la réglementation de la tarification applicable aux hôpitaux relevant du Ministère de la Santé.

Le tarif des prestations est fixé par voie réglementaire. Les hôpitaux ne peuvent déroger aux dispositions réglementaires érigeant la tarification applicable.

La facturation des prestations est effectuée, au niveau des services d’admission, sur la base des relevés des soins, actes, examens complémentaires et autres services dont a bénéficié l’usager. Ces relevés sont établis, sous la responsabilité du chef de l’unité de soins, sur la base du dossier d’hospitalisation.

L’hôpital organise le processus de perception et de recouvrement des frais liés aux prestations rendues conformément à la législation en vigueur.

Ce module doit gérer la facturation et prend en considération le mode de règlement des patients

Créer la facture : Il permet de créer automatiquement la facture du patient dès son admission contient toutes les informations administratives.

Page 35: Medical openerp

Rapport de stage PFE

35

Enregistrer les prix :

Il permet d’enregistrer les prix de différentes consultations et examens dans la base de données et de donner le droit de supprimer ou modifier. Facturer de façon automatique chaque prestation (consultation, examen, hospitalisation) dont a bénéficié le patient.

Rechercher : Cette fonction permet de chercher la facture d'un patient donné par le nom et prénom ou d’autre information administrative.

Régler une facture :

Cette fonction permet de régler la facture en précisant le mode de règlement chèque ou espèce en vérifiant les informations qui sont introduites au départ (la mutuelle, caisse,…).

Edition de la facture :

Lorsque le patient est prêt à quitter l’établissement il se présente à la caisse avec un bon de sortie signé par son médecin. Le 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 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.

5.3 Analyse de système 5.3.1 Identification des acteurs

La liste des acteurs de notre nouveau système, se présente comme suit :

Agent ou personnel administratif(PA) : son rôle est de gérer l’admission et l’orientation des patients et la gestion des personnels hospitaliers ainsi que la facturation.

Médecin : son rôle est de créer le dossier médical de chaque patient et la mise à jour des informations médicaux après chaque consultation. il est chargé de l’hospitalisation et la préparation des examens.

Infirmière : son rôle est de créer les rendez-vous et organiser l’agenda du travail du médecin. Réceptionniste : elle est chargée d’admettre les patients, créer le dossier administratif et

donner le premier rendez-vous. Laborantin : il est chargé de gérer les demandes d’examens et l’édition des résultats. Administrateur : son rôle est de gérer l’utilisation du système et les droits d’accès de chaque

utilisateur en fonction de son catégorie

5.3.2 Identification des cas d’utilisation

Dans ce qui suit nous proposons une description textuelle des cas d’utilisation. Cette description n’est pas la plus exhaustive possible, mais permet d’avoir une idée sur le fonctionnement de chaque cas d’utilisation. Les cas d’utilisation sont structurés comme suit :

Page 36: Medical openerp

Rapport de stage PFE

36

Un sommaire d’identification qui contient : Le titre du cas d’utilisation Le but du cas d’utilisation Le résumé du cas d’utilisation

Les pré-conditions La description des différents enchaînements du cas d’utilisation Use case détaillé

5.3.3 Description des cas d’utilisation

Authentification

Sommaire d’identification Titre : S’authentifier.

But : La connexion d’un utilisateur au système.

Acteurs : les utilisateurs du système.

Description : L’utilisateur s’authentifie en saisissant son login et son mot de passe.

Pré-conditions :

L’utilisateur saisit ses droits d’accès (login et mot de passe). Description des enchaînements : Enchaînements :

L’utilisateur saisit en premier ses droits d’accès. Si le système détecte une erreur d’authentification, alors la fenêtre d’authentification sera réaffichée, sinon le système affiche la page d’accueil. Gestion des patients :

Diagramme de cas d’utilisation:

Page 37: Medical openerp

Rapport de stage PFE

37

<include>

<include><include>

<include>

<include>

<include><include>

<include>

agent

médecin

création du dossier administratif

observation médicale

régime suivi

suppression

accès et modification

bilans et suivi

gestion du dossier médical

anticédents et diagnostic

recherche un patient

gestion d'hospi talisation

gestion de la sortie

consulter la liste des patients

reservation de salle et lit

affecter le patient à un lit

archivage du dossier

di ffuser les infos de sortie

réceptionniste

ajout

authentification

Figure 8 : Diagramme de cas d’utilisation gestion patient

Sommaire d’identification :

Titre : gestion des patients

But : permet de suivre le patient dés l’entré jusqu’à sa sortie.

Résumé : la réceptionniste crée un dossier administratif du patient qui contient les informations personnel et le type de visite et de maladie et il lui affecte à un médecin qui crée à son tour un dossier médical qui contient tous les informations qui décrivent la consultation, le traitement à suivre, les ordonnances et les examens à faire.

Acteurs : médecin, administrateur, réceptionniste

Page 38: Medical openerp

Rapport de stage PFE

38

Pré-condition :

-Le médecin, l’administrateur, réceptionniste sont authentifiés

Post-condition :

-Un dossier du patient est créé dans le système

-Les données de base (identité, médecin traitant, conditions connues)

Description des sous cas d’utilisation :

(1) « créer un nouveau dossier patient ‘administratif’ »

Cette opération est réalisée chaque fois qu’un nouveau patient se

Présente, La réceptionniste clique sur l’onglet nouveau patient, puis, il clique sur « ajouter patient » pour créer un nouveau dossier administratif d’un nouveau patient on lui affecte un num automatique en saisissant les différents informations nécessaires (nom, prénom, date de naissance, adresse,..)

*Si tous les champs ne sont pas remplis, un message d ‘erreur s’affiche invitant à compléter les champs.

(2) « créer le dossier médical »

Le médecin cherche le dossier patient par « recherche », lorsque le dossier est afficher il clique sur l’onglet « dossier médical » qui contient plusieurs onglet (symptôme, observation médical, ordonnance, examens, antécédents) ; le médecin remplis les champs par les informations nécessaires, il confirme l’enregistrement, un message confirme que les informations sont bien enregistrées.

(3) «recherche d’un patient »

Lors de l’inscription du patient la réceptionniste vérifie par nom si le patient existe déjà, s’il n’existe pas il passe à la création du dossier

si le patient est déjà inscrit, la réceptionniste clique sur recherche dans le menu gestion de patient, une page s’affiche, donne la main pour saisir soit le nom ou le numéro de dossier, le système effectue une recherche puis il affiche une liste des patients, on sélectionne le patient et le dossier s’affiche.

S’il n’existe aucun patient un message d’erreur s’affiche.

(4) « Accès et modification »

Page 39: Medical openerp

Rapport de stage PFE

39

Le médecin et l’administrateur accèdent au dossier patient avec droit de modification et de la mise à jour du dossier médical et du dossier administratif, il peut modifier en cliquant sur le bouton modifier puis enregistrer , un message confirme la modification.

(5) « liste des patients »

Pour consulter la liste des patients on clique sur l’onglet « liste des patients » une liste sera afficher

(6) « suppression du dossier »

La suppression du dossier patient n’effectue par l’administrateur que s’il a commis une erreur lors de la création du dossier, une demande de confirmation est affiché.

(7) « gestion d’hospitalisation »

Un onglet hospitalisation dans le dossier patient, Pour chaque patient qui doit être hospitalisé, l’agent lui affecte un numéro de chambre, un numéro de lit et le numéro de l’infirmier soigné, ces informations doit être enregistré dans le dossier patient après une justification de l’hospitalisation qui doit être faite par le médecin.

(8) « gestion de la sortie »

Si l’hospitalisation du patient est terminée l’agent doit diffuser les informations et le type de la sortie, ces informations doit être enregistrer dans l’hospitalisation pour préparer la facture et un reçu de sortie puis libération de chambre et l’archivage du dossier s’il n’y a pas de prochain RDV.

Gestion des chambres :

Diagramme de cas d’utilisation

ajouter une chambre

modifier une chambreconsulter infos

chambre

supprimer une chambre

<extend>

<extend>agent

Figure 9 : Diagramme de cas d’utilisation: gestion des chambres

Page 40: Medical openerp

Rapport de stage PFE

40

Sommaire d’identification :

Titre : « gestion des chambres »

But : - gérer les chambres de l’hôpital.

Résumé : l’agent gère les chambres de l’hôpital les affecter aux patient hospitalisés selon la

disponibilité, il a la possibilité de les modifier, les supprimer ou les consulter.

Acteur : agent

Pré-conditions :

- les caractéristique des chambres est déjà saisie dans le système.

-l’agent est authentifié.

Enchainement A: « accès et modification »

L’agent peut accéder à une chambre par numéro pour La consulter ou la modifier selon le choix.

Enchainement B: «suppression du chambre ».

On supprime une chambre en saisissant son numéro, après une confirmation la chambre sera supprimer.

Gestion des rendez-vous

<<include>>

<<include>>

<<include>>

infirmier

consulter la liste des RDV

créer rendez_vous

modifier rendez_vous

authentification

Figure 10 : Diagramme de cas d’utilisation gestion Rendez-vous

Page 41: Medical openerp

Rapport de stage PFE

41

Sommaire d’identification Nom du cas d’utilisation : Prise des rendez-vous

But : Le patient souhaite obtenir un rendez-vous

Résumé : Un patient demande un rendez-vous. Ce rendez-vous peut provenir de deux sources :

De la prescription d’un acte médical par un personnel médical Du désir du patient de consulter un PM, par spécialité, ou par nom.

Acteur : Un Personnel Administratif (PA), en interaction avec le patient Les horaires du personnel et de l’équipement médical sont déjà saisis dans le système.

Description des enchaînements

Pré-conditions

Les horaires du personnel et de l’équipement médical sont déjà saisis dans le système.

Le PA est déjà authentifié

Post-conditions :

Le patient a un rendez-vous pour son acte médical à une date et heure donnée

Le personnel médical qui va effectuer l’acte a le même rendez-vous saisi dans son calendrier

Nom du cas d’utilisation : gestion des rendez-vous

But : fixer un rendez-vous selon la disponibilité du médecin

Résumé : l’infirmière crée un nouveau rendez-vous pour un patient après la vérification de disponibilité du médecin, elle peut par la suite consulter la liste des rendez-vous, annuler ou modifier la date.

Acteur : infirmière.

Description des enchaînements

Pré-conditions

Calendrier du médecin existe.

L’infirmière est déjà authentifiée.

Page 42: Medical openerp

Rapport de stage PFE

42

Post-conditions :

Le patient a un rendez-vous.

Gestion des examens médicaux

<<extend>>

<<extend>>

<<extend>>

<<extend>>

Consulter la l iste des examens

Modifier

Supprimer

Remise des résultats des analyses

Demander examen

Effectuer examen

Fixer rendez-vous

Patient

Medecin

Générer compte rendu

Prescrire du traitement

Prescrire des medicamentsPrescrire une chirurgie

Creer examen

Détéction de maladie

Infirmier

Figure 11 : Diagramme de cas d’utilisation: gestion des examens médicaux Sommaire d’identification

Titre: Gestion des examens.

But : Réalisation d’un examen programmé (ou un cas d’urgence) pour un patient.

Résumé : Lorsqu’un patient se présente pour effectuer un examen (cas ordinaire ou cas d’urgence), le médecin vérifie que c’est bien le patient à examiner pour cette séance, auquel cas il réalise l’examen, de plus il édite un compte rendu instantané dans le cas d’un examen simple, ou d’un examen complexe (cas d’urgence.).

Acteurs : Médecin.infirmier,

Page 43: Medical openerp

Rapport de stage PFE

43

Description des enchaînements

Pré-conditions

1. Le médecin se connecte, s’identifie et s’authentifie auprès du système. 2. Le patient se présente muni de sa fiche de RDV (Programmé pour la journée).

Scénarios

1. Le cas d’utilisation commence lorsque le médecin se connecte au système en fournissant son

login et son mot de passe. 2. Lorsque le tour d’un patient arrive, il se présente chez le médecin, ce dernier choisit l’option

‘Réaliser un nouveau examen’, la fiche correspondant s’affiche sur écran, il saisit le code de l’examen puis vérifie que c’est bien le patient à examiner.

3. Auquel cas, le médecin consulte les observations de l’anesthésiste, et les antécédents du patient.

4. Scénario 1. Si l’examen à effectuer présente un risque sur le patient (le médecin se réfère aux observations de l’anesthésiste), Le médecin choisit l’option ‘Prescrire un examen’, puis réoriente le patient à la réception.

5. Scénario 2. Si l’examen à effectuer ne présente aucun risque sur le patient :

5.1. Le médecin réalise l’examen à l’aide de l’appareil (La modalité). L’image de la radio est récupérée, traitée et archivée.

5.2. Si c’est le cas d’un examen simple, le médecin interprète l’examen puis édite un compte rendu, le valide ensuite, compte rendu final, (le compte rendu et une référence à l’image de la radio sont rajoutés au dossier patient). Il imprime ensuite le cliché de la radio et le compte rendu, et remet le tous au patient.

5.3. Dans tous les cas, et pour des raisons pédagogiques, le médecin choisit de proposer des examens qu’il juge intéressants pour les médecins radiologues résidents qu’il suit, pour interprétation.

5.4. Dans tous les cas, si le médecin juge la nécessité d’un examen complémentaire, il choisit l’option ‘Prescrire un examen’, puis le prescrit au patient (Le numéro de l’examen qui a généré cet examen complémentaire est mentionné dans l’ordonnance), auquel cas ce dernier se présentera à la réception pour fixer la date du rendez-vous.

Edition et Remise des résultats

Sommaire d’identification Nom du cas d’utilisation : Edition et remise des résultats d’un examen complexe.

But : Edition et remise des résultats (cliché de radio et compte rendu final) d’un examen au patient.

Résumé : Edition d’un résultat d’examen à partir du dossier patient puis remise du cliché et du compte rendu final.

Acteurs : Secrétaire médicale.

Page 44: Medical openerp

Rapport de stage PFE

44

Description des enchaînements Pré-conditions

1. Connexion, identification et authentification de la secrétaire médicale. 2. Le patient se présente muni d’un bon de retour (Programmé pour la journée) Scénarios 1. Le cas d’utilisation commence lorsque la secrétaire médicale se connecte au système en

fournissant son login et son mot de passe. 2. Lorsque le patient se présente muni de son bon de retour pour récupérer les résultats de son

examen, la secrétaire vérifie la date de retour mentionnée sur le bon et saisit le numéro de l’examen.

3. Si l’examen n’est pas prêt à être remis (l’examen est en instance d’interprétation, attente de

l’avis du médecin expert, ou du colloque), le patient sera appelé dés que les résultats de son examen seront prêts, l’examen est automatiquement rajouté à la liste des examens en instance de remise. Sinon la secrétaire médicale lance l’impression du compte rendu final et du cliché de la radio de l’examen.

4. Elle récupère la radio et le compte rendu qu’elle signe, puis elle met le tous dans une chemise qu’elle remet au patient.

Exception

1. Échec de connexion au système. 2. Résultats non disponibles : le patient sera appelé dés que les résultats de son examen seront

disponibles.

Post-conditions :

1. Résultats de l’examen du patient remis. 2. L’examen (Dont le compte rendu n’est pas disponible) est mis en instance de remise.

Facturation

<<includes>> PatientRégler facture

Carte crédi t

AssuranceEspèce

Effectuer le paiement

Page 45: Medical openerp

Rapport de stage PFE

45

<<includes>>

<<includes>>

<<includes>>

<<includes>>

<<includes>>

Rechercher une facture

Consulter la liste des factures

Authenti fication

Imprimer facture

Enregistrer facture

Creer facturePersonnel administrati f

Modifier le prix

Figure 12 : Diagramme de cas d’utilisation: facturation Sommaire d’identification But : Paiement et facturation d’une prestation

Résumé : Un patient est appelé à payer pour un acte médical. Le membre du personnel administratif (MPA) interagit avec le patient pour le paiement. Il y a différentes modalités de paiement, dépendant du type d’acte, et du type d’assurance détenu par le patient :

1) paiement comptant 2) paiement par carte de crédit 3) paiement par transmission à l’assurance du patient 4) Dans tous les cas, un reçu est remis au patient avec indication du mode de paiement

Acteur : Un Personnel Administratif (PA)

Description des enchaînements

Pour simplifier, on va supposer que le paiement est enclenché à la fin d’un acte médical quand le patient se dirige vers le PA. En réalité, le paiement se fait souvent avant le début de l’acte (pour un rendez-vous simple, un test biologique) quand on en connait les paramètres et après quand le nombre

Page 46: Medical openerp

Rapport de stage PFE

46

de tests / examens peut varier dépendant de ce que le personnel médical juge. Dans ce dernier cas, on saisit au début le mode de paiement (assurances, numéro de carte de crédit, etc.)

Gestion de chirurgie :

<include>

<include>

<include>

chirurgien

chef de bloc

demande la chirurgie pour un patient

affecter le patient à un bloc authentification

donner un RV pour l'opération

Description :

Titre : gestion de la chirurgie

But : Bonne gestion des blocs opératoires

Résumé : le médecin détecte que le patient a besoins d’une chirurgie, il envoie la demande au chef du bloc qui a son tour précise la date et lui affecte à un bloc

Acteurs : médecin, chef du bloc

Pré-condition :

Le médecin a effectué la consultation.

Le chef du bloc s’authentifié.

Post-condition :

La chirurgie est planifiée.

Pré-conditions L’agent du personnel administratif est déjà authentifié On a déjà accès à la prestation en question

Post-conditions : Le paiement est reçu La prestation médicale en question est marquée payée

Page 47: Medical openerp

Rapport de stage PFE

47

Description des enchaînements

Cas (1) : « demande de chirurgie »

Lors de la consultation, si le patient a besoins d’une opération le médecin remplie la fiche de chirurgie en indiquant le code et le type de la chirurgie.

Cas (3) : « Affecter le patient à un bloc »

Lorsque le chef du bloc reçoit la demande de la chirurgie à partir du dossier médical du patient il introduit les informations suivantes : le chirurgien l’anesthésiste et le numéro du bloc où l’opération sera effectuée selon la disponibilité.

Cas (2) :« donner un rendez-vous pour l’opération »

Après l’affectation du bloc et du chirurgien, le chef du bloc fixe la date de l’opération et il confirme.

Gestion des utilisateurs :

<<extend>>

<<extend>>

Modifier informations personnelles

Mise à jour util isateur

Supprimer uti lisateur

Creer uti lisateur

Administrateur

Retirer profi lAjouter nouveau profil

Modifier profi l

Moifier droits d'accès

Gestion des profils des util isateurs

Figure 13 : Diagramme de cas d’utilisation: gestion utilisateurs

Page 48: Medical openerp

Rapport de stage PFE

48

Sommaire d’identification Titre : Gestion des utilisateurs

But : Enregistrement des utilisateurs actuels du système et l’attribution des droits d’accès et des profils à chaque utilisateur.

Résumé : L’administrateur attribue un profil et des droits d’accès (nom d’utilisateur, mot de passe) à chaque nouvel utilisateur enregistré. Il peut aussi modifier des utilisateurs existants (informations personnelles, droits d’accès et profils) ou supprimer les profils de certains utilisateurs (inactifs).

Acteurs : Administrateur

Pré-conditions

L’administrateur s’authentifie

Post-conditions

Tous les utilisateurs actuels du système sont enregistrés avec leurs droits d’accès et leurs profils

Description des enchaînements : Enchaînement (a) : Création d’un nouvel utilisateur

L’administrateur sélectionne la catégorie socioprofessionnelle du nouvel utilisateur (médecin, infirmier, secrétaire médical,…). Il remplit les informations personnelles de l’utilisateur et lui attribue ses droits d’accès au système (nom d’utilisateur, un mot de passe) et valide l’opération.

Enchaînement (b) : Mise à jour des utilisateurs existants

L’administrateur peut modifier les informations personnelles, le profil ou les droits d’accès des utilisateurs existants. Après chaque mise à jour, il valide toutes les modifications apportées.

Enchaînement (c): Gestion des profils utilisateurs

L’administrateur peut mettre à jour le profil des utilisateurs existants. Ainsi, il peut ajouter, ou retirer un ou plusieurs profils aux utilisateurs existants.

6. Capture des besoins techniques

6.1 Benchmarking des ERP Open Source:

Le marché des ERP pour PME est en pleine expansion. Comme sur tous les marchés, les acteurs se sont d’abord intéressés aux plus grands clients. Concernant les ERP, les éditeurs visaient dans un premier temps les multinationales. Une fois ce marché saturé ils ont racheté des solutions

Page 49: Medical openerp

Rapport de stage PFE

49

pour PME afin de mettre un pied dans ce secteur d’activités. Les logiciels libres ont ciblé les petites structures dès le départ. Développés en étroite collaboration avec les utilisateurs et les intégrateurs, ces solutions sont parfaitement adaptées à ces entités.

OpenERP représente un idéal de logiciel agile, apte à répondre à n'importe quel besoin. OpenERP combine à la fois la force d'un éditeur et une réelle communauté qui balise la plupart des cas d'usages et fournit de précieux retours, notamment sous forme de modules réutilisables. Tout ceci est rendu possible par une réelle innovation technologique qui s'appuie néanmoins sur des standards reconnus et terme de base de données et de webservices.

Smile a étudié la majorité des ERP Open Source existants et tout particulièrement Openbravo, Neogia, OpenERP, Compiere et ERP5. Elle n’a pas retenu ces deux derniers à cause de leur manque d'ouverture et de l'absence d'une communauté d'utilisateurs active. Plus récemment, Smile s’est engagé plus fermement avec OpenERP, qu'elle considère comme l'offre la plus prometteuse dans le domaine des ERP Open Source

Profile par caractéristiques générales

Les caractéristiques générales d’un ERP porte surtout sur :

- Sa notoriété actuelle, qui est importante dans la mesure où elle est source de sécurité et que les indicateurs sont bons pour montrer que la solution restera valable dans 5ans au moins.

- Son dynamisme, il s’agit de la dynamique communautaire autour de la solution. Cette dynamique avec la qualité technique déterminera la place de l’ERP dans le futur.

- Sa technologie, elle mesure le degré de la cohérence, la puissance et l'adéquation avec les standards des modélisations au cœur d'un ERP.

- Son périmètre fonctionnel, c'est-à-dire le volume global de fonctionnalités couvertes par l’ERP.

- Sa souplesse, dans la mesure où l’on doit absolument dépasser le périmètre natif de l’outil, est-il possible ? est-ce un facteur déterminant dans le coût global de la possession de la solution

- La difficulté ou non à mobiliser des ressources capables d'effectuer des développements pointus sur l'outil

On peut synthétiser le résultat des études comparatives effectuées sur cet aspect des ERP par le tableau et le graphe suivant :

Solution notoriété dynamique techno périmètre souplesse ressources OpenERP 4 5 4 5 5 4 OpenBravo 4 5 3 4 3 4 Neogia 3 3 4 4 3 3 ERP5 4 2 4 4 4 1 Adempiere 4 4 3 4 3 4 Compiere 5 3 3 4 3 4

Page 50: Medical openerp

Rapport de stage PFE

50

Figure 14: graphe comparatif des caractéristiques générales

Profile par caractéristiques générales

Voici un récapitulatif des capacités relatives de chacun des ERP retenus sur les domaines fonctionnels les plus caractéristiques (de 0 à 5 pour le plus adapté).

Les différences les plus marquantes se font sentir sur les modules de gestion des ressources humaines pour lequel seuls ERP5 et OpenERP sont complets. ERP5 va même jusqu'à gérer les paies alors qu'aucun autre ERP libre n'est allé aussi loin (OpenERP s'y essaie, le partenaire marocain d’OpenERP, SYSTEMUM, a présenté récemment sa version bêta du module de paie entièrement adapté à la législation marocaine, avec gestion des allocations sociales). Sans module RH, la gestion de projet est aussi plus limitée et c'est ainsi que OpenERP traite mieux que ses concurrents ce domaine fonctionnel. De même, ERP5 et OpenERP sont plus complets sur la CRM, où Openbravo est plus limité. En revanche, ce dernier se distingue avec son interface web inégalée.

OpenERP

Page 51: Medical openerp

Rapport de stage PFE

51

Solution

achats

ventes

compta

CRM

SCM

GPAO

POS

RH

Paies

Projets

Web

BI

OpenERP 4 4 4 4 4 4 4 4 1 4 4 4

OpenBravo 4 4 3 2 5 4 5 0 0 3 5 4

Neogia 4 4 4 3 5 3 4 1 0 3 3 3

ERP5 4 4 5 4 4 4 1 4 4 ? 4 ?

Adempiere 4 4 4 3 5 3 4 0 0 3 1 3

Compiere 4 4 5 3 5 3 4 0 0 3 1 3

Tableau 1: Récapitulatif du profil des ERP selon le domaine fonctionnel

Figure 15: graphe comparatif des ERP selon les domaines fonctionnels

OpenERP

Page 52: Medical openerp

Rapport de stage PFE

52

6.2 Solution choisie pour l’implémentation de projet : OpenERP est une solution complète qui automatise et unifie tous les processus critiques de

l’entreprise : la finance, la gestion de caisse, les processus d’achat et vente, la gestion de production,

la logistique et la relation client et fournisseur. De nombreux outils de reporting sont disponibles.

OpenERP fournit un accès rapide à l’information. Chaque employé accède aux informations

nécessaires en un temps record : les informations sont traitées simplement et efficacement, avec par

exemple l’intégration directe avec OpenOffice.org (il est possible d’importer n’importe quel type de

données par l’intermédiaire d’un fichier de type CSV, avec OpenOffice Calc),

OpenERP tient compte des préférences et besoins de chaque utilisateur afin d’accélérer son travail,

ou pour qu’il construise et automatise la solution selon ses besoins.

Smile a étudié la majorité des ERP Open Source existants et tout particulièrement Openbravo,

Neogia, OpenERP, Compiere et ERP5. Elle n’a pas retenu ces deux derniers à cause de leur manque

d'ouverture et de l'absence d'une communauté d'utilisateurs active. Plus récemment, Smile s’est

engagé plus fermement avec OpenERP, qu'elle considère comme l'offre la plus prometteuse dans le

domaine des ERP Open Source.

Ils permettent à des petites PME de disposer d'outils de gestion complets au meilleur

coût, leur apportant rapidement un vrai bénéfice en termes de compétitivité. Les seuls

coûts étant alors la formation des utilisateurs et le service éventuellement assuré par le

fournisseur du logiciel.

Ils s'adressent aussi à des PME de plus de 1000 salariés, que ce soit dans les secteurs

industriels, distribution ou services.

6.3 Présentation de l’OpenERP

6.3.1 Profil général

Notoriété actuelle

Plusieurs dizaines voire centaines de déploiements dans le monde entier, de l'Argentine à la Chine en passant par l'Inde. Mais encore assez peu de grosses PME. Citons pourtant parmi les références les Hôtels de luxe Costes (Sednacom), Whirlpool Paris, l'ENA, la chambre de commerce et industrie, l'administration du canton de Vaud (Suisse), IR-Microsystems... Étant donné le potentiel du produit, de nouvelles références importantes ne devraient pourtant pas tarder.

Page 53: Medical openerp

Rapport de stage PFE

53

Dynamique

La dynamique est aussi très forte. La société éditrice est passée de moins de 5 à plus de 60 salariés en moins d'un an et demi pour répondre à une demande en très forte croissance. De même, le nombre d'intégrateurs s'étoffe significativement de mois en mois dans le monde entier.

Technique

Sans doute l'ERP open source le plus moderne au plan technique. La souplesse de modélisation d'un ERP5 mais la base relationnelle d'un Compiere. Pour autant, on pourra regretter que ni l'ORM ni le moteur de BPM ne soient des standards reconnus. De même, si l'usage d'un langage dynamique tel que Python pour les couches métiers de l'ERP participe indubitablement à la souplesse inégalée de l'outil, pour les couches basses d'infrastructure, un langage statique tel que Java aurait apporté un gain de performance et de fiabilité. Notons cependant que cette fiabilité semble pourtant assurée dans le cas d’OpenERP par une large batterie de tests unitaires et une très large communauté d’utilisateurs et de développeurs vigilants. Mais comme l'ERP idéal n'existe pas et étant données les contraintes existantes lors de sa création, OpenERP mérite déjà largement le meilleur classement en terme de technologie.

Périmètre

Là aussi, le plus vaste périmètre fonctionnel grâce à ses quelques 500 modules. Si 50% de ces modules relèvent d'un certain amateurisme, il en reste néanmoins une large base de modules réellement efficaces. Outre les domaines classiques, il y a une foule de modules variés dédiés à des cas très spécifiques: tels que la création de portails pour les clients, la gestion des adhésions aux associations, la gestion de projet informatique agile (SCRUM)...

Figure 16 : Adéquation par rapport au secteur et la taille de l’entreprise

Page 54: Medical openerp

Rapport de stage PFE

54

Figure 17 : Aptitudes par fonctionnalités

Souplesse

Très bonne souplesse grâce à la scriptabilité de bout en bout et plus spécifiquement dans les workflows et le reporting. Par ailleurs, le puissant moteur de workflow mis en œuvre par OpenERP est une des clés de sa souplesse.

Web

eTiny, la surcouche serveur développée initialement par Axelor, puis désormais co-développée par Axelor et Tiny.be est un modèle de simplicité et d'efficacité. Elle ne fait que traduire les web services de OpenERP en HTML et apporte des fonctionnalités avancées comme l'auto complétion Ajax ou les raccourcis clavier. La couche web ajoute même un composant qui permet de visualiser les plannings, il s'agit de la seule différence sensible avec le client lourd.

Comptabilité

Comme sur d'autres ERP, la comptabilité analytique est compétitive: gestion des budgets, comptabilité analytique multiaxiale et hiérarchique. Concernant la comptabilité générale, elle est l'une des plus avancée et bien qu'utilisée dans certaines PME. Notons toutefois qu'en dépit de certains manques de finitions, le plan comptable marocain peut être importé autant que module développé par SYSTEMUM ; cette comptabilité permet l'édition des bilans, comptes de résultats et liasses fiscales.

Business Intelligence (BI)

La Business intelligence comporte des rapports paramétrables. Elle inclut également une solution de raquetteur de cube OLAP pour des analyses plus fines et sans coût d'intégration démesuré. La version en développement est néanmoins largement avancée et déjà testable.

Page 55: Medical openerp

Rapport de stage PFE

55

6.3.2 Avantages

Éditeur très dynamique Communauté dynamique et expérimentée Périmètre fonctionnel inégalé avec ses quelques 300 modules et des nouveaux

modules tous les mois. Conception très intelligente. Souvent jusqu'à 10 fois moins de code que les ERP en Java pour

offrir les mêmes fonctionnalités! Interface web très compétitive Vrai ORM qui fait le pont entre la base relationnelle et le code objet proche des spécifications

fonctionnelles Tout le datamodel et les méthodes métier sont nativement exposés en webservices , c'est un

gage d'interopérabilité facile Moteur BPM intégré très efficace Grand souplesse générale, notamment grâce à la scriptabilité des rapports Croissance autofinancée Les coûts d'intégration les plus faibles grâce à du paramétrage graphique très avancé et grâce

à la simplicité générale du code.

6.3.3 Architecture modulaire d’OpenERP Un module OpenERP est la définition, dans le «Framework» OpenERP, d’une gestion

informatisée d’un domaine. Cette architecture n’est pas propre à open ERP. Elle est en fait partagée par tous lesERP.Ils’agit de la faculté de construire des applications informatiques de manière modulaire (modules indépendants entre eux) tout en partageant une base de données unique. Ceci apporte une importance significative puisque les données sont maintenant standardisées et partagées. Ce qui élimine les saisies multiples et évite l'ambiguïté des données de même nature. L’architecture modulaire d’open ERP lui permet de couvrir plusieurs domaines illustrés dans la figure ci-dessous :

Figure 18 : Architecture modulaire d’open ERP

Page 56: Medical openerp

Rapport de stage PFE

56

6.3.4 Architecture technique d’OpenERP Architecture Client/Serveur

Open ERP est basé sur une architecture client/serveur. Le serveur et le client communiquent via le protocole XML-RPC.C’est un simple protocole qui permet au client de faire des appels aux procédures. Une fois la fonction est appelée, ses arguments et ses résultats sont envoyés par le protocole http, eux-mêmes sont encodés par le langage XML.

OpenERP est couplé à une base de données PostgreSQL. De plus,il est compatible au pack Open Office, et aussi avec des outils de reporting (ReportLab) pour produire des rapports en PDFou en HTML.

La logique d’openERP est entièrement du côté serveur.La tâche du client se résume à demander les données (formulaire ou listes) au serveur et de les renvoyer. Avec cette approche, presque tout le développement est fait du côté serveur.Ce qui rend OPENERP plus simple au développement et à la maintenance.

L’opération client est très simple. Quand un utilisateur exécute une action (sauvegarder un formulaire, ouvrir un menu, imprimer, ...) il envoie cette action au serveur. Le serveur envoie alors la nouvelle action pour s'exécuter côté client.

Il y a trois types d'actions :

Ouvrir une fenêtre (formulaire,listes) Imprimer un document. Exécuter un wizard.

Figure 19:Architecture Client-Serveur d’open ERP

Le Framework développement OpenObject

OpenERP offre un cadre de développement, c’est à dire des «services» techniques

informatiques :

Un serveur de base de données objet pour représenter et mémoriser les objets de gestion

et les rendre accessible via le réseau.

Page 57: Medical openerp

Rapport de stage PFE

57

Un "workflow" qui contrôle l’évolution des objets suivant une procédure. Des formulaires et écrans pour l’interaction avec l’utilisateur. Des états imprimables des objets.

Figure 20 : Structure d’un module OpenERP

7. Analyse et Conception

7.1 Développement du modèle dynamique

7.1.1 Formalisation des scenarios

Authentification

fenetre d'authentification()

connexion réussite

connexion échouée

fenetre d'accueil()

alt

Authentifier(login,password)

Systeme

Personnel medical

fenetre d'authentification()

fenetre d'accueil()

Authentifier(login,password)

Figure 21: Diagramme de séquence : Authentification

Page 58: Medical openerp

Rapport de stage PFE

58

Création nouveau dossier patient Sénario

patient existepatient existe

alt dossier créé

affiche la l iste des medecins concerné

enregistrer données patient

chercher medecin selon la spéciali té

affiche patient existe deja

fin

patient n'existe pas

afficher la fiche administrative patient

authentificationREF

créer nouveau dossier patient

demande d'enregistrer nouveau patient

selectionner categorie(patient ambilatoire/hospitalisation/urgence)

saisir les données patient(nom, prenom)

saisir type de maladie

selectionner le medecin

receptionniste

system

dossier créé

affiche la l iste des medecins concerné

enregistrer données patient

chercher medecin selon la spéciali té

affiche patient existe deja

fin

afficher la fiche administrative patient

demande d'enregistrer nouveau patient

selectionner categorie(patient ambilatoire/hospitalisation/urgence)

saisir les données patient(nom, prenom)

saisir type de maladie

selectionner le medecin

saisir nom de patient

oid patient

saisir medecin traitant

oid medecin

selectionner maladie

oid maladie

saisir assurance

oid assurance

créer dossier patient(oid dossier, oid patient)

IHM patient medecin maladie assurance dossier patient

saisir nom de patient

oid patient

saisir medecin traitant

oid medecin

selectionner maladie

oid maladie

saisir assurance

oid assurance

créer dossier patient(oid dossier, oid patient)

Figure 22 : Diagramme de séquence Création nouveau dossier patient

Page 59: Medical openerp

Rapport de stage PFE

59

Rechercher un patient Scénario

alt

créer nouveau dossierref

patient existe

patient n'existe pas

authentificationref

demander chercher patient

recherche

afficher dossier

affiche patient n'existe pas

saisir nom ou id patient

fin

personnel médical

système

demander chercher patient

recherche

afficher dossier

affiche patient n'existe pas

saisir nom ou id patient

fin

Nouvelle prescription pour un patient

Figure 23: Diagramme de séquence Création de prescription de médicament

Page 60: Medical openerp

Rapport de stage PFE

60

Gestion d’hospitalisation :

Scénario :

alt

opt

chercher un patientref

cas d'hospitalisation

cas de fin d'hospitalisation

vérifier la disponnibi li té

enregistrer

saisir info de sortie (type....)

enregistrer

archivage du dossier

authentificationref

saisir num de chambre, l it et infirmier

verifirer la date de sortie

fin

systeme

agent

vérifier la disponnibi li té

enregistrer

saisir info de sortie (type....)

enregistrer

archivage du dossier

saisir num de chambre, l it et infirmier

verifirer la date de sortie

fin

Commentaire :

L’hospitalisation ne peut s’autoriser que si elle est justifier par le médecin à partir la vérification du diagnostic et aussi après la vérification de la disponibilité de chambre sinon elle va reporter a une date précise.

Les informations d’hospitalisation doit être saisi et enregistrer dans le dossier médical.

L’archivage du dossier n’effectue que si l’hospitalisation est terminé et on n’a pas de prochain rendez-vous.

Page 61: Medical openerp

Rapport de stage PFE

61

Figure 24 : Diagramme de séquence : gestion hospitalisation

Gestion de RDV :

Diagramme de séquence :

nom patient

selectionner medecin

oid patient

oid medecin

créer RDV (oid rdv, oid patient)

imprimer

definir date

selectionner etat de patient

IHM patient medecin RDV

nom patient

selectionner medecin

oid patient

oid medecin

créer RDV (oid rdv, oid patient)

imprimer

definir date

selectionner etat de patient

Figure 25 : Diagramme de séquence : gestion RDV

Page 62: Medical openerp

Rapport de stage PFE

62

Ajouter chambre

Scénario :

[ tout les champs sont rempli ]

sinon

alt

authentification

ref

verification

demander le remplissage de tout les champs

enregistrer la chambre

demander l 'ajout du chambre

afficher les champs à saisir

saisir les info chambre

ajouter

agent.

system.

verification

demander le remplissage de tout les champs

enregistrer la chambre

demander l 'ajout du chambre

afficher les champs à saisir

saisir les info chambre

ajouter

authentificationref

opt [ le numéro du chambre valide ]

fin

demander la consultation du chambre

demander la saisie du numéro de la chambre

saisir le numéro du chambre

afficher les caractéristiques de la chambre

systeme.

age nt

fin

demander la consultation du chambre

demander la saisie du numéro de la chambre

saisir le numéro du chambre

afficher les caractéristiques de la chambre

Page 63: Medical openerp

Rapport de stage PFE

63

Gestion d’examen : Diagramme de scénario qui decrit les processus d’un examenns médicale :

Figure 26 : Diagramme de séquence : gestion examen

Page 64: Medical openerp

Rapport de stage PFE

64

Gestion de la chirurgie :

Diagramme de séquence :

saisir le nom

selectionner médecin

affecter au bloc

saisir infos chirurgie (nom d'opération, description...) et creer nouvelle chirurgie

oid patient

oid medecin

oid bloc

oid chirurgie

vérifier disponibilité

saisir la date d'opération

IHM patient medecin bloc operatoire chirurgie

saisir le nom

selectionner médecin

affecter au bloc

saisir infos chirurgie (nom d'opération, description...) et creer nouvelle chirurgie

oid patient

oid medecin

oid bloc

oid chirurgie

vérifier disponibilité

saisir la date d'opération

Figure 27: Diagramme de séquence : gestion chirurgie

7.1.2 Diagramme d’état

Diagramme d’état/transition : « Gestion de patient »

malade/créer() admission/créer_rdv()

avoir un rdv/ créer_med(dossier-admin)

etat de malade/ créer_rdv()

etat non hospital isé/ordonnance()

consulter()

etat hospital isé/séjour()

soins/ordonance()

bonne santé / sortie()

bonne santé/archiver()

fin séjour/ archiver()

fin

dossier administratif rendez-vous

dossier médical

consultation

hospital isation

traitement

sortie

archivage du dossier

Figure 28 : Diagramme d’état de transition : gestion patient

Page 65: Medical openerp

Rapport de stage PFE

65

Commentaire :

L’hôpital admet des patients qui doivent avoir un dossier qui sera créé et enregistré par la réceptionniste puis il passe à l’infirmier pour prendre un rendez-vous et l’enregistrer dans le dossier. A ce moment le patient peut visiter le médecin qui doit à son tour créer le dossier médical au cour de la consultation, il saisit la description de maladie, les symptôme, les examens à faire et le traitement à suivre qui sera enregistré comme des antécédents avec la date, si la consultation est terminé l’infirmier lui donne un nouveau rendez-vous et l’enregistrer dans le dossier.

Dans le cas où le patient a besoins d’être hospitalisé, il passe à l’agent qui vérifie la justification d’hospitalisation et lui affecte une chambre et un lit après la vérification de la disponibilité de chambre.

« Gestion personnel »

nouvelle En validation

refusé

validé

création de demande/ajouter()

envoi au administra

teur

modification/renvoi

traitment de

demande

OK

non

arrivé/prise de fonction

demande de retraite/mise en retraite

prise de congé/mise en congé

retour de congé/ mise en fonction

absence/mise en absence

retour/reprise de fonction

démission/départ

recrutéretraite

en congéactivité

en arretparti

Figure 29: Diagramme d’état de transition : gestion personnel

Page 66: Medical openerp

Rapport de stage PFE

66

7.1.3 Diagramme d’activité

infirmiere médecin laboratoire caisseur

<<nouveau patient>>

<<patient existe>>

créer nouveau dossier

donner un RDV consultation

presciption des tests

ordonnancechirurgie

imprimer

éditer facture

.

hospitalisation

sortie

traiter la demande de test

remise des resultatsdetection de maladie

prescription de traitement

approuver la facture

Figure 30 : Diagramme d’activité : suivi de patient

Page 67: Medical openerp

Rapport de stage PFE

67

7.2 Développement du modèle statique

7.2.1 Diagramme de classe

0..*

0..*

0..10..*

1..*

1..1

1..1

0..*

0..1

0..*

1..*

1..*0..1

0..*

1..*

0..*

0..1

0..*

1..*

1..1

1..1

0..*

0..*

0..*

0..1

0..*

0..1

0..*

0..1

0..*

Product_Product

- id_product : int

Service

--

codenom

: int: char

Patient

--------------

id_patientnomprenomrefdatephotoagesexedate_naisssituationadressedate_décesraison-décesinfo_général

Assurance

------

id_assurancecompaniecategorietypedate-debdate-fin

Res_partner

Medicament

----------

id_medicamentnomcompositionindicationdosagestokageprixquantité_valableinfoeffet_indesirable

Medecin

---

id_medecinspecialitéinfo

Rendez_vous

-------

id_rendez_vousmedecinpatientniveau_urgenceserviceetat_patientdate

Consultation

---------

id_consultationtypedate_consultationdate_finsignesstatut_mentaldiagnosticsymptomesid_patient

Prescription

-----

id_prescriptionpatientdatenoteligne_prescription

Medicament_template

---------

medicamentvoie_d'administrationdoseformedebut-trai tementfin_traitementfréquencedurée_traitementquantité

Maladies

---------

codenomcatégoriesévéritésituation_maladiedate_diagnostiquedate-guérissonAllergiesthérapie

Ligne_prescription

----

id_ligne_prescriptionimpressionsubstitutionrenouvellement

Hospitalisation

---------

codeadmision_typedate_hospitalisationdate_sortieraison_admissionlit_hopitalmedecin_traitantchi rurgienetat

Chi rurgie

---------

codedate_chirurgiechirurgienanesthesisteblocserviceclassificationbase_conditionid_patient

hr_employe

------

id_employenomprenomdate_naissadressecinFacture

----

codedateetattotal

: int: Date: String: Double

acount.acount

Chambre

---

id_chambretypecapacité

Lit

---

id_littypeprix

: int: int: int

Examen medicale

---

id_examendésignationdate

: int: int: int

Figure 31 : Diagramme de classe globale

Page 68: Medical openerp

Rapport de stage PFE

68

8. Outils de réalisation et mise en œuvre

8.1 Choix des outils de développement et de modélisation

yEd Pour réaliser les diagrammes fonctionnels, yEd Graph Editor recèle des trésors de fonctions destinées

à la fois à personnaliser le moindre détail mais aussi à optimiser la lecture globale. Le programme est

très riche en fonctions et en méthode d'organisation : couches hiérarchiques interactives, couches

orthogonales, couches organiques, schémas UML, circulaires, en arbre, etc. Bien entendu, les

diagrammes générés peuvent être sauvegardés en plusieurs formats dont PDF, Flash, SVG, HTML,

EPS ou BMP. Une fonction très utile permet de découper de très grands schémas afin de les imprimer

sur plusieurs feuilles et de pouvoir ensuite les assembler entre elles pour reconstituer l'image en

grandeur réelle. Développé entièrement en Java, le programme fonctionne indépendamment du

système d'exploitation, il a juste besoin d'une machine virtuelle Java.

PowerAMC

PowerAMC est un environnement graphique de modélisation d’entreprise très simple d’emploi qui permet d’effectuer les tâches suivantes : Modélisation intégrée via l’utilisation de méthodologies et de notation standard :

Données (E/R, Merise) Métiers (BPMN, BPEL, ebXML) Application (UML)

Génération automatique de code via des templates personnalisables : SQL (avec plus de 50 SGBD),Java ,NET.

Fonctionnalités de reverse engineering pour documenter et mettre à jour des systèmes existants

Une solution de référentiel d’entreprise avec des fonctionnalités de sécurité et de gestion des versions très complètes pour permettre un développement multiutilisateur

Un environnement extensible, qui vous permet d’ajouter des règles, des commandes, des concepts et des attributs à vos méthodologies de modélisation et de codage.

Eclipse

Eclipse est un environnement de développement intégré libre extensible, universel et polyvalent, permettant de créer des projets de développement mettant en œuvre n'importe quel langage de programmation. Eclipse IDE est principalement écrit en Java(à l'aide de la bibliothèque graphique SWT, d'IBM), et ce langage, grâce à des bibliothèques spécifiques, est également utilisé pour écrire des extensions.

Page 69: Medical openerp

Rapport de stage PFE

69

La spécificité d'Eclipse IDE vient du fait de son architecture totalement développée autour de la notion de plugin (en conformité avec la norme OSGi) : toutes les fonctionnalités de cet atelier logiciel sont développées en tant que plug-in.

Plusieurs logiciels commerciaux sont basés sur ce logiciel libre, comme par exemple IBM Lotus Notes 8, IBM Symphony ouWebSphere Studio Application Developer.

8.2 Choix du SGBD postgresql

Présentation de PostgreSQL :

PostgreSQL est un SGBD très performant sous license BSD dont les performances sont comparables à Oracle 9.

PostgreSQL remonte à la base de données Ingres, développée à Berkeley par Michel STONEBRAKER.Lorsque ce dernier décida en 1985 de recommencer le développement de zéro, il nomma le logiciel Postgres, comme raccourci de post-Ingres. Lors de l’ajout des fonctionnalités SQL en 1995,Postgres fut renommé Postgres95.Ce nom fut changé à la fin de 1996 en PostgreSQL. PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO). C’est un outil libre disponible selon les termes d’une licence de type BSD.Ce système est concurrent à d’autres systèmes de gestion de base de données, qu’ils soient libres(comme MySQL et Firebird),ou propriétaire(comme Oracle, Sybase, DB2).

Comme les projets libres Apache et Linux, PosgreSQL n’est pas contrôlé par une seule entreprise, mais est fondé sur une communauté mondiale de développeurs et d’entreprises.

Le client Graphique pgadmin3:

PgAdmin III est un outil graphique d'administration de votre serveur PostgreSQL. L'application pgAdmin III peut être utilisé pour administrer les serveurs PostgreSQL 7.3 et les versions supérieures. PgAdmin III existe pour toutes les plateformes.

PgAdmin III a été conçu pour répondre aux besoins de tous les utilisateurs, depuis la rédaction de simples requêtes SQL au développement complexe de base de données. L'interface graphique supporte toutes les fonctionnalités de PostGreSQL et permet une administration simple. L'application inclut aussi un éditeur de requête avec coloration syntaxique, un éditeur de code, un agent de gestion de tâche automatique, un support pour les réplications via Slony-I et bien d'autres fonctionnalités.

8.3 Linux

Présentation

Linux ou GNU/Linux qui est un système d'exploitation, et logiciel libre créé en1991 par Linus Torvalds. Aujourd'hui, grâce à un effort considérable de développement fourni par des personnes du monde entier, Linux fonctionne sur quasiment toute architecture moderne.

Le noyau Linux a pris une importance aussi bien idéologique que technique. Il existe une communauté entière de personnes qui croient aux idéaux du logiciel libre et donnent de leur temps pour aider à rendre la technologie libre aussi performante que possible.

Page 70: Medical openerp

Rapport de stage PFE

70

L'esprit du libre, souvent attribué à Linux, influence les développeurs et les utilisateurs de logiciels partout dans le monde et entraîne des communautés partageant des objectifs communs.

Le projet GNU

Le projet GNU a été lancé en janvier 1984 par Richard Stallman, pour développer un système

d'exploitation complet de type UNIX, composé de logiciels libres: le système GNU. Les variantes

du système d'exploitation GNU, construites autour du noyau Linux, sont aujourd'hui largement

utilisées. Le projet GNU est étroitement lié à la philosophie du logiciel libre qui est omniprésente

dans les projets qui en découlent tels qu’ubuntu.

Ubuntu

Ubuntu est un système d'exploitation entièrement libre construit autour du noyau Debian. La communauté Ubuntu s'est formée autour des idéaux constitutifs de la philosophie d'Ubuntu :

Le logiciel doit être disponible gratuitement. Les logiciels doivent être utilisables dans la langue de l'utilisateur et en dépit de tout

handicap. L'utilisateur doit avoir la liberté de personnaliser et de modifier le logiciel à sa guise.

Ubuntu est le système d’exploitation sous lequel le module a été développé pour que le stage soit conforme aux idéaux de l’organisme d’accueil.

8.4 Choix du langage de programmation

8.4.1 Langage Python

Présentation

Python est un langage portable, dynamique, extensible, gratuit, qui permet (sans l'imposer) une approche modulaire et orientée objet de la programmation. Python est développé depuis 1989 par Guido van Rossum etde nombreux contributeurs bénévoles. [5]

Caractéristiques du langage Python

Ci-dessous le détail des principales caractéristiques du langage Python:

Portable: Il est supporté par les différents systèmes d’exploitation. Gratuit Simple : Il possède une syntaxe très simple tout en combinant des types de données évolués

(listes, dictionnaires…) Absence des pointeurs. Il est orienté objet et supporte l’héritage multiple et la surcharge des opérateurs Dynamique : Cette fonctionnalité est probablement la plus intéressante de Python. Extensible : On peut facilement l’interfacer avec des bibliothèques C existantes.

Page 71: Medical openerp

Rapport de stage PFE

71

Python gère ses ressources (mémoire, descripteurs de fichiers...) sans intervention du programmeur, par un mécanisme de comptage de références.

Python possède actuellement deux implémentations .L'une, interprétée, dans laquelle les programmes Python sont compilés en instructions portables, puis exécutés par une machine virtuelle (comme pour Java, avec une différence importante: Java étant statiquement typé,il est beaucoup plus facile d'accélérer l'exécution d'un programme Java que d'un programme Python).L'autre génère directement du bytecode Java.

Dynamiquement typé. Soutenu par la communauté d’utilisateurs qui tentent à l’évoluer.

8.4.2 Langage XML

Présentation du langage XML :

XML (eXtensible Markup Language et en Français Langage à balises étendu, ou Langage à balises extensible) était lancé en 1997 par la communauté SGML (Standard Generalized Markup Language). XML est un langage simple et puissant de description et d’échange de documents structurés de n’importe quel domaine de données grâce à son extensibilité, il décrit cette structure à l’aide d’un système de balises.

Quelques points remarquables d’XML :

Il apparaît comme un format d’échange de données universel. Il a la possibilité de créer des nouvelles balises contrairement à HTML qui définit un nombre

limité. Il garantit à ses utilisateurs l’indépendance de leurs documents de toute technologie

propriétaire. Il unifie le monde du traitement de document et celui du Web.

Tout document XML se compose :

D’un prologue qui peut contenir une déclaration XML, des instructions de traitement et une déclaration de type de document, dont la présence est facultative mais conseillée. Il contiendra un certain nombre de déclarations.

D’un arbre d’éléments, on parle d’élément père et d’élément fils. En fait la partie essentielle d’un document XML sera toujours formée d’une hiérarchie d’éléments qui dénote la sémantique de son contenu.

De commentaires et d’instructions de traitement, dont la présence est facultative. Ils pourront, moyennant certaines restrictions, apparaître aussi bien dans le prologue que dans l’arbre d’éléments.

Un document XMLvalide est forcément un document bien formé mais il obéit en plus à une structure type définie dans une DTD (Document Type Definition)

Une DTD peut contenir : - Des déclarations d'entités générales. - Des déclarations d'entités paramètres. - Des déclarations de notations. - Des déclarations d'éléments. - Des déclarations de listes d'attributs. - Des commentaires.

Page 72: Medical openerp

Rapport de stage PFE

72

9. Présentation du prototype réalisé Dans cette partie, nous présentons le prototype réalisé à travers des prises d’écrans, qui illustrent les fonctions principales fournies par noter système.

9.1 Présentation et description :

Médical est un module qui représente un système d’information hospitalier avec les caractéristiques suivantes :

Multi utilisateur

Entièrement paramétrable

Administration financière de l’institut hospitalier

Information pharmaceutique

Administration du laboratoire

Administration des patients (création, évaluations, consultations, historique,…)

Examination des patients et enregistrement de l’historique sans aucun papier.

Rapports sur les maladies.

Gestion des stocks et d’approvisionnement

Les standards sur les maladies et les actes médicales

Gestion centralisée du dossier patient

9.2 Process du module :

Le schéma suivant représente les processus de suivi du patient selon le module médical :

Page 73: Medical openerp

Rapport de stage PFE

73

Figure 32 : Process du module medical

Page 74: Medical openerp

Rapport de stage PFE

74

9.3 Configuration et Paramétrage du module medical

Exemple de module patient

Nouveau dossier patient :

Quand le patient arrive à l’hôpital, un nouveau dossier médical va être créé afin de contenir tous les informations administratives, médicales, antécédents et l’historique médical

Définir un nouveau rendez-vous

L’infirmière est chargée de la préparation et la coordination des rendez-vous pour les consultations entre les patients et les médecins, pour réaliser cette procédure, elle va remplir les champs suivants :

Le patient et le médecin consultant

Préciser la date et l’heure de consultation

Le niveau d’urgence et l’état de patient

Page 75: Medical openerp

Rapport de stage PFE

75

Spécialité de secteur médical

Le produit de consultation

Si le patient n’est pas exonéré de facture, l’infirmière va la créer.

En cliquant sur calendrier on peut consulter le calendrier des rendez-vous pour chaque médecin selon le mois, le jour ou la semaine :

Gestion des consultations

Après la fixation du rendez-vous, le patient arrive à l’hôpital pour effectuer la consultation médical,

L’interface suivant représente la fiche de consultation concernant un patient, l’infirmière va saisir les informations suivantes :

Page 76: Medical openerp

Rapport de stage PFE

76

Patient qui va effectuer la consultation

Date début et date fin de consultation

Symptôme principale

Docteur consultant

Test de laboratoire

Après la consultation, le médecin peut demander au patient d’effectuer un test de laboratoire, pour cela le personnel médical au sein du laboratoire va créer un nouveau demande de test qui se compose de :

Type de test

Date du test

Patient qui va effectuer le test

Docteur qui a prescrit le test

Par défaut, l’état du test est marqué Brouillon, après la création de l’analyse, elle est mentionné A été testé

Page 77: Medical openerp

Rapport de stage PFE

77

Le personnel médical peut consulter la liste des demandes de test de laboratoires

Après la création de l’analyse, une fiche du résultat va être générée qui contient les informations sur le patient, médecin, le pathologiste, le type de test et la date de l’analyse, puis le médecin va saisir les résultats trouvés.

Page 78: Medical openerp

Rapport de stage PFE

78

Détection des maladies

Après le diagnostic et les tests de laboratoire, le médecin peut détecter la maladie de patient, puis il remplit la fiche suivantes :

Page 79: Medical openerp

Rapport de stage PFE

79

Prescription des médicaments

Pour définir une nouvelle prescription, le personnel médical choisit le patient concerné puis il saisit la date de prescription, le médecin qui a prescrit l’ordonnance, ensuite il va définir la ligne de prescription, cette dernière présente toutes les informations et les spécificités sur le médicament et son mode d’emploie.

Ligne de prescription contient l’historique des ordonnances, le médecin peut ajouter une nouvelle ordonnance.

Page 80: Medical openerp

Rapport de stage PFE

80

Gestion de la chirurgie

Pour planifier une chirurgie, il faut utiliser le menu : médical/chirurgie/chirurgie

Pour une nouvelle on clique sur nouveau, pour consulter la liste des chirurgies on clique sur liste, pour afficher sous forme calendrier on clique sur calendrier

Consultation de la liste des actes médicaux

Page 81: Medical openerp

Rapport de stage PFE

81

Gestion des médicaments

Page 82: Medical openerp

Rapport de stage PFE

82

Conclusion

Les systèmes d'information hospitaliers (SIH) jouent un rôle non négligeable dans l'atteinte des

objectifs des établissements hospitaliers (hôpitaux, cliniques, etc.) qui en possèdent.

Le thème traité a été très enrichissant pour moi. En effet, il m’ a permis de découvrir un domaine qui

m’ était, jusque là, peu connu, à savoir celui de la santé. Désormais, sur le plan de la santé, je serai

compté parmi les moins ignorants.

Je juge très utile cette expérience de 4 mois que j’ai passé dans ce stage de fin d'études. En effet, le fait de plonger dans les méandres d'open ERP est lui-même une motivante aventure où j’ai été amené à intercepter tous les côtés d'un projet, parmi lesquels je cite :

Sur le plan professionnel, ce stage m’a permis d'avoir une idée des réalités d'un monde autre

que celui académique: organisation du travail, relations humaines, etc.

Sur le plan technique (informatique), ce stage a été une opportunité pour mois de mettre en

pratique les connaissances théoriques acquises au cours de ma formation. En plus, j’ai

engrangé de nouvelles connaissances: apprentissage des langages de programmation (python),

découvertes de nouvelles techniques et surtout un nouveau logiciel open source (OpenERP)

qui représente un idéal de logiciel agile, apte à répondre à n'importe quel besoin. OpenERP

combine à la fois la force d'un éditeur et une réelle communauté qui balise la plupart des cas

d'usages et fournit de précieux retours, notamment sous forme de modules réutilisables.

Ce stage a été pour moi un grand pas vers le milieu professionnel, où j’ai bénéficié d'une

excellente expérience qui m’a permis de concrétiser mes connaissances informatiques voire

économiques acquises au cours des années d'études lors de la période de ma formation à

FSTG de Marrakech.

Ce projet m’a permis également d'acquérir des valeurs indispensables pour le métier

d'ingénieur telles que la responsabilité et le respect des engagements, le travail d'équipe, l'adaptabilité

à l'environnement de l'entreprise et le sens d'analyse. Ces valeurs sont sans aucun doute les bases de

réussite dans le milieu professionnel.

Je précise que la solution est conçue de manière à garantir son extensibilité et évolutivité

selon les besoins spécifiques des clients de SYSTEMUM. Ainsi, On peut facilement y ajouter de

nouvelle fonctionnalité sans toucher à la structure générale du module.

Page 83: Medical openerp

Rapport de stage PFE

83

Références

« open ERP book» Auteur : Fabien Pinckaers

« Apprendre à programmer avec Python» Auteur : Gérard SWINNEN

www.systemum.com

www.doc.openerp.com

www.mediboard.com

www.python.org

www.fsf.org/about/what-is-free-software

www.openobject.com

http://www.openerp.com/community communauté OpenERP

http://www.assurancemaladie.ma/

Www.openerp.com : site officiel de la solution ERP.

Système de gestion informatisé d’une clinique médicale externe (SGICM), Document d’analyse Auteurs : Michèle Garceau, Isabelle Landry et Hafedh Mili

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

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

Conception et réalisation d’un système d’information de gestion budgétaire OUHARZOUNE MOUNIA, SENOUCI Amel ,2009/2010

Conception et réalisation d’un système d’information de gestion du dossier médical pour la médecine du travail. OTMANE LAID, SMAIAH LOTFI, Mémoire présenté en vue de l’obtention du diplôme d’ingénieur d’état en informatique, Septembre 2008(système d’information)

Page 84: Medical openerp

Rapport de stage PFE

84

ANNEXE A : L’Open Source

A.1 Définition

Un logiciel open source est un logiciel qui est fourni avec l'autorisation pour quelconque de l'utiliser, de le copier, et de le distribuer, soit sous une forme conforme à l'original, soit avec des modifications, ou encore gratuitement ou contre un certain montant. Ceci signifie en particulier que son code source doit être disponible.

A.2 Principes

La Free Software Foundation maintient une définition du logiciel libre basée sur quatre libertés :

Liberté 1 : La liberté d'exécuter le programme, pour tous les usages

Liberté 2 : La liberté d'étudier le fonctionnement du programme. Ceci suppose l'accès au code source.

Liberté 3 : La liberté de redistribuer des copies. Ceci comprend la liberté de vendre des copies.

Liberté 4 : La liberté d'améliorer le programme et de publier ses améliorations. De part ces libertés, les utilisateurs, les développeurs et les entreprises jouissent des mêmes droits que le propriétaire du programme, excepté son droit de propriété.

A.3 Licences Open Source

À l'exception des logiciels dans le domaine public, les logiciels libres sont protégés comme tout logiciel par le droit d'auteur. La particularité des logiciels libres est que l'auteur renonce à l'exclusivité de la plupart des droits que lui donne le droit d'auteur. Il distribue le logiciel accompagné d'une licence libre qui énumère les droits donnés à l'utilisateur.

Certaines licences, dont la plus connue et utilisée pour les logiciels libres, la licence publique générale GNU, sont relativement complexes. Ainsi la GPL ne donne le droit de redistribuer un logiciel que si l'ensemble du logiciel, y compris toutes les éventuelles modifications, sont redistribuées selon les termes exacts de la GPL. Cette licence est dite virale ou contaminante, car si elle autorise la fusion d'un logiciel sous GPL avec un logiciel sous une autre licence, elle n'autorise en revanche la redistribution de la fusion que sous GPL.

Les licences des logiciels libres sont souvent divisées en deux, selon le degré de liberté accordé par la licence en matière de redistribution.

A.3.1 Licence BSD

Il s'agit des licences qui offrent la plus grande liberté. En général, seule la citation des auteurs originaux est demandée. En particulier, ces licences permettent de redistribuer un logiciel libre sous une forme non libre. Ces licences permettent donc à tout acteur de changer la licence sous laquelle le logiciel est distribué. Un cas de changement de licence courant est l'intégration de logiciel sous

Page 85: Medical openerp

Rapport de stage PFE

85

licence BSD dans un logiciel sous copyleft (licence GPL). Un autre cas courant est l'intégration de logiciel sous licence BSD dans les logiciels propriétaires.

A.3.2 Licence GPL

Il s'agit des licences qui obligent la redistribution sous une licence libre. Les licences du projet GNU sont les plus célèbres. Une telle licence permet d'intégrer du logiciel sous licence BSD et de le redistribuer sous licence GPL, alors que l'inverse est impossible.

Le degré de liberté moindre des licences de type copyleft a été critiqué par des acteurs des projets BSD et des acteurs commerciaux; Ce qui a poussé la Free Software Fondation à proposer la LGPL. La différence entre GPL et LGPL réside principalement dans le fait que la LGPL permet de lier un programme tiers non GPL à une bibliothèque LGPL, sans pour autant révoquer la licence.

Ainsi, il devient possible à un programmeur désireux de faire un logiciel propriétaire d'utiliser certains outils du libre (ex: la bibliothèque graphique GTK).

A.4 Le modèle économique

Le modèle économique des SSLL (sociétés de services en logiciels libres) est lié principalement à la notion de service : vendre un savoir-faire et une expertise plutôt qu'un droit d'usage sur un logiciel.

Ce modèle consiste à facturer au client non pas le logiciel lui même, qui reste open source, mais le service de support, d'installation, de personnalisation, de configuration et de maintenance que l'on vend autour sous forme d'abonnement.

Un autre système payant, utilisé par d'illustres éditeurs de logiciels libres comme MySQL, consiste en une licence commerciale qu'achètent certains clients afin d'intégrer le produit libre dans leurs propres produits dans le but de les redistribuer de manière payante, avec un code source fermé.

Une troisième forme de financement pour les éditeurs de logiciels libres est l'organisation de séminaires pour la présentation des solutions open source au grand public, notamment aux commerciaux.

Le modèle économique des logiciels open source a suscité toutefois certaines critiques : incompatibilité entre les besoins des clients et les demandes de la communauté. Les revenues sont générés par le service, et non pas par le logiciel lui même.

Difficulté du maintien sur le long terme d'une ressource humaine compétente et capable de tenir des délais compatibles avec la notion de service.

A.5 Avantages et limitations de l’open source

A.5.1 Avantages

Des logiciels de qualité Un programmeur qui expose son code au monde et aux autres participants du projet fera en sorte que le code soit de qualité. Si ce n'est pas le cas, un autre programmeur du projet proposera à la place un code plus efficace ou plus propre. De plus, un grand nombre de personnes participent en permanence aux tests des logiciels libres, ce qui permet d'identifier les bugs très tôt.

Page 86: Medical openerp

Rapport de stage PFE

86

Un coût raisonnable pour les utilisateurs Les logiciels Open Source sont soit gratuits soit proposés à un coût raisonnable, dans tous les cas inférieur à celui des logiciels commerciaux équivalents

Si des bugs sont identifiés, la prise en compte de la correction de ces erreurs est assurée gratuitement par les participants du projet.

Une forte réactivité En général les utilisateurs ayant un besoin précis d'amélioration du logiciel reçoivent un écho favorable et rapide de la part de la communauté des développeurs du projet. Un utilisateur peut lui même coder une fonctionnalité dont il a besoin, en accord avec le coordonnateur du projet.

Des logiciels à long terme Les projets aboutis de logiciels libres ont une très longue durée de vie, car il y a toujours des volontaires pour poursuivre le projet.

A.5.2 Limitations

Les obstacles financiers Les façons de génération de profits restent assez restreintes en quantité et en qualité.

Orientation vers les aspects techniques La plupart des projets Open Source réussis concernent des "logiciels techniques", c'est-à-dire des logiciels non pas applicatifs mais remplissant une fonctionnalité technique utilisée par d'autres logiciels.

Le support et la formation des utilisateurs Beaucoup d'utilisateurs de logiciels ont besoin non seulement d'un support technique pointu pour corriger les bugs éventuels, mais surtout d'un support de base pour être aidé dans l'utilisation du logiciel, voire de formations.

Le marketing et l'inertie de marché Les premiers projets Open Source ne disposaient pas de budgets marketing. Cependant, on voit apparaître de plus en plus de projets Open Source appuyés ou financés par des éditeurs de logiciels ou des intégrateurs.

Page 87: Medical openerp

Rapport de stage PFE

87

ANNEXE B : Exemples de rapports générés par OpenERP

Page 88: Medical openerp

Rapport de stage PFE

88

Page 89: Medical openerp

Rapport de stage PFE

89

Page 90: Medical openerp

Rapport de stage PFE

90

ANNEXE C : Exemples d’arabisation d’interface