DN 123 0037

PRÉSENTATION ET VISUALISATION DES DOCUMENTS MÉDICAUX
Le dossier médical numérique
Salma Sassi, Christine Verdier
Lavoisier | « Document numérique »
2009/3 Vol. 12 | pages 37 à 58

ISSN 1279-5127
ISBN 9782746226432
Article disponible en ligne à l'adresse :
--------------------------------------------------------------------------------------------------------------------
https://www.cairn.info/revue-document-numerique-2009-3-page-37.htm
--------------------------------------------------------------------------------------------------------------------
Distribution électronique Cairn.info pour Lavoisier.

© Lavoisier. Tous droits réservés pour tous pays.
La reproduction ou représentation de cet article, notamment par photocopie, n'est autorisée que dans les
limites des conditions générales d'utilisation du site ou, le cas échéant, des conditions générales de la
licence souscrite par votre établissement. Toute autre reproduction ou représentation, en tout ou partie,
sous quelque forme et de quelque manière que ce soit, est interdite sauf accord préalable et écrit de
© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

l'éditeur, en dehors des cas prévus par la législation en vigueur en France. Il est précisé que son stockage
dans une base de données est également interdit.
Powered by TCPDF (www.tcpdf.org)

Présentation et visualisation
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
RSTI - DN – 12/2009. Documents médicaux, pages 37 à 58

38 RSTI - DN – 12/2009. Documents médicaux
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
Présentation et visualisation des documents médicaux 39
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 IXe 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

18e 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édicaux1. 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 (CI2) 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.
Modèle : des ontologies d’un domaine particulier
Ontologie de domaine Ontologie de

médical tâches du domaine
Objet Classe
d’objets
médical Instanciation
Expert du domaine
Classe
Objet Objet Point de vue Objet
communication d’objets
simple complexe
médical
Instance des ontologies : Données
Instance de Instance de
l’ontologie de l’ontologie de tâches
domaine
Objet Classe
d’objets
Objet Objet Point de vue
Utilisateur
Classe simple complexe communication
Objet
d’objets
DVU
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
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.
Objet A Objet B Visite Radio © Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)
= =
Figure 2. Contrainte d’égalité (CE) Figure 3. Exemple de CE
Objet A Objet B Visite Radio

+ +
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
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.
Objet A d Objet B

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 PSA2 é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.

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.
Objet A Objet B
+
Ptdéc : X
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.
– 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.
1er 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.
e
2 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.
e
3 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 :
Ordre décroisant de priorité
Accessible par tous

Accessible par certain
Accessible par une personne

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
S’il ∃ Tap ∈ Q et ∃ au moins Tac ∈ Q alors la tâche est accessible par certains.
S’il ∃ Tap ∈Q et ∃ Tac ∈Q alors la tâche est accessible par tous.
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 simple tâche abstraite simple accessible par certains
tâche abstraite simple accessible par une personne
tâche abstraite complexe accessible par tous (Règle3).
Tâche complexe tâche abstraite complexe accessible par certains (Règle2).
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. Cela veut 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 © Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)
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 © Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)
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.

DN 123 0037

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DN 123 0037

Transféré par

Droits d'auteur :

Formats disponibles

PRÉSENTATION ET VISUALISATION DES DOCUMENTS MÉDICAUX

Le dossier médical numérique

Salma Sassi, Christine Verdier

Lavoisier | « Document numérique »

2009/3 Vol. 12 | pages 37 à 58

Distribution électronique Cairn.info pour Lavoisier.

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

Powered by TCPDF (www.tcpdf.org)

Salma Sassi* — Christine Verdier**

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

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

RSTI - DN – 12/2009. Documents médicaux, pages 37 à 58

Le dossier médical informatisé se visualise par une suite de documents numériques

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

document médical) au niveau de cette interface. Cette structuration contient une

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

Le dossier médical contient l’ensemble des données médicales, sociales,

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

Historiquement la relation médecin-malade est inscrite dans l’oralité. L’écrit n’a

La notion de dossier médical rattaché à chaque patient n’apparaît qu’à la fin du

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

Comme précisé par le Groupement de préfiguration du DMP en 2006, « Le DMP

2.3. Difficultés de représentation

La structuration du dossier médical dans les produits commerciaux est proche de

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

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

Le système ICOP proposé (ICOnic Project management system) est un

représentation graphique temporelle des informations médicales en fonction du

3.1. Présentation générale du système

3.1.1. Concepts de base

3.1.1.1. Dossier d’informations

3.1.1.2. Dossier virtuel unifié

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

3.1.1.3. Carte d’informations iconiques

3.1.1.4. Interface utilisateur iconique

3.1.2. Architecture du système

3.1.2.1. Niveau modèle

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

Modèle : des ontologies d’un domaine particulier

Ontologie de domaine Ontologie de

Instance des ontologies : Données

Objet Objet Point de vue

Figure 1. Architecture du système

3.1.3. Ontologie de domaine

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

3.1.3.1. Structuration d’objets

3.1.3.2. Dépendance entre objets

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

Objet A Objet B Visite Radio

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

objets déclencheurs et déclenchés peuvent décrire la même activité. En revanche

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

Un point de déclenchement noté (ptdéc) indique le moment où le déclenchement

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

La contrainte A d+ B spécifie une contrainte de déclenchement avec point de

Figure 7. Point de déclenchement

Comme le montre la figure 7, si l’objet A atteint le point de déclenchement X,

3.1.4. Ontologie de tâche

3.1.4.1. Classification des tâches

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)

3.1.4.2. Accessibilité des tâches

© Lavoisier | Téléchargé le 13/06/2022 sur www.cairn.info (IP: 41.97.121.54)