Serious games pour la e-santé

Moteur de dialogue dirigé par le modèle 

 Introduction 

Comme nous l’avons souligné lors du Chapitre 1 (page 9), pendant une consultation médicale, les médecins se doivent de questionner et d’encourager leurs patients à exprimer leurs préoccupations et leurs idées. En cas d’incompréhension ou d’information incomplète, le médecin doit revenir vers son patient en insistant ou en trouvant une nouvelle approche. Une fois l’information acquise, le médecin peut évaluer l’état de santé du patient et concevoir un diagnostic ainsi qu’un plan de traitement. Ceci fait, il doit expliquer à son patient ses conclusions de façon détaillée, en insistant sur les points importants. Il doit également vérifier la bonne compréhension du patient et écouter ses remarques dans le but de parvenir à une décision partagée. Les deux moments importants au cours desquels les compétences communicationnelles du médecin sont particulièrement importantes sont par conséquent la collecte d’information et la communication du diagnostic. S’ajoute à ces deux moments, l’établissement souhaité tout au long de la consultation d’un état de confiance et de collaboration entre le patient et son médecin. Le moteur de dialogue (MD) que nous décrivons ici doit donc être capable de générer un dialogue répondant aux trois fonctions suivantes de l’entrevue médicale présentées page 6 :  La collecte d’informations.  La mise en place d’une relation avec le patient.  L’enseignement thérapeutique. La Figure 7.1 illustre ces trois objectifs. Sur celle-ci, la flèche entre le patient dénoté par le rond « Patient » et le rond « Collecte information » signifie que le patient fourni des informations. Le médecin récupère ces informations comme en témoigne la flèche entre le médecin dénoté par le rond « Médecin » et le rond « Collecte information ». Cette chaine a son symétrique pour la fonction « Enseignement thérapeutique ». Toutefois, même si le sens de la chaine est du médecin vers le patient, le flot des informations n’est pas à sens unique et le contenu des enseignements sont le résultat de décisions partagées entre le patient et le médecin. Chapitre 7-Moteur de dialogue dirigé par le modèle 124 Lors des activités correspondant à ces deux fonctions, le médecin doit mettre en œuvre les compétences lui permettant d’établir une relation de confiance et de collaboration avec son patient. Cet objectif apparaît au centre du schéma. Figure 7.1 : Trois fonctions dans la consultation médicale Le moteur de dialogue donc doit couvrir ces trois fonctions. Pour répondre à la première fonction, le MD doit proposer aux joueurs un certain nombre d’actions possibles relatives à l’obtention des informations présentes dans le modèle. Il doit également stocker les informations obtenues par le joueur. Les questions à résoudre ici sont : comment organiser les données dans le programme, quelles sont les données à récupérer, etc. Pour répondre à la deuxième fonction, le MD doit être capable de catégoriser chaque action en fonction de son effet sur la relation patient-médecin, en particulier sur la façon dont le patient considère son médecin. Pour quantifier cette relation, il utilise pour cela un ensemble de caractéristiques qui sont définies au préalable par les experts du domaine. Par exemple, dans le cas d’AgileDoctor et à titre expérimental, trois caractéristiques sont utilisées : la confiance du patient envers son médecin, son respect pour lui et enfin l’influence du médecin envers son patient. Les actions sont dotées d’attributs qui font varier les valeurs de ces caractéristiques. Ainsi, les phrases de soutien, empathiques, rassurantes, ou sincères contribuent directement à la construction de la relation médecin-patient et se caractérisent visuellement par une émotion éprouvée par le patient. Le moteur doit être capable de proposer au joueur des phrases dont les caractéristiques permettent au joueur de faire évoluer aussi bien l’état mental de son patient que sa relation avec lui sur le long terme : choisir de rassurer, de soulager, ou encore faciliter l’engagement du patient dans son plan de traitement. Enfin pour répondre à la troisième fonction, le MD doit proposer plusieurs façons d’informer le patient. Par exemple donner directement le diagnostic et le plan de traitement avec ou sans explications ; proposer plusieurs plans de traitement et en discuter avec le patient, vérifier ou pas sa compréhension, etc. Comme nous l’avons analysé dans le Chapitre 5 (page 88), pour répondre à l’objectif pédagogique, le MD doit distinguer les bons choix des mauvais en proposant systématiquement plusieurs scénarios possibles. De plus les données enregistrées à la fin de chaque session de jeu doivent être accessibles pour permettre l’évaluation de la performance du joueur. Bien entendu et dans un but ludique, les bons choix ne doivent pas paraître évidents, et les parties ne doivent pas se ressembler. Globalement, le principe simplifié du moteur de dialogue que nous proposons est le suivant : Des instances du modèle MCPM qui permettent d’alimenter les actions possibles du médecin et du patient sont définies. D’autres informations nécessaires au fonctionnement du système comme des variables et des valeurs des paramètres le sont également. Le moteur utilise ces informations pour organiser les sessions de dialogues en flux de dialogues, ce qui génère le scénario de la consultation et pour proposer au final des actions possibles aux participants du dialogue. Appliqué à AgileDoctor, ce fonctionnement permet au joueur de sélectionner l’action du médecin parmi celles proposées par le MD. En fonction de ce choix, le MD sélectionne l’action du patient répondant à celle du joueur. Ce processus continue jusqu’à la fin de la consultation. Plus précisément, dans notre approche, pour chaque niveau d’une session de dialogue, une ou plusieurs actions du médecin sont définies qui sont en lien avec une ou plusieurs actions du patient. Chaque paire constitutive d’une session de dialogue est toujours lancée par l’action du médecin. Pour une action du médecin choisi, le MD est en mesure de trouver l’action la plus appropriée du patient en fonction des paramètres initiaux (profil du patient) et de la valeur des variables représentant l’état du patient. La structure du système est illustrée sur Figure 7.2. Figure 7.2: Structure du système proposé. Les sections qui suivent présentent ce système de façon détaillée en insistant particulièrement sur les actions proposées au joueur ainsi que sur le stockage des données. Des définitions supplémentaires sont introduites de manière à faire le lien avec le modèle défini lors du chapitre précédent, et nous illustrons cela avec quelques exemples de données. Nous présentons ensuite comment le système est paramétré. Enfin nous détaillons l’algorithme qui utilise tous ces éléments pour animer le moteur. 

 Compléments au MCPM

 Introduisons un certain nombre de définitions qui viennent compléter les éléments du MPCM et qui sont nécessaires pour le MD. 

 Etat d’une session (Session State) 

Une session de dialogue a un état pris dans l’ensemble { } Où représente l’état « Don’t Understand » (incompréhension), l’état « Questioning » (questionnement), l’état « Refuse » (Refus) et l’état « Normal » (normal). Voici le détail de ces états :  : Don’t understand Cet état signifie que le patient n’a pas compris ce que le médecin a dit. La session peut entrer dans cet état pour plusieurs raisons comme par exemple le fait que le patient était distrait ou encore que l’environnement était trop bruyant. La raison peut également provenir d’une absence de clarté de la phrase prononcée par le médecin ou d’un déficit de compréhension de la part du patient dû à son âge (enfant) ou à sa non maitrise de la langue (patient étranger). Enfin l’état émotionnel du patient peut également jouer sur les chances d’entrer dans cet état. Selon les raisons ayant conduit à l’entrée dans cet état, une simple répétition de l’action par le médecin peut mener à sa sortie, tout comme une reformulation plus claire ou plus insistante de la phrase.  : Questioning Cet état signifie que le patient a des doutes et a décidé de poser une question à propos de ce que le médecin vient de dire. Un niveau de confiance faible du patient peut être à l’origine d’une entrée dans cet état. Un patient dont la caractéristique agressivité est élevée a également plus de chance d’entrer dans cet état.  : Refuse Dans cet état, le patient va refuser ce que le médecin lui a demandé de faire, ou exprimer un désaccord. Par exemple, en entrant dans cet état, le patient pourra refuser de se laisser examiner. Tout comme pour l’état , un faible niveau de confiance ou une agressivité élevée augmente les chances d’entrer dans cet état. La différentiation avec l’état Q se fait selon que le patient est doté d’une caractéristique le rendant plus susceptible de poser une question au lieu de simplement refuser.  : Normal L’état normal est l’état standard du patient. Dans cet état, si la phrase du médecin est de type « Open Question » ou « Closed Question », la réponse du patient pourra contenir des informations avec un type de Phrase de catégorie « AnswerWithInfo ». Dans le cas où le médecin a utilisé une phrase de type « Require », le patient suivra les instructions du médecin ou sera d’accord avec lui en utilisant une Phrase de type « Agree ». Les informations données par le patient sont déterminées par le niveau de confiance du patient envers son médecin ainsi que par le profil du patient. Si par exemple le patient est de type bavard, il aura tendance à Chapitre 7-Moteur de dialogue dirigé par le modèle 128 exprimer plus d’informations, sauf si son niveau de confiance a baissé au cours de la consultation. Les états Q et caractérisent une situation de conflit entre le patient et le médecin. Comme le décrivent (Richard & Lussier, 2005), il existe plusieurs stratégies pour sortie de cette situation, comme par exemple insister et tenter de convaincre le patient en cas de refus, ou au contraire passer à autre chose pour y revenir plus tard. Ces différentes stratégies font partie des choix proposés au médecin, en y incluant également les choix consistant à ignorer le refus ou la question, choix qui terminent alors la session de dialogue sur un échec. 

 Transition d’états de session

 Nous l’avons vu, une session de dialogue peut changer d’état en cours de déroulement. Quand une session de dialogue quitte l’état courant pour entrer dans un autre état, on a alors une transition d’état. Les transitions possibles sont présentées dans le Table 7.1 et illustrées Figure 7.3. Si un état se note Si , on notera Si+1 l’état suivant. 

 Arbre d’information 

Comme nous l’avons dit lors du Chapitre 1 et plus récemment section 7.1 (page 123), l’un des objectifs de la consultation médicale est la collecte d’information. Les informations dont nous parlons ici sont celles qui concernent le patient du point de vue du modèle d’information présenté section 5.1. Dans cette partie nous présentons notre approche pour représenter ces informations. Les informations sont organisées sous la forme d’arbres (Figure 7.4). Les nœuds de ces arbres représentent les différentes unités d’information telles que définies par l’ontologie « profil du patient » du modèle MCSOnto. Chaque unité est indépendante et chaque nœud est relié à une seule catégorie de l’ontologie. Les arbres s’organisent en groupes qui rassemblent les arbres contenant des nœuds d’information liés. La nature de cette liaison dépend du type de l’information décrite et est utilisée par le moteur pour proposer au joueur des actions connexes au thème en cours de discussion. Au sein d’un arbre, la relation parent-enfant est utilisée pour qu’un nœud enfant détaille l’information portée par le nœud parent. La Figure 7.4 illustre un arbre contenant douze unités d’information. Le trait plein représente la relation hiérarchique alors que la ligne pointillée représente l’appartenance à une même catégorie.