Modélisation et méthode de conception de systèmes de …docinsa.insa-lyon.fr › these › 2002 › ghedira › 11_chapitre5.pdf · 2005-01-20 · Méthode de conception de systèmes

Méthode de conception de systèmes hypermédia adaptatifs pour l'aide à la décision

92

Chapitre 5

IMPLÉMENTATION DE LA MÉTHODE HANS

ous avons présenté dans les deux précédents chapitres les éléments que nous apportons pour la conception de systèmes hypermédia adaptatifs. Ces éléments sont constitués d'une part par des principes techniques et d'autre part par la méthode HANS. Nous avons appliqué notre méthode et ces techniques à un domaine qui

nécessite un accès rapide aux informations les plus significatives pour une prise de décision, à savoir le domaine médical. Nous allons donc présenter, dans ce chapitre, l'implémentation de la méthode HANS dans ce domaine.

1. PRÉSENTATION GÉNÉRALE - LE SYSTÈME D'INFORMATION

Le domaine médical est un secteur crucial où les professionnels de santé sont amenés à prendre des décisions de la plus haute importance le plus rapidement possible. La quantité d’information est considérable et ne cesse de croître avec l’âge du patient. En effet, le dossier d’un patient est constitué par la somme des informations recueillies au sein de l’ensemble des structures médicales qu’il a pu côtoyer tout au long de sa vie.

Ces informations de types variés peuvent être issues d’observations cliniques, de signaux biologiques, d’images capturées par différents moyens, etc. Ces informations sont très hétérogènes et de granularités variées. Citons, par exemple, les données de mesure issues d’examens radiologiques, d’encéphalogrammes ou d’examens cardiologiques qui ont des formats différents, sont dérivées d’autres informations et qui se révèlent être d’une extrême richesse : de calculs complémentaires sur des données brutes, de courbes de tendance, etc.. Notons en particulier qu'il existe plusieurs types d’enregistrements électrocardiographiques

N

Implémentation de HANS

93

(ECG) d’où sont issues une centaine de mesures utiles pour prévenir ou détecter un éventuel disfonctionnement cardiaque.

Dans le cas de l’analyse d’un électrocardiogramme, le praticien doit pouvoir passer de la vision du signal à des informations de mesure, puis naviguer au sein des informations physiologiques du patient, de ses antécédents médicaux, pour revenir à la présentation des enregistrements électrocardiographiques, afin d'établir son diagnostic. Chacune de ces informations n’est certainement pas pertinente pour tous les utilisateurs d'un système de consultation de ces données. En effet, un médecin généraliste sera intéressé par le rapport d’interprétation des différents examens. Par contre un spécialiste ira analyser tels examens et telles données issues de celui-ci en vue d’une prise de décision.

La qualité des décisions thérapeutiques est par conséquent conditionnée, d'une part par la disponibilité et la facilité d’accès à l’information la plus pertinente du dossier médical pour chaque utilisateur, et d’autre part par l’amélioration de l’environnement décisionnel du praticien [RON 96, FAYN 96]. En d’autres termes, il s’agit d’adapter les systèmes aux pratiques des médecins (propres à chacun d’entre eux et évolutives) et aux spécificités du patient, de façon à fournir des présentations synthétiques de données.

C’est dans ce contexte de données cardiologiques que nous allons appliquer la méthode HANS et en illustrer chaque étape. Nous avons nommé notre prototype HEMA "HEalthdata Manager Application".

2. LES MÉTA CONNAISSANCES

L'expérience montre que, pour un patient donné, sur 200 paramètres de consultation clinique, à une étape donnée de l'évolution de la maladie, seuls une vingtaine d'entre eux en moyenne sont pris en considération par le médecin, et ce, sans dégradation notable du diagnostic final. Ainsi une prise de décision rapide et fiable s'appuie sur un sous-ensemble pertinent de l'information disponible sans que ce sous ensemble puisse être défini a priori. Ce sont ces éléments pertinents qu'il faut extraire et présenter de la manière la plus significative possible.

Pour satisfaire cet objectif, il nous faut connaître les logiques décisionnelles employées par les utilisateurs dans leur pratique et représenter cette connaissance sous une forme adaptée à la construction dynamique d’interfaces et de sessions.

Rappelons que la méthode HANS amène à une modélisation de l'environnement décisionnel du corps médical en lui fournissant des instanciations de modèles (les modèles MD, MN, MP définis au niveau des concepts, et qui sont instanciés avec les données d'un patient) permettant de construire une session d'interrogation, d'analyse et de présentation de données. Ces modèles sont organisés selon trois axes : le profil de l'utilisateur (le médecin), la tâche (le processus de décision) et la nature des objets (les éléments manipulés).

Ainsi, en appliquant la méthode HANS, nous concevons des modèles qui servent de base pour le développement de systèmes de consultation de type hypermédia particulièrement orientés sur la capitalisation des connaissances d'expert, la gestion de profils de navigation individuels et la personnalisation de la présentation. L'application de la méthode HANS que nous avons menée s'est accompagnée de l'étude des différents éléments nécessaires à la conception du système hypermédia adaptatif dans le domaine médical, et plus particulièrement en cardiologie. Ces éléments sont non seulement


94

conceptuels (modélisation) mais aussi techniques (langages utilisés, et composants produits à chaque étape).

3. IMPLÉMENTATION DE HANS

Dans cette partie, nous rappelons chaque étape de la méthode et les modèles associés, et nous présentons le déroulement de ces étapes, avec les modèles produits.

Nous reprenons ci-après la figure 4.7 du précédent chapitre, représentant le schéma complet de la méthode HANS.

Figure 5.1 : Schéma global de la méthode HANS

3.1. Niveau conceptuel

3.1.1. Modèle du Domaine (MD) Le MD est constitué de l'ensemble des concepts du domaine, leur structure et relations.

Pour le réaliser, nous avons eu recours aux experts du domaine cardiologique, afin d'identifier les objets concernant l'enregistrement électrogardiographique et leurs associations. Ce modèle représente les différentes caractéristiques du dossier patient, comme par exemple les données administratives, le descriptif des antécédents, les contacts établis précédemment, les traitements suivis, telles qu'elles sont définies dans la norme HISA1 [CEN 98]; il reprend également les informations liées aux différents signaux électrocardiographiques, telles qu'elles sont définies dans la norme SCP-ECG [CEN 93] et ŒDIPE [RUBE 95], et plus particulièrement les enregistrements, les séquences, les mesures standards (QRS-Duration, QT-Duration, PR-interval, etc.), les rapports d’interprétation, etc.

1 HISA: Healthcare Information System Architecture définie par le CEN/TC 251.

Mod èle d u Dom a in e Mod èle Ut i l i sa t eu r s/Act eu r s

Mod èle N a v iga t ion n el

Fichiers XS L

Mod èle d e Pr ésen t a t ion

XML/XLink

In terface H/ M

Bdliens+

contextes

# MoteurD’adaptativité

# Filtrage

Observation

Analyse et Mise à Jour

Mod èle d uDon n ées S t ru ct u r ées


95

Nous avons par la suite traduit ce modèle en une DTD, c'est-à-dire que chaque élément constitutif du schéma de la base représente une balise. Notre modélisation est ainsi basée sur le concept de la structuration des informations concernant les dossiers sous la forme d’un graphe, où chaque nœud informationnel correspond à une instance d’un type de données, et peut être le point de départ pour accéder à d’autres nœuds. Un nœud peut être lui-même un graphe qui inclut des données semi-structurées, élémentaires et/ou inter reliées.

La figure 5.2 montre un exemple du résultat de cette étape et son contenu, à savoir le

MD et la traduction2 du schéma du MD en une DTD en utilisant le langage XML.

Figure 5.2 : Exemple de traduction du MD en DTD

2 Pour récupérer le schéma du MD, nous nous inspirons de la proposition du groupe OMG (Object

Management Group) du W3C concernant l'échange de métadonnées XML : XMI (XML Metadata Interchange) pour traduire un schéma de base de données réalisé avec le formalisme UML.

<XML version=’1.0’ encoding=’ISO-8859-1’standalone=’no’>

<!ELEMENT HANSWORKSTATION (SUBJECTOFCARE,HEALTHCARACTERISTIC,TYPE_OF_ACTIVITY,PHYSICIAN,TYPE_OF_CONTACT,DRUGS,DEPARTEMENT,COMPOSITE,ELEMENTARY_HC,ECG_REC_SEQ,ECG_MEAS,ACTIVITY,CONTACT,PATIENT,ECG_RECORD,INT_REPORT,STANDARD_MEAS,HAS_ACTIVITY,HAS_DRUG,HAS_HEALTHCARACTERISTIC,HAS_HC,BELONGS_TO_DEPARTEMENT,LISTHC)>……..<!ELEMENT ELEMENTARY_HC (ITEM_ELEMENTARY_HC)*><!ATTLIST ITEM_ELEMENTARY_HC (ELEMENTARYHC_ID,IDHEALTHCARACTERISTIQUE)><!ELEMENT ELEMENTARYHC_ID (#PCDATA)>……..<!ELEMENT ECG_REC_SEQ (ITEM_ECG_REC_SEQ)*><!ATTLIST ITEM_ECG_REC_SEQ (ECG_REC_SEQ_ID,ELEMENTARYHC_ID,DATE_ACQ,ECG_DATA_SEC,SCP_ORIGINAL_FILE,MEDIAN_USED)>

<!ELEMENT ECG_REC_SEQ_ID (#PCDATA)><!ELEMENT DATE_ACQ (#PCDATA)><!ELEMENT ECG_DATA_SEC (#PCDATA)><!ELEMENT SCP_ORIGINAL_FILE (#PCDATA)><!ELEMENT MEDIAN_USED (#PCDATA)>……..<!ELEMENT STANDARD_MEAS (ITEM_STANDARD_MEAS)*><!ATTLIST ITEM_STANDARD_MEAS (ECG_MEAS_ID,P_DURATION,PR_INTERVAL,QRS_DURATION)><!ELEMENT P_DURATION (#PCDATA)><!ELEMENT PR_INTERVAL (#PCDATA)><!ELEMENT QRS_DURATION (#PCDATA)>……..

</XML>

PatientidPatientVitalisSexRaceHistoric Description

HealthCaracteristic

idHealthCaracteristicStatusdateOfCreationidCreatordateOfValidation

SubjectOfCareidSubjectOfCareNameFirstNameAddressDateOfBirthDateOfDeath

int_ReportReport_IDReport_Date

0,n

0,n

0,n0,n

ContactContact_IdStarting DAte & TimeReasonContact_type

Type of contact

TypeOfContactId

0,n1,1

0,1

1,1

1,1

Composite

Composite_IDelementary HC

ElementaryHC_ID

ECG_RecordECG_Rec_IDPatient_Rec_IDECG_Nbr

Ecg_Rec_SeqECG_Rec_Seq_IDDate_AcqECG_Data_SecSCP_Original_FileMedian_Used

Drugs

Drug_IDDrung_Ind

ECG_Meas

ECG_Meas_ID

0,n 0,n

0,n

0,n

0,n1,1

0,n

0,n

PhysicianPhy_IDPhy_descriptor

Departement

Dpt_IDDpt_NbrDpt_Descriptor

0,n1,n

1,n

0,n

Activity

activity_IDDate & timeReason for executionlevel of urgency

Standard_Meas

P_DurationPR_IntervalQRS_DurationQT_Dura_Interval

MD


96

3.1.2. Modèle d'Acteurs/Utilisateurs (MU) Le modèle des acteurs est la représentation par le système informatique de sa

connaissance de l’utilisateur afin d’améliorer son interaction avec lui. Dans cette optique, ce modèle des acteurs doit permettre :

D’être ouvert à d’autres modélisations ; De représenter la connaissance et le comportement de chaque utilisateur dans une

base de connaissance spécifique ; L’efficacité d'un système hypermédia tient pour une grande partie dans la pertinence et

l’exactitude du modèle des acteurs dont il dispose. Le modèle des acteurs a pour but : De tenir compte de la présence de plusieurs tâches de navigation De prendre en compte les différents objectifs de l’utilisateur dans sa démarche de

recherche d’informations De prendre en compte l’évolution des besoins des acteurs en matière d’aide à la

prise de décision De prendre en compte le niveau d’expertise de l’utilisateur.

Ce modèle fournit en fin de compte les outils nécessaires pour distinguer les différents

acteurs susceptibles d’interagir avec l’application, et permettre à celle-ci de s’adapter à leurs spécificités.

Au vue des objectifs attendus du MU, il ressort très clairement que le fondement de ce modèle est le profil utilisateur et par conséquent de la méthode HANS. Un profil utilisateur est constitué d'un ensemble d'attributs qui pointent sur les parties (tables, listes) du profil ou sur leurs valeurs. Nous proposons de regrouper l'ensemble des attributs associés à chaque objet ou partie du profil utilisateur (cf. figure 5.3) sous une formalisation vectorielle décrivant une classification des constituants de profil utilisateur :

U = <U1, U2, U3, U4, U5> ou Ui représente la ième classe du profil utilisateur. La

première classe regroupe les informations concernant les habitudes et les goûts de l'utilisateur. La seconde résume les tâches d'activité de l'utilisateur. La troisième nous informe sur toutes les connaissances qu'a l'utilisateur à propos du système, des concepts, etc. La quatrième classe récapitule les expériences de l'utilisateur face au système et enfin la cinquième classe concerne l'historique des interactions de l'utilisateur. Nous détaillons chacune de ces classes ci-après.

1. Habitudes et goûts :

Dans la mesure où nous nous positionnons dans le cas d'une modélisation implicite à

long terme (chapitre 2 §6.3.2.2) et que seule la pratique des utilisateurs eux-mêmes amène à des choix motivés, nous préconisons que les connaissances sur les goûts et préférences de l'utilisateur soient construites au fur et à mesure de l'interaction en fonction des enregistrements des modifications personnelles effectuées (choix de couleur, de positions des éléments de l'interface, de l'environnement de travail, du type de présentation des données) et présentés par les valeurs des attributs de la classe :

U1 = <Modif-options, Choix-persos> où


97

U1.1 appartient à l'ensemble des modifications d'options qui représente un pointeur sur la liste des choix sélectionnés.

U1.2 représente le pointeur sur la liste des choix effectués suite à des commandes proposées par le système.

2. Tâches :

Les informations concernant la tâche de l'utilisateur sont représentées par le vecteur U2 composé des attributs :

U2 = <Liste_tâches, But_à_atteindre> où U2.1 appartient à la liste des tâches que l'utilisateur effectue dans son activité. Cet

attribut est extrait automatiquement du profil de groupe auquel l'utilisateur appartient. Il est évolutif avec l'évolution professionnelle de l'utilisateur.

U2.2 représente la liste d'informations spécifiques que l'utilisateur souhaite consulter.

3. Connaissances : Dans le chapitre précédent §3.2.2, nous avons décrit l'étape de définition de stéréotypes

ou encore de groupes d'acteurs concernés par domaine (construction du MU). Cette étape va permettre d'éviter les redondances et de déterminer implicitement les connaissances qu'a l'utilisateur de son domaine. Chaque stéréotype contient l'ensemble des concepts et contextes navigationnels qui lui sont nécessaires. Dans notre étude, nous avons défini quatre stéréotypes, à savoir les cardiologues, les médecins généralistes, les infirmieres et les secrétaires médicales. A chacun de ces stéréotypes, nous avons associé les concepts du MD utiles à sa tâche ou à une prise de décision. Par exemple, le groupe d'acteurs "secrétaires médicales" consultera uniquement les informations administratives des patients, par contre le groupe d'acteurs "cardiologues" ne sera pas limité dans sa consultation de données médicales.

Comme nous l'avons mentionné, le profil utilisateur hérite du profil du stéréotype (le groupe auquel il appartient). Afin d'éviter la rigidité, ces connaissances ne seront pas figées mais seront enrichies par des connaissances personnelles sur les concepts du MD (concepts régulièrement consultés, ou au contraire faiblement visités, etc.) qui seront détectées à la suite des différentes interactions. Par ailleurs, le système disposera, au travers des contextes navigationnels du stéréotype, de l'ensemble des liens génériques (chapitre 3 §4.2.1) associés au profil de chaque utilisateur. Ces éléments sont présentés par les attributs du vecteur U3 :

U3 = <Stéréotype, Entrées_sur_concepts, Liste_liens>

4. Expériences :

Un autre type de connaissance qui apparaît dans le profil utilisateur est celui récapitulant les expériences de l'utilisateur face au système et à son utilisation, son expérience de l'hyperespace. Ceci permettra au système de savoir si l'utilisateur est novice, débutant, moyen ou expert en se basant sur la fréquence d'utilisation et des interactions effectuées dans le but de convenir des règles d'adaptativité à utiliser. Ces expériences se retrouvent à travers les valeurs des pointeurs des attributs du vecteur U4 :

U4 = <Objet, Fréquence_utilisation, Niveau> où :


98

U4.1 ∈ {système, commande, hyperespace} U4.2 ∈ {rare, normal, souvent} U4.3 ∈ {novice, moyen, expert}

5. Historiques : Il est important de noter que le profil utilisateur est évolutif, et que toute interaction est

susceptible de le modifier. C'est ainsi que chaque profil contient aussi des historiques regroupant les enregistrements des actions effectuées par l'utilisateur, et notamment le dernier nœud visité, le/les nœuds les plus visités dans un contexte, et la dernière session de navigation. Ces enregistrements sont représentés par les attributs et pointeurs du vecteur U5 :

U5 = <Date_dernière_session, Dernière hyperdonnée visitée, Hyperdonnées+visitées, commandes_effectuées, Historiques_liens, Dernière_session>

Figure 5.3 : Modèle du profil utilisateur

Le fait d'utiliser des historiques pour construire de façon incrémentale le profil de

l'utilisateur, permettra d'effectuer les différentes adaptations mentionnées dans le chapitre 3.

L’enregistrement et la récupération de la dernière session de navigation peuvent techniquement être réalisés en se basant sur le mode d’hibernation de Windows. En déchargeant la partie de la mémoire dédiée à l’application (système hypermédia) dans un fichier (exemple "hiberfile.sys"), il est possible de récupérer ces informations lors de la prochaine navigation de cet utilisateur au sein du système hypermédia. Cette partie de mémoire est composée des différents objets de l’application activés et observés par le système

ConnaissancesStéréotype : cardiologueEntrées_sur_concepts : <informations supplémentaires et commandes concernant des concepts> exple : (QT_Duration cmd_affichage_constant)Liste_liens : <la liste des liens génériques associés au profil>

ExpériencesObjet_concerné : <système, commande,

hyperespace>Fréquence_utilisationNiveau : <novice, moyen, *>

Habitudes et goûtsModif-options : <liste des choix sélectionnés ou modifiés > exple : (colorframe1 vert, *)Choix-persos : <liste des choix suite à des commandes proposées> exple : (choix-presentation donnée_QT XSL_tableau)

HistoriquesDate_dernière_sessionDerniere hyperdonnée visitéHyperdonnées+visitées : < la liste des hyperdonnées les plus visitées et la fréquence de leur consultation>Commandes_effectuées : <la liste par ordre chronologique des commandes effectuées>Historiques_liens : < la liste des liens visités >Dernière_session : < l’ensemble des composants présents à la fin de chaque session >

TâchesListe_tâchesValeurBut_à_atteindre : <liste d’informations spécifiques à consulter>

Profil Utilisateur


99

d’espionnage dont nous avons définis les fonctions dans le chapitre 3 et dont nous décrivons le fonctionnement ci-après.

La mise en place du MU s'accompagne d'un composant que nous nommons

"Gestionnaire de connexions et de profils" (Figure 5.4). Ce composant, comme son nom l'indique, identifiera les différents utilisateurs, récupérera, et mettra à jour leur profil.

Figure 5.4 : Résultat de l'étape 3. Lors de la consultation d’un dossier d’étude, le système remonte en mémoire les

informations contenues dans ce dossier relatives aux contextes navigationnels et mettra en sur-brillance les contextes navigationnels pouvant être suivis, afin de proposer à l’utilisateur la sélection du contexte le plus adéquat à l’accomplissement de sa tâche. Mais pour cela, il faut d'abord définir et décrire les contextes dans le modèle navigationnel. C'est ce que nous allons proposer dans le paragraphe suivant.

3.1.3. Modèle Navigationnel (MN) Une fois le MU défini, nous avons procédé, avec l'aide des experts du domaine

cardiologique, à l'établissement de la liste des activités et des tâches effectuées par chaque groupe d'utilisateurs afin de faire ressortir l'ensemble des données et des concepts utiles à l'accomplissement de chaque activité et de chaque tâche.

Chaque donnée de chaque ensemble est transformée en hyperdonnées. L'ensemble des hyperdonnées utiles pour chaque activité de chaque groupe d'utilisateurs constitue un contexte navigationnel. La transformation des données en hyperdonnées se fait par l'ajout d'attributs tel que l'ancre et la liste des contextes auxquels elles appartiennent.

Comme nous l'avons précisé au chapitre 3 §5, les contextes navigationnels sont

constitués de : listes d’hyperdonnées (par identifiant) listes des contextes de navigations liés (intra et inter) un ou plusieurs points d'entrées d’une liste des éléments visibles pour les contextes qui lui sont sous-jacents, et

avec lesquels il existe un lien. Nous avons précisé aussi que les associations sémantiques du MD sont transformées lors

de la conception en liens navigationnels génériques. Ces liens traduisent des liens structuraux et de hiérarchisations.

Pour offrir une navigation pertinente à l’utilisateur, nous établissons pas la suite les autres liens génériques entre les hyperdonnées. Rappelons que ces liens sont exprimés au niveau des concepts (et non des instances), avec l'aide des experts du domaine qui matérialisent ainsi leur savoir-faire et leur expérience dans leur activité de recherche, de consultation, et de parcours de bases d’information en vue d’une prise de décision.

Gestionnaire de connexions & de

profils M U


100

En poursuivant l'exemple donné figure 5.2 (MD), nous donnons ci-après la transformée de la donnée "ECG_REQ_SEQ" correspondant à la séquence d'enregistrement de l'électrocardiogramme, et la création d'une hyperdonnée transformée d'un attribut (QT_duration) de l'objet "Standards_Meas" faisant partie du contexte associé à la tâche d'un cardiologue, comme nous l'avons défini dans le chapitre 3. En effet, comme nous l'avons précisé précédemment, un cardiologue a besoin pour formuler un diagnostic, d'accéder au signal ECG et aux paramètres issus de l'analyse automatisée et leur évolution.

Un autre scénario de prise de décision peut être illustré concernant la tâche de

consultation en urgence. L'utilisateur aura besoin d'informations telles que les données cliniques, les antécédents, les rapports d’interprétation des examens effectués à chaque contact avec des services de soins, et les traitements en cours du patient. Le contexte navigationnel correspondant à la consultation en urgence sera constitué des hyperdonnées transformées de ces informations. Nous illustrons ci-après deux hyperdonnées, à savoir la transformée de l'entité "Contact" et de l'entité "Int-Report" correspondant aux rapports d'interprétation des examens effectués.

Les liens sont définis par leur identifiant, leur label, leur type, l'hyperdonnée source, l'hyperdonnée destination, et la date de création. La détermination des différents attributs de navigation de chaque hyperdonnée se fait grâce aux caractéristiques des contextes et par l'interrogation de la base des liens génériques qui nous renseigne sur l'ensemble des hyperdonnées destination.

Pour récapituler, le MN est constitué de l'ensemble des contextes navigationnels que nous avons définis, des hyperdonnées, et des liens génériques établis entre elles.

Hyperdonnée_Ecg_Rec_Seq

ECG_Rec_Seq_ID : integer Date_Acq : date ECG_Data_Sec : string SCP_Original_File : string Median_Used : string Listcontext : {Id_cardiologuecntxt, *} To_in_report : anchor (refer to) To_QT_duration : anchor-1 (release from) To_Contact : anchor (associated to) …

Hyperdonnée_QT_duration

QT_duration_ID : integer

Listcontext : {Id_cardiologuecntxt,*} To_Ecg_Rec_Seq : anchor-1 (release from)…

Hyperdonnées_Contact

Contact_Id : integer Starting Date & Time : string Reason : string Contact_type : string

Listcontext : {Id_cardiologuecntxt, Id_généralistcntxt, *} To_Healthcaracteristics : anchor (associated to) …

Hyperdonnée_int_Report

Report_ID : integerReport_Date : date

Listcontext : {Id_cardiologuecntxt, Id_généralistcntxt, *} To_ Healthcaracteristics : anchor -1 (refer to)


101

Techniquement, ces liens sont traduits en utilisant les standards associés à XML que nous avons définis dans le chapitre 2.

De même que pour le MU, nous définissons un composant "Gestionnaire des liens et

des contextes navigationnels" permettant d'interpréter les différentes requêtes concernant aussi bien les liens que les contextes navigationnels ainsi que la mise à jour du MN (cf. Figure 5.5).

Figure 5.5 : Résultat de l'étape 4.

Une fois ces modèles conceptuels élaborés et les différents sous-systèmes de gestion

associés établis, nous pouvons les exploiter au niveau application que nous allons détailler ci-après.

3.2. Niveau application

3.2.1. Modèle de Données Structurées (MDS) Comme nous l’avons précisé dans le chapitre précédent, ce modèle découle des trois

modèles élaborés au niveau conceptuel, à savoir le MD, le MU et le MN. Le modèle de données structurées (MDS) est généré automatiquement en fonction de la tâche et du profil de l’utilisateur connecté. Le MDS est constitué de l’ensemble des objets visibles par l’utilisateur, pour un patient donné, dans un contexte donné. Nous rappelons que ce modèle est construit suite à un mécanisme de filtrage consistant en la récupération des données brutes du patient utiles à la consultation et à la prise de décision. En se basant sur le groupe d’appartenance de l’utilisateur, nous extrayons les contextes navigationnels auxquels l’utilisateur est rattaché. Ceci nous permet de faire ressortir les différents éléments constituant le fichier XML. Parallèlement, nous vérifions le contenu de la base et la conformité du fichier XML par rapport à la DTD. Ce fichier XML constitue donc le MDS.

Comme nous l'avons précisé (chapitre 4 §3.3.1), le MDS résulte de l'union de

l'ensemble des requêtes associées à chacune des étapes présentées dans le paragraphe précédent et répondant à l'attente de l'utilisateur dans un processus donné concernant un patient donné. Chaque requête est gérée par le gestionnaire de la base de données correspondant au modèle concerné.

Nous reprenons les mêmes exemples présentés précédemment, pour illustrer la génération du MDS pour une session de consultation associé à un patient donné. Pour cela le processus se résume à : Rf = Ra ∪ Rn ∪ Rd où : Rf : est le résultat de l'union des requêtes qui permettra la génération du MDS ; Ra : représente la requête associée à la base du MU. Typiquement cette requête va gérer la

connexion et le profil de l'utilisateur, ce qui se traduit par une interrogation de la base des profils, la vérification de l'identité de l'utilisateur et le chargement de son profil.

Gestionnaire des liens & des contextes navigationnels

MN


102

L’utilisateur dans notre exemple appartient au groupe de médecins généralistes. Un médecin a accès à diverses données concernant le patient. Les données administratives, telles que nom, adresse… L’accès à ces données est en fait hérité de profils plus restreints, typiquement le profil des secrétaires. Ces données sont l'historique du patient, les contacts qu'il a effectués, ses antécédents, ses données cliniques, ou encore son traitement actuel. Les accès aux dossiers médicaux et aux rapports d’interprétation restent propres à cet utilisateur, le reste étant hérité de profils plus restreints, typiquement, celui des infirmières. Rn : représente la requête associée à la base du MN. Cette requête ne peut s'exécuter sans une

réponse de la Ra. En effet, cette dernière requête indique le profil de groupe auquel appartient l'utilisateur. Ceci permet au gestionnaire des liens et des contextes navigationnels d'interroger la base du MN.

L'utilisateur faisant partie d'un groupe de médecins généralistes, les contextes navigationnels sont composés des hyperdonnées représentant principalement les données cliniques du patient, les différentes consultations précédentes indiquées par la liste des contacts, de la liste des examens qu'il a subi et des différents rapports d'interprétation Le gestionnaire interrogera la base du MN afin de récupérer les différents liens génériques (tel que le lien entre un contact et les examens effectués durant ce contact ou encore un contact et les rapports d'interprétation des examens) et spécifiques associés à cet utilisateur. Rd : représente la requête associée à la base du MD. Cette requête interroge la base des données et récupère l'ensemble des données existant dans le dossier patient en fonction du résultat de la requête Rn. Nous présentons ci-après le résultat de notre requête Rf correspondant aux deux scénarios de navigation : Le premier concernant le contexte de navigation d'urgence d'un généraliste intéressé entre

autres par les données administratives, le contact, le rapport d'interprétation, et le traitement du patient (cf. figure 5.6a).

Le second concerne le contexte de navigation d'un cardiologue intéressé essentiellement par les informations concernant un signal ECG et les mesures standards associées (cf. figure 5.6b).

<Patient>

<IdPatientVitalis> 2 <\IdPatientVitalis> <name> Maffi <\ name> <FirstName> Mirella <\FirstName> <adresse> Valeur <\adresse>

….. <\Patient> <Contact>

<contact_id> N3 <\contact_id> <startingdate&time> 1996-12-02 <\startingdate&time> < reason> Referral Indication < \reason> <contact_type> control <\contact_type>

<\Contact> <int_Report>

<Report_id> N3-1 <\Report_id> <Report_ date> 1996-12-02 <\Report_ date> <Report_ description> Valeur <\Report_ description>

<\int_Report> <Drugs>

<Drug_id> 4 <\Drug_id>


103

<Drug_ind> unspecified antiarrythmic drug <\Drug_ind> <\Drugs> <Drugs>

<Drug_id> 6 <\Drug_id> <Drug_ind> Quinidine <\Drug_ind>

<\Drugs>

Figure 5.6 a : Illustration du MDS associé au contexte de navigation d'un généraliste

<Patient>

<IdPatientVitalis> 2 <\IdPatientVitalis> <name> Valeur <\ name> <FirstName> Eugène <\FirstName> <adresse> Valeur <\adresse>

….. <\Patient> … <ECG_RECORD_SEQ

xlink : href= « Ecg\patient-ID_Date.ecg » xlink : label=« ECG patient-ID_Date » xlink : role = « http://www.ecg.com/ecg/ecgrole » xlink : title= « electrocardiogram »/> <ECG_REC_SEQ_ID> Valeur </ECG_REC_SEQ_ID> <DATE_ACQ> Valeur </DATE_ACQ> <ECG_DATA_SEC> Valeur </ECG_DATA_SEC> <SCP_ORIGINAL_FILE>Valeur </SCP_ORIGINAL_FILE> <MEDIAN_USED> Valeur </MEDIAN_USED>

</ ECG_RECORD_SEQ> <QT_DURATION xlink : label= « Duration_patient _ID_Date »/> <Calcul xlink : from= « ECG patient-ID_Date » xlink : to= « Duration_ECG patient-ID_Date » xlink : show= « new » xlink : actuate= « onLoad » xlink :title= « Calculating an ECG duration »/>

Figure 5.6 b : Illustration du MDS associé au contexte de navigation d'un cardiologue

Techniquement, les différents liens sont décrits au moyen du langage Xlink [W3C 00a].

Un lien XLink est une relation explicite entre des ressources et des portions de ressources.

Six éléments permettent de décrire un lien Xlink. Deux déterminent la source et la destination du lien. Les autres éléments décrivent les caractéristiques du lien tel que le titre (xlink :title), le type (xlink :type), le type d’actualisation sur demande, sur chargement etc. (xlink :actuate). L’intérêt d’utiliser Xlink dans le déroulement de notre méthode est qu’il permet aux documents XML de :

Contenir des relations de liens avec plus de 2 ressources distinctes. Définir des liens qui résident dans un emplacement différent des ressources

liées.


104

Notons que l’adressage des extrémités des liens navigationnels au sein de la structure interne du document XML se fait par l’intermédiaire du langage XPointer qui fournit les références pour ces éléments même si ceux-ci ne possèdent pas d’attributs d’identification spécifique [W3C 00b].

3.2.2. Modèle de Présentation

Le modèle de présentation est constitué de deux grandes parties. D’un côté, nous avons l'interface implémentée à l'aide d’applet java qui permet la connexion à l’application, ainsi que l’affichage d’informations partielles et le suivi de liens, et d’un autre côté, l'affichage dynamique au cours de l'interaction H/M des informations utiles à l'utilisateur concernant le patient.

La première partie regroupe les fenêtres de l'étape de connexion et d'affichage des

éléments statiques de l'interface. Nous détaillerons cette partie dans le paragraphe §4 de ce chapitre.

La deuxième partie, comme nous l'avons précisé précédemment, consiste à étudier les

différentes façons de représenter les données pouvant exister dans le dossier d’un patient. Avec les experts du domaine, nous avons, suivant le type de données, sélectionné différents affichages pertinents et décrit leur présentation selon la norme XML dans les feuilles de style XSL. Par exemple la donnée "QT_duration" peut se représenter soit sous forme de tableau, soit sous forme de texte. Deux fichiers XSL seront donc associés à ce type de données, et l’utilisateur pourra choisir suivant ses préférences l’une ou l’autre des représentations. Ce choix sera enregistré dans la base de données profils en associant chaque type de données à un type de représentation pour un utilisateur donné.

La sélection d’un type d'une donnée provoque l’affichage de cette donnée dans la partie

centrale de l'interface en HTML. Le processus s’effectue en réalité à l’aide de la feuille XSL propre à l’utilisateur, et propre aux données à afficher. Un processeur XSLT transforme le fichier XML suivant cette feuille XSL en sélectionnant les données du patient à afficher et en reformatant ces dernières afin de les représenter sous forme HTML. < ?XML Version= ’1.0’ ?> <xsl :stylesheet xmlns :xsl=’http://www.w3.org/TR/WD-xsl’ xmlns :fo=’http://www.w3.org/TR/WD-xsl/Format’ version=’1.0’> <xsl :template match=’/’> …. <fo :namespace select=’QT_Duration’> …. <fo :table border=’3’ align=’center’> <TR> <TD style=’color :0000’>QT Interval Duration</TD> <TD align=’right’><xsl.value-of select=’QT_Interval_Duration’/></TD> </TR> </fo :table> </fo :namespace> </xsl :template> </xsl :stylesheet>

Figure 5.7 : Feuille XSL associée à la donnée QT_duration (représentation tabulaire)


105

Un autre choix peut être pris en compte pour la constitution de feuilles XSL. Il se

résume en une seule feuille de style par mode de présentation, paramétrée suivant le type d’objet à représenter. Dans ce cas il faut redéfinir la DTD de la façon suivante :

<!ELEMENT HemaObjects (TypedObjects+)> <!ELEMENT TypedObjects (ObjectType, Object+)> <!ELEMENT ObjectType (#PCDATA)> <!ELEMENT Object (Attribute+) > <!ELEMENT Attribute (Name, Type, (Data|Path))> <!ELEMENT Name (#PCDATA)> <!ELEMENT Type (#PCDATA)> <!ELEMENT Data (#PCDATA)> <!ELEMENT Path (#PCDATA)>

Un exemple du sous-fichier XML obtenu de cette DTD sera :

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE HemaObjects SYSTEM "..\DTD\HemaObjects.dtd"> <HemaObjects> <TypedObjects> <ObjectType>ADMINISTRATIVE</ObjectType> <Object> <Attribute>

<Name>numéropatient</Name> <Type>INT</Type> <Data>2</Data> </Attribute> <Attribute> <Name>Name</Name> <Type>TEXT</Type> <Data>Jean-Philippe</Data>

</Attribute> <Attribute>

<Name>Firstname</Name> <Type>TEXT</Type> <Data>Couderc</Data>


<Name>Address</Name> <Type>TEXT</Type> <Data>17, rue Blanche 38000 Grenoble</Data>


<Name>Date of birth</Name> <Type>DATE</Type> <Data>1976-04-12</Data>

</Attribute> </Object>

</TypedObjects> </HemaObjects>


106

La feuille de style sera pour l'affichage de données sous forme d’un tableau la suivant :

<?xml version="1.0" encoding="ISO-8859-1"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > <xsl:template match='/'> <HTML> <HEAD>

<TITLE><xsl:value-of select="$TITLE"/></TITLE> </HEAD> <BODY LINK='000000' ALINK='000000' VLINK='000000' Fontcolor='000000' bgcolor="#006E8C"> <center>

<font size='+3'><xsl:value-of select="$SUBTITLE"/></font><br/><br/> </center> <TABLE BORDER='3' align='center' bgcolor="yellow">

<xsl:for-each select="HemaObjects/TypedObjects[ObjectType=$TYPE]/Object"> <xsl:if test="Attribute[Name='n°' and Data=$ID]"> <xsl:for-each select="Attribute"> <xsl:choose> <xsl:when test="Data"> <TR><TD style='color:000000' align='center'><xsl:value-of select='Name'/></TD><TD align='center'><xsl:value-of select='Data'/></TD></TR> </xsl:when> <xsl:otherwise> <TR><TD style='color:000000' align='center'><xsl:value-of select='Name'/></TD><TD align='center'><xsl:value-of select='Path'/></TD></TR> </xsl:otherwise> </xsl:choose> </xsl:for-each> </xsl:if> </xsl:for-each>

</TABLE> </BODY> </HTML> </xsl:template> </xsl:stylesheet>

Si nous analysons cette feuille, nous remarquons, dans un premier temps, que nous

intégrons le code permettant la représentation sous forme de tableau à partir de l'élément racine.

Ensuite, pour chaque donnée correspondant au critère passé en paramètre au processeur XSLT (for-each select=’HemaObjects/TypedObjects[ObjectType=$TYPE]/Object, où $Type est le paramètre concernant le type d’objet que nous souhaitons afficher), nous vérifions s’il s’agit bien de l’objet à afficher (paramètre $ID), et si oui, nous l’affichons.

Dans le cas de la représentation de la donnée "QT_duration", cette feuille se verra tout simplement affecter "QT_duration" au paramètre $TYPE, et l’identifiant du "QT_duration" que nous voulons associer à $ID, et nous obtenons ainsi l’affichage sous forme de tableau.

Cette seconde proposition permet de réaliser une application plus générique, et donc

plus simple à maintenir. Par contre la première est complète et plus précise, même si elle exige de maintenir et de gérer plusieurs feuilles de style par type de données.

Le domaine de la cardiologie nécessite assez souvent des représentations graphiques

permettant des comparaisons entre paramètres et plus précisément leur évolution. Pour cela,


107

nous enrichissons notre modèle de présentation grâce à la norme SVG [JACK 02] qui est un langage de description de graphiques en XML. SVG permet trois types d'objets graphiques : les formes vectorielles (lignes brisées, courbes, etc.), les images et le texte. Les objets graphiques peuvent être groupés, transformés, composés dans d'autres éléments et des styles peuvent leur être appliqués. Dans notre cas, les objets graphiques sont enrichis par des attributs de style délimités par les balises <SVG>.

Par ailleurs, il est fréquent dans les modèles de données que certains types de données

nécessitent des programmes externes pour leur visualisation. Dans ce cas, lors de la déclaration de l’élément et de ses attributs, il faut indiquer au parseur la nécessité d’un traitement spécial. Ceci se fait au moyen du mot clé NDATA, qui est suivi du nom d’une notation préalablement définie. Une "Notation" permet d’associer au type d’objet en question, l’application capable de le traiter. La syntaxe d’une telle inclusion et la suivante :

<!ENTITY nom_entité SYSTEM "../chemin entité" NDATA type_ de_ notation> <!NOTATION type_de_notation SYSTEM "chemin_relatif_application"> A titre d’exemple d'examens nécessitant une application spéciale pour la visualisation,

citons l'électrocardiogramme. Il est visualisé grâce à l’application externe EcgviewPro qui permet l'affichage des signaux et de leurs interprétations contenus dans un fichier au format du protocole SCP-ECG. Dans ce cas précis la déclaration sera la suivante :

<!ENTITY ECG_RECORD_SEQ SYSTEM "…/fichier scp-ecg” NDATA ECG> <!NOTATION ECG SYSTEM "../applications/EcgviewPro.exe">

Le modèle de présentation est accompagné d'un sous-système de gestion de la

présentation permettant de faire l'association entre les données sélectionnées par l'utilisateur et/ou faisant partie du MDS et leur mode de présentation défini dans le MP.


108

4. IMPLÉMENTATION

4.1. Architecture générale

Figure 5.8 : Architecture générale du système

L’application de la méthode HANS se concrétise par la mise en place d'un système tel que

celui représenté en figure 5.8. Le système proposé repose sur les points suivants :

Toute interaction de l’utilisateur est analysée par le module analyseur/rédacteur de requêtes qui aiguillera vers les différents modules (Gestionnaire de connexion et de profils, Gestionnaire des liens et des contextes navigationnels, et le Module de chargement) concernés par l’interaction. Parallèlement, cette interaction est captée par le module d’espionnage qui, en fonction de la base des règles, enregistrera l'action et/ou proposera l’adaptation à effectuer. Le résultat de l’union des requêtes envoyées vers les différents modules est acheminé

vers le constructeur MDS afin d’établir le fichier XML et vérifier sa conformité. Le module de présentation quant à lui, interrogera la base issue du MP afin d’attribuer

(récupérer) les différents modes de présentations (feuilles XSL) aux types de données présentes dans le fichier XML. Le transformateur XML/HTML récupère le résultat des deux derniers modules et

génère le fichier HTML correspondant qui sera affiché à l’écran.

Base MA

Base MN

Module d’analyse / de rédaction de requêtes

Module d’analyse / de rédaction de requêtes

Module d’espionnageModule d’espionnage

Base MD

Module de chargement

Gestionnaire des liens& des contextes navigationnels

Gestionnaire de connexions & de

profils

Base MD

Base MD

Constructeur MDS

Module de présentation

Base deRègles

Base MP

TransformateurXML / HTML

TransformateurXML / HTML …


109

4.2. Génération d'interface H/M et de système hypermédia adaptatifs

La convivialité et l'ergonomie de l'interface H/M est un facteur déterminant dans la motivation et l'efficacité des utilisateurs pour se servir d'un outil informatique dans le cadre de leurs activités. L'interface d'un système hypermédia doit donc être flexible, personnalisable, et surtout indépendante du support physique qui va la supporter. Pour la modélisation de l'interface qui permettra la connexion et l'affichage des éléments statiques, nous proposons deux façons de faire : La première consiste à afficher les différents fichiers HTML avec un browser auquel nous

incorporons d’autres types d’objets plus évolués, tels les Applets Java, les Scripts,...Le comportement des objets est géré (clic sur un lien, action par défaut, traitement lors de l’appui sur un bouton,...), ce qui permet d'introduire n’importe quel type d’objet à condition d'installer les applications permettant leurs gestions (ex. des plug-ins). L’affichage dans l’applet java consiste en un arbre contenant les composants du dossier patient en fonction du profil de l'utilisateur et du contenu réel du dossier. La deuxième consiste à utiliser le langage UIML. Comme il a été cité dans le chapitre 2

§5.2.3, UIML est un standard de définition d'éléments structurés composant une interface utilisateur. Il suffit donc de définir une bibliothèque de DTD définissant les balises, leurs attributs ainsi que leur agencement. Le squelette des documents UIML correspondants sont composés de quatre grandes balises (cf. chapitre 2 §5.2.3) :

l'entête donnant les méta-données relatives au document, la description de l’interface utilisateur, sa structure, son contenu, son style et son

comportement en fonction du type d'utilisateur, la description des liens entre chaque propriété et événement utilisés dans le

document UIML et le UI toolkit et/ou l’application logique, et la description des éléments permettant la réutilisation d’un fragment UIML.

L'exécution de l'interface se fait par la suite par un processus de conversion (le Rendering) obtenu soit par compilation d'un programme écrit dans un langage traditionnel (traduit du UIML en, par exemple, Java), soit par interprétation (lecture du fichier UIML et affichage de l’interface sur l’écran par le programme client, à la manière d’un navigateur web affichant du HTML). L’application permettant de récupérer les informations concernant l'utilisateur va générer dynamiquement les documents UIML correspondants, la partie statique de l’interface étant définie préalablement comme un patron UIML.

En résumé, UIML est adapté pour des applications qui nécessitent la génération

dynamique d’interfaces personnalisées. Basé sur XML, il réunit tous les meilleurs ingrédients pour la génération d’interfaces à la volée. Par ailleurs, UIML peut très bien être utilisé par des non programmeurs désirant créer des interfaces en utilisant des IDE (Integrated Development Environment), c'est à dire des ateliers graphiques de conception d’interfaces faciles à utiliser. Cependant, si on la compare à la première approche décrite ci-dessus, son principal inconvénient réside dans la complexité actuelle de son implémentation.


110

4.3. Navigation Afin de faciliter l’établissement du MN, nous avons muni le système d’un composant

java nous permettant de créer, avec l’aide des experts, les différents liens génériques en accord avec les règles établies chapitre 3. Ce composant consiste à sélectionner l’hyperdonnée source à partir de la liste des hyperdonnées prédéfinies dans le MN et de la même manière à sélectionner l’hyperdonnée destination, puis à entrer les caractéristiques du lien à créer (le nom, le type, la date de création, et l'attribut de chaque hyperdonnée sur lequel se fait la jointure).

Nous présentons ci-après une illustration de l'utilisation du composant pour la création du lien générique existant entre l’hyperdonnée "Contact" et un examen "ECG_Req_Seq" (cf. figure 5.9).

Figure 5.9 : Exemple de création d'un lien générique.

De la même manière, nous avons conçu un composant java pour la création de liens

spécifiques. Comme nous l'avons précisé au chapitre 3, ces liens portant sur des instances, la sélection ne se limite pas à la classe hyperdonnée mais à la sélection de l'une des instances de la classe hyperdonnée source et pareillement de l'une des instances de la classe hyperdonnée destination. La figure 5.10 illustre la création d'un lien spécifique, où nous remarquons la sélection de l'instance (destination du lien à créer) ayant l'identifiant 5 de la classe hyperdonnée "ECG_REQ_SEQ".

Generic Links Addition for profile supuser


111

Figure 5.10 : Exemple de création d'un lien spécifique

La transformation du MDS et du MP associés aux deux cas considérés et présentés

précédemment (session de cardiologues et session de généralistes pour un même patient), aboutit à la génération des deux sessions d'IHM de HEMA illustrées ci-après. Nous présenterons plus en détail les figures correspondant à la navigation de chacun de ces deux profils en annexe.

Figure 5.11 - a : l'instance de HEMA pour la session de consultation d'un cardiologue


112

Figure 5.11 - b : l'instance de HEMA pour la session de consultation d'un généraliste

4.4. Génération automatique de liens Nous avons mis en place notre système d'espionnage et avons testé notre moteur

d'adaptativité et la base de règles notamment pour le traitement de l'adaptativité pour les liens spécifiques. Suite à une observation des interactions de l'utilisateur, le système a exécuté les règles d'adaptativité nécessaires à l'ajout de liens entre deux classes (lien générique) et entre deux instances (lien spécifique) ; et à la proposition de généralisation d'un lien spécifique ayant été parcouru à chaque session par le même utilisateur. Nous présentons dans la figure ci-après la proposition d'un ajout d'un lien pour le cardiologue entre un enregistrement d'un ECG, à savoir l'hyperdonnée "ECG_REC_SEQ", et les données du contact dans l'hyperdonnée "CONTACT". Nous présentons en annexe les figures illustrant l'ajout de lien en cas d'acceptation par l'utilisateur.


113

Figure 5.12 : Proposition d'ajout de lien spécifique entre deux entités

4.5. Outils externes Comme nous l'avons mentionné précédemment, le domaine cardiologique nécessite

souvent la présentation de données graphiques par des outils externes spécialisés à définir et à configurer dans les fichiers XML et XSL. La génération de l'IHM associé à la navigation entre les données ciblées par l'utilisateur, nous a permis de vérifier la bonne présentation de la donnée conformément à la configuration et aux préférences de l'utilisateur. Nous présentons en figure 5.13 l'affichage du signal électrogardiographique lors de la consultation d'un dossier médical par un cardiologue.


114

Figure 5.13 : Appel de l'outil de visualisation de signaux électrocardiographiques ECGViewPro

5. CONCLUSION

Nous avons présenté dans ce chapitre les différentes étapes que nous avons suivies lors de l'implémentation de notre méthode HANS dans le domaine cardiologique. Nous mettons en lumière leur faisabilité et l'aboutissement des objectifs attendus. En effet, nous avons remarqué que la préparation de l'ensemble de contextes utiles à chaque tâche et processus de décision réduit de manière significative le temps de recherche du fait de la génération de l'interface à partir du mécanisme de filtrage pour le MDS et le MP en fonction des préférences de l'utilisateur permettant l'accès et la présentation personnalisée aux hyperdonnées (informations) qui lui sont pertinentes.

Par ailleurs, l'association de liens (génériques et spécifiques) à des profils permet de ne mettre en évidence que les informations utiles.

Enfin, l'ensemble de règles associé au moteur d'adaptativité permet de suivre la pratique et le savoir-faire des utilisateurs et d'adapter le système hypermédia à cette pratique.

Documents

Modélisation et méthode de conception de systèmes de …docinsa.insa-lyon.fr › these › 2002 › ghedira › 11_chapitre5.pdf · 2005-01-20 · Méthode de conception de systèmes