Vous êtes sur la page 1sur 73
U niversité de T unis I nstitut S upérieur de G estion D épartement I

Université de Tunis Institut Supérieur de Gestion Département Informatique

Mémoire de fin d’études

Pour l’obtention du diplôme de

Licence Fondamentale En Informatique de Gestion

« Aide à la Décision Médicale pour la Prise en Charge des Patients ayant La Paralysie Faciale »

Réalisé par :

SAKOUHI Thouraya

Encadré par :

Dr. AKAICHI Jalel

Année Universitaire 2010/2011

Dédicaces

Je dédie ce modeste travail :

A

Mes chers parents

Pour leurs encouragements et leurs sacrifices tout au long de mes études. Que Dieux leurs réserve bonne santé et longue vie

A

Mes sœurs Hayet et Mouna

Avec tout mes souhaits de succès

A

Tous mes amis

Aucun chemin de fleurs ne conduit à la gloire.

Thouraya

Remerciements

Nos remerciements les plus chaleureux s’adressent à notre encadreur Docteur Jalel Akaichi pour sa disponibilité, son assistance, son aide et ses précieux conseils au cours de la réalisation de ce travail.

Nos vifs remerciements s’adressent, également, à tous Nos enseignants pours les efforts déployés au cours de notre formation.

Enfin, nous tenons à présenter notre gratitude aux Membres du jury qui ont pris la peine d’évaluer ce travail.

Sakouhi Thouraya

TABLES DE FIGURES

FIGURE 1 : CAS D’UTILISATIONS DE L’ACTEUR MEDECIN

14

FIGURE 2 : CAS D’UTILISATION DE L’ACTEUR INFIRMIER

16

FIGURE 3 : CAS D’UTILISATION DE L’ACTEUR TECHNICIEN LABO

17

FIGURE 4 : CAS D’UTILISATION DE L’ACTEUR EQUIPE DE RECHERCHE

18

FIGURE 5 : DIAGRAMME DE CLASSES GENERAL

22

FIGURE 6 : SCHEMA EN ETOILE DE L’ENTREPOT DE DONNEES

28

FIGURE 7 : SCHEMA EN FLOCON DE NEIGE DE L’ENTREPOT DE DONNEES

30

FIGURE 8 : SCHEMA EN CONSTELLATION DE L’ENTREPOT DE DONNEES 1

31

FIGURE 9 : SCHEMA EN CONSTELLATION DE L’ENTREPOT DE DONNEES 2

32

FIGURE 10 : SCHEMA DE L’ARCHITECTURE GENERALE DU DATA WAREHOUSE

36

FIGURE 11 : SCHEMA D’UNE TRANSFORMATION DANS L’INTERFACE SPOON

37

FIGURE 12 : «

EXTRACTION DEPUIS UN FICHIER » EMPLACEMENT DU FICHIER SOURCE

37

FIGURE 13 : «

EXTRACTION DEPUIS UN FICHIER » ADAPTER AU CONTENU DU FICHIER

38

FIGURE 14 : «

EXTRACTION DEPUIS UN FICHIER » RECUPERATION DES CHAMPS

38

FIGURE 15 : «

EXTRACTION DEPUIS UN FICHIER » PREVISUALISATION DE DONNEES

39

FIGURE 16 : INTERFACE POUR EDITER L’ETAPE « INSERTION DANS TABLE»

39

FIGURE 17 : « INSERTION DANS TABLE» CONFIGURATION DE LA CONNEXION

40

FIGURE 18 : « INSERTION DANS TABLE» RECUPERATION DES CHAMP

40

FIGURE 19 : « INSERTION DANS TABLE»: REQUETE SQL

41

FIGURE 20 : EXECUTION DE LA TRANSFORMATION

41

FIGURE 21: ETAPES POUR ALIMENTATION DE LA TABLE FAIT

42

FIGURE 22: EXTRACTION DEPUIS TABLE

43

FIGURE 23 : RECHERCHE DANS LA BASE DE DONNEES

43

FIGURE 24 : INSERTION/MAJ DANS TABLE

44

FIGURE

25 : PREVISUALISATION DE DONNE

44

FIGURE 26: CONFIGURATION DE LA CONNEXION A LA SOURCE DE DONNEES

45

FIGURE 27 : EXPLORATEUR DE BASE DE DONNEES

46

FIGURE 28 : STRUCTURE DU SCHEMA

47

FIGURE 29 : EDITEUR CODE XML

47

FIGURE 30 : EXECUTION DE LA REQUETE MDX

48

FIGURE 31 : CONNEXION A LA SOURCE DE DONNEES

49

FIGURE 32 : QUERY DESIGNER

50

FIGURE 33 : RAPPORT LISTE PATIENTS

51

FIGURE 34 : RAPPORT NOMBRE TESTS EFFECTUES PAR PATIENT

53

TABLE DE MATIERES

1. INTRODUCTION GENERALE

1

1.1.CONTEXTE

1

1.2.PROBLEMATIQUE

2

1.3.CONTRIBUTIONS

2

1.4.PLAN DU RAPPORT

3

2. ETAT DE L'ART

4

3. MODELISATION CONCEPTUELLE

12

3.1.SPECIFICATION DES BESOINS

 

12

3.2.PRESENTATION DU LANGAGE DE MODELISATION

13

3.3.DESCRIPTION DU LOGICIEL DE MODELISATION RATIONAL ROSE

14

3.4.CAS DUTILISATION PRINCIPAL DUN SYSTEME OPERATIONNEL ET DECISIONNEL MEDICAL

14

3.4.1.ACTEUR

MEDECIN

14

3.4.2.ACTEUR

INFIRMIER

16

3.4.3.ACTEUR

TECHNICIEN LABO

17

3.4.4.ACTEUR EQUIPE DE RECHERCHE

18

3.5.CONCEPTION DE LA BASE DE DONNEES SOURCE

20

3.6.CONCEPTION DE LENTREPOT DE DONNEES DU SYSTEME DECISIONNEL

23

3.6.1.PRESENTATION D’UN SYSTEME DECISIONNEL

23

3.6.2.GLOSSAIRE DE L’INFORMATIQUE DECISIONNELLE

24

3.6.3.SCHEMA

EN

ETOILE

28

3.6.4.SCHEMA EN FLOCON DE NEIGE

29

3.6.5.SCHEMA

EN

CONSTELLATION

31

4. IMPLEMENTATION ET EXPERIMENTATION

33

4.1.DESCRIPTION DE LENVIRONNEMENT DE DEVELOPPEMENT

33

4.1.1.MYSQL SERVER 5.1

33

4.1.2.PENTAHO

BI

33

4.1.3.PENTAHO

DATA INTEGRATION

34

4.1.4.PENTAHO

SCHEMA WORKBENCH

34

4.1.5.JASPERSOFT IREPORT

34

4.2.REALISATION

35

4.2.1.CONSTRUCTION DE L’ENTREPOT DE DONNEES

35

4.2.2.ANALYSE DE L’ENTREPOT DE DONNEES

45

4.2.3.REPORTING

49

5. CONCLUSION ET PERSPECTIVES

54

6. LES REFERENCES BIBLIOGRAPHIQUES

55

BIBLIOGRAPHIE

55

NETO-GRAPHIE

58

1.

INTRODUCTION GENERALE

1.1.

CONTEXTE

Le domaine médical de nos jours a beaucoup évolué aussi scientifiquement que technologiquement. Le dossier patient est informatisé et l'information est stockée sur plusieurs supports d‟où la complexité de la tache de récupération de ces données.

L'accès aux données à travers les applications n'était pas une tache aussi facile et rapide depuis longtemps. En 1970, les mainframes n'étaient pas facilement accessibles. Au début des années 80, il y avait les systèmes de gestion de base de données distribués, encore des difficultés en tirant les données du système. En 1990, il y avait l‟avènement des entrepôts de données d'entreprise (EDE) et des magasins de données qui sont optimisés pour l'analyse.

« Un entrepôt de données est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d‟un processus d‟aide à la décision » [1]. Chaque unité de données est pertinente à un certain moment dans le temps. Un entrepôt de données contient des données atomiques et légèrement résumées. Les Data Marts sont des sous ensembles de l‟entrepôt de données que sont organisés par sujet et optimisés pour appuyer les rapports et l'analyse.

En fait, les fournisseurs de soins de santé, les chercheurs cliniques et les administrateurs de l'hôpital ont besoin d'accéder à différents types de données cliniques et administratives. Ces derniers ont besoin de données de patients complètes, actuelles, mises à jour, précises et longitudinales dans des objectifs de prise de décision sanitaire efficace, la recherche et l'amélioration des processus tel que: la modélisation des processus de santé, modélisation des connaissances cliniques pour les systèmes d'aide à la décision, bioinformatique, la recherche pharmaceutique, etc.

Dans ce travail, nous nous intéressons à l‟intégration de données médicales et nous proposons une solution consistant en la création d‟une source de données intégrée pour faciliter l'analyse des données ou ce qu'on appelle entrepôt de données (ED).

Un ED médical peut contenir des donnés tel que : des données de patients et de visites, données opérationnelles, données cliniques, données financières, données de recherche, etc. L'utilisation des entrepôts de données comme solution pour l'aide à la décision datent du début des années 80, les termes ''dimensions'' et ''faits'' ont été créés par General Mills et l'Université Dartmouth pendant les années 1960.

1.2.

PROBLEMATIQUE

La Paralysie Faciale est une maladie affectant le nerf facial qui, malgré les techniques qui sont utilisés pour accélérer le recouvrement, un traitement efficace n‟est pas encore bien définit.

Afin d‟améliorer la connaissance médicale de cette maladie, médecins, chercheurs cliniques et administrateurs ont besoins de l'information dans des objectifs de prise de décision sanitaire.

Vu les différentes sources de données cliniques, une programmation extensive est exigée pour extraire et intégrer l'information à chaque fois que celle-ci est demandée. Ceci engendre un retard de livraison de l'information à ceux qui en ont besoin.

Les systèmes d'informations opérationnels sont non fiables. En effet, ils existent multiples sources de données mais qui sont parcellaires, catégorielles et non coordonnées.

L'information est hétérogène et localisée dans différents emplacements: structurée et non structurée, en différents formats et non conformes.

En revanche, les concepts de soins de santé manquent de structure formelle, aucune représentation standard qui peut être entrée dans les formules et les modèles n'existe, il y a un grand besoin de forme canonique et de vocabulaires normalisés, afin qu'on puisse identifier les concepts équivalents. L'information disponible dans les bases de production manque de qualité générale et sémantique.

Du coût, ces problèmes peuvent nuire à la qualité des données acquises ce qui obère la réalisation d'études et d'analyses médicales.

1.3.

CONTRIBUTIONS

Ce projet est réalisé dans le but de concevoir et créer un entrepôt de données d'aide à la décision médicale dans le domaine de la paralysie faciale pour aider l'utilisateur qui est un médecin, un chercheur ou un analyste à extraire les données utiles contenues dans le système et les exploiter efficacement pour comprendre et améliorer les pratiques des standards des soins de cette maladie.

1.4.

PLAN DU RAPPORT

Le plan du mémoire est organisé comme suit:

Le chapitre 2 est consacré à l'état de l'art en évoquant les différents travaux de recherche réalisés relatifs au domaine d'aide à la décision médicale.

Le troisième chapitre présente la modélisation conceptuelle de la base de données source et de l‟entrepôt de données.

Par la suite vient le quatrième chapitre contenant la présentation de l‟architecture logicielle utilisée, l'implémentation et la mise en œuvre de la solution.

Le cinquième et le dernier chapitre résume et conclut ce mémoire et présente les perspectives de recherche dans ce domaine.

2. ETAT DE L'ART

Un ED est une base du type OLAP (On Line Analatical Processing ou traitement analytique en ligne) alimentée en provenance de la base de production disponible dans le système d‟informations. En fait, les données entreposées sont intégrées dans des modèles multidimensionnels organisés selon le sujet analysé, appelé fait, et des axes d‟analyse, appelés dimensions.

Les entrepôts de données et les systèmes OLAP sont de plus en plus utilisés car ils proposent des architectures et des outils pour organiser, analyser et exploiter de grands volumes de données et améliorer ainsi la prise de décision. Dans ce travail nous nous intéressons plus particulièrement aux ED médicales. Plusieurs travaux ont été proposés pour résoudre le problème de l‟hétérogénéité des données dans le domaine médical à travers les entrepôts de données.

Certains travaux tels que l‟ED pour l‟aide à la décision sanitaire [2] prennent en compte la durée de vie potentielle d‟un entrepôt et l‟évolution des besoins durant la tache de la conception du schéma de l‟entrepôt. Cette phase prend en considération aussi la structure dimensionnelle appropriée pour créer un design hiérarchique.

SIMS-REIN est un programme d‟intérêt commun dédié aux malades, professionnels de santé, décideurs et institutions. Ce projet prend en charge la construction de toute une architecture du type n- tiers intégrant un ED centré patient pour une meilleure appréhension de la situation et satisfaire les besoins en IRT.

Les principaux objectifs du schéma de l‟ED es de permettre une étude épidémiologique particulière (filière de soin) et globale (régionale et nationale). Donc on a choisi la granularité la plus fine possible pour permettre une structure susceptible à évoluer plus facilement et permettant de s‟adapter le plus aux contraintes de l‟analyse qui exige des niveaux de granularité distincts.

Il y a 2 grandes catégories d‟utilisateurs du système : les chercheurs et les responsables de santé, et les médecins fournissant les données. Pour cela, lors de la conception de l‟ED des vues persistantes ont été prédéfinis pour répondre aux requêtes les plus attendues. Ces vues sont mises à jour lors de l‟alimentation.

Les données provenant de la base de production sont alimentées par saisie directe. L‟extraction est effectuée à l‟aide d‟outils JDBC, puis, enrichir sémantiquement les métadonnées extraites. Le processus d‟alimentation est déclenché à des intervalles de temps réguliers, fonctionnant par lots de

données. Chaque déclenchement les données consolidées depuis la dernière alimentation sont incorporés dans l‟ED.

Par la suite, on valide l‟alimentation si l‟intégralité du lot de données a pu être interprétée sans erreurs. L‟alimentation continue à se refaire jusqu‟à ce qu‟aucune erreur ne se produise.

Les données de l‟entrepôt sont présentées aux utilisateurs à partir du serveur épidémiologique. En plus de ça, des tableaux de bord et des représentations graphiques sont disponibles. Une exportation de données au format XML est possible.

Les auteurs dans [3] caractérisent l'ED comme une solution efficace aux problèmes cités auparavant pour répondre aux besoins du centre de soins de santé de contenir les coût et en même temps maintenir ou améliorer la qualité clinique des soins, et ceux suite à la création du modèle de soin géré intégrant un data warehouse pour fournir les ressources de données.

Suite à ce changement, différentes catégories d'analyses de soins de santé à l'aide de requêtes multidimensionnelles complexes au niveau financier, administratif et clinique sont supportées. Selon cet article, les prochaines ères d'analyses de soins de santé supporteront : une qualité d'évaluation des soins, des études d'utilisation, des analyses des résultats et des gestions des maladies.

CP-NEXUS DATABASE est un ED créé par CPMC utilise le meilleur des composantes du SI pour accomplir cette tache : un SAS SYSTEM composé de SAS/ACCESS, SAS/SHARE et SAS/CONNECT, en collaboration avec SYSBASE V11 SQL SERVER et une architecture client/serveur adéquate.

Le processus de construction de l'ED représente la 1 ère phase d'une solution data warehouse de soin de santé intégrée. La phase de suite implique une couche d'outils de requêtes pour transformer la grande quantité de lignes de données en information actionnable. Cette couche va contenir une collection d'applications ciblés sujets, requêtes guidées, création de rapports, requêtes de données activées Web et des outils d'analyse basées clients.

Cette architecture vise à :

- Améliorer les résultats patient et coûts

- Utiliser la connaissance du à la qualité d'analyse

- Utilisation efficace des ressources

CP-NEXUS est un outil stratégique supportant l'information basée gestion qui fournit de la valeur clinique aux patients et valeur financière aux acheteurs de soins de santé.

La solution data warehouse proposée par NLL [4] ATOS Origin a été entraîné par le manque d'adaptabilité des systèmes d'informations opérationnels aux contraintes confrontés. Cette solution a été réalisée pour diminuer l'effort manuel, améliorer la flexibilité et surveiller la performance.

Norbotten est une région du nord du suède et corps politique dont les principales affaires sont: santé, médecine et dentisterie. Pour cela cette dernière vise améliorer ces services dans ces domaines en fournissant des services conformes aux besoins des individus, personnel compétent et un choix correct des traitements. Dans le temps, il y avait 7 bases de données différentes, une par administration. L'information est capturée des interfaces vers le système.

Maintenant, l'information est chargée, intégrée et transformée puis stockée dans l'ED, structuré en schéma en étoile. L'information disponible dans l'ED aux utilisateurs: les mesures de soin de santé

(cas, occasions d'opérations, nombre total de lits, mesures) (soins de première ligne, soins spéciales…).

les classes de soins de santé (classer les

),

Précédemment pris en charge par les systèmes d'information opérationnels, la fonctionnalité Reporting est maintenant menée par le Data Warehouse. L'effort manuel a diminué comme c'est prévu concernant les rapports mensuels et trimestriels. En revanche, l'information est plus facilement accessible et l'utilisateur a une vue d'ensemble de la qualité et de la quantité de l'information disponible.

L'intégration de l'information médicale provenant de plusieurs sources est devenue une tache critique. Du coût, les groupes médicaux tentent de gagner de nouvelles idées des données du patient existantes. Et dans ce contexte, le travail de recherche [5] a été intéressé par la qualité de l'information existante.

Un autre défi se posant aux créateurs de systèmes conçus pour le partage de l'information patient, c'est la protection de l'intimité du patient lui-même. Comme solution proposé pour cette problématique de confidentialité des données patient, on propose de supprimer l'identificateur patient en chargeant les données dans l'ED, car celui-ci sera visible par toutes les parties en ont besoin.

Cette solution est bénéfiques pour des raisons multiples: permettre des requêtes ad hoc et des analyses complexes avec des térabits de données cliniques détaillées, supporte les analyses cliniques itératives et évolutivité de la solution.

Selon le cas étudié par les auteurs du [6], le but est de créer un ED servant de référentiel central de données cliniques, intégrant les îles isolés d'informations, fournir des rapports inter-fonctionnels et des outils d'analyse pour les unités fonctionnelles du système de santé, visant la compréhension et l'amélioration des pratiques des standards de soins.

Le Data Warehouse pour les fournisseurs de soin de santé réalisé par Plural Soft, s'est engagé à analyser les informations courantes et futures pour permettre la surveillance de la maladie et la qualité des rapports pour les autorités de régulation.

Les dossiers des patients sont demandés par les médecins, analystes statistiques et les groupes d'analyse de contrôle de qualité pour des fins d'études. La recherche d'un dossier médical prend 17minutes par thème, par contre, après l'implémentation du Data Warehouse, la recherche se fait en 2 minutes, d‟où réduction des coûts et du temps nécessaires pour l'accès aux données, ce qui fournit le temps nécessaire à la communauté analytique pour analyser le contenu des données des dossiers médicaux.

Le travail de recherche Entreprise Data Warehouse [7] présente une stratégie, architecture, design et l'implémentation d'un ED clinique de recherche. L'objectif est de créer une base et une infrastructure pour supporter la médecine personnalisée dans un réseau affilié de fournisseurs et de partenaires. Ce programme fournit des rapports intégrés et un Framework analytique pour permettre l'analyse d'une grande variété de données cliniques provenant de différentes sources de l'entreprise étendue.

En fait, cet Entreprise Data Warehouse soutient les objectifs primaires du Centre de Cancérologie pour le soin du patient et la recherche clinique. Les paramètres critiques et les observations sur les expériences de chaque patient et les différents aspects de la performance de l'entreprise sont capturés dans le cadre des opérations normales et continues. Les données critiques sont capturées, intégrés et présentés d'une façon consistante et cohérente pour aider les chercheurs, les analystes et les décideurs à mesurer et améliorer les résultats du patient en facilitant l'accès aux différents traitements, programmes de préventions, examens et études cliniques. De ce fait, le référentiel de données intégrées doit être présenté par une plateforme compréhensible et adaptative pour permettre l'avancement de la recherche et la thérapeutique.

Le programme implémenté doit être souple pour évoluer dans le temps comme le fait l'utilisateur. Le design et la construction du référentiel de données de base a été élaboré et mis en œuvre suivant une série de phases distinctes et successives.

Dans une 1 ère étape, fallait identifier données et les exigences techniques des divers groupes d'utilisateurs, formuler une vision globale de la solution pour supporter les objectifs de l'entreprise, par la suite, faire un plan d'implémentation multi phases.

Durant la 2 ème phase, les premières sources de données déjà identifiées, l'infrastructure de base pour extraction, transformation et chargement dans les différentes composantes du référentiel est conçue et implémentée. Les composantes de conception critique permettent une sémantique cohérente entre source de données et domaines introduits. L'architecture de base de rassemblement de données, les stocks opérationnels, ED de base et Data Marts ont été conçus, implémenté et remplis.

Dans une 3 ème phase, les nouvelles fonctions, les sources de données et les domaines sont incorporés dans le référentiel de base. Les utilisateurs accèdent aux données utilisant leurs outils et applications préférés.

Oracle Healthcare Provider Intelligence [8] est une solution Data Warehouse supportant les besoins des hôpitaux pour rassembler l'information de qualité des systèmes opérationnels vers un seul ED. Cette solution fournit une vue compréhensible de l'information clinique à tout les niveaux de direction, une réduction du temps d'implémentation et des coûts de développement.

Les fournisseurs de soins de santé exigent de grandes quantités d'informations pour leurs opérations financières et leur efficacité clinique. D‟où l'intérêt du Healthcare Provider Intelligence d'accélérer un projet informationnel dans le secteur de Healthcare.

Afin d'optimiser les ressources financières, humaines et matérielles, les responsables de soins de santé on besoin de prendre des décisions complexes. Pour cela il est nécessaire d'avoir une vision intégrée de l'information simple et rapide.

Cette solution définit une représentation multidimensionnelle de l'information, un accès basé Web à l'ED. Les utilisateurs peuvent créer, exécuter et manipuler les rapports facilement en respectant chacun son niveau de sécurité, en plus de leurs permettre d'obtenir des données agrégées et d'accéder aux informations de qualité du système opérationnel à un rythme plus rapide. Les données critiques sont chargées dans l'ED dans un temps quasi-réel.

Une 1ère version de HPI peut être implémentée rapidement avec un minimum de modification. Dans ce cas, le seul aspect à redévelopper est l'extraction du système source dans la zone de rassemblement, le processus de transformation entre la zone de rassemblement et le modèle de données multi dimensions est une complexité déjà traité.

Le travail de recherche [9] développe un Data Waehouse médical ou épidémiologique orienté patient. Comme les données clients sont propagées dans différentes structures de santé, cette solution a des exigences spéciales par rapport aux projets de data warehousing à l'intra structure de soins de santé.

La différence est que les structures de soin de santé impliquées dans un projet Data Warehouse orienté patient exigent certaines considérations sur la confidentialité des données du patient et des activités des structures de soins de santé.

Les structures de soins de santé veulent préserver la confidentialité des données de leurs patients pour des raisons économiques, comme la tenue des patients en tant que de leurs clients.

La construction d'un système de Data Warehousing à un niveau régional, par exemple en cancérologie, exige la participation de toutes les structures de santé concernées, ainsi que différents professionnels de santé.

L'hétérogénéité des sources de données médicales doit être prise en compte pour choisir entre plusieurs configurations organisationnelles du système d'entreposage de données.

En outre de l'entreposage de données, on a proposé le concept de l'Intranet virtuel, qui fournit une solution au problème de la sécurité de l'information médicale découlant de sources hétérogènes.

On a développé une architecture “Epidware” [10], basé sur le concept de Data Warehousing (Entreposage de données) pour supporter la collection et l'intégration des données des différents partenaires de soin de santé : les hôpitaux publics et privés, les laboratoires anatomopathologiques, et les bureaux de consultants privés. Ces partenaires ont souvent recours à différents systèmes de codification et de classification pour coder leurs données.

L'intégration des données dans l'entrepôt est une tache compliquée par le fait que le choix doit être fait entre l'utilisation d'un système de classification unique ou de conserver les données dans leur format d'origine. Dans le premier cas, la transcription des données est nécessaire que, dans ce dernier cas, les requêtes de données doivent prendre en compte chaque code existant dans l'entrepôt.

D'autre part, l'architecture organisationnelle d'aide à la décision dépend de l'accord des partenaires et des fonctions assignées au système. Il faut tenir compte des souhaits des partenaires dans la gestion et l'analyse de leurs données respectives. S'ils acceptent de regrouper leurs informations avec d'autres, il reste encore le choix entre un entrepôt de données global ou un par thème spécifique.

En outre, la confidentialité des activités des structures de soins de santé et des statuts personnel, social et médical du patient doit être assurée.

L'architecture générale du système intégré Epidware se compose de 3 niveaux. Le niveau inférieur est consacré aux sources d'information pouvant avoir différents formats: les systèmes de base de données, systèmes de fichiers, des documents HTML ou des bases de connaissancesLe niveau intermédiaire comprend un groupe de composants appelés "enveloppes" qui offrent trois fonctions principales: la traduction, le suivi et l'anonymat. Le niveau supérieur est constitué de l'intégrateur et de l'entrepôt de données dont la fonction principale est de charger les données dans le système d'entreposage de données. Il doit filtrer, affiner, intégrer et combiner les informations provenant des sources locales.

Pour modéliser la structure de données cible, les concepteurs doivent établir, avec l'aide de l'entreprise ou une institution, un dictionnaire de descriptions de données (méta données) et spécifier des outils pour extraire, traduire et intégrer les données provenant des différentes sources d'information (bases de données initiale).

Cela nécessite des techniques d'intégration de concilier les différences sémantiques entre le les structures de données et les bases de données sous-jacentes. Une fois le schéma cible est implémenté, l'entrepôt de données doit être mis à jour pour être sur que le format de données correspond aux besoins de l'utilisateur pouvant changer plus tard.

En outre, les changements dans les sources d'information doivent être propagés sur l'entrepôt de données.

Enfin, les données des bases de données source sont extraites, agrégées et filtrées pour harmoniser leurs formats et éliminer les redondances.

Avant de charger des données dans l'entrepôt de données, des valeurs cohérentes sont assignées à des variables ou des champs qui ne peuvent pas être initialisé à partir des systèmes locaux.

Périodiquement, extraire et de copier les données des sources d'information permet la mise à jour l'entrepôt de données. L'intégrateur peut alors combiner ces données avec celles provenant d'autres sources ou demander à toutes les sources d'information d'apporter des changements à l'entrepôt.

Dans cet article, on a proposé le concept du la technologie d'entreposage de données, y compris un Intranet virtuel pour assurer la confidentialité des données des patients à travers des structures de soins différentes à l'échelle régionale. L'application de cet Intranet virtuel, dans la région de Bourgogne, est en cours au niveau du réseau périnatal régional. Certaines structures de soins de santé, tels que le centre hospitalier universitaire de Dijon on déjà implémenté leur Intranet.

Cet article [11] vise à décrire les processus d'entreposage de données pour l'industrie pharmaceutique et les industries des soins de santé. Dans la société de l'information postindustrielle actuelle, les données sont une des ressources les plus précieuses. Toutefois, les données ne sont pas utiles à moins qu'il puisse être traité et transformé en information qui permet aux entreprises un avantage concurrentiel.

3. MODELISATION CONCEPTUELLE

Durant ce chapitre nous allons définir les besoins qui ont engendré la proposition de cette solution, suivie d‟une présentation de la conception en utilisant le langage de modélisation UML.

3.1. SPECIFICATION DES BESOINS

L‟application du Business Intelligence dans le domaine de la médecine est dans le but de supporter les besoins des hôpitaux pour rassembler l‟information de qualité des systèmes opérationnels vers un seul entrepôt de données et fournir une vue globale de l‟information clinique compréhensible par tous les niveaux de directions et des personnels.

En fait, les fournisseurs de soins de santé exigent de grandes quantités d‟informations pour leurs opérations financières et leur efficacité clinique. En outre, il y a un besoin de prendre des décisions complexes.

La paralysie faciale (PF) est un domaine médical ou les ED ont un rôle important à jouer. Il s'agit d'un déficit moteur complet ou partiel des muscles peauciers d'une moitié de la face, dont l'origine est une atteinte du nerf facial, par opposition aux paralysies d'origine centrale où la lésion responsable est au niveau cérébral (accident vasculaire cérébral, tumeur cérébrale, etc.)

La paralysie de Bell est un type spécifique de la PF, c‟est la paralysie des muscles facials causé par des perturbations qui affectent le nerf facial due à la lésion du neurone moteur, celle-ci est à l‟origine de souffrance physique et ayant un impact psychologique et émotionnel sur le patient.

Néanmoins, le traitement de cette maladie n‟est pas encore bien définit à mois des techniques kinésithérapeutes, tels que les exercices facials, biofeedback, laser, électrothérapie, massage, thermothérapie, qui sont utilisés pour accélérer le recouvrement.

Le principal inconvénient des techniques utilisées est l'absence d'une modélisation claire et concise des données manipulées, résultant de traitements effectués sur différents patients par une série de médecins dans différents institutions de soins de santé. Cela rend l'échange et l'exploitation à grande échelle de données difficile et complexe.

Diverses

compréhension de la maladie. Par exemple, dans le travail [12] l‟objectif de l‟auteur est de superviser

la

techniques ont

été proposées pour

aider les

médecins dans

le

traitement et

l‟évolution des états patients conduisant à la récupération par la modélisation de flux de données trajectoires du nerf facial qui est une étape essentielle menant à accomplir le but visé.

En outre, la visualisation des trajectoires des flux du nerf facial peut aider les médecins à comprendre en profondeur la maladie à travers des comparaisons effectuées sur les états du patient dans le temps, ou entre les états de différents patients.

Néanmoins, le problème de l‟hétérogénéité de la structure des données d‟une institution à l‟autre persiste encore, d‟où le besoin de collecter les informations relatifs dans une ressource de données intègre et concise pour unifier la présentation et faciliter l‟interrogation des données par les médecins, les chercheurs et les preneurs de décisions, et ce dans le but d‟assurer une surveillance de la récupération et la compréhension de la maladie PF. D‟où l‟objectif de la solution que nous proposons, la conception et l‟implémentation d‟un système d‟aide à la décision médicale pour la prise en charge de la PF, constitué de 3 parties : la modélisation des interactions du système avec les différents acteurs, la conception d‟un exemple de base de données source provenant du système opérationnel clinique, par la suite la modélisation du schéma de l‟entrepôt de données composant le système décisionnel.

3.2. PRESENTATION DU LANGAGE DE MODELISATION

UML (Unified Modeling Language) est un standard défini par l'OMG (Object Management Group) comme étant une notation ou un langage de modélisation graphique orienté objet permettant de modéliser un problème de façon standard. Ce langage est né de la fusion de plusieurs méthodes existant auparavant, et est devenu désormais la référence en termes de modélisation objet. Le modèle UML est composé de 13 types de diagrammes.

diagramme a des acteurs, des cas d'utilisation, et de la communication.

Diagrammes

de

cas

d'utilisation : donnent un

regard

extérieur d'un système. Chaque

Diagrammes de classe : est un schéma qui permet de présenter les classes et les interfaces des

systèmes ainsi que les différentes relations entre celles-ci, en fait, il permet de définir quelles seront les composantes du système final. Une classe est un ensemble de fonctions (Opérations) et de données (attributs).

3.3.

DESCRIPTION DU LOGICIEL DE MODELISATION RATIONAL ROSE

Rational Rose est un logiciel édité par l'entreprise Rational (rachetée par IBM) pour créer et éditer les

différents diagrammes d'un modèle UML (Unified Modeling Language) d'un logiciel. Il permet

également de sauvegarder et d'imprimer ces diagrammes, ainsi que de générer le code

source Java ou C++ qui leur correspondent.

3.4. CAS D’UTILISATION

PRINCIPAL D’UN SYSTEME OPERATIONNEL ET DECISIONNEL MEDICAL

Les diagrammes de cas d‟utilisation suivants vont présenter une visualisation des différentes

fonctionnalités pouvant être présentes dans un système logiciel médical par chaque acteur. Par la

suite nous allons analyser les cas d‟utilisations un par un.

3.4.1. ACTEUR MEDECIN

Les interactions de l‟acteur médecin avec le système sont présentées par le diagramme de cas d‟utilisations présenté ci-dessous :

Consulter traitements effectués sur les patients <<include>> <<include>> Consulter
Consulter traitements
effectués sur les patients
<<include>>
<<include>>
Consulter dossiers patients
<<include>>
Consulter informations
Consulter resultats tests et
<<include>>
examens
<<include>>
Authentification
Saisir diagnostique de la
Medecin
gravité de PF
<<include>>
Saisir prescription du
traitement

FIGURE 1 : CAS D’UTILISATIONS DE L’ACTEUR MEDECIN

Authentification : Un médecin ou n‟importe quel utilisateur metier tentant d‟acceder aux données

doit s‟authentifier avec un nom d‟utilisateur et un mot de passe avant de se connecter à la base de données.

Consulter information : Pour commencer l‟examination d‟un patient, l‟acteur médecin impliqué

dans le traitement du patient atteint de la PF consulte les informations disponibles dans la base de données du système d‟informations ou le système d‟annotations comme étant un pré condition de la prise en charge du cas du patient. La consultation des informations inclus 3 autres cas d‟utilisations suivant le type de l‟information consultée :

Consulter traitements effectués sur différents patients : accéder au système d‟annotations et

chercher des cas similaires à celui en cours de traitement, pour avoir une idée sur le type du traitement nécessaire au patient.

Consulter dossiers patients : accéder à la base de données du système pour avoir une idée sur les

informations concernant le patient âge, historique médical aidant le médecin à effectuer sa tache.

Consulter les résultats des tests et des examens: accéder à la BD et voir les résultats de différents tests et examens prescrits par le médecin lui-même ou par un autre médecin.

Saisir diagnostique de la gravité de PF: Le médecin diagnostique d‟après les informations du

patient et du système d‟annotations, les tests réalisés et l‟examination du patient puis précise la gravité de la PF, il saisit par la suite les résultats dans le système d‟informations dans l‟historique du patient et fait le transfert d‟une copie au système d‟annotations pour aider dans le futur à diagnostiquer la maladie dans les prochaines consultations d‟autres patients.

Saisir prescription du traitement : Après avoir diagnostiqué la PF, le médecin prescrit un traitement pour le patient, après avoir cherché dans l‟historique médical du patient en identifiant les faits qui pourraient interférer avec le traitement (diabète).

3.4.2.

ACTEUR INFIRMIER

Les interactions de l‟acteur infirmier avec le système sont présentées par le schéma de cas d‟utilisations présenté ci-dessous :

Test neurologique Test ORL Examen ophtalmologique Saisir prescription de tests Test électromyographique et examens
Test neurologique
Test ORL
Examen ophtalmologique
Saisir prescription de tests
Test électromyographique
et examens
<<include>>
Saisir nouveau dossier
<<include>>
patient
<<include>>
<<include>>
Authentification
Modifier dossier patient
Infirmier
Gérer dossiers patients
<<include>>
Supprimer dossier patient

FIGURE 2 : CAS D’UTILISATION DE L’ACTEUR INFIRMIER

Saisir prescription de tests et examens : l‟infirmier saisit les tests et les examens demandés par le

médecin pour un patient dans le système d‟informations, pour que les techniciens du laboratoire les

effectuent avec vérification de dates disponibles selon disponibilité de matériels et de personnels. Puis

imprime la fiche du rendez-vous et la donne au patient incluant toutes les informations nécessaires

(type tests, date, technicien labo, etc.).

Relation de généralisation-spécialisation entre ce dernier cas d‟utilisation et les cas d‟utilisations :

test ORL, test neurologique, test ophtalmologique et test électromyographique, que sont des types

spécifiques de tests héritant du cas d‟utilisation père.

Gérer les dossiers patients : gestion du dossier patient

modification des données ou la suppression d‟un dossier déjà existant.

par l‟ajout d‟un nouveau dossier, la

3.4.3. ACTEUR TECHNICIEN LABO

Les interactions de l‟acteur technicien labo avec le système sont présentées par le schéma de cas d‟utilisations présenté ci-dessous

<<include>> Verifier disponibilité Consulter materiels materiels <<include>> Test
<<include>>
Verifier disponibilité
Consulter materiels
materiels
<<include>>
Test électromyographique
Authentification
<<include>>
Examen ophtalmologique
Technicien
Saisir resultats tests ou/et
labo
examens
Test neurologique
Test ORL

FIGURE 3 : CAS D’UTILISATION DE L’ACTEUR TECHNICIEN LABO

d‟un

médecin pour effectuer des tests particuliers à un patient, le technicien du laboratoire doit vérifier la

Vérifier disponibilité matériels : suite à la demande d‟un infirmier faisant partie du

staff

disponibilité du matériel nécessaire à la réalisation de ces tests pour une date prédéfinie par l‟infirmier.

-

Consulter

matériels:

vérifier

la

disponibilité

du

matériel

inclut

les

cas

d‟utilisation

de

la

consultation de la BD plus précisément la table Matériels.

doit intégrer les données

concernant les résultats du test dans la bases pour que les acteurs qui en sont intéressés (infirmiers,

médecins, chercheurs, etc.) pourront les récupérer.

Saisir résultats tests et/ou examens: le technicien du laboratoire

-

neurologique, etc.)

<<Extend>> :

la

saisie

des

résultats

s’étend

aux

différents

types

d’examens/tests

(ORL,

3.4.4. ACTEUR EQUIPE DE RECHERCHE

Les interactions de l‟acteur équipe de recherche avec le système sont présentées par le schéma de cas d‟utilisations présenté ci-dessous

Lancer des requetes OLAP <<include>> <<include>> Authentification Reporting Equipe de
Lancer des requetes OLAP
<<include>>
<<include>>
Authentification
Reporting
Equipe de
<<include>>
recherche
Data mining
Medecin
Analyste
Preneur de
decision

FIGURE 4 : CAS D’UTILISATION DE L’ACTEUR EQUIPE DE RECHERCHE

L‟équipe de recherche est une généralisation de différentes parties intéressées de l‟information

récupérée du système décisionnel tel que les médecins, les analystes, les chercheurs et les preneurs de

décisions.

Le cas d‟utilisation recherche s‟étend à d‟autres cas d‟utilisations :

- Lancer des requêtes OLAP : L‟équipe de recherche a besoin de collecter des informations à partir de

plusieurs sources dans le but d‟exploiter leur synthèse mais le problème est que les données disponibles dans les BD sources sont autonomes et hétérogènes. La solution est donc d‟utiliser un schéma fédérateur, avec ou sans données, que les utilisateurs manipulent comme s‟il s‟agissait d‟une base de données habituelle avec données courantes provenant d‟une seule source (vues matérialisées) ou de plusieurs sources autonomes et éventuellement hétérogènes (base de données intégrée) ou plutôt entrepôt de données constituant la cellule de base d‟un système décisionnel. Par la suite, des requêtes OLAP (Online Analytic Processing) seront disponibles pour interroger les données et avoir une vue globale de l‟information existante dans la BD avec des agrégations selon plusieurs critères et sur plusieurs dimensions.

- Reporting: génération automatique de rapports utiles au travail de recherche en fournissant un environnement de conception visuelle pour créer des définitions du rapport. L‟outil de Reporting permet aux chercheurs de sélectionner des données relatives à telle période, tel patient, tel traitement d‟une maladie, etc., de trier, regrouper ou répartir ces données selon les critères de leur choix, de

réaliser divers calculs (totaux, moyennes, écarts, comparatif d'une période à l'autre,

les résultats d‟une manière synthétique ou détaillée, le plus souvent graphique selon leurs besoins ou

les attentes des dirigeants de l‟entreprise.

) et de présenter

- données) dans des buts d‟analyses et de prises de décision. Son utilisation permet par exemple d'établir des corrélations entre ces données et de définir des traitements-type de maladies et d‟extraire des connaissances originales auparavant inconnues. Il s'agit de "fouilles" visant à découvrir "de l'information cachée" que les données renferment et que l'on découvre à la recherche d'associations, de tendances, de relations ou de régularités.

Data mining: extraction de connaissances à partir de grandes masses de données (Fouille de

3.5.

CONCEPTION DE

LA BASE DE DONNEES SOURCE

Pour commencer, on va présenter une conception générale de l‟architecture de la base de données du système opérationnel pouvant être disponible dans une institution fournissant des services de soins de santé, spécialisée au traitement de la paralysie faciale, à l‟aide des diagrammes de classes (figure 5). Par la suite, nous allons mettre l‟accent sur la description des classes (nerf facial) que vont être modélisées dans l‟entrepôt de données.

La paralysie de Bell résulte d'une inflammation d'origine virale du nerf facial périphérique. Pour pouvoir traiter différents cas de patients attaqués de la PF, les médecins ont besoin d‟analyser des données diverses telles que celles relatives au nerf facial affecté. D‟où l‟intérêt de modéliser ce dernier de façon détaillée. Au fait, la modélisation du nerf facial nécessite auparavant la compréhension de l‟anatomie de ce dernier. Voici une explication brève du fonctionnement différents composants du nerf facial.

Un nerf facial peut être divisé en deux types de composants principaux :

- Les composants moteurs

- Les composants sensoriels

Les composants moteurs essentiels sont :

- Le moteur branchial : qui fournit les muscles d‟expression du visage

- Le moteur viscéral : qui véhicule les innervations parasympathiques à toutes les glandes de la tête.

Les composants sensoriels sont localisés dans l‟oreille, la membrane tympanique et les deux tiers antérieurs de la langue.

Le moteur branchial détaillé est composé de :

- La portion du nerf facial

- Les muscles du visage

Les muscles du visage sont divisés en 3 classes :

- Muscles postérieurs

- Muscles de la moitié supérieure

- Muscles de la moitié inférieure

Les points de terminaison des ramifications du nerf facial innervent les muscles du visage, pour chaque ramification il y a un point d‟intersection pour acquérir une nouvelle portion. Chaque portion est identifiée par un point de début et un point de fin.

Pour suivre les états des patients, l‟électromyographie est utilisée pour détecter l‟activité électrique du muscle pour l‟amplifier et la rendre audible et affichable sur un moniteur. On dit que le muscle répond normalement à l‟excitation provoquée par les électrodes, si le score qui est calculé en fonction de l‟amplitude et l‟intensité est supérieur à un seuil préalablement définit, sinon, on dit que le muscle ne répond pas normalement.

Le flux du nerf facial est considéré comme un objet en mouvement qui circule dans un réseau définit. Pour effectuer le test électrique, on doit mesurer l‟amplitude et la fréquence du flux du nerf facial appliquée à chaque portion du nerf, on doit mesurer aussi l‟intensité du flux du nerf passant par une portion spécifique. Si l‟intensité est > 0 donc le flux du nerf passe par une portion.

Ce test peut être effectué périodiquement pour évaluer l'évolution des états des patients à travers une comparaison méthodique effectuée sur les états du patient dans le temps, ou entre les états de différents patients pour peut aider les médecins à comprendre en profondeur la maladie.

FIGURE 5 : DIAGRAMME DE CLASSES GENERAL 22

FIGURE 5 : DIAGRAMME DE CLASSES GENERAL

22

3.6.

CONCEPTION DE L’ENTREPOT DE DONNEES DU SYSTEME DECISIONNEL

3.6.1. PRESENTATION D’UN SYSTEME DECISIONNEL

Un système décisionnel comme son nom l‟indique, aide le staff responsable de la prise de décision (analystes, chercheurs, médecins et dirigeants) à effectuer son travail.

La prise de décision est une tache relativement complexe, qui nécessite une recherche dans les données disponibles dans les BD du système opérationnel. En revanche, celui-ci stocke les données dans des structures hétérogènes, distribuées et volatiles (non historisées), ce qui fait que ces données ne sont pas ou peu adaptés à l‟analyse qui demande le lancement de requêtes lourdes pouvant bloquer le système transactionnel.

Contrairement, aux systèmes opérationnels ou de production les systèmes décisionnels ont besoins de données :

- Orienté métier : les informations sont organisées par fonction dans l'entreprise

- En lecture seule : on ne supprime JAMAIS des données puisque sa raison d'exister est de conserver tout changement.

- Organisé en axes : les données sont organisées en axes (dimensions) suivant lesquels nous allons analyser un phénomène (fait).

- Intégrées : pour former une vision unique de l‟information.

- Différents niveaux de granularité : capable de livrer des informations aussi détaillées que générales et ce de la façon la plus transparente possible.

Il peut paraître évident de dire que le monde décisionnel est le contraire du monde opérationnel. On préfère dire que l'un chapote l'autre. Tandis que les systèmes opérationnels font rouler l'entreprise, l'informatique décisionnelle voit rouler l'entreprise et agit en fonction de ce qu'elle voit. L'informatique décisionnelle est l'ensemble des méthodes, moyens et outils informatiques utilisés pour piloter le processus d‟aide à la décision.

3.6.2.

GLOSSAIRE DE L’INFORMATIQUE DECISIONNELLE

DSS

Decision Support System, système d'information décisionnel, SIAD Système d'Information d'Aide à la Décision ou EIS Executive Information System. C'est un système d'interrogation et de présentation des données adapté pour l'aide à la décision. Le terme français équivalent est informatique décisionnelle.

BUSINESS INTELLIGENCE

On parle aussi de systèmes d'aide à la décision et d‟informatique décisionnelle. Désigne les moyens, les outils et les méthodes qui permettent de collecter, consolider, modéliser et restituer les données, en vue d'offrir une aide à la décision et d‟avoir une vue d‟ensemble de l‟activité traitée, et ce, à travers les mois ou les années. Il permet de générer de la connaissance à partir des données, et donc, d'aider à faire des décisions stratégiques. L'intelligence d'affaires se base sur un concept clé qui est l'entrepôt de données ou le Data Warehouse.

ENTREPOT DE DONNEES

L'entrepôt de données est l'élément central de l'informatique décisionnelle. C'est une architecture de données (comme une base de données relationnelle classique) qui permet de représenter et de rendre disponible un gros volume de données historiées, nettoyées, valides, complètes et cohérentes, organisées, de façon à avoir une structure compréhensible et exploitable par des non informaticiens pour des fins de recherche et d‟analyse. Avant d'arriver dans la forme souhaitée dans l'entrepôt, les données des systèmes opérationnels doivent passer par une étape fondamentale „„intégration de données‟‟ ou „„Data Intégration‟‟.

DATA INTEGRATION

Processus consistant à combiner les données résidant dans différentes sources et en fournissant aux utilisateurs une vue unifiée de ces données. Sert à transposer le modèle entité-relation des bases de données de production ainsi que les autres modèles utilisés, en modèle à base de dimensions et de faits à l‟aide d‟outils ETL.

E .T.L

Extraction, Transformation, Loading, il s'agit d'une technologie informatique qui prend en charge l‟extraction de données à partir de différentes sources (BD, XML, CSV, etc.), de les transformer légèrement (format, dénomination), et de les charger dans une nouvelle base, qui sera ici le data warehouse.

OLAP

Online Analytical Processing ou traitement analytique en ligne, est un type d'application informatique orienté vers l'analyse sur-le-champ d'informations des bases de données multidimensionnelles (entrepôt de données), permettant de collecter, stocker, traiter et restituer ces données selon plusieurs axes, dans le but d'obtenir des rapports de synthèse.

HYPERCUBE OLAP

Ou cube OLAP, est une représentation abstraite d'informations multidimensionnelles caractérisée par la capacité à manipuler les données agrégées selon différentes dimensions. Chaque cellule est définie par un seul membre de chaque dimension. Cette structure est prévue à des fins d'analyses de données.

DIMENSION

Un ensemble de données du même type, permettant de structurer la base multidimensionnelle. Une dimension est l‟axe selon lequel on veut faire l'analyse.

FAIT

Le fait, en complément aux dimensions, c‟est sur quoi va porter l'analyse. Ce sont des tables qui contiennent des informations opérationnelles. Un fait est tout ce qu'on voudra analyser.

BD MULTIDIMENSIONNELLE

Structure de données ayant au moins trois dimensions indépendantes, les donnés sont agrégées suivant les dimensions.

DATA MART

Ou magasin de données est un sous-ensemble du data warehouse, il est généralement exploité pour restituer des informations ciblées sur un métier spécifique.

MESURE

Le plus souvent de type entier ou décimal, c‟est un élément de donnée sur lequel portent les analyses, en fonction des différentes dimensions.

CELLULE

Une donnée du cube définie par une position de chaque dimension.

HIERARCHIE

Une hiérarchie est un ensemble de membres organisés en une structure pour l'analyse pratique. Cette organisation de données est comparable à un arbre logique, ou chaque membre n'a pas plus d'un père mais un nombre quelconque d'enfants.

MEMBRE

Un membre est un point dans une dimension déterminée par un ensemble particulier de valeurs d'attribut.

NIVEAU HIERARCHIQUE

Au sein d'une hiérarchie, les positions sont en général organisées en niveaux. Un niveau est une collection de membres qui ont la même distance de la racine de la hiérarchie.

REPORTING

Un environnement de conception visuelle pour créer des définitions et générer automatiquement des rapports, on peut aussi présenter les résultats d‟une manière synthétique ou détaillée, le plus souvent graphique selon les besoins.

DATA MINING

Fouille de données extraction de connaissances à partir de grandes quantités de données par des méthodes automatiques. L'utilisation industrielle ou opérationnelle de ce savoir dans le monde professionnel permet de résoudre des problématiques très diverses.

3.6.3.

SCHEMA EN ETOILE

Un schéma de données en étoile est un arrangement de tables dans une base de données relationnelle. Au centre, on trouve la table de faits, dont les colonnes constituent les mesures permettant de réaliser les analyses, et les clés étrangères vers les tables de dimensions. Les branches de l'étoile qui rayonnent à partir de la table de fait correspondent aux dimensions. Une dimension englobe un ensemble de descripteurs. Le modèle conceptuel de données permet de retrouver cette forme en étoile.

Dans notre cas, le fait central est présenté par la table „„test électrique‟‟ et des dimensions „nerf facial‟, „flux nerf facial‟, „temps‟, „patient‟, „médecin‟ et „institution‟. Le but est d‟analyser les informations suivantes : amplitude, intensité, fréquence suivant les axes que sont les dimensions.

fréquence suivant les axes que sont les dimensions. FIGURE 6 : SCHEMA EN ETOILE DE L’ENTREPOT

FIGURE 6 : SCHEMA EN ETOILE DE L’ENTREPOT DE DONNEES

3.6.4.

SCHEMA EN FLOCON DE NEIGE

Ou snowflake schema, est une variante du schéma en étoile plus adapté pour des usages bien spécifiques. Dans la théorie, la différence réside dans la simple normalisation des tables de dimensions. Il est donc tout simplement question de mettre les attributs de chaque niveau hiérarchique dans une table de dimension à part.

Ci-dessous (figure 7), le même exemple précédent de la modélisation de notre entrepôt de données portant sur l‟analyse des données des patients atteints de la paralysie faciale, mais avec l‟ajout de niveaux hiérarchiques à quelques dimensions pour plus de souplesse aux utilisateurs lors de la génération de requêtes OLAP et approfondir par la suite l‟analyse.

Les hiérarchies créées sont pour :

La dimension temps:

Temps

créées sont pour : La dimension temps : Temps jour La dimension institution : semaine mois

jour

créées sont pour : La dimension temps : Temps jour La dimension institution : semaine mois

La dimension institution:

semaine

temps : Temps jour La dimension institution : semaine mois Institution ville région La dimension nerf

mois

temps : Temps jour La dimension institution : semaine mois Institution ville région La dimension nerf

Institution

jour La dimension institution : semaine mois Institution ville région La dimension nerf facial Nerf_facial

ville

La dimension institution : semaine mois Institution ville région La dimension nerf facial Nerf_facial

région

institution : semaine mois Institution ville région La dimension nerf facial Nerf_facial portion_nerf_facial

La dimension nerf facial

Nerf_facial

: semaine mois Institution ville région La dimension nerf facial Nerf_facial portion_nerf_facial pays semestre année 29

portion_nerf_facial

pays

semestre

: semaine mois Institution ville région La dimension nerf facial Nerf_facial portion_nerf_facial pays semestre année 29

année

FIGURE 7 : SCHEMA EN FLOCON D E NEIGE DE L’ ENTREPOT DE DONNEES 30

FIGURE 7 : SCHEMA EN FLOCON DE NEIGE DE L’ENTREPOT DE DONNEES

30

3.6.5.

SCHEMA EN CONSTELLATION

Dans un schéma en constellation, plusieurs modèles dimensionnels se partagent les mêmes dimensions, c'est-à-dire, les tables de faits ont des tables de dimensions en commun. Donc un modèle en constellation comprend ainsi plusieurs faits et des dimensions communes ou non à ces faits. Nous avons proposées deux exemples de modèles en constellation possibles pour notre cas d‟étude. Pour le premier (figure 8), les deux faits sont le „test_électrique‟ et le „test_cliniquequi ont 4 dimensions en commun : „patient‟, „médecin‟, „institution‟ et „temps‟.

„médecin‟, „institution‟ et „temps‟. FIGURE 8 : SCHEMA EN CONSTELLATION DE L’ENTREPOT DE DON

FIGURE 8 : SCHEMA EN CONSTELLATION DE L’ENTREPOT DE DONNEES 1

Pour le deuxième, les deux tables de faits sont „test_electrique‟ et „test_électromyographique‟ dont les dimensions en communs sont : temps, patient, médecin, institution, flux_nerf_facial, nerf_facial.

médecin, institution, flux_nerf_facial, nerf_facial. FIGURE 9 : SCHEMA EN CONSTELLATION DE L’ENTREPOT DE DON

FIGURE 9 : SCHEMA EN CONSTELLATION DE L’ENTREPOT DE DONNEES 2

Pour conclure, les différences entre ces trois modèles sont faibles et ne peuvent donner lieu à des comparaisons de performance. Ce sont des schémas issus de la modélisation dimensionnelle utilisés par les outils décisionnels.

4.

IMPLEMENTATION ET EXPERIMENTATION

Dans ce chapitre, nous commençons par décrire le choix de l‟environnement de développement de notre application. Ensuite, nous décrivons le système obtenu via des captures écran.

4.1.

DESCRIPTION DE L’ENVIRONNEMENT DE DEVELOPPEMENT

4.1.1.

MYSQL SERVER 5.1

IRONNEMENT DE DEVELOPPEMENT 4.1.1. MYSQL SERVER 5.1 MySQL 5.1 est la dernière version de la base

MySQL 5.1 est la dernière version de la base de données open source la plus populaire du monde. Le logiciel MySQL offre un très rapide, multithread, multiutilisateur et robuste serveur base de données SQL (Structured Query Language).

4.1.2. PENTAHO BI

données SQL (Structured Query Language). 4.1.2. PENTAHO BI Business Intelligence complète qui comprend les

Business Intelligence complète qui comprend les fonctionnalités Reporting,

analyse de données (OLAP), tableaux de bord, data mining et intégration de données (ETL). Peut être

utilisé comme une suite complète ou en tant que composants individuels qui sont accessibles via des services Web. Classé n° 1 en open source BI.

Une plate-forme de

4.1.3.

PENTAHO DATA INTEGRATION

4.1.3. PENTAHO DATA INTEGRATION Anciennement Kettle, est un ETL complet de la suite décisionnelle Open Source

Anciennement Kettle, est un ETL complet de la suite décisionnelle Open Source Pentaho, pouvant être utilisé indépendamment de cette dernière. Ce produit fournit une interface graphique pour la manipulation des données et cela contrairement à la plupart des autres produits non commerciaux. Il est le fruit du travail de Matt Casters, un consultant BI qui l'a développé à l'origine pour ses propres besoins au début des années 2000.

4.1.4. PENTAHO SCHEMA WORKBENCH

Le Mondrian

Schema Workbench

4.1.4. PENTAHO SCHEMA WORKBENCH Le Mondrian Schema Workbench est une interface de conception qui des schémas

est une interface de conception qui

des schémas cubes OLAP Mondrian visuellement.

permet de créer et

tester

4.1.5. JASPERSOFT

IREPORT

permet de créer et tester 4.1.5. JASPERSOFT IREPORT JasperReports est outil de Business Intelligence Open Source
permet de créer et tester 4.1.5. JASPERSOFT IREPORT JasperReports est outil de Business Intelligence Open Source

JasperReports est outil de Business Intelligence Open Source de génération de rapports développé en Java, pour des applications Java.

4.2.

REALISATION

Au cours de cette section, nous allons aborder la réalisation de la solution. On va traiter la mise en œuvre de la conception et de l‟étude architecturale précédemment établie, et ce en invoquant la description du travail accompli à travers des imprimes écrans du développement des fonctionnalités BI traités au cours de ce projet que sont la construction de l‟entrepôt de données, la génération des cubes OLAP et le Reporting.

4.2.1. CONSTRUCTION DE L’ENTREPOT DE DONNEES

Pour la construction de l‟entrepôt de données, nous allons alimenter les tables de dimension et de fait pouvant avoir différentes sources de données (ici on choisi l‟exemple fichier texte). Des outils logiciels sont alors nécessaires pour intégrer les données dans le data warehouse. En fait, On parle d'ELT (Extract, Transform, Load). Dans ce projet, nous avons choisi de travailler avec la suite open source de Pentaho Business Intelligence dont « Pentaho Data Integration » est l‟outil ETL. Les phases de l'alimentation d'un data warehouse sont les suivantes :

Extraction des données : Il s'agit de collecter les données utiles à l‟analyse des systèmes de production. Dans notre cas, on va extraire les données des fichiers textes contenants les données sources.

Transformation des données : Il faut rendre les données cohérentes avec la structure du data warehouse. On d'applique alors des filtres sur les données. Par exemple, il peut être nécessaire de convertir le format des données de string en dates (jj/mm/aaaa). Il faut également associer les champs source avec les champs cibles.

Chargement des données : C'est la dernière phase de l'alimentation d'un data warehouse. Il s'agit d'insérer les données au sein des tables du data warehouse.

FIGURE 10 : SCHEMA DE L’ ARCHITECTURE GENERALE DU DATA WAREHOUSE [13] L‟architecture de l‟ED

FIGURE 10 : SCHEMA DE L’ARCHITECTURE GENERALE DU DATA WAREHOUSE [13]

L‟architecture de l‟ED préalablement définie lors de la phase de la conception est constitué de tables de dimensions et une table de fait ou 2, selon le schéma de modélisation choisi pour implémenter le data warehouse. Dans cet exemple, on a choisi le schéma en étoile puis qu‟il est plus simple à implémenter et à gérer. Donc on a l‟architecture suivante du DW :

- 5 tables de dimensions : médecin, patient, institution, nerf facial et temps.

- 1 table de faits : test électrique.

La création d‟une table de dimension avec l‟outil PDI est beaucoup plus simple qu‟une table de fait. En fait, on doit juste extraire les données disponibles dans le fichier texte et les charger dans la table dimension. Grâce à l‟interface graphique de l‟outil SPOON de PDI, on peut créer des transformations, les exécuter et les sauvegarder. Les composants permettant la manipulation des données dans le schéma de la transformation sont nommés « étapes ». Entre deux étapes consécutives il faut avoir un lien pour indiquer vers quelle étape est dirigé le flux (matérialisé par le sens de la flèche). Dans notre cas, la création de la dimension, on a besoin de deux étapes :

- Extraction depuis fichier

- Insertion dans table

L‟écran suivant donne un aperçu de l‟interface de SPOON. Les différentes étapes sont visibles dans la l‟interface. Le schéma de la transformation est dans la partie droite de l‟interface.

transformation est dans la partie droite de l‟interface. FIGURE 11 : SCHEMA D’UNE TRANSFORMATION DANS L’I

FIGURE 11 : SCHEMA D’UNE TRANSFORMATION DANS L’INTERFACE SPOON

La première étape « Extraction depuis fichier » permet l‟extraction de données depuis un fichier texte, on doit éditer l‟information de l‟étape pour pouvoir extraire les données du fichier, par exemple l‟emplacement du fichier, le délimiteur entre les champs du contenu du fichier, le type et le format de données, etc. Par la suite, on doit importer les champs. Une fois importés, on peut prévisualiser les données existantes dans le fichier s‟il n‟y a aucun problème.

existantes dans le fichier s‟il n‟y a aucun problème. FIGURE 12 : L’ETAPE « EXTRACTION DEPUIS

FIGURE 12 : L’ETAPE «

EXTRACTION DEPUIS UN FICHIER » EMPLACEMENT DU FICHIER SOURCE

FIGURE 13 : « EXTRACTION DEPUIS UN FICHIER » ADAPTER AU CONTENU DU FICHIER FIGURE

FIGURE 13 : «

EXTRACTION DEPUIS UN FICHIER » ADAPTER AU CONTENU DU FICHIER

DEPUIS UN FICHIER » ADAPTER AU CONTENU DU FICHIER FIGURE 14 : « EXTRACTION DEPUIS UN

FIGURE 14 : «

EXTRACTION DEPUIS UN FICHIER » RECUPERATION DES CHAMPS

FIGURE 15 : « EXTRACTION DEPUIS UN FICHIER » PREVISUALISATION DE DONNEES La deuxième étape

FIGURE 15 : «

EXTRACTION DEPUIS UN FICHIER » PREVISUALISATION DE DONNEES

La deuxième étape « Insertion dans table » permet l‟insertion des données extraites dans une table de base de données. On doit préparer en avance une base de données dans laquelle la table va être créée. De nombreux types de SGBD sont supportés (une trentaine). Nous avons choisi de travailler avec « MySQL SERVER 5.1 » qui la dernière édition du produit MySQL comme étant outil connu et simple. Nous avons créé une nouvelle BD avec la possibilité de travailler avec la BD par défaut « Test ». Pour personnaliser cette étape, nous devons créer une nouvelle connexion avec la base de données MySQL en insérant les informations relatives.

de données MySQL en insérant les informations relatives. FIGURE 16 : INTERFACE POUR EDI TER L’ETAPE

FIGURE 16 : INTERFACE POUR EDITER L’ETAPE « INSERTION DANS TABLE»

FIGURE 17 : « INSERTION DANS TABLE» CONFIGURATION DE LA CONNEXION Par la suite on

FIGURE 17 : « INSERTION DANS TABLE» CONFIGURATION DE LA CONNEXION

Par la suite on doit récupérer les champs de l‟étape précédente.

on doit récupérer les champs de l‟étape précédente . FIGURE 18 : « INSERTION DANS TABLE»

FIGURE 18 : « INSERTION DANS TABLE» RECUPERATION DES CHAMP

Un script SQL est créé lors du clic sur bouton SQL.

Un script SQL est créé lors du clic sur bouton SQL. FIGURE 19 : « INSERTION

FIGURE 19 : « INSERTION DANS TABLE»: REQUETE SQL

On exécute le script SQL, puis la dernière phase, après avoir terminé la modification de la transformation votre transformation pour l‟intégration des données dans la table, est l‟exécution de la transformation.

dans la table, est l‟exécution de la transformation. FIGURE 20 : EXECUTION DE LA TRANSFORMATION On

FIGURE 20 : EXECUTION DE LA TRANSFORMATION

On a dans l‟interface ci-dessus, au bas de l‟imprime écran, les étapes et les résultats de leurs exécution : lignes lues du flux d‟entrée provenant du fichier source, lignes lues de l‟étape précédente et

écrites dans la table, etc. S‟il y‟aura une erreur dans l‟exécution, l‟étape contenant le bug apparaitra en rouge. Vous pouvez ainsi choisir de modifier l'étape source de l'erreur.

Ainsi, on a construit les tables de dimension que sont disponibles dans la base de données MySQL. Maintenant, on passe à la création de la table de fait qui est un peu plus compliqué.

Une table de fait doit contenir toutes les clés relatives aux tables de dimensions, ainsi on aura la forme en étoile qu‟a le schéma de conception de l‟entrepôt, en plus des mesures, les données susceptibles d‟être analysées en fonction de diverses valeurs de chaque dimension. Le processus de l‟alimentation de la table de fait est visible dans l‟écran suivant :

de la table de fait est visible dans l‟écran suivant : FIGURE 21: ETAPES POUR ALIMENTATION

FIGURE 21: ETAPES POUR ALIMENTATION DE LA TABLE FAIT

Le processus de création de la table de fait « test électrique » est constitué des étapes suivantes :

« Extraction depuis table » : on extrait les données de la « table test_electrique » déjà existante dans la BD source et qui ne contient pas les identificateurs des tables de dimensions. En fait, elle contient les identificateurs des tables sources dont on a extrait les tables dimensions. Les tables dimensions en fait contiennent ces clés aussi.

FIGURE 22: EXTRACTION DEPUIS TABLE « Recherche dans dimension » : ayant déjà les clés

FIGURE 22: EXTRACTION DEPUIS TABLE

« Recherche dans dimension » : ayant déjà les clés des tables sources de dimensions extraites de la table « test_electrique » on cherche dans chaque table dimension la clé correspondante à celle de la table « test_electrique », trouvée on retourne l‟identificateur de la table dimension du même champ.

l‟identificateur de la table dimension du même champ. FIGURE 23 : RECHERCHE DANS LA BASE DE

FIGURE 23 : RECHERCHE DANS LA BASE DE DONNEES

Après avoir recherché les id des différentes dimensions en question, on met à jour la table de fait et on insère les données provenant des différentes étapes, et ce en éliminant les champs inintéressants dans

la table de fait. Donc on doit avoir par la fin une table de fait contenant les id des dimensions et les champs mesures de la table « test_electrique ».

et les champs mesures de la table « test_electrique ». FIGURE 24 : INSERTION/MAJ DANS TABLE

FIGURE 24 : INSERTION/MAJ DANS TABLE

On peut par la suite explorer la base et voir la nouvelle table fait crée, on peut aussi visualiser les lignes et ce à l‟aide de l‟explorateur de BD.

on peut aussi visualiser les lignes et ce à l‟aide de l‟explorateur de BD. FIGURE 25

FIGURE

25 : PREVISUALISATION DE DONNE

4.2.2.

ANALYSE DE L’ENTREPOT DE DONNEES

L‟analyse de données aide à les exploiter avec le maximum d‟efficacité ce qui permet de gagner de nouvelles idées, mieux comprendre et optimiser l‟acte de prise de décision.

Dans ce travail, on a pris en charge l‟analyse de données de l‟entrepôt de données en utilisant comme outil le Pentaho Schema Workbench. PSW permet de créer des cubes OLAP Mondrian à partir d'un modèle en étoile de l'entrepôt de données.

Il offre les fonctionnalités suivantes:

- Editeur de schéma intégré avec la source de données pour la validation.

- Test des requêtes MDX par rapport au schéma et à la base de données.

- Parcourir la structure des bases de données.

Une fois qu‟on a le fichier XML du schéma, on peut le télécharger dans une application pour en utiliser les données. En premier lieu, on doit configurer les propriétés connexion à la source de données qui est dans notre cas la base de données MySQL.

données qui est dans notre cas la base de données MySQL. FIGURE 26: CONFIGURATION DE LA

FIGURE 26: CONFIGURATION DE LA CONNEXION A LA SOURCE DE DONNEES

Comme c‟est déjà dit, l‟outil PSW permet d‟explorer la base et de visualiser sa structure.

permet d‟explorer la base et de visualiser sa structure. FIGURE 27 : EXPLORATEUR DE BASE DE

FIGURE 27 : EXPLORATEUR DE BASE DE DONNEES

Par la suite, nous venons de créer un nouveau schéma, qui permet à son tour de créer et éditer des cubes et des sous-éléments des cubes, tel que les dimensions, les tables de faits, les hiérarchies, les niveaux, les mesures, etc. Ci-dessous, un écran de l‟architecture du schéma de notre entrepôt de données.

FIGURE 28 : STRUCTURE DU SCHEMA L‟outil permet aussi la visualisation du schema que vous

FIGURE 28 : STRUCTURE DU SCHEMA

L‟outil permet aussi la visualisation du schema que vous éditez sous forme de code XML.

permet aussi la visualisation du schema que vous éditez sous forme de code XML. FIGURE 29

FIGURE 29 :

EDITEUR CODE XML

L‟outil PSW permet l‟exécution de requêtes MDX pour tester le schéma prédéfinit. Les messages d'erreur ou les résultats sont affichés.

Pour notre exemple, nous lançons la requête MDX suivante pour récupérer les résultats visés. En fait on a besoin des résultats en amplitude et en fréquence du test électrique pour tous les patients, les femmes et les homes.

SELECT {[Measures]. [Amplitude], [Measures]. [Frequence]} ON COLUMNS,

{[Sexe].members} ON ROWS

FROM [cubepf]

L‟écran suivant montre le résultat :

ON ROWS FROM [cubepf] L‟écran suivant montre le résultat : FIGURE 30 : EXECUTION DE LA

FIGURE 30 : EXECUTION DE LA REQUETE MDX

4.2.3.

REPORTING

Après avoir créé notre schéma Workbench, on a besoin de produire des documents de types dynamiques pour visualiser nos données en différents formats, la fonctionnalité Reporting répond à notre besoin. JasperReports est un outil Business Intelligence de Reporting permettant l‟exportation de données de différentes sources : schémas, bases de données, fichiers Excel, fichiers textes, etc. Il permet aussi la visualisation de données dans des rapports et sous différentes formes (chartes, tableaux, etc.).

En premier lieu, on doit créer la connexion de l‟outil avec la source de données qui est soit un schéma Workbench, soit la base de données MySQL pour récupérer les données. L‟écran suivant montre l‟interface utilisé pour configurer la connexion :

suivant montre l‟interface utilisé pour configurer la connexion : FIGURE 31 : CONNEXION A LA SOURCE

FIGURE 31 : CONNEXION A LA SOURCE DE DONNEES

Pour effectuer les rapports dont on a besoin, on a lancé la requête suivante à l‟aide du Query Designer :

SELECT

Dim_patient.`code_patient` AS CODE,

Dim_patient.`nom_patient` AS NOM,

Dim_patient.`prenom_patient` AS PRENOM,

Dim_patient. Sexe` AS SEXE

FROM

`Dim_patient` dim_patient

Une requête peut être générée soit manuellement soit à l’aide du Query Designer.

Le Query Designer permet à l‟aide de visualiser les données disponibles dans la source de données et d‟en sélectionner les données dont on a besoin et la requête est générée automatiquement.

sélectionner les données dont on a besoin et la requête est générée automatiquement. FIGURE 32 :

FIGURE 32 : QUERY DESIGNER

Le résultat de cette requête est un rapport contenant la liste des patients avec les attributs : code, nom, prénom et sexe.

contenant la liste des patients avec les attributs : code, nom, prénom et sexe. FIGURE 33

FIGURE 33 : RAPPORT LISTE PATIENTS

On lance la requête suivante :

SELECT

Count (ft.id_patient) tests, dp.ID_patient patient

FROM

`Dim_patient` dp,

`Fait_te` ft

Where dp.ID_patient=ft.id_patient

GROUP BY

Patient

ORDER BY

Patient

Cette fois nous allons visualiser les résultats sous forme de liste de données et graphique :

les résultats sous forme de liste de données et graphique : FIGURE 34 : RAPPORT NOMBRE

FIGURE 34 : RAPPORT NOMBRE TESTS EFFECTUES PAR PATIENT

5. CONCLUSION ET PERSPECTIVES

La paralysie faciale est une maladie attaquant le nerf facial et étant à l‟origine d‟une souffrance physique et ayant un impact psychologique et émotionnel au patients.

Ce travail présente une conception et une implémentation d‟un système d‟aide à la décision médicale pour la prise en charge des patients ayant la paralysie faciale consistant en la création, l‟analyse et l‟exploitation des données d‟un entrepôt pour en tirer de la connaissance et améliorer le processus de prise de décision sanitaire efficace.

Les travaux futurs porteront sur un accès basé Web à l'ED qui permet à un utilisateur métier d'accéder à l'ensemble des ressources décisionnelles : rapports, analyses multidimensionnelles, tableaux de bords, créer, exécuter et publier les rapports facilement en respectant chacun son niveau de sécurité.

Les travaux futurs consisteront également en l‟assurance de la sécurité des données patients existantes dans l‟entrepôt de données et pouvant être consulté par différents structures de l‟institut de soins de santé, vu que ces données présentent une confidentialité du patient.

6.

LES REFERENCES BIBLIOGRAPHIQUES

BIBLIOGRAPHIE

[1]:

Titre:

Date de publication:

1994

[2] :

Titre: Un entrepôt de données pour l‟aide à la décision sanitaire en néphrologie -

Lien :

Auteur: Ana Simonet, Michel Simonet, Franck Gaspoz, Mohamed Ben Said, Didier Guillon, Christien Jacquelinet, Claude Mugnier, Jean-Philippe Jais, Paul Landais.

Date de publication:

8 /2003

[3]:

Titre: Titre: CP-Nexus: A Clinical Data Warehouse at Columbia-Presbyterian Medical Center Lien : http://www.cpmc.columbia.edu/ais/resources/ic/ Auteur: Philip Burrowes, Jason Oliveira,

Date de publication :

-

[4]:

Titre: Atos Origin‟s Data Warehouse solution Lien : www.atosorigin.com

Auteur: Atos Origin Date de publication :

06/2004

[5]:

Titre: Convergence CT Clinical Data Warehouse

Lien : www.convergencect.com

Auteur: Convergence CT

Date de publication : 2007

[6]:

Titre: Data Warehouse for a Healthcare Provider

Lien : www.pluralsoft.com

Auteur: Plural Soft

Date de publication :

-

[7]:

Titre: Enterprise Data Warehouse Lien : www.edgewater.com Auteur: Edgewater technology Date de publication : 2007

[8]:

Titre: Oracle Healthcare Provider Intelligence

Lien : oraclesales_us@oracle.com.

Auteur: Oracle Date de publication : Février 2004

[9]:

Titre: A Virtual Intranet and Data-warehousing for Healthcare Co-operation

Lien :

-

Auteur: El Mostafa Kerkri, Catherine Quantin, Thierry Grison, François André Allaert Anne Tchounikine and Kokou Yétongnon

Date de publication : 2001

[10]:

Titre: medical warehousing architecture and its application to epidemiological follow-up -

Lien :

Auteur: Kerkri E., Qantin C., Yétongnon K.

Date de publication:

23-23 mars 1999

[11]:

Titre: Data Warehousing in Pharmaceuticals and Healthcare: An Industry Perspective -

Lien :

Auteur: M. Kumar Sagar, Himanshu Raval -

Date de publication:

[12]:

Titre: Facial Nerve Stream Trajectory Data Modeling and Visualization

Lien:

-

Auteur: Dr. Jalel Akaichi

Date de publication : Avril 2011

[13]:

Titre: Architecture générale Lien : http://xpose.avenir.asso.fr/viewxpose.php?site=39&subpage=/archi.html#alim Auteur: J Detroyes, supinfo -

Date de publication :

RESUME

La Paralysie Faciale (PF) est une maladie affectant le nerf facial qui, malgré les techniques qui sont utilisés pour accélérer le recouvrement, un traitement efficace n‟est pas encore bien définit. Afin d‟améliorer la connaissance médicale de cette maladie, médecins, chercheurs cliniques et administrateurs ont besoins de l'information dans des objectifs de prise de décision sanitaire. Vu les différentes sources de données cliniques, une programmation extensive est exigée pour extraire et intégrer l'information à chaque fois que celle-ci est demandée. Ceci engendre un retard de livraison de l'information à ceux qui en ont besoin. Fournir des moyens pour accéder à la donnée précise et instantanée est un grand défi supportant la prise de décision efficace, la recherche et l'amélioration des processus. Notre solution proposée consiste à créer une source de données intégrée pour faciliter l'analyse des données relatives aux patients affectés de la PF.

ABSTRACT

Facial paralysis (FP) is a disease affecting the facial nerve which, despite techniques that are used to accelerate recovery, effective treatment is not yet well defined. To improve the medical knowledge of the disease, doctors, clinical researchers and administrators need the information in the objectives of health decision making. Given the different sources of clinical data, an extensive program is required to extract and integrate information whenever it is requested. This causes a delay in delivering information to those who need it. Provide means to access specific and instantaneous data is a big challenge that supports effective decision making, research and process improvement. Our proposed solution is to create an integrated data source to facilitate analysis on patients affected with FP data.