Modèle d'entrepôt de données pour l'exploitation et le partage de dossiers patient

Transcription

1 Modèle d'entrepôt de données pour l'exploitation et le partage de dossiers patient David Ouagne 1, 3, Christel Daniel - Le Bozec 1,2, Eric Zapletal 2, Jean- Christophe Cauvin 3 1 INSERM, U729 Paris,F France; Univ René Descartes, Paris, F France ; 2 AP-HP,Hôpital Georges Pompidou,Département d Informatique Hospitalière,Paris,F France 3 MEDASYS, Espace Technologique Saint-Aubain, Gif-Sur-Yvettes, France Abstract Objectives: Rationale and design of a data warehouse based on the Reference Information Model (RIM. The aim is to enhance patient data exploitation and to achieve syntactic and semantic interoperability between Electronic Healthcare Records in the framework of the French personal EHR project. Methods: We followed a 3 steps methodology a) identification et extraction of medical data required for analysis or continuity of care. Alignment of these data with the RIM ; b) design of the RIM based database model for clinical data warehousing, c) definition and automation of feeding procedures of the data ware house from heterogeneous data sources. We conducted a preliminary evaluation of the architecture of the data warehouse with regards to clinical data sharing or analysis. Results: We propose a RIM based model including 10 classes. Quality indicators of the EHR were produced relying on structured entries of the administrative data of clinical documents. Conclusions: The RIM based data ware house enhances both continuity of care and data analysis. Our perspectives are to extend the evaluation using clinical structured data in addition to administrative data. Keywords: Data warehouse, Syntactic and semantic interoperability, Personal Electronic Healthcare Record 1 Introduction Un Dossier Patient Informatisé (DPI) doit permettre le partage des données cliniques pour assurer une prise en charge médicale du patient de qualité et garantir la continuité des soins [1]. La nécessité du partage des données médicales devient stratégique en France avec la mise en oeuvre du Dossier Médical Personnel (DMP). Un DPI doit également fournir des aides à la pratique afin d éviter les erreurs médicales (alertes, guides de bonnes pratiques) et des solutions d'exploitation des données médicales (entrepôt de données cliniques pour le pilotage économique et médical)[2]. L'informatisation du dossier patient au sein des établissements de santé doit s'accompagner de la mise en place d'un entrepôt de données

2 alimenté par l'ensemble des applications hétérogènes du système d'information de santé [3,4]. Des efforts considérables ont été réalisés pour la définition et la diffusion de standards de structuration et de communication des éléments du dossier patient [5,6]. Cependant, actuellement, les bases de données des DPI reposent généralement sur des modèles d'informations propriétaires, ce qui pose des problèmes pour le partage et l'exploitation des données médicales stockées. L'Hôpital Européen Georges Pompidou (HEGP) est un hôpital de taille moyenne (827 lits) qui assure des soins d'hospitalisation aiguë dans trois pôles d'activité : urgences-réseaux, cancérologie et spécialités (médicales et chirurgicales), et cardio-vasculaire. L HEGP s est doté dès l ouverture en Août 2000 d'un dossier patient informatisé (DPI) multimédia unique [7]. Le DPI est géré par l application DxCare de la société Medasys [8]. Les informations produites par les professionnels de santé lors de la prise en charge des patients - observations, rendez-vous, résultats d examens complémentaires ou d actes thérapeutiques sont stockées au sein d une base de données reposant sur un modèle d information propriétaire. La société Medasys a de plus développé une solution de partage de documents médicaux entre établissements de santé et notamment dans le cadre de l expérimentation de mise en oeuvre du DMP. Cette solution doit être adaptée à chaque situation d'intégration du fait de l'absence de modèle d'information commun aux applications. Par ailleurs, la mise en œuvre d indicateurs de pilotage médical ou économique s avère être une tâche consommatrice de temps, basée sur une démarche souvent intuitive, là encore peu généralisable et produisant des résultats peu évolutifs. Notre hypothèse est que la conception d'un entrepôt de données basé sur un modèle d information standard de référence - le Modèle d'information de Référence d'hl7 (RIM) - doit contribuer à homogénéiser l'accès aux données et faciliter le développement à la fois de solutions de partage de données dans le cadre notamment de l'interface au DMP et également d outils de pilotage. L'objectif principal de ce travail est de mettre en place un entrepôt de données basé sur le RIM d HL7. Cet article présente les approches de standardisation de la représentation de l information médicale conduites par HL7 et le CEN TC251 ainsi que la solution de partage de documents cliniques proposée dans le cadre de l expérimentation DMP. Puis nous présentons la méthodologie suivie pour concevoir le modèle de données de l'entrepôt de données réalisé. Cette méthodologie comporte trois étapes: a) identification et extraction des données à exploiter (donnés à partager dans le cadre du DMP ou à analyser) et alignement de ces données avec le RIM, b) proposition d un modèle de données relationnel basé sur le RIM permettant d'archiver ces données cliniques, c) définition des procédures d alimentation de cette base de données à partir de sources hétérogènes et d historisation des données. Enfin, nous avons conduit une évaluation préliminaire des possibilités de partage et d analyse de données à partir de l entrepôt de données constitué. 2 Etat de l art 2.1 Modèles d information de référence pour le DPI Les organismes de standardisation (HL7, CEN TC 251) proposent des approches pour représenter, partager et exploiter l'information médicale des dossiers de santé. Ces approches reposent sur des modèles d'information génériques ou de référence (ISO/EN Part 1, openehr Reference Model, Reference Information Model (RIM)), sur des

3 modèles médicaux d éléments de dossiers (archétypes (ISO/EN13606 Part 2) et templates) et sur des systèmes terminologiques (ou "modèle conceptuel") (LOINC, SNOMED-CT, CIM10, CCAM, etc) Health Level 7 (HL7) D origine américaine, Health Level 7 (HL7) s impose comme la démarche de standardisation de référence en informatique médicale [6]. Largement implantés depuis 15 ans aux Etats-Unis, les messages HL7 sont de plus en plus utilisés dans plusieurs pays européens, en Australie et en Asie. En France, l association Hprim, qui regroupe plusieurs centaines d adhérents, est devenue HL7-France. HL7 a développé une centaine de messages «version 2» pour les principaux échanges au sein de l hôpital, avec un travail important autour des la gestion administrative du patient. Afin de mieux prendre en compte le contenu médical, HL7 a développé depuis près de 10 ans une «version 3» de ses messages, codés en XML et rendus cohérents entre eux par l utilisation du Modèle d Information de Référence (RIM) adopté par l ISO. Le RIM version 2.14 (juillet 2006) d HL7 est un modèle UML métier constitué de 37 classes dont les attributs correspondent à 27 types de données précisément définis. Les classes du RIM héritent de 6 classes principales (entité, acte, rôle, participation, relations entre actes et liens entre rôles). La première utilisation concrète de ce codage HL7 v3 a été développée au sein d un document clinique (Clinical Document Architecture (CDA)), dont l entête (méta-données) est structurée selon le RIM et le contenu est pour partie non structuré (texte en langue naturelle, lisible par l utilisateur) et pour partie éventuellement structuré (sections comportant des items (ou «entries») codés) CEN TC251 Dans la même période, le CEN a développé une pré-norme ENV13606 appelée depuis EHRCOM (Electronic Healthcare Record COMmunication), permettant l échange d informations structurées entre dossiers patient. Cette pré-norme décrit une structuration de l information médicale au sein de deux documents. La partie 1 décrit un modèle d information de référence générique pour le partage de tout ou partie(s) de DPI en définissant des extraits de dossiers, des répertoires, des compositions, des sections, des entrées, des agrégats («clusters»), des éléments et des valeurs. La partie 2 décrit un modèle d «archétypes». Ce modèle permet de décrire les archétypes en tant qu «objets métiers» cliniques permettant de standardiser et de structurer des agrégats d'items cliniques, d exprimer le contexte clinique relatif à ces données et de les mettre en relation avec les ressources terminologiques. Ce lien avec un vocabulaire de référence permet une relecture la plus fiable possible des données. C est à partir de ces «objets métiers» que sont développés notamment des formulaires structurés pour la saisie d information médicale au sein des DPI [9]. La pré-norme EHRCOM est en cours de refonte, en prenant en compte le RIM proposé par HL7. OpenEHR est une organisation a but non lucratif favorisant l interopérabilité des DPI en participant à l élaboration de standards européens (notamment EN 13606, part 2) et en développant des logiciels opensource. Le modèle d information d openehr est un modèle UML de 65 classes. Il est le résultat de 10 ans de conception dans le cadre de projets européens. Des implémentations de ce modèle ont été réalisées en Australie, au Royaume Uni et aux Pays Bas. Malgré ces efforts de standardisation, très peu de DPI opérationnels ont été développés selon les modèles d information proposés par les organismes de standardisation. Certains travaux soulignent l intérêt de constituer des DPI «virtuels» basés sur des standards pour des raisons d interopérabilité ou d exploitation des données [10].

4 2.2 Partage de documents cliniques dans le cadre de l expérimentation DMP IHE (Integrating The Healthcare Enterprise), créé en 1998, a pour objectif de favoriser la mise en place d échanges d informations médicales entre systèmes provenant d éditeurs différents en utilisant des standards opérationnels. Basé sur des groupes de travail réunissant des utilisateurs et des industriels, IHE va à partir des besoins applicatifs exprimés spécifier les processus d échange d informations (appelés «profils d intégration») et choisir les standards les plus appropriés pour réaliser ces fonctions. IHE s est développée en Amérique du Nord, en Europe et en Asie. Son cycle annuel de définition de nouveaux profils par des utilisateurs et des fournisseurs aboutissant à l organisation de plates-formes internationales de test d interopérabilité (appelées connectathons ) lui confère une efficacité unique, transformant des standards de base en solutions «plug and play». Dans le cadre du partage de documents, IHE a défini un nouveau profil (XDS) qui définit la manière d alimenter un «dossier médical» à partir de document et de les consulter. L expérimentation pour la mise en place du Dossier Médical Personnel (DMP), en France est basée sur la mise en œuvre de ce profil XDS qui propose une approche pragmatique intégrant à la fois la perspective du format de document CDA sur lequel il base la définition des ses méta données et ebxml en terme de communication et d architecture de service. Implémenté par 28 sociétés dès la première année de sa définition, dont des acteurs français de l hôpital, de la ville et de l hébergement, il devrait s imposer au niveau mondial pour les réseaux régionaux, nationaux ou spécialisés. 2.3 Entrepôt de données cliniques pour le pilotage et l aide à la décision Le principe d entrepôt de données cliniques consiste à extraire, intégrer et agréger les données de production de manière à réduire leurs volumes et à les organiser afin de faciliter leur analyse. Il s agit de constituer à partir de plusieurs bases de données hétérogènes une «collection de données orientées sujet (c'est-à-dire organisées par thèmes et non par domaines fonctionnels comme les bases de données de production), intégrées, contenant des informations non volatiles et historisées». Cette collection de données exclusivement destinées aux processus d aide à la décision doit permettre de retrouver et d analyser facilement et rapidement l information. Dans le domaine de la santé, il existe de nombreux travaux décrivant la mise en œuvre d entrepôt de données permettant le partage de données entre établissements de santé [3,4]. Peu de travaux présentent l avantage de structurer cet entrepôt de données en liaison avec un modèle d information de référence tel que le RIM. 3 Matériel et méthodes 3.1 Matériel Documents cliniques du DPI de l HEGP Le dossier patient informatisé (DPI) de l HEGP comporte des éléments de dossier, données ou documents, de nature variable tels que des notes cliniques, des prescriptions, des résultats d'actes ou d'examens diagnostiques, des comptes rendus d'hospitalisation etc. Le format de ces éléments de dossiers peut être du texte libre ou semi-structuré ou structuré. Les éléments de dossiers en texte libre sont saisis grâce à un éditeur Word intégré à DxCare. Les éléments de dossier semi-structurés sont saisis grâce à des questionnaires créés selon

5 des modèles médicaux d éléments de dossier (exemple : volet médical (antécédents, allergie), questionnaire observation médicale initiale, questionnaire de consultation d HTA, questionnaire de coronarographie,etc). Les réponses aux questions sont stockées dans une base de données relationnelle. Elles peuvent être binaires, de type liste (choix unique ou multiple de réponse(s) parmi une liste prédéfinie), numériques ou de type texte libre. Chaque question et chaque item de réponse des questions de type liste sont liés à un concept médical issu d'un système terminologique local. Les données issues des questionnaires sont stockées dans une base de données relationnelle. Les résultats des examens diagnostiques réalisés au niveau des plateaux techniques de biologie et d imagerie sont transmis par une interface et automatiquement intégrés à la base de données. Nous nous intéressons dans un premier temps aux documents cliniques produits soit grâce à l éditeur Word («Courriers») soit grâce à l éditeur de questionnaires («Questionnaires»). Six ans après l ouverture, sont produits à l HEGP par an en moyenne «courriers» et observations ou bilans médicaux saisis grâce à des questionnaires. Sont exclus de l analyse les données issues des interfaces avec les plateaux techniques (résultats biologiques et d imagerie), les prescriptions, les transmissions, etc. Dans le cadre de cette première évaluation de l entrepôt de données seules les informations de l entête des documents cliniques réalisés en 2005 à l HEGP ont été transférés dans l entrepôt de données Outil de partage de documents cliniques de l HEGP (Multi connecteur) L outil de partage d éléments de dossier développé par la société Medasys, appelé multi connecteur s appuie sur un module de gestion d événements de DxCare afin de déclencher des procédures d import ou d export de données. Le module de gestion d événement centralise les évènements métiers dans un ensemble de tables pour traitement ultérieur. Ces évènements sont générés chaque fois qu'une action est menée sur un élément de dossier tel qu un compte rendu ou un bilan médical par exemple (c'est-à-dire une entité ou un acte au sens HL7). Des exemples d'actions peuvent être la création (INSERT), la mise à jour (UPDATE) ou la suppression (DELETE) d'un objet. Chaque action est associée à un déclencheur (trigger) exécutant une procédure alimentant la table des «évènements» par l ensemble des identifiants des données spécifiques à l'élément de dossier sur lequel porte l'action. Ces identifiants sont stockées dans la table «événements» sous forme de fichiers XML contenant les données de l élément de dossier. Par exemple pour un compte rendu : date de création, type de document, rédacteur, etc En cas d export de données, l extraction des données pertinentes est réalisée par le multi connecteur qui parcourt la table des événements et exécute une action en conformité avec un abonnement. Un abonnement est une relation entre un type d'élément de dossier, un événement et un type d'intégration (codec). L'intégration est une étape de réorganisation des données issues du modèle propriétaire au sein d un autre modèle requis par l application cible. Le codec permet de spécifier le modèle cible ainsi que les procédures d alignement entre le modèle propriétaire DxCare et ce modèle cible. Lorsqu un nouvel événement est détecté alors le multi connecteur déclenche l'extraction en prenant comme paramètres le type d évènement ainsi que les identifiants des données spécifiques à l'élément de dossier (structures XML). Ces derniers permettent d exécuter les requêtes d extraction des données pertinentes au sein de la base de données propriétaire Outil d exploitation de données cliniques de l HEGP L HEGP met en place BusinessObjects XI qui est une plate-forme de «Business Intelligence» comportant des outils de requête ad hoc, d intégration de données, de gestion

6 de performance (tableaux de bord, systèmes de pilotage) et de diffusion large d indicateurs («reporting» de masse). Ces outils s appuient sur un dictionnaire de données commun. Le même vocabulaire est donc utilisé pour décrire à la fois les données et les indicateurs. Toute la richesse de cette plate-forme réside d'ailleurs dans la maîtrise de ces «métadonnées», une couche d'abstraction appelée «univers», qui simplifie l administration. Les utilisateurs alimentés en rapports de masse peuvent manipuler les indicateurs de performance et procéder à leur propre analyse ou encore déclencher, depuis des tableaux de bord, une analyse via des requêtes. 3.2 Méthodes Nous allons présenter une méthodologie permettant l'exploitation de données cliniques d un DPI en terme de partage et d analyse décisionnelle. Cette méthodologie comporte trois étapes. La première étape consiste à identifier et extraire les données à exploiter (données à partager dans le cadre du DMP ou à analyser) et à les aligner sur le modèle RIM. La 2 ème étape consiste à définir un modèle de données relationnel basé sur le RIM permettant d'archiver ces données cliniques et la 3 ème étape consiste à définir les couches d accès aux données et les procédures d alimentation de cette base de données à partir de sources hétérogènes. Nous avons également conduit une évaluation préliminaire des possibilités de partage et d analyse de données à partir de l entrepôt de données constitué Etape 1 : identification, extraction et alignement sur le RIM des données pertinentes L'étape d'extraction commence à partir de la réception d'un événement généré dans DxCare de type ajout, modification ou suppression d un type de document et finit par la constitution d'un fichier XML au format CDA d HL7 correspondant à ce document clinique. Pour réaliser cette étape nous nous appuyons sur la gestion des évènements de DxCare et sur le multi connecteur de Medasys. Pour l expérimentation DMP, nous avons développé un codec spécifique afin d aligner les données de DxCare aux templates CDA d HL7. Quelque soit le mode de saisie du document (document texte saisi grâce à l éditeur «Word», document structuré ou semi-structuré saisi grâce à un questionnaire, résultat structuré intégré via une interface (résultats de biologie ou d imagerie),etc), les données administratives et médicales du document sont alignées respectivement dans les parties «header» et «body» du CDA Etape 2 : définition du modèle de données de l entrepôt de données Nous proposons un modèle de données basé sur le RIM ayant la capacité de stocker les informations constitutives des documents au format HL7 CDA. Le modèle de données proposé est conforme au R-MIM CDA, qui est une spécialisation du RIM (dans le contexte du CDA) Etape 3 : alimentation de l entrepôt de données L alimentation de la base de données de l entrepôt à partir de fichiers CDA consiste tout d abord à effectuer une transformation XML-objet du fichier HL7 CDA. Puis il s agit de réaliser une transformation objet-relationel du modèle objet dérivé afin d intégrer les informations administratives et cliniques du document à la base de données relationnelle. La couche d accès aux données développée est basée sur une architecture comportant les composants Data Access Layer (DAL) et Business Logic Layer (BLL) Evaluation préliminaire de l architecture mise en oeuvre Cette étape a consisté à évaluer les possibilités de partage et d exploitation des données

7 cliniques à partir de l entrepôt de données. En ce qui concerne le partage de données, nous avons vérifié que l extraction de documents au format CDA était réalisable à partir de l entrepôt de données et qu il était possible notamment de gérer l historisation des documents. En ce qui concerne l analyse de données, nous nous sommes intéressé aux indicateurs de qualité du dossier patient de l HEGP (taux de dossier d hospitalisation comportant un compte rendu d hospitalisation envoyé dans les 8 jours, taux de consultations ayant donné lieu à un compte rendu, etc). Les informations administratives des documents cliniques élaborés grâce à l éditeur Word («Courrier») ou grâce à l éditeur de questionnaire («Questionnaires») et transformés au format CDA ont été importées dans la base de données conçue selon le RIM. Nous avons extrait ces indicateurs en utilisant l outil Business Object Live Office XI (Business Object ) et comparé la procédure d extraction à partir du dossier patient directement avec celle obtenue à partir de l entrepôt de données. 3 Résultats 3.3 Etape 1 : identification et alignement des données A titre d illustration, nous présentons certains résultats d alignement concernant les méta données des éléments de dossier (données administratives). Type de saisie Table Colonne Attribut RIM HL7 Data type tous pensoins.pck_synthese.f_get_oid id II tous pensoins.pck_synthese.f_gettypedocument code Code éditeur Word pensoins.cour_ide Libelle title ST questionnaire pensoins.re_bilan Libelle interface ND ND module presc. ND ND éditeur Word pensoins.cour_ide datecrea effectivetime TS questionnaire pensoins.bm_th_s datevaleur interface pensoins.re_bilan dem_date module presc. pensoins.presc Datedeb éditeur Word pensoins.cour_ide confident_dmp confidentialityc questionnaire pensoins.bm_th_s confidentiel ode interface pensoins.re_bilan confidentiel module presc. pensoins.presc ND Code Class Author Type de saisie Table Colonne Attribut RIM HL7 Data type éditeur Word pensoins.cour_ide datemodif time TS questionnaire pensoins.bm_th_s Dates module presc. pensoins.presc Datesais éditeur Word pensoins.cour_ide niredact

8 questionnaire pensoins.bm_th_s niuser id II module presc. pensoins.presc Saisipar éditeur Word questionnaire interface module presc. pensoins.ej_perso nom; prenom; titre Person.name SET<PN> Organization.id Organization.na me II SET<ON> Class PatientRole Type de saisie Table Colonne Attribut RIM HL7 Data type éditeur Word pensoins.cour_ide Nipatient Id II questionnaire pensoins.bm_th_s Nipatient interface pensoins.re_bilan Nipatient éditeur Word questionnaire interface module presc. éditeur Word questionnaire interface module presc. pensoins.patient nom; prenom Person.name SET<PN> pensoins.patient Sexe Patient.administ rativegenderco de Code éditeur Word questionnaire interface module presc. pensoins.patient Datenais Patient.birthTim e Organization.id Organization.na me TS II SET<ON> 3.4 Etape 2 : Entrepôt de données Modèles de stockage de l entrepôt de données cliniques Le modèle de données proposé contient dix tables faisant référence directement ou indirectement à l'une des six classes de base du RIM. Pour matérialiser cette filiation le nom des tables modélisées est préfixé du nom de la classe RIM de référence.

9 Figure 1 : Modèle de données basé sur le RIM La table hl7_act_clinical_document contient les données du document clinique ainsi que les références vers les données d'autres éléments du document clinique comme l'auteur ou le patient. La table hl7_participation_record_target contient les données concernant la relation entre le rôle Patient et le document clinique. La table hl7_role_patient contient les données associées à la notion de rôle Patient et permet de lier finalement le patient au document clinique. La table hl7_entity_patient contient les données du patient comme le nom du patient ou bien son sexe. La table hl7_dt_ii contient l'ensemble des identifiants des objets contenus dans les documents cliniques stockés. Cette table ne fait pas directement référence à une des classes de base du HL7 RIM, mais aux types de données HL7 (également décrits dans le RIM). La table hl7_dt_code contient l'ensemble des nouveaux codes n'existant pas dans des vocabulaires standard. Cette table ne fait pas non plus directement référence à une des classes de base du HL7 RIM, mais aux tables de vocabulaire du RIM HL7. La table hl7_role : contient l'ensemble des données associées à l'ensemble des objets faisant référence à la classe Rôle. Cette table contient les données spécifiques associées aux différents métiers en santé (médecin, infirmière, secrétaire, etc). La table hl7_participation : contient l'ensemble des données associées à l'ensemble des objets faisant référence à la classe Participation et permet d'associer un rôle à un document clinique. La table hl7_entity_person contient les données concernant une personne jouant un rôle dans le SIH à l'exception du patient.

10 La table hl7_entity_organization contient les informations concernant une organisation : hôpital, service, etc. 3.5 Evaluation de l architecture Les informations de l entête des documents cliniques (comptes rendus d hospitalisation, comptes rendus de consultation, ordonnance, courriers, etc) réalisés en 2005 à l HEGP ont été transférées dans l entrepôt de données et les indicateurs de qualité ont été produits. Les requêtes nécessaires à l extraction sont plus complexes mais plus génériques et ne dépendent pas du mode de saisie du document. 4 Discussion conclusion 4.1 Mise en œuvre des objectifs Nous avons montré qu il est possible de concevoir un modèle de stockage des données cliniques conforme au Modèle d Information de Référence (RIM) d HL7. La première étape de la méthodologie présentée consiste en l'extraction et l alignement des informations administratives et médicales de documents cliniques. Les développements réalisés lors de cette étape ont été mis en œuvre et sont utilisés dans le cadre de l expérimentation Dossier médical personnel (DMP). Par ailleurs, en se limitant à la prise en compte des données de l entête des documents cliniques, nous avons montré qu il est possible d extraire des indicateurs de la qualité de la tenue du dossier patient. L intérêt principal de ce travail est de montrer que la conception d un entrepôt de données cliniques selon un modèle d information médical de référence permet de mettre en place une démarche de développement d outils de partage et d exploitation des données génériques. Au niveau du DPI, les informations constitutives des documents cliniques ne sont plus archivées uniquement selon un modèle de données propriétaire et souvent selon des modalités variant en fonction mode de création du document (via un éditeur de texte, via un questionnaire ou via une interface). Au niveau de l entrepôt de données, les méta données des documents sont stockées de manière homogène et les informations administratives structurées sont définies en référence un vocabulaire contrôlé partagé. 4.2 Limites Les limites du travail présenté sont liées au fait que l évaluation de l entrepot de données n a porté que sur une partie des documents cliniques de l HEGP («Courriers» et «Questionnaires») et de plus que les indicateurs extraits ne concernaient dans un premier temps que les données administratives des documents. La structure du modèle de données de l entrepôt permet d archiver les informations médicales structurées selon un vocabulaire contrôlé. Le vocabulaire contrôlé utilisé à l HEGP est un dictionnaire de concepts local. Si cela ne constitue pas un obstacle à l extraction d indicateurs médicaux qui resteraient d exploitation locale, cela constitue un obstacle majeur au partage de documents. L interopérabilité entre DPI nécessite soit de faire référence à un vocabulaire standard, soit de proposer une solution de partage d un vocabulaire non standard mais commun. 4.3 Perspectives Nos perspectives sont d étendre l évaluation de l architecture proposée en prenant en

11 compte l information médicale structurée des documents cliniques. Il s agit d évaluer l intérêt de l entrepôt de données pur l extraction d informations cliniques permettant d analyser la prise en charge médicale des patients. Nous envisageons également d évaluer le partage de documents non seulement textuels mais structurés avec d autres établissements de santé. Pour cela nous travaillons à intégrer au modèle de la base de données de l entrepôt des solutions d'alignement entre des systèmes de codage locaux et des systèmes terminologiques «standards» de référence (comme la SNOMED ou la CIM par exemple). Une perspective à plus long terme consiste à interfacer un moteur de règles à l entrepot de données cliniques afin de d évaluer si l élaboration d assistance à la pratique médicale (alertes, guides de bonnes pratiques, workflow) en est facilitée. Remerciements Réseau d excellence européen Semantic Mining, coordonné par l université de Linköping en Suède Bourse CIFRE de l entreprise MEDASYS, subventionnée par l ANRT (David Ouagne). Références [1] Hersh WR. (2002). Medical informatics: improving health care through information. Jama 288(16): [2] Wang SJ, Middleton B, et al. (2003). A cost-benefit analysis of electronic medical records in primary care. Am J Med 114(5): [3] Ledbetter, Craig S., Morgan, Matthew W., Toward Best Practice: Leveraging the Electronic Patient Record as a Clinical Data Warehouse, Journal of Healthcare Information Management, vol. 15, no. 2, summer [4] Wisniewski, M.F., A Clinical Data Warehouse for Infection Control, Journal of the American Medical Informatics Association Volume 10 Number 5 Sep / Oct [5] Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo Shvo A. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc Jan-Feb;13(1):30-9. [6] HL7 : (accédé le 4 octobre 2006) [7] Degoulet P, Marin L, Lavril M, Le Bozec C, Delbecke E, Meaux JJ et al. The HEGP component-based clinical information system. Int J Med Inform 2003; 69(2-3): [8] (accédé le 10 octobre 2006) [9] Beale T. Archetypes: Constraint-based domain models for future-proof information systems. Workshop on behavioural semantics (OOPSLA) [10] Bergmann J, Bott OJ, Pretschner DP, Haux R. An e-consent-based shared EHR system architecture for integrated healthcare networks. Int J Med Inform Sep 11; Adresses de correspondance David Ouagne, Christel Daniel-Le Bozec SPIM, Faculté de Médecine Paris 5 15, rue de l Ecole de Médecine, 75006, Paris s: {david.ouagne, christel.lebozec}@spim.jussieu.fr