Présentation et visualisation des documents médicaux

des documents médicaux

Le dossier médical numérique

Salma Sassi* — Christine Verdier**

* LIRIS-DRIM – INSA de Lyon, UMR 5205 CNRS

bâtiment Blaise Pascal, 7 avenue Jean Capelle, F-69621 Villeurbanne cedex salma.sassi@liris.cnrs.fr

** LIG-SIGMA – Université Joseph Fourier, UMR 5217 CNRS, bâtiment C 220 route de la chimie, F-38400 St Martin d’Hères

christine.verdier@imag.fr

RÉSUMÉ. Construire un dossier médical numérique adapté à chaque médecin dans sa pratique courante, à partir de documents locaux ou de documents extraits d’autres sources de données, représente plusieurs difficultés : l’interrogation et la récupération des données distantes (sujet non étudié dans cet article) et la représentation de ces données dans un environnement graphique facile à utiliser et totalement paramétrable en fonction des besoins du médecin, besoins immédiats durant la consultation médicale ou besoins plus pérennes, liés à son métier. Nous proposons dans cet article de construire des documents numériques visualisés par une interface graphique de représentation du dossier médical à partir des documents médicaux créés en interne ou récupérés de systèmes d’information distants. Dans cet article, nous présentons l’architecture générale du système ICOP (Iconic Project Mangement System), la structuration des objets médicaux au niveau de l’interface et le résultat obtenu dans le prototype OR.

ABSTRACT. Building a numeric medical record adapted to health professionals’ current practice through local documents or documents extracted from other data sources presents several difficulties: distant data querying and retrieving (subject not studied in this paper) and the data representation in a graphical environment easy to be used and totally configured according to health professionals’ needs, immediately needed during medical appointment or more perennial needs related to health professional’ job. We propose in this paper to build numerical documents visualized through a graphical interface representing the medical record from medical documents created locally or retrieved from distant information systems. In this paper, we present the general architecture of ICOP system (Iconic Project Mangement System), the structure of medical documents at the interface level and the results obtained on OR prototype.

MOTS-CLÉS: document médical numérique, représentation, structuration, visualisation, partage.

KEYWORDS:numerical medical document, representation, structuration, visualization, sharing.

DOI:10.3166/DN.12.3.37-58 © 2009 Lavoisier, Paris

1. Introduction

Le dossier médical informatisé se visualise par une suite de documents numériques dont la présentation et le contenu représentent un facteur capital dans l’amélioration du travail du professionnel de santé. Le dossier informatisé médical actuel (qui représente une partie importante des logiciels médicaux du marché) se prête mal au partage des informations médicales destiné à suivre les pathologies d’un patient dans le temps (suivi temporel) et dans l’espace (suivi entre différents professionnels de santé). Le dossier médical traditionnel est donc suffisamment figé pour qu’il soit difficile d’en extraire des parties qui pourraient alimenter le dossier médical d’un confrère dans le cadre de la continuité des soins. Une solution alternative est constituée par les réseaux de soins qui créent des dossiers ad hoc indépendants des dossiers traditionnels sur lesquels les médecins saisissent les informations patients (Abbas et al., 2007). Une autre solution consiste à développer des plateformes de consultation des données médicales communes à tous les praticiens inscrits mais qui nécessitent la conception de connecteurs permettant d’alimenter facilement ce dossier partagé (DPPR Rhône- Alpes) (Durand et al., 2007). Même si cette dernière solution semble constituer une avancée considérable dans le partage des informations médicales et donc le soin collaboratif au patient, il reste encore des points de blocage : lenteur des connexions, attribution d’identifiants patients régionaux, développement de connecteurs ad hoc, aide à la saisie des données dans la plateforme, etc.).

Partager l’information médicale du patient dans le cadre de la continuité des soins pour en accroître la qualité, éviter les redondances d’actes ou sécuriser la prescription pharmaceutique est un constat bien ancré dans l’esprit de chacun et qui ne porte plus à discussion. Pour autant, même si technologiquement, on sait rendre interopérables les systèmes d’information (notamment par l’utilisation de services web), les considérations politiques et financières orientent souvent vers d’autres solutions.

Le dossier médical unique pour tous est totalement irréel. Il serait inadapté à chacun (un dossier médical de néphrologie est totalement différent d’un dossier médical de cancérologie, dans ses buts, les informations nécessaires au suivi de la pathologie et les documents utiles). À l’opposé, construire un système d’information dédié à chacun est une idée qui a fait son temps mais elle a le désavantage, outre d’être très coûteuse, de ne pas permettre la communication des informations d’un système à l’autre et de dupliquer bon nombre d’informations communes.

La solution idéale n’existe pas dès lors que l’on admet que la médecine est un métier d’artisan où chaque cas est différent même avec des caractéristiques communes fortes (deux personnes de même sexe, même âge, même pathologie n’auront pas forcément les mêmes traitements).

Dans cet article, nous présentons un système de visualisation de l’information médicale qui permet au médecin de construire son propre dossier médical numérique sur son interface de consultation. Le système, apparenté à un middleware sémantique, consiste en la structuration d’objets médicaux (partie indivisible d’un

document médical) au niveau de cette interface. Cette structuration contient une représentation vectorielle des objets médicaux ainsi qu’une représentation graphique sous forme d’icônes qui portent une même sémantique. Ces icônes sont manipulées et visualisées sur un axe temporel qui représente l’histoire santé du patient.

2. Evolution de la représentation du dossier médical 2.1. Définitions

Le dossier médical contient l’ensemble des données médicales, sociales, professionnelles concernant un patient et ayant un intérêt pour la connaissance de son état de santé. Il récapitule l’ensemble des informations qui sont nécessaires à l’identification de la maladie du patient ainsi qu’à la manière dont la thérapie va être conduite : éléments diagnostics, examens complémentaires puis thérapie médicamenteuse ou non médicamenteuse (arrêt de travail, soins infirmiers, rééducation fonctionnelle, etc.) (Flory et al., 1998).

Une définition intéressante a été donnée par le Journal Officiel n° 65 du 17 mars 2004 (Journal Officiel JO, 2004) : « Le terme dossier est utilisé (...) pour désigner l’ensemble des informations de santé concernant une personne donnée ». Nous considérons le dossier patient comme une mémoire représentant les données et les connaissances médicales, relatives à un patient et qui sont produites et utilisées par une organisation médicale. La représentation de cette information doit être persistante, c’est-à-dire constante et durable dans le temps et explicite, c’est-à-dire suffisamment claire et compréhensible pour ne pas être ambiguë lorsque les professionnels de santé l’interprète. Grâce à cette mémoire, les diverses catégories de professionnels de santé doivent pouvoir stocker et retrouver toutes les connaissances nécessaires à leurs activités.

2.2. Les différentes générations du dossier médical

Historiquement la relation médecin-malade est inscrite dans l’oralité. L’écrit n’a de place que dans les registres visant à recueillir le savoir médical et la connaissance. A l’origine, le dossier médical constitue un outil professionnel, pour le seul usage du médecin. Il est sa mémoire. Il existe physiquement sous forme d’un document papier jusqu’à l’arrivée de l’informatisation des données. Ses premières traces datent du IX^e siècle, époque à laquelle des médecins arabes (tels que Rhazès (865-925), Avicenne (930-1037) ou Avenzoar (1073-1162)), créent la médecine clinique. L’historique des cas intéressants est ainsi rédigé et conservé dans des registres tels que les observations de l’hôpital.

La notion de dossier médical rattaché à chaque patient n’apparaît qu’à la fin du 18^e siècle, comme un registre du patient dans les Hôtel Dieu, mais dont le contenu reste succinct.

La structuration du dossier médical est probablement l’un des exercices les plus difficiles. La difficulté majeure de la structuration tient à plusieurs phénomènes : l’information médicale est complexe, versatile en fonction de différents critères (lieu, temps, par exemple), liée à un métier donné (un urologue n’utilise pas les mêmes informations qu’un médecin généraliste), rétroactive et évolutive. Ajoutons à cette liste l’absence de définition précise du dossier médical que ce soit entre médecine de ville et médecine hospitalière ou encore au sein d’une même structure entre médecins différents. Le contenu du dossier médical, la législation et les autres contraintes ont entraîné une solution propriétaire sous forme papier qui était à la fois parfaite pour les médecins et totalement inutilisable sous forme informatique (le support textuel ne permet pas de faire des recherches sur les données).

L’automatisation des systèmes d’information a fait prendre conscience aux différents partenaires de l’importance de structurer et modéliser le dossier médical.

Les produits industriels au début des années 1970 se contentaient de structurer quelques éléments de base et n’étaient pas reliés à un réseau. Ces logiciels assurant surtout des fonctions de gestion et pour l’information médicale (le suivi des maladies chroniques, aide à la prescription et mémorisation des actes, des biologies, des ordonnances…).

En médecine de ville, chez les généralistes et les spécialistes de ville, des logiciels relatifs à la spécialité du métier ont été proposés. Chaque logiciel a été écrit pour répondre aux besoins d’une spécialité médicale.

Chez les libéraux, cette génération s’est caractérisée par l’apparition de nombreux logiciels construits avec une même logique : écrans paramétrés, liste de médicaments, classification de maladies, fonctions administratives (fiscalité, comptabilité), fonctions statistiques.

Dans ce contexte, nous pouvons citer les travaux de (Ciminio, 1996 ; Barrows et al., 1994 ; Ciminio et al., 1994) sur la modélisation des classifications et leur inclusion dans le dossier médical. Un autre travail (Verdier et al., 1994 ; Verdier, 1995) avait eu comme but de modéliser un système d’information médical totalement structuré permettant de réaliser à la fois un suivi médical et des enquêtes épidémiologiques.

Cette période s’est déterminée par une forte concurrence, il y a à l’heure actuelle plus de 110 logiciels pour médecins généralistes et plus de 80 logiciels pour médecins spécialistes. Pour autant, la concurrence est virtuelle car trois leaders émergent de cette offre commerciale : Cegedim (70 % du marché), Hellodoc et Axilog.

Pour ce qui est des hôpitaux, les systèmes ont souvent été construits sur mesure, pour la spécialité et en prenant totalement en compte la spécificité du service. Dans les années 1990, beaucoup de services se sont équipés de logiciels fabriqués pour les besoins du service sans communiquer les uns avec les autres. On comptait en 1995

dans un seul (grand) hôpital lyonnais, une centaine de logiciels installés. Nous évoquons les travaux de J.R. Scherrer autour des systèmes Diogène et Galen (Borst, 2000) à l’hôpital de Genève.

Les premières générations ont posé les jalons d’une véritable réflexion en profondeur sur la structuration du dossier médical. La deuxième génération va voir s’affirmer la notion de partage du dossier médical et de factorisation d’éléments communs. La deuxième génération s’est donc développée autour d’un réseau local.

En effet, depuis 20 ans, il y a eu de nombreuses tentatives visant à définir a priori un dossier partagé minimum, pertinent pour toutes les spécialités médicales.

Un tel dossier est basé sur le formatage des informations et encourage une vision globale du dossier. Ces projets ont été en partie des échecs car « il est difficile de spécifier et de partager une sémantique partagée des données médicales » (Fieschi, 2003). Devant ces échecs, la communauté médicale a préféré le terme de « dossier partagé ». (Fieschi, 2003) le définit comme un réservoir commun de données, qui

«vise à recueillir toutes les données médicales d’un patient ». Les professionnels de santé n’ont plus besoin de se mettre d’accord sur une sémantique commune. Ils doivent juste fournir ce dossier en documents qu’ils considèrent utiles à partager.

Cette notion de dossier partagé ayant été incluse dans une réforme de l’assurance maladie, le terme de « dossier médical personnel » DMP a été préféré à celui de

« dossier médical partagé ». En effet, pour des raisons politiques, le terme

« personnel » recentre cette notion de dossier sur le patient et non sur les professionnels de santé.

En médecine de ville, il y avait l’apparition de réseaux de soins. Les acteurs du réseau (généralistes, spécialistes, hospitaliers) communiquent entre eux à l’aide d’un réseau local non ouvert sur l’extérieur et concernant une pathologie spécifique. Dans les hôpitaux, le réseau permettait le partage de toute l’information hospitalière. Il s’agit de faire communiquer au travers d’un réseau local l’ensemble des acteurs de santé de l’hôpital.

La troisième génération se caractérise par l’apparition du dossier de spécialité, En effet, la plupart des services hospitaliers ont à leur disposition leur propre outil informatisé leur permettant de gérer un certain dossier patient. Ces outils sont adaptés à leurs pratiques car ils représentent les connaissances avec la sémantique relative à leur spécialité. Nous en donnons la définition suivante : Le dossier médical de spécialité est un dossier médical qui représente toutes les connaissances médicales relatives à un patient, produites dans un service hospitalier et spécifique à une spécialité donnée.

Les services hospitaliers ont eu du mal à partager toutes les informations.

D’ailleurs, comme nous l’avons dit précédemment, toute information n’est pas pertinente à partager. Certaines informations doivent donc être seulement accessibles du dossier de spécialité. Au contraire, il y a des informations qui sont utiles à plusieurs spécialités. Elles doivent être accessibles depuis le dossier de spécialité et le DMP. Ce dernier établit le lien entre tous les dossiers de spécialité.

Comme précisé par le Groupement de préfiguration du DMP en 2006, « Le DMP n’a pas vocation à se substituer au dossier métier des professionnels de santé, ni au dossier médical partagé des établissements de santé, ni au dossier des réseaux de soins dont les objectifs sont différents. Ces dossiers métiers concernent une prise en charge spécifique ou spécialisée du patient. Ils contiennent toutes les données et les informations liées à cette prise en charge. Parmi ces informations, certaines sont utiles à la coordination des soins et des prises en charge du patient par d’autres professionnels de santé. Ce sont précisément ces informations qui alimenteront le DMP, avec l’accord du patient ».

2.3. Difficultés de représentation

La structuration du dossier médical dans les produits commerciaux est proche de la façon dont les médecins exercent leur métier (cardiologie hospitalière, cardiologie de ville) et de l’influence que les informaticiens ont sur les médecins lors de leur négociation commerciale. Chaque dossier médical électronique mis sur le marché correspond à un métier spécifique et dans un même métier, souvent à une vision particulière de l’éditeur (un accent particulier peut être apporté à l’IHM, à la classification de maladies ou au choix des fonctionnalités). Cette hétérogénéité devient pénalisante à présent qu’il est nécessaire de partager une partie de l’information contenue dans les dossiers entre professionnels de santé en charge d’un même patient pour toutes les pathologies du patient.

Se surajoutant à ce problème, l’information médicale revêt des formes de structuration différentes (données atomiques, complexes, documents non structurés, semi-structurés) et des formes de représentation également dissemblables (courbes, tableaux, etc.).

De cet état de fait, il est aisé de déduire que la refondation des dossiers médicaux existants n’est ni aisée, ni pertinente, que même si l’hétérogénéité des structures des données médicales est acquise, on peut toutefois essayer de proposer une nouvelle structuration des données médicales au niveau de l’interface de consultation.

3. ICOP : interface de représentation iconique des données médicales

Le système ICOP proposé (ICOnic Project management system) est un middleware sémantique qui se place en sur-couche de n’importe quel système d’information de santé. Il prend, en entrée, les données médicales extraites du dossier médical local mais aussi permet l’accès aux données médicales distantes contenues dans les autres dossiers médicaux¹. Il produit, en sortie, une

1. Nous n’abordons pas dans cet article la problématique des requêtes à mettre en œuvre pour récupérer ces données, ni des aspects liés à la sécurité des transactions.

représentation graphique temporelle des informations médicales en fonction du processus de filtrage relatif au professionnel de santé (filtrage métier) et à ses besoins du moment (filtrage interactif).

Le processus de construction du document numérique visualisé par une interface graphique est le suivant : création du Dossier d’Informations (à partir des sources de données hétérogènes), création du Dossier Virtuel Unifié (unification des concepts grâce à une méta-ontologie de tâches et une méta-ontologie de domaine), création de la Carte d’Informations Iconiques (qui représente les objets médicaux sous forme d’icônes) et enfin, création de l’Interface Utilisateur Iconique suite au processus de filtrage (qui donne une vision synoptique des objets iconisés selon l’axe des temps) (Sassi, 2009)

3.1. Présentation générale du système 3.1.1. Concepts de base

3.1.1.1. Dossier d’informations

Un dossier d’informations est tout fichier contenant une information ayant un intérêt pour l’utilisateur. Cette information peut être non décrite, non référencée, sans origine, mais de grand intérêt pour l’utilisateur.

3.1.1.2. Dossier virtuel unifié

Nous définissons un dossier virtuel unifié (DVU) comme étant un ensemble de concepts reliés entre eux par des relations sémantiques. Contrairement aux informations contenues dans le dossier d’informations qui ne sont ni décrites, ni référencées, les concepts du DVU, sont décrits sémantiquement par des annotations et des métadonnées et sont contextualisés. Ces concepts sont également référencés par des icônes attribués à des documents. Tout dossier d’informations est donc transformé en DVU. Une description détaillée des composants du DVU est définie dans (Sassi, 2007). Dans ce papier nous avons défini les différents composants du DVU et nous avons présenté un métamodèle à partir duquel seront définies des primitives de représentation adaptées à un domaine, à un type d’activité particulière et à un utilisateur bien déterminé.

3.1.1.3. Carte d’informations iconiques

On appelle carte d’informations iconiques (CI²) une représentation graphique du Dossier virtuel unifié à travers des icônes. Cette carte représente un synoptique de l’historique du projet d’un sujet quelconque (déjà décrit à l’aide des concepts dans le DVU) permettant ainsi d’associer des icônes à la composante temporelle.

3.1.1.4. Interface utilisateur iconique

Nous présentons l’Interface utilisateur iconique (IUI) comme étant une interface permettant d’échanger des informations représentées sous forme d’icônes entre l’utilisateur humain et la machine. Pour que cette communication soit la plus simple à faire et à réaliser, on utilise les icônes. Les périphériques d’entrée, comme le clavier, la souris, ou les périphériques sonores, permettent à l’utilisateur de manipuler son espace iconique en donnant des renseignements ou des ordres à la machine. Les périphériques de sortie comme l’écran ou l’imprimante permettent à la machine de répondre aux ordres et d’afficher la connaissance sous formes d’icônes.

3.1.2. Architecture du système

Pour faire face à la variabilité et à la comptabilité des sources d’informations médicales très diversifiées, nous avons mis en œuvre une structure générale de ces sources. Le système Object Rebuilding (OR) est la concaténation d’une ontologie de domaine et d’une ontologie de tâches. Il permet de répondre à un besoin en termes de modélisation d’informations de plus en plus diverses et hétérogènes. La figure 1 définit l’architecture du système OR composée de deux niveaux.

3.1.2.1. Niveau modèle

Le niveau modèle définit les ontologies médicales. Ce niveau est constitué par les métadonnées décrivant l’information médicale. En d’autres termes, le modèle définit l’ontologie de domaine médical permettant au professionnel de santé de représenter les différents objets médicaux étudiés sous une forme unifiée. Il définit également une ontologie de tâches du domaine médical permettant au professionnel de santé de représenter les différentes tâches du domaine médical pouvant être effectuées sur les objets de l’ontologie du domaine médical.

3.1.2.2. Niveau instance

Le niveau instance des ontologies correspond au système modélisé. C’est aussi le niveau contenant les informations à décrire. En d’autres termes, ce niveau représente l’instanciation par l’utilisateur des éléments de l’ontologie de domaine médical ainsi que celle de tâches du domaine médical et qui permet ainsi la reconstruction de l’information médicale dans le Dossier virtuel unifié.

Afin de pouvoir appliquer notre système sur d’autres domaines relevant de la gestion de projet, nous avons construit un niveau métamodèle et défini des méta- ontologies (méta-ontologie de domaine et méta-ontologie de tâches). Ces métamodèles définissent les méta-métadonnées, c’est-à-dire la description de la structure et de la sémantique des métadonnées. Ces métadonnées concernent soit l’objet lui-même à travers la méta-ontologie de domaine, soit la tâche effectuée sur l’objet à travers la méta-ontologie de tâches.

Figure 1. Architecture du système

3.1.3. Ontologie de domaine

L’ontologie de domaine permet la description et la classification d’objets, de propriétés, de domaines de valeurs et d’instances.

Un objet est une entité soit naturelle, soit fabriquée par l’homme, défini en intension. Cet objet désignable par une étiquette verbale (un nom) a une fonction précise. Il est caractérisé par des propriétés, des relations binaires entre deux objets ou entre un espace et un objet, son état et les mouvements ou modifications qu’il subit ou qu’il cause. De ce fait, puisque rien n’est permanent, il peut évoluer dans le temps.

3.1.3.1. Structuration d’objets

Au regard de la diversité des objets utilisés dans un domaine déterminé, une catégorisation a été faite qui consiste à classifier les objets (Sassi, 2009). Dans cet article une catégorisation a été faite et qui consiste à classifier les objets selon les critères suivants : la composition qui nous permet de distinguer les objets simples des objets complexes. Le critère de la communication qui permet de distinguer les objets communiqués par tout le monde, les objets communiqués entre des spécialistes et les objets propriétaires.

3.1.3.2. Dépendance entre objets

L’activité traduite par l’acte médical est le travail du médecin, un acte médical va se matérialiser par un résultat. Un résultat est un ensemble de couples <code, valeur> qui est dépendant du type icône. Par exemple pour l’acte consultation médicale, le résultat se traduira par une ordonnance qui contiendra une liste de

Instance de l’ontologie de

domaine

Classe d’objets Objet

Instance de l’ontologie de tâches

Objet complexe Objet simple

Classe d’objets

Point de vue communication Objet

Instance des ontologies : Données Ontologie de domaine

médical

Objet complexe Objet simple

Classe d’objets

Point de vue communication Objet

Ontologie de tâches du domaine

médical

Classe d’objets Objet

Modèle : des ontologies d’un domaine particulier

Instanciation

DVU

Expert du domaine médical

Utilisateur

couples <code médicament, posologie>, pour la biologie ce sera une liste de couples

<code examen, valeur du paramètre> (la valeur du paramètre peut être une valeur booléenne Oui/Non).

L’acte médical représente l’unité de base de l’information d’un domaine et concerne un épisode bien déterminé. Un épisode – de santé – représente un segment temporel d’information (correspond généralement à une maladie) qui s’écoule entre une date de début (date de découverte de la maladie) et une date de fin (facultative).

Cependant, à l’intérieur d’un même épisode, on trouve ce que l’on va appeler des

« activités principales » et des « activités dépendantes » c’est-à-dire des activités qui sont déclenchées pour une autre activité. Par exemple, les activités de type

« radiologie », « biologie », etc. en sont des exemples mais aussi les activités dites complémentaires liées à une affectation principale (par exemple examen par un diabétologue d’une femme enceinte lors d’un épisode « grossesse »).

Ces activités dépendantes doivent renvoyer une information à l’activité initiale qui les a provoquées. On doit alors associer à chaque activité un statut qui prend deux valeurs : « En attente » et « Terminée ». Une activité est en attente lorsque les informations complémentaires obtenues par une activité dépendante ne sont pas encore disponibles. Une activité est terminée lorsque toutes les informations complémentaires sont disponibles. Par extension, nous dirons que toute activité qui ne fait pas appel à des résultats obtenus par des activités complémentaires est en état

« terminé ».

Nous avons modélisé la dynamique du système d’informations médicales et en particulier les liens qui peuvent exister entre les objets médicaux. Dans la plupart des cas, des objets que nous appelons « objets déclencheurs » peuvent mettre en action d’autres objets appelés « objets déclenchés ». Nous avons modélisé ce processus de déclenchement par des contraintes sur objets.

Figure 2. Contrainte d’égalité (CE) Figure 3. Exemple de CE

Figure 4. Contrainte de différenciation (CD) Figure 5. Exemple de CD

En effet, lors d’une activité, la création d’un objet médical peut être provoquée par celle d’un autre objet médical qui se réalise sur la même activité. De ce fait, les

Objet A = Objet B ^Visite = ^Radio

Objet A + Objet B ^Visite + ^Radio

objets déclencheurs et déclenchés peuvent décrire la même activité. En revanche dans d’autres cas, l’objet déclenché peut concerner une activité différente de la première. Dans ce cas, les deux objets peuvent décrire deux activités différentes. On distingue donc deux types de contraintes ; la contrainte d’égalité et la contrainte de différenciation. La première concerne les objets qui décrivent la même activité. La deuxième exprime le fait que deux objets décrivent deux activités différentes. La contrainte d’égalité est modélisée en utilisant le signe (=), la contrainte de différenciation est exprimée par le signe (+). Une flèche est utilisée pour désigner le sens du déclenchement.

En figure 2, le sens de la flèche montre que l’objet A déclenche l’objet B, la contrainte exprime le fait que le deuxième objet est décrit pour compléter la description de la même activité. Un exemple de cette description est présenté dans la figure 3 qui montre que l’objet Visite déclenche la création de l’objet Radio qui vient compléter la description de l’épisode Grossesse par exemple.

On reprend le même exemple qui montre une contrainte de différenciation. On peut imaginer que lors d’une consultation des reins, le médecin a vu la nécessité de faire pratiquer au malade une radio en diabétologie.

Contrairement aux contraintes d’égalité et de différenciation où le déclenchement n’est pas obligatoire dans le sens où l’objet B peut être créé même si l’objet A ne l’est pas, la contrainte de dépendance exprime un déclenchement impératif. En d’autres termes, l’existence de l’objet B dépend impérativement de la création de l’objet A.

Figure 6. Contrainte de dépendance

Un point de déclenchement noté (ptdéc) indique le moment où le déclenchement doit être fait dans l’objet déclencheur (par exemple si le médecin remarque dans une analyse biologique un taux de PSA² élevé, il demandera une biopsie de la prostate.

Le point de déclenchement spécifie donc une option et n’est pas obligatoire. Si rien n’est renseigné et qu’il existe une contrainte de déclenchement, ceci signifie que l’objet B doit être déclenché après l’achèvement de l’objet A. Le déclenchement spécifie une condition nécessaire pour déclencher l’activité B.

2. Un taux de PSA élevé oriente vers un diagnostic de cancer de la prostate.

Objet A _d Objet B

La contrainte A d+ B spécifie une contrainte de déclenchement avec point de déclenchement, les deux objets déclencheur et déclenché doivent décrire deux activités différentes.

Figure 7. Point de déclenchement

Comme le montre la figure 7, si l’objet A atteint le point de déclenchement X, l’objet B est déclenché pour décrire une autre activité que celle décrite par l’objet A (A + B).

3.1.4. Ontologie de tâche

Nous définissons une tâche par toute action qui traduit une activité professionnelle dans un contexte particulier et désignable par une étiquette verbale (un verbe). Elle est définie par les relations externes qu’elle entretient avec son environnement, par son état et les mouvements ou modifications qu’elle cause.

3.1.4.1. Classification des tâches

Au regard de la diversité des tâches qui peuvent être modélisées dans un domaine déterminé, une catégorisation a été faite. Elle consiste à classifier les tâches selon les deux critères suivants : composition et accessibilité des tâches. Tout comme les objets, le premier critère, composition, consiste à distinguer les tâches simples des tâches complexes. Le deuxième critère, accessibilité des tâches, nous a amené à classifier nos tâches en tâches accessibles à tous, accessibles à certains et restreintes à une personne, selon la nature et l’objectif de la tâche.

a. Critère de composition

Le critère de la composition signifie qu’une tâche engendre une autre tâche pour son propre usage. En réalité, la seconde tâche ne peut conceptuellement pas être dissociée de la première. Par exemple, la suppression d’une relation dépend obligatoirement de la suppression d’un objet médical. De fait, la tâche SupprimerRelationAnnotation (relation qui relie un objet médical à un épisode), ne peut pas s’exécuter sans la présence de la première tâche : supprimer Objet médical.

C’est une relation extrêmement forte entre deux tâches. On distingue deux types de tâches : les tâches simples et les tâches complexes.

– Une tâche simple est une tâche dont l’exécution ne concerne qu’un seul élément de l’ontologie de domaine médical. En d’autres termes une tâche simple est une tâche composée d’une seule action.

Objet A + Objet B

Ptdéc : X

– Une tâche complexe est une tâche composée d’une ou plusieurs tâches simples ou complexes. En d’autres termes, la tâche complexe est composée de plusieurs actions et peut affecter plusieurs éléments de l’ontologie de domaine médical.

b. Critère d’accessibilité

Certaines tâches peuvent être effectuées par tous les utilisateurs du domaine comme la tâche CréerObjetsPropriétaires () et sont donc considérées comme accessibles pour tous les utilisateurs. En revanche d’autres tâches sont spécifiques à un ou plusieurs sous- domaines et sont jugées accessibles uniquement par les professionnels de ce sous- domaine. Enfin, nous avons relevé la nécessité de disposer d’un espace privé, permettant à l’utilisateur d’acquérir une certaine marge de liberté dans son travail où il peut ajouter ses propres tâches qu’il juge importantes pour son activité.

– Les tâches accessibles par une personne : une tâche est qualifiée d’accessible par une personne si elle est configurée uniquement dans l’espace profil de son créateur qui l’a déclaré comme propriétaire. Une telle tâche ne peut jamais être configurée dans les autres espaces de travail des utilisateurs.

– Les tâches accessibles par tous : une tâche est qualifiée d’accessible par tous si au contraire elle est configurée dans tous les espaces de travail des utilisateurs.

– Les tâches accessibles par certains : une tâche est qualifiée d’accessible par certains si elle n’est configurée que dans les espaces de travail des utilisateurs du même sous-domaine. Une telle tâche n’est jamais réutilisée par les professionnels d’un autre sous-domaine.

3.1.4.2. Accessibilité des tâches

Tout comme les objets, nous avons défini des règles pour spécifier cette accessibilité. Nous nous basons sur le tuple <tâche, profil, objet> pour spécifier un graphe d’accessibilité de la tâche. Le but de ce graphe est de préciser pour chaque tâche dans quel espace de travail il doit être configuré.

a. Graphe d’accessibilité

Soit U1, U2, U3, U4, U5, des utilisateurs du système parmi lesquels U1, U2, U3 sont de spécialité S1 et U4, U5 sont de spécialité S2. Nous présentons l’accessibilité de la tâche VisualiserObjet () à travers un graphe.

Soit O un objet médical et T la tâche VisualiserObjet().

Soit Visible (O) la fonction qui permet de visualiser l’objet O.

Config (T) la fonction qui permet de configurer la tâche T dans l’espace de travail de l’utilisateur.

1^er Cas : O est un objet communicant

Si ∀ O Visible (O) est vrai pour {U1, U2, U3, U4, U5} alors Config (T) est vrai pour {U1, U2, M3, U4, U5}. T est accessible par tous les utilisateurs.

2^e Cas : O est un objet de la spécialité S1

∀ O, Visible (O) est Vrai pour {U1, U2, U3}, alors config (T) est vrai pour {U1, U2, U3}. T n’est accessible que par les utilisateurs de spécialité S1.

3^e Cas : O est un objet propriétaire créé par l’utilisateur U1

∀ O, Visible (O) est Vrai pour {U1}, alors config (T) est vrai pour {U1}. T n’est accessible que par l’utilisateur U1.

b. Règles de priorité d’ordre des tâches

Il est facile de décider de l’accessibilité des tâches simples. En effet, si la tâche est simple, l’accessibilité de la tâche prend la valeur du type de la tâche correspondante. Elle est donc soit accessible par tous, voir accessible par certains, soit accessible par une seule personne. En revanche, si la tâche est composée d’autres tâches, il devient plus compliqué de déterminer son accessibilité. Pour cela nous avons défini des règles d’accessibilité qui permettent de juger si une tâche est accessible ou pas. Conformément au principe de la communication des objets, ces règles se basent sur le principe d’ordre de priorité d’accessibilité présenté dans la figure ci-dessous :

Figure 8. Ordre de priorité des tâches

Soit les tâches suivantes : Tat : Tâche accessible par tous, Tac : Tâche accessible par certains et Tap : Tâche accessible par une personne. Soit Q l’ensemble des tâches formant la tâche complexe TC.

Règle 1 : priorité d’ordre1

S’il ∃ au moins Tap ∈Q alors la tâche n’est accessible que par la personne qui l’a créée

Règle 2 : priorité d’ordre2

S’il ∃ Tap ∈ Q et ∃ au moins Tac ∈ Q alors la tâche est accessible par certains.

Règle 3 : priorité d’ordre3

S’il ∃ Tap ∈Q et ∃ Tac ∈Q alors la tâche est accessible par tous.

Ordre décroisant de priorité Accessible par tous Accessible par certain Accessible par une personne

Les critères de classification que nous avons définis nous ont permis de dresser ce tableau qui présente une répartition selon les différentes classes d’objets qu’on a pu dégager.

Type

Critère de composition Critère d’accessibilité tâche abstraite simple accessible par tous tâche abstraite simple accessible par certains Tâche simple

tâche abstraite simple accessible par une personne tâche abstraite complexe accessible par tous (Règle3).

tâche abstraite complexe accessible par certains (Règle2).

Tâche complexe

tâche abstraite simple accessible par une personne (Régle1)

Tableau 1. Répartition des tâches 3.1.5. Arbre de concepts

3.1.5.1. Présentation générale

L’arbre de concept regroupe les éléments nécessaires pour la construction de la carte d’informations iconiques. Nous présentons ici une présentation simplifiée de l’arbre de concept. Cet arbre est généré à partir d’un fichier de métadonnées, le fichier XML sémantique (XMS) et de l’ontologie de domaine. Ainsi, le contenu de l’arbre est extrait à partir du fichier XMS alors que la sémantique (les relations entre les concepts) entre les différents concepts de l’arbre est déduite à partir de l’ontologie de domaine médical.

Une étape de filtrage selon le profil de l’utilisateur est nécessaire pour générer correctement cet arbre de concepts. Pour ce faire, nous devons générer le graphe profil de l’utilisateur.

3.1.5.2. Filtrage de l’arbre de concept

Le graphe profil de l’ophtalmologiste est composé d’un espace d’objets propriétaires contenant les comptes rendus personnels et les notes personnelles. Un espace d’objets communicants contient les visites et les prescriptions et un espace d’objets de spécialité comporte les comptes rendus de consultation d’anesthésie, les

« autres » prescriptions, les comptes rendus opératoires, les imageries de diagnostics, les traitements médicamenteux… Nous remarquons que le profil ophtalmologiste n’est pas autorisé à visualiser les objets médicaux comme les chimiothérapies. Pour cela, cet objet ne doit pas figurer dans l’arbre de concept de l’utilisateur appartenant à ce profil.

Figure 9. Arbre de concept

Figure 10. Graphe profil

3.1.5.3. Arbre de concept filtré

L’ophtalmologiste n’a pas droit de visualiser les protocoles de chimiothérapie suivis par le patient.

Figure 11. Arbre de concepts filtré du profil ophtalmologiste

3.1.6. Génération de la carte d’informations iconiques

La première étape de la génération de la carte d’information iconique est la génération du vecteur de concepts. Un vecteur concept (VC) est une organisation vectorielle des concepts. Ce Vecteur est généré à partir de l’arbre de concepts.

Pour chaque nœud de l’arbre, on crée un vecteur concept. Ce vecteur contient la liste des nœuds ou des feuilles qui sont en relation avec le nœud parent. Un concept est représenté par une feuille ou un noeud. On distingue deux types de concepts : un concept simple et un concept composé. Un concept simple est une feuille qui n’est plus décomposable alors qu’un concept composé est un nœud pour lequel on définit un vecteur concept. Sur la base de ce vecteur de concepts, on génère le vecteur relations. Un vecteur relations (VR) est une organisation vectorielle des relations entre les différents concepts du domaine. Une relation est définie à partir des types des nœuds de l’arbre de concepts.

Pour chaque relation de l’arbre de concepts, on crée un vecteur de relations. Ce vecteur rassemble les différents nœuds qui sont reliés par ce type de relation.

La dernière étape consiste à dessiner la carte d’informations iconiques à partir des vecteurs de concepts et de relations. Pour ce faire, on recherche les relations d’annotations (relation reliant un icône décrivant l’objet médical à l’épisode) dans le vecteur relations. Pour chaque relation trouvée, on cherche dans le même vecteur, les relations d’attributs de l’épisode, de l’icône et ceux du parcours santé et on dessine la relation Ra. Celaveut dire qu’on génère l’épisode et l’icône qui l’annote. Pour chaque relation d’attribut trouvée, on cherche dans le vecteur concept, les valeurs des attributs trouvés, on ajoute ces attributs aux objets de la carte d’informations iconiques.Enfin, pour chaque nœud de type icône (Ic) on cherche dans le vecteur relations, les relations de référence aux documents. Pour chaque relation trouvée, on cherche dans le vecteur de concepts, la valeur de l’URL correspondante.

3.2. Processus de construction du dossier médical numérique

Le prototype développé offre un accès iconique à l’information médicale. ICOP permet de présenter les dossiers médicaux sous un format unifié, iconisé et chronologique répondant aux attentes des utilisateurs qui veulent un accès flexible pour tous. ICOP visualise donc par un système d’icônes les différents actes représentés sur une échelle chronologique. ICOP facilite la saisie des données et des informations à travers la manipulation des icônes et la proposition des assistants de création. La figure 12 résume les différentes fonctions d’ICOP. Avec ICOP, l’utilisateur peut gérer la Carte d’informations iconiques à l’aide des tâches orientées icônes. Sur sa carte, l’utilisateur peut récupérer des données créées par d’autres utilisateurs du système. Sur ces données récupérées, l’utilisateur n’a que le droit de lecture. Il ne peut pas modifier les données des autres utilisateurs du système. Par ailleurs, il peut créer ses propres donnés, gérer sa base de connaissances et modifier

(s’il le souhaite) son espace de travail. Des assistants sont proposés pour l’aider dans ses différentes tâches. L’utilisation de ces assistants n’est pas obligatoire mais aide amplement l’utilisateur dans son travail.

Figure 12. Fonctions d’ICOP

La première interface est l’interface d’accueil du Bureau Virtuel du médecin. Le professionnel de santé a accès aux différentes fonctionnalités du bureau virtuel : la messagerie, le calendrier partagé, l’organisation des contacts, la sauvegarde de documents partagés et de documents personnels, le bloc notes, les tâches, les favoris et les outils de communication synchrones (Chat et Forum) et finalement le parcours santé du patient. Un click sur l’un des boutons représentant ces fonctionnalités affiche une vue globale de la fonctionnalité. Pour accéder aux différentes fonctionnalités du parcours santé, il suffit juste d’appuyer sur le bouton Naviguer dans le parcours santé du patient.

Figure 13. Interface représentant le bureau virtuel du médecin

Figure 14. Interface générale du parcours santé du patient

L’interface représentant le parcours santé du patient est composée d’une base de connaissances contenant les différents objets que l’utilisateur a le droit de manipuler

selon son profil (située à gauche de l’interface). Au milieu de l’interface nous présentons la Carte d’informations iconiques du patient. Cette carte représente un synoptique de l’historique du patient dès sa naissance jusqu’à sa mort. Comme le montre la figure 14, les épisodes sont représentés avec des rectangles balisés par une date de début et éventuellement une date de fin. Chaque épisode est annoté par des actes médicaux représentés sous la forme d’icônes. Un click sur une icône affiche les métadonnées de l’acte médical sous forme d’une brève description de l’icône. Un passage de souris sur l’icône affiche sur le personnage situé à droite de l’interface l’organe concerné par l’acte médical. Si un document numérique est affecté à l’icône, un petit schéma apparait sur l’icône indiquant la présence d’un document descriptif de l’acte médical. Un click sur ce petit schéma ou un double click sur l’icône affiche le (ou les) document(s) attribué(s) à cet icône. Comme le montre la figure 14, un click sur l’icône Ordonnance (O) affiche le document numérique ordonnance, un click sur l’icône Radio (R) affiche l’image de la radio avec un résumé.

4. Conclusions et perspectives

Nous avons proposé une vision métier du problème de la visualisation du dossier numérique du patient en ce sens qu’elle reflète bien le fonctionnement du médecin et que c’est l’outil qui s’adapte à l’utilisateur et non pas l’inverse. Le système de visualisation développé a été présenté au corps médical et a reçu un certain accueil encourageant ; les médecins considérant que cet outil était, en l’état actuel des techniques, celui qui s’approchait le plus de leurs besoins. Cette interface a en outre l’avantage de pouvoir s’intégrer tout à fait dans la logique actuelle des réseaux de soins dont le DMP (dossier médical patient) en cours d’élaboration en France, doit être la clé de voûte. En effet, si cet outil peut visualiser le dossier médical du médecin, il peut tout aussi bien, dans une approche réseau (réseau de soins) permettre de la même façon de visualiser non seulement les actes du médecin mais également tous ceux effectués sur le malade par l’ensemble des professionnels de santé. Ceci permet donc d’approcher un autre souhait du législateur, à savoir une vue centrée malade où un soignant peut accéder à l’ensemble des informations médicales concernant un patient quel que soit le lieu ou le temps où cette information a été recueillie. Cette trajectoire du patient représente ce que nous appelons un parcours santé.

En termes de perspectives, nous souhaitons développer des infrastructures permettant d’adapter l’interface graphique traçant la carte d’informations iconiques répartie. Nous pensons qu’il est possible de réaliser dynamiquement des adaptations de données graphiques, et que cela permettra de mieux gérer les ressources utilisées par l’application lorsque celles-ci sont limitées.

Une autre perspective est relative aux techniques d’interface et vise à concevoir un zoom portable, c’est-à-dire un zoom implémenté sur une interface mobile. Afficher une grande quantité d’informations sur un petit écran reste très problématique. En ce sens, la conception d’un zoom, permettant la reconnaissance et la localisation d’objets

non visibles (ou assister la lecture visuelle d’objets) apparaît comme une opportunité pour repenser la dimension multimodale de l’interaction avec les interfaces portables.

Dans la même perspective, nous envisageons de pouvoir comparer au sein de la même interface graphique deux parcours santé différents.

5. Bibliographie

Abbas K., Verdier C., « Conception d’une structure globale du dossier médical pour les réseaux de soins », Systèmes d’information et santé, SAS – 10/2007, Paris, Hermès, p. 137-156.

Barrows J.R., Cimino J.J., Clayton P.D., “Mapping Clinically useful terminology to a controlled medical vocabulary”, Proc Annu Symp Compt Appl Med Care, 1994.

Bors F.T., Grisser P., .Bourdilloud R., Scherrer JR., “Fifteen years of medical encoding in the Diogene HI”S, Medinfo, 1995.

Cimino J.J., “Review paper: coding system in health care”, Methods Inf Med, 1996.

Cimino J.J., Clayton P.D., Hripcsak G., Johnson J.B., “Knowledge-based approaches to the maintenance of a large controlled medical terminology”, J Am. Med. Inform. Assoc., 1994.

Durand T., Spacagna H., Verdier C., Biron P., Flory A., “The Rhône-Alpes health platform”, Journal Methods Inf. Med., Schattauer Eds, 4/2007, p. 451-57.

Fieschi M., « Les données du patient partagées: la culture du partage et de la qualité des informations pour améliorer la qualité des soins », Note d’orientation remise au ministre de la santé, de la famille et des personnes handicapées. Les données du patient partagées:

propositions pour l’expérimentation. http://www.sante.gouv.fr/htm/actu/fieschi/ sommaire .htm.

Flory A., Verdier C., Leverve X., Informatique et Internet chez le médecin, Doin, Initiative Santé, 1998.

Journal Officiel N° 65 du 17 mars 2004. Arrêté du 5 mars 2004 portant sur l’homologation des recommandations de bonnes pratiques relatives à l’accès aux informations concernant la santé d’une personne, et notamment l’accompagnement de cet accès NOR:SANP 0420786A. http://www.admi.net/jo/20040317/SANP0420786A.html.

Sassi S., « Un médiateur sémantique pour une représentation unifiée et chronologique du dossier médical », Revue Santé et Systématique, vol. 10, n° 1-2/2007, p. 105-136.

Sassi S., Le système ICOP : représentation, visualisation et communication de l’information à partir d’une représentation iconique des données, Thèse de doctorat, INSA de Lyon, 2009.

Verdier C., Propositions pour la conception et la mise en œuvre d’un système d’information médical, Thèse de doctorat, Université Lyon 1, 1995.

Verdier C., Flory A., “An information system for epidemiology based on a computer-based medical record”, Journal Methods of Information in Medecine, vol. 33, 5/94, p. 496-501, Dec 1994.