An explanation-oriented inquiry dialogue game for expert collaborative recommendations

1.Introduction

As the human society has become more digitally connected, it has developed an increased appreciation for interdisciplinary collaboration [23]. Healthcare is one such domain which has a long tradition of interdisciplinary collaboration amongst different medical experts [67]. Imagine a distributed health recommendation system where different experts come together to find the best possible diagnosis for a patient. These experts could be human agents, artificial agents or a combination of human and artificial agents. The goal of the collaboration would be to integrate multiple perspectives through knowledge transfer and conflict resolution in order to recommend the best possible diagnosis. Additionally, the system should offer explanations for its recommendation in order to build trust between the users and the system [44].

As an example scenario, consider the dialogue given in Table 1 between three medical experts represented by α, β and γ. The first column of Table 1 shows the identifier for the statement while the second column indicates the expert name followed by the statement they are making. The experts are participating in a semi-structured formal discussion similar to the ones that take place in oncology [43]. They are already aware of the objectives and format of the meeting before the dialogue starts so there is no build up on the objectives of the discussion as is the case in oncology meetings. We cover this in detail in Section 3. In this example, the meeting is not about a cancer diagnosis, but rather a more general diagnosis for a patient denoted by A. This is a contrived example, aimed at illustrating the conversation flow among healthcare experts who are participating in a semi-structured discussion to collaboratively make a recommendation for a patient. The goal of this example is not to provide a comprehensive medical discussion on the patient’s diagnosis as this is not the objective of this work. Moreover, note that the dialogue only shows the knowledge and reasoning of the experts to the extent that they choose to reveal through their conversation. It does not show the complete knowledge base or the reasoning process of the expert agents (who can be human or artificial).

In this example, we assume that agent α loosely represents a clinical psychologist, agent β a general practitioner and agent γ an endocrinologist (specialist in ear, nose and throat). Agent α first presents the facts of the case and offers his own diagnosis (depression). This is challenged by agent β. α then justifies their stance which is rejected by γ. γ then proposes their own diagnosis. β asks γ to explain their diagnosis. Subsequently, both α and β accept γ’s explanation. Then α proposes some tests to which β agrees and propose an additional test. γ agrees and proposes yet another test. However, their suggestion is ignored by the other two as they propose to close the discussion. However, γ does not consent and asks the other agents to respond to their suggestion. They do respond and subsequently γ agrees to end the discussion. Throughout the discussion, the agents try to collaborate in a cooperative manner. We use this dialogue as a running example throughout the rest of the paper to illustrate our approach.

As a first step towards realising such a hybrid human-artificial multiagent system capable of such a dialogue, we propose a novel interaction protocol between experts agents (whether human or artificial). We call this protocol as Experts’ Dialogue Game (EDG). Figure 1 visualises how EDG would fit into the pipeline for building such a system. As a first step, real-life consultations among medical experts are formalised as a requirement specification. Building on this specification, EDG is defined as a dialogue game among the participants in a hybrid human-artificial multiagent system (MAS). The output of EDG is a recommendation from the system along with a sequence of explanations justifying the recommendation. These explanations can then be plugged into a system-user dialogue to justify the system’s recommendation to the user. The user in this case could be the patient himself or a physician in charge of the patient. While most of the current literature [3,17,36,65,76] focuses on explaining the working of a system to a human user through a system-user dialogue, EDG investigates how an explanation dialogue can be used within a multiagent system as part of agent reasoning.

Fig. 1.

Workflow diagram of an explainable multiagent recommendation system employing EDG.

Dialogue games are dialectical systems [22] in the tradition of informal logic [77] and are formally defined as verbal interactions between two or more players according to some pre-defined rules for the dialogue [39]. Each interaction is specified with the use of locutions which represent speech acts permitted in a given dialogue [62]. Dialogue games require that each participant maintains consistency across its statements, also called commitments, at any point in the dialogue [77]. Characteristics of these verbal interactions are typically defined in multiagent communication according to the popular typology introduced by Walton and Krabbe [77]. Dialogue games have a long tradition of being used to solve formal problems as well as to model natural language communication in real-life settings. In the first case, they have been employed to search for formal logical proofs in the tradition of Lorenzen [1] and leading to the field of dialogical logic, as well as in the prescriptive approach such as Hamblin’s system [22], to disallow logical fallacies during natural language argumentation. In the second case, they are used to study the communication dynamics in real life settings, giving rise to the descriptive approach to dialogue games [11,27,36,40,53,64]. This approach can also be used to inform computational models of interactions between agents in a multiagent system.

The goal of EDG is for the participants to collaboratively find the best recommendation through exchange of knowledge and mutual agreement. In Walton–Krabbe’s typology, this scenario fits an inquiry type of dialogue in which an initial situation is a need to have proof (i.e. in our case – to find the best recommendation), the participants’ goal is to find and verify an evidence (i.e. to consult an observation), and the goal of the dialogue is to prove or disprove a hypothesis (i.e. to argue for or against a recommendation). This is in contrast to a deliberation dialogue where the initial situation is a need for action, the participants’ goal is to influence the outcome and the goal of the dialogue is to reach a decision on the best possible action [77]. In order to generate explanations of the recommendations, we define agents’ communicative behaviour in the dialogue through explanation-based illocutionary forces which can then be traced back and retrieved in response to a query and presented to the user as an explanation of the recommendation: (1) explanation requests such as wh-explain(p) when the speaker knows that p is the case, but does not understand why it is the case; wh-justify(p) when the speaker does not agree that p is the case and asks the hearer for the justification of p; and wh-clarify(p) when the speaker does not understand a term in p and asks for the clarification of this term; and (2) explanation replies such as explain(p) when the speaker provides an explanation for p; justify(p) when they provide a justification of p; and clarify(p) when they provide a clarification of the term in p.

The contribution of this work is threefold. First, we present a requirement specification for collaboration between experts. While the requirement specification is grounded in the medical domain, it focuses on the general communication issues that can come up during expert collaborations. Hence, it can be abstracted to consultations among experts in general. Next, inspired by the tradition of dialogue embedding [77], we combine explanation-based illocutionary forces in an inquiry dialogue to generate richer traces for the inquiry process than what is possible with the assert locution, typically used in inquiry dialogues. Moreover, the dialogue game is unique in that sense that it meets the requirement specification from the domain experts. While the combination of different dialogue types is not ground breaking formally, the proposal makes an important methodological step into the applications of such formal dialogue systems into real-life domains which is empirically grounded in users’ requirements. Furthermore, to the best of our knowledge, no other descriptive dialogue game has focused on interactions among experts. The rich game traces allow the system to be transparent and can be used to explain the recommendations of the system to a human user through human-machine interfaces such as verbal and visual interaction. Finally, we evaluate the dialogue game against the requirement specification and verify the evaluation through a formative user study. Thus, we introduce the methodology of user-centred software engineering practice to dialogue games. While other works [11,27,36,40,53,64] in descriptive dialogue games have used insights from their domain of interest to inform the dialogue games, none of them have provided a requirement specification as far as we are aware.

The rest of this work is structured as follows. Section 2 summarises related work. Section 3 presents the requirement specification for expert collaborations. Section 4 formally presents the Experts’ Dialogue Game (EDG) while Section 5 provides implementation details of a web-based platform implementing the EDG. In Section 6, EDG is evaluated against the requirement specification presented in Section 3. Section 7 highlights user perspectives on EDG and the platform described in Section 5. Finally, Section 8 concludes the paper and provides directions for future work.

2.Related work

This section summarises related work on explanatory and inquiry dialogues, dialogue games in multiagent systems for healthcare, argumentation in healthcare and communication tools for multidisciplinary collaborations in healthcare.

Amgoud et al. [2] present an argumentation system for resolving inconsistencies in an agent’s knowledge base. Subsequently, they show how dialogue game theory can be applied on top of this to realise the different dialogue types in Walton and Krabbe’s typology [77]. A minimal framework for an explanatory dialogue system is presented in Walton [76]. The goal of the dialogue is for an explainer (an entity that explains, usually the system) to fill in the gaps in the knowledge base of the explainee (the target of the explanation, usually a human user) by informing them why something happened. This is considered as a transfer of understanding from the explainer to the explainee. Building on Walton’s minimal framework, Arioua et al. [3] combine an explanatory dialogue with argumentative illocutions. The explanatory illocutionary force is used by the system to explain the behaviour of some phenomena to the user while the argumentative force helps to resolve inconsistency in the knowledge bases of participants. In addition to commitment stores for each participant, they introduce an understanding store for the user which stores the missing links in understanding rather than what is currently understood. The discharging of all issues in the understanding store confirms a successful transfer of understanding.

Madumal et al. [36] analyse human-human and human-agent explanatory dialogues from various domains and propose an explanatory dialogue protocol based on induction. Their protocol also combines an explanatory dialogue with argumentative faculty. The goal of the dialogue is the same as proposed by Walton [76]. They use double acknowledgement for confirming understanding, that is, acknowledgement by the explainee on being satisfied with the explanation and explainer’s return acknowledgement. Dennis et al. present an explanatory dialogue game for explaining the behaviour of a Belief–Desire–Intention System [17]. Their protocol, like EDG, is grounded in dialogue game theory from informal logic using argumentation schemes and critical questions rather than argumentation theoretic dialogue [75]. The goal of the dialogue in this case is to understand system behaviour through comparing traces of the system from different participants. Similar to these works, we use explanation-based illocutionary forces to fill in missing gaps in the knowledge bases of participants.

Ilia et al. [65] extend an information seeking dialogue with explanatory illocutionary forces. The goal of the dialogue is to offer factual and counter factual explanations of a classifier’s output to a human user. They also evaluate the protocol through a user study and process analytics. Prakken and Ratsma [54] propose a case-based explanation dialogue to explain the outcome of a linear binary classifier. The goal of the dialogue is to provide a model-agnostic local explanation. The explanations in this case are not trying to explain the system reasoning but rather trying to come up with reasons to justify the system result. The dialogue game starts with the proponent of the dialogue presenting a similar example from the training set with the same outcome as the current instance. The opponent can argue against this using two strategies. The first is to use counter examples from the training set. The second is to highlight the differences between the current instance and the instance being presented as a justification by the proponent. A successful explanation amounts to a winning strategy for the proponent. However, unlike these approaches, we incorporate the explanatory illocutionary forces in the reasoning process itself rather than to only explain why the system behaved in a certain way. While these works target a transfer of understanding from the system to a human user, EDG involves explanations amongst the reasoning agents.

Although not as common as persuasion dialogues, a few other works have explored inquiry dialogues as stand alone dialogues or in combination with other dialogue types. Bex et al. [7] combine an inquiry dialogue with a persuasion dialogue for discussions between criminal investigators. The goal of the dialogue is to come up with the most robust explanation. They assume an adversarial setting in which each agent advocates for its own preferred explanation. Unlike this work, EDG assumes a cooperative setting where the main goal is to come up not only with the most robust explanations but decisions as well. Black and Atkinson propose a framework that embeds an inquiry dialogue over beliefs with a persuasion dialogue over actions. The inquiry dialogue allows the participants to collaboratively decide what to believe whereas the goal of the persuasion dialogue is to collaboratively decide what is the best action to do in order to reach the proponent’s goal. Once all the arguments have been given, it is upto to the proponent of the dialogue to make the final decision based his personal preferences [8].

Black and Hunter [9,10] propose two types of inquiry dialogues, which they call as argument inquiry and warrant inquiry. The goal of argument inquiry dialogue [9] is for two agents to jointly construct an argument for a claim by sharing relevant beliefs. The protocol has three moves and allows nesting of argument inquiry dialogues. In addition to a conventional commitment store, they also introduce a question store which keep tracks of the premises that need to be proven in order to prove the claim representing the dialogue topic. They prove soundness and completeness for their protocol. The goal for a warrant inquiry dialogue [10] is for two agents to share arguments to jointly construct a dialectical tree in order to determine the acceptability of a particular argument. The main difference between the two types of dialogues is that argument inquiry is not concerned about the acceptability of the argument constructed while the latter is. Warrant inquiry dialogue allows embedding argument inquiry dialogue and also involves a question store like the former. They also provide a strategy for selecting the next move for a participant for both types of dialogues. However, to the best of our knowledge, none of these works combine an explanatory dialogue with an inquiry dialogue to make agent reasoning explainable.

Other works have incorporated argumentation and dialogue games in multiagent systems to provide clinical decision support in a distributed environment such as cancer diagnosis and management. Huang, Jennings and Fox [24,25] present a multiagent architecture for medical decision support in an interdisciplinary setting. The architecture has four components; a three layered knowledge base, a centralised working memory, a communications manager and a human-computer interface. The architecture also covers decision making under uncertainty, task management and agent cooperation. The communication manager works with communication primitives or locutions and a communication protocol. However, the locutions in this case are geared towards managing the tasks in a distributed environment rather than a discussion amongst different experts. For example, the locutions request, accept, reject and alter are used in the task allocation stage. The locution inform is used to report on the allocated task while the locution propose is used to recommend a treatment plan in response to a query. In contrast, EDG is focused on facilitating the discussion amongst the experts rather than a distributed management of responsibilities.

Beveridge and Fox [6] use a dialogue game as an interface between the underlying task structure and ontological knowledge and the spoken dialogue generation system. They implement their approach to provide clinical decision support for breast cancer diagnosis. They use several locutions as initiating locutions. For example, inform is used to present new information, instruct is used to request an action from the user, query-yn to ask a question with a yes or no answer and query-w to elicit a value from the user as part of data entry. They treat the dialogue started from each initiating locution as a sub-game. In contrast, the query locutions in EDG are targeting towards incorporating different types of explanations into the multidisciplinary discussion amongst experts. This is because the goal for EDG is to support collaborative discussion among experts rather than supporting an individual user with decision support.

Vasileiou et al. [73] present an argumentation-based justification dialogue between two participants. The explainee is a human user who wants to understand the explainer’s (artificial intelligent agent) reasoning. The dialogue game has four locutions, two of which are reserved for each of the participants. The game only allows a single locution per turn. They provide evaluation of their dialogue game through a user study and discuss its properties. Rago et al. [56] present the notion of explanatory dialogue between two participants as an Argument eXchange (AX). They discuss desirable properties of AX for agents equipped with quantitative bipolar argumentation frameworks and gradual semantics. [29,59,60] propose an interactive clinical decision support system, called CONSULT, for multimorbidity patients to self-manage their treatment. The system integrates four types of data sources; the patient’s electronic health record, data from sensors monitoring the patient’s symptoms, the clinician’s input and finally treatment guidelines. It uses computational argumentation to aggregate the data and resolve inconsistencies in the data sources. It also provides an argumentation-based dialogue interface for system-patient interaction to interactively deliver the recommendations to the user. The system-patient interaction uses templates for its text-based natural language interface. It is based on three different argumentation schemes and their associated critical questions. These cover deliberation, persuasion and explanation dialogues. Castagna et al. [13] propose an explanation dialogue between two participants that also interfaces with the CONSULT system through a chatbot. They propose an argument scheme based on practical reasoning and use it for the explanatory dialogue. Shaheen et al. [63] propose an explanatory dialogue between two participants to explain the recommended treatment plan for multimorbid patients. All of these works focus on explanation dialogues between two participants, mainly a system as an explainer and a human as an explainee. In contrast to these works, EDG aims to use different types of explanatory dialogue forces to generate richer traces during inter-agent reasoning processes.

Pancho et al. [41,71] propose an argumentation-based deliberation dialogue between two agents to discuss the viability of transplant organs. The dialogue is implemented as part of Carrel+, a health information system to manage organ transplants in Spain. The dialogue model, called ProCLAIM, [70] is based on argument schemes and case-based reasoning. ProCLAIM employs a mediator agent to guide the participant agents on their legal moves, decide the validity of submitted arguments and finalise the recommendation regarding the viability of the proposed transplant organ. The mediator agent uses argument schemes, existing guidelines, case-based reasoning and a component manager to manage the strengths of submitted arguments. It applies abstract argumentation semantics [18] to decide the winning argument.

Xiao et al. [81] present a group decision description language and a consensus protocol for a multiagent system. However, the protocol is not based on speech act theory [62], but is an agent communication protocol that uses functions like averaging and intersection to generate consensus values unlike the work presented here. Patkar et al. [49] developed a clinical decision support tool, called MATE (Multidisciplinary meeting Assistant and Treatment sElector), to support multidisciplinary cancer conferences. The tool is responsible for information management and providing treatment recommendations after processing the data. It does not present a dialogue game to support multidisciplinary discussion amongst experts as is presented here. A comprehensive survey describing the use computational argumentation for explainable artificial intelligence can be found in Vassiliades et al. [74]. Some other works have proposed computational argumentation systems for clinical decision support [15,20]. [] present a negotiation protocol for agents in a Belief Desire Intention (BDI) architecture. However, the protocol is grounded in agent communication language rather than dialogue game theory.

The term Health Information Technology (HIT) refers to the application of information technology to facilitate healthcare. HIT systems fall on a wide spectrum ranging from administrative support, patient information management and retrieval, communication and decision support [14]. Carayon et al. [12] point out that most of the existing HIT systems are focused towards individual tasks rather than teams, even as team-based care is becoming a popular paradigm. Here we review representative HIT applications targeting multidisciplinary communication and collaboration support.

Care Connector [46,68,69] is a communication and collaboration platform implemented in a community hospital in Canada. It is a web application that integrates into the HIT of the hospital to retrieve and update electronic records. The application covers both care planning and monitoring modules in addition to a messaging module between multidisciplinary care providers. The patient information is stored as part of a Care Planner module. The messaging modules provides asynchronous communication of non-urgent messages using the information in the Care Planner as a shared knowledge base. The messaging module allows linking each conversation to a patient. It informs participants to post messages following the Situation, Background, Assessment and Recommendation (SBAR) framework which is used in healthcare communication. However, it does not force the participants to frame their messages according to this framework.

Kurahashi et al. [30] present another communication and collaboration tool called Loop. It allows multidisciplinary collaboration between teams. The teams can include healthcare professionals, caregivers as well as the patient. Each conversation loop is centred around a patient. The application includes a card with patient information on the left hand side while the right hand side has the messaging thread. The information exchange is secure and sharing information between different subgroups is allowed. For example, a professional only message exchange or with all the participants in the loop. It also allows tagging messages with user-defined labels to facilitate search later on. The labels represent different themes or issues described in the message.

[32] implemented a platform, called one-stop platform, for multidisciplinary collaboration among healthcare professionals in a Taiwanese hospital. The platform integrates into existing HIT system of the hospital. It covers administrative and planning aspects in addition to a messaging module. The messaging modules allows transparency and accountability for message posting and viewing. It supports exchanging text, audio and video messages. However, there is no specification on the format of the content that is exchanged.

Shared Care Platform (SCP) [38] is yet another collaboration tool implemented in a hospital in Spain that builds on social networking and open source tools. The tool is targeted towards facilitating healthcare professionals to manage multimorbidity patients. It has two components; a social networking component, called the Clinical Wall, and a decision support component. The Clinical Wall provides social networking like collaboration and communication support amongst healthcare professionals. It is integrated into the electronic health records of the patient. The record has an assessment section, a discussion section and a conclusion section. The assessment section includes information on patient history and assessments. The conversation starts with one clinicians posing a question to others. In the discussion section the clinicians exchange messages to arrive at an agreement with regards to the question. In the conclusion section all participants need to sign off on the agreed decision. During the discussion any clinician can be added to the conversation to invite their feedback. The decision support component uses the Clinical Wall and provides clinical guidelines in the form of rules. Other works [42,45,80,82] implement mobile applications to support care and communication amongst healthcare professionals, caregivers and patients. These applications mainly support administrative and information management tasks with simple messaging support for communication.

All these platforms and applications provide secure messaging amongst participants and well integrated interfaces for the existing HIT systems in place. In contrast, the prototype implementation provided for EDG does not provide any of these features since the goal in this work was to evaluate the underlying protocol rather than present a full-fledged web application. However, none of the existing applications provide support for framing the content and type of messages with an underlying dialogue protocol as is proposed in this work. So the platform provides a novel idea of supporting collaborative communications amongst healthcare experts based on an underlying dialogue protocol.

3.Requirements for expert collaboration

In this section, we propose a requirement specification for successful consultations among experts. Consultations among experts are common in the professional world, especially when critical decisions are concerned such as in medicine, aviation and engineering. We focus on consultations among medical experts as our domain of choice in order to develop a dialogue protocol for consultations among expert agents. This is because it is easier to abstract away from domain specific terminology in this case in order to understand the interaction dynamics. However, the requirement specification we present is abstract enough to be applied to consultations among experts in general since it avoids domain specific scenarios and terminology.

In order to understand collaboration scenarios between experts, we held informal discussion with some medical experts (specifically a gynaecologist, a radiologist, a general physician and a dentist). We identified two main scenarios, informal consultations such as during hand-off of a patient from an emergency room to a general or specialist ward, and formal consultations which usually take the form of multidisciplinary cancer conferences or case conferences for short. These conferences are structured discussions between different specialists to finalise diagnosis and treatment options for cancer patients [78]. The conference is attended by multiple specialists such as surgery, oncology and pathology. It starts off with the specialist in charge presenting each case history to the panel of experts. This is followed by a discussion amongst experts as to the best possible diagnosis and treatment options for each patient [21]. During the discussion, knowledge transfer between experts takes place. This happens through the explanatory, inquisitive and cooperative tone of the dialogue. Because of its explanatory value, many specialists consider it to have educational value for trainees [21]. We chose the case conference as our main use case to inform the protocol because of its formal and structured format. Moreover, some of the general communication issues [33,66,72] during informal hand-off also come up in case conferences. Subsequently, we reviewed medical literature on communication in case conferences to identify possible issues. We also included some works on general communication issues during informal collaboration between medical experts. These works were included since they were general enough to be understood by non-medical audiences.

Sutcliffe et al. [66] identify two types of communication failures in the medical profession: systematic and individual. While systematic failures result from a lack of sufficient organisation, individual failures have complex roots such as hierarchical and power dynamics and excessive workload. They suggest establishing communication guidelines to minimise both types of failures. In order to mitigate against these failures, we develop an interaction protocol grounded in the interaction dynamics during case conferences [16] as well as general communication dynamics [66] that can come up during informal collaboration between medical experts as a result of organisational subculture [66]. Formally, we used Scopus, PubMed and GoogleScholar to look for papers from the medical community that identify communication issues in cancer conferences and in general. We used the keywords ‘communication multidisciplinary cancer conference’, ‘multidisciplinary cancer conference’ ‘communication failure medical experts’ and ‘tumour board decision making’. All open-access, English language articles between 2001 and June 2021 related to medicine were considered. Amongst these, manual filtering was done to narrow down results to works involving reflections on communication issues amongst medical experts in cancer conferences and in general. The included articles were either reporting reflections from user studies [16,31,33,34,55,61,66,72], surveys [35,57,78,79] or best practices [43,55,78] followed by professionals. Works related to communication between patients and healthcare professionals were excluded. As were works that focus on the diagnostic recommendations for different medical conditions. The articles included in the study are given in Table 2. We stopped our search for articles when the same ideas started to recur in different articles and we felt confident that new articles were not adding any new perspectives.

We identified fourteen basic requirements for consultations among medical experts which are presented in Table 2. These cover both the systematic and individual needs for effective consultations between experts. A requirement was considered as inferred from a publication if it was explicitly or implicitly mentioned as a standard practice, a desired outcome or as a lack thereof. All the best practices, guidelines, reflections in the papers were taken into account, grouped together and summarised. This robust process of systematic and rigorous data collection from the domain literature is treated as providing validation of requirements which are then further evaluated in the user study on requirements embedded in the dialogue protocol (see Section 6). These requirements adhere to the structural guidelines and best practices for case conferences while at the same time addressing the communication issues that come up during informal consultations. They are abstract enough to be applicable in a formal collaboration setting between experts in different domains. They can be seen as sub-goals that can facilitate the collaboration in order for it to be productive.

The requirements were then categorised into four classes depending on the mechanism through which they can be satisfied. Table 2 lists the requirements according to their proposed categorisation. Each row presents the requirement id, description, number of papers in the literature that mentioned this requirement and references to the corresponding works. Each of the categories and their corresponding requirements are described next.

4.A formal dialogue system for expert collaboration

This section formally presents the Experts’ Dialogue Game (EDG) which embeds explanation-based illocutionary forces in an inquiry dialogue in order to emulate the inquisitive, explanatory and cooperative aspects of real-life consultations. This is done so that the dialogue game can generate richer reasoning traces and meet the needs of successful collaboration amongst experts. An Inquiry Dialogue is defined in Walton and Krabbe’s popular typology of dialogue types [77] as a collaborative discussion amongst participants to find out the answer to one or more questions when none of them is presumed to know the correct answer beforehand. Later, Walton [76] introduces an Explanatory Dialogue as a discussion between two or more participants in order to bring about a transfer of understanding from one to another. In this case, the participants already agree on the topic but differ in their understanding of it.

Each of these elements is described next.

4.4.Rules, R

The game has three stages: an opening stage governed by Commencement Rules, a progress stage governed by Combination Rules and a termination stage described by Termination Rules [52]. Each of these are described next, followed by commitment, turn-taking and politeness rules.

Commencement rules. The topic of the dialogue game can be one or more subsets of O. The game always starts with the initiator agent presenting the facts of the case (observations), its own conclusions (verdicts), corresponding recommendations (advice) and any critical points (concerns) it deems important. Thus, the first turn is composed of the first four locutions from the locution subset L1. A move, represented by μ, is a tuple μ=⟨τ,τ′⟩ where τ is the new locution being introduced in the current turn while τ′ is a previously introduced locution. τ′ is null for all moves made in the commencement phase. Formally, entries L1.1 to L1.4 in the Locution column of Table 4 formally present the four Informational locutions that are part of the first turn. Strict ordering is enforced on the four locutions that make up the first move and is given by the sequence L1.1 to L1.4 in the table.

Combination rules. The protocol allows participants to start new threads in the conversation at any time. This is achieved by allowing one or more locutions in the same turn where each locution corresponds to a move. For a move which uses the prompt locution, τ′ is null. Repeating the same move is not allowed, however, repeating the same locution in the same turn with different content is allowed. Hence, the next participant can respond to any number of locutions from the previous turns. In doing so, they have to specify the locution they are responding to (τ′) and pick any of the valid responses for that locution as defined in Table 4 where the Reply column indicates possible reactions to each locution from the Locution column. Subscripts α and β identify the agent playing the move.

Termination rules. The dialogue terminates when all the participants agree to end it. Any participant can start the process for getting consent from others to end the dialogue. They can do this by using the end locution. This signals the start of the termination stage. Since the participants are assumed to be assertive and cooperative, this means that anything that the participants do not explicitly challenge is taken for granted as an agreement. Hence, when the dialogue ends, all the participants are assumed to have agreed on all the elements of set O under discussion. However, each voting for termination may not always end in successful termination since any participant can refuse to give their consent. They are then invited to highlight any outstanding issues they have by using the prompt locution as explained in Section 4.3. If this happens, the dialogue moves back into the progress stage. Otherwise, they give their consent to end the dialogue (and to accept all the statements that went unchallenged by them) by using the end locution. A move which uses the end locution also has τ′ set to null.

Commitment rules. Dialogue games generally require each participant have their commitments publicly available in the form of a Commitment Store. The commitments are created as a result of particular speech acts and they ensure accountability for the participants. This is useful for making the dialogue coherent and productive. We follow Hamblin’s notion of commitment stores as done by [48] where an agent’s commitment store, CS(i) for agent i∈X, corresponds to a publicly available subset of its original knowledge base Σi. Specifically the commitment store CSt(i) at any time interval t for agent i∈X contains elements of Hi∪Oi∪Fi, where Hi⊂H, Oi⊂O and Fi⊂F. These represent the observations, verdicts, advice and concerns known by each agent at any time during the game such that CSt+1(i)=CSt(i)+{c|c is a new commitment}. In addition we introduce a multilateral agreement store for all agents, AS(MAS)={c|∃i,j∈Xsuchthatc∈CS(i)∩CS(j) and c∈K∪F∪O∪H}. That is, it contains the observations, verdicts, advice and concerns that have had a multilateral agreement at any time during the dialogue. As in the case of [48], the union of all individual commitment stores reflect the dialogue state any time whereas AS(MAS) shows the global agreements rather than the information state of the dialogue. AS(MAS) can be considered as a collective agreement store which provides a summary of the agreements during the dialogue to all participants. This is because of the assumption that the agents are assertive and therefore, commit to any statement that they do not explicitly challenge. Locution L3.4 (agree) helps to incrementally build up this summary, making it easier to synchronise the collective commitments of all agents. The mechanism of how this works is explained in the commitment rules that follow. Each rule describes the changes to CS(i) for agent i∈X and AS(MAS) in reaction to each locution.

• C1: For locutions subset L1 and L3.1 to L3.3, the content of the locution is added only to the individual commitment store of the speaker, CS(i).

• C2: For locution L3.4, the content of the locution is added to the individual commitment store of the speaker agent and also to AS(MAS). If the content of L3.4 is already added to AS(MAS) as a result of a previous application of C2, it is not added again.

• C3: For a locution loc(arg)∈L2 where arg∈L, no changes are made to the individual commitment store of the speaker. However, if arg had been added to AS(MAS) following C2 earlier in the dialogue, it is removed from AS(MAS) since it only contains multilateral agreements rather than bilateral ones.

• C4: For all locutions belonging to L4, no changes are made to neither the individual commitment store of the speaker nor AS(MAS).

• C5: For L3.5, which represents a retract, the content of the locution is removed from the commitment store of the speaker and from AS(MAS) if it has been added following rule C2.

• C6: After the dialogue terminates, the union of all individual commitment stores minus the conflicts is added to AS(MAS) following the notion of implicit agreement to all unchallenged statements as described in Termination Rules.

Table 5

Example of a dialogue game between three medical expert agents, α,β,γ∈X¹

Id	Speaker	Sequence of locutions	CS(Speaker)	AS(MAS)
T1	α	observation(h1−h7) verdict(d1) advise(r1,r2) concern(c1) pass	h1−h7 d1 r1, r2 c1
T2	β	⟨wh-justify(d1),verdict(d1)⟩ pass
T3	γ	⟨verdict(d3),verdict(d1)⟩ pass	d3
T4	α	⟨justify(f1),wh-justify(d1)⟩ pass	CST1(α)∪f1
T5	γ	⟨assert(⇁f2),justify(f1)⟩ pass	CST3(γ)∪ ⇁f2
T6	β	⟨wh-justify(d3),verdict(d3)⟩ pass
T7	γ	⟨justify(h7,c1,f10),wh-justify(d3)⟩ pass	CST5(γ)∪{h7,c1,f10}
T8	α	⟨agree(h7,c1,f10),justify(h7,c1,f10)⟩ ⟨advise(e1,e2,e3),advise(r1,r2)⟩ pass	CST4(α)∪ {h7,c1,f10,e1,e2,e3}	{h7,c1,f10}
T9	β	⟨agree(e1,e2,e3),advise(e1,e2,e3)⟩ ⟨advise(e4),advise(e1,e2,e3)⟩ ⟨assert(f3),justify(h7,c1,f10)⟩ pass	{e1,e2,e3,e4,f3}	AST8(MAS)∪ {e1,e2,e3}
T10	γ	⟨agree(e1,e2,e4),advise(e1,e2,e3)⟩ end pass	CST7(γ)∪{e1,e2,e4}	AST9(MAS)∪ e4
T11	β	⟨end,end⟩ pass	No change
T12	α	⟨prompt,advise(e1,e2,e3)⟩ pass	No change
T13	γ	⟨wh-explain(e3),advise(e1,e2,e3)⟩ pass	No change	AST10(MAS)−e3
T14	α	⟨explain(f12),wh-explain(e3)⟩ pass	CST8(α)∪ f12
T15	β	⟨agree(f12),explain(f12)⟩ pass	CST9(β)∪f12	AST13(MAS)∪ f12
T16	γ	⟨assert(f4,f7,f11),explain(f12)⟩ pass	CST10(γ)∪{f7,f11}
T17	α	⟨agree(f4,f7,f11),assert(f4,f7,f11)⟩ end pass	CST14(α)∪ {f4,f7,f11}	AST15(MAS)∪ {f4,f7,f11}
T18	β	⟨end,end⟩ pass
T19	γ	⟨end,end⟩ pass		AST17(MAS)∪ {h1,h2,h3,h4,h5,h6}∪ {r1,r2,d3}

¹ Subscripts of locutions are not mentioned for clarity.

Table 5 exemplifies the commencement, combination, commitment and termination rules for the running example. The first column of Table 5 indicates the turn identifier, the second column lists the identifier of the agent making the move, the third column identifies the locutions moved, the fourth column shows the changes in the commitment store of the speaker and the last column indicates the changes in the multilateral agreement store. In T1, the first agent sets the context of the dialogue in accordance with the commencement rules. In T2, agent β asks α to justify their diagnosis of depression since its inference rule f3 is in conflict with the diagnosis made by α. In T4, α provides this justification. However, in T3, γ provides its own diagnosis and challenges α’s justification in T5. Similarly, β then asks γ to justify their diagnosis of hypothyroidism in T6 because it is in conflict with their inference rule f3. γ’s justification is accepted by the other two agents in T8 and T9 respectively. In T13, γ asks α to explain why it recommends testing T3 levels. This is because it already has inference rule f12 in its knowledge base but is confused with α’s reasoning because of inference rules f7 and f11. Figure 2 shows how the dialogue switches between the commencement, progress and termination states as a result of the different turns. Each node in the diagram represents a state with the state label given in the centre. Each arc represents a transition with the arc labels corresponding to the turn Ids in Table 5.

Fig. 2.

State transitions between commencement, progress and termination states for the example dialogue in table 5.

EDG promotes making justifications, explanations and clarifications explicit in the discussion by not allowing assert in response to locutions L1.2–L1.4. Table 6 highlights how this can affect the dialogue. It shows how the running example in Table 1 would change after the twelfth move by α if assert was allowed in response to locution L1.3. The first column indicates the identifiers of the alternative statements made by the experts. The identifiers for the alternative scenario are appended with a ′ symbol to indicate that this is the alternative scenario. The second column shows the expert id and the statement they are making. Table 7 shows the corresponding dialogue game. The columns are organised in the same way as for Table 5. In this case, γ does not ask α for an explanation, rather it provides it’s own reasoning and the dialogue can close earlier. Hence, it is clear that EDG promotes justifications, explanations and clarifications at the expense of shorter discussion time.

Table 6

Alternative ending for the running example. α, β, γ

Id	Dialogue
13′	γ: I don’t think it is necessary to test T3 at this stage since she is not asymptomatic.
14′	α: Okay. I think we can close the discussion now.
15′	β: I agree.
16′	γ: I agree.

Table 7

Dialogue game between three medical expert agents for the alternative ending in Table 6²

Id	Speaker	Sequence of locutions	CS(Speaker)	AS(MAS)
T13′	γ	⟨assert(f7,f11),advise(e1,e2,e3)⟩ pass	CST10(γ)∪{f7,f11}
T14′	α	⟨agree(f7,f11),assert(f7,f11)⟩ end pass	CST8(α)∪{f7,f11}	AST10(MAS)∪ {f7,f11}
T15′	β	⟨end,end⟩ pass	No change
T16′	γ	⟨end,end⟩ pass	No change	AST14(MAS)∪ {h1,h2,h3,h4,h5,h6}∪ {r1,r2,d3}

² Subscripts of locutions are not mentioned for clarity.

The collective agreement store serves as the output of the multi-agent system. It allows the most relevant knowledge for the decision making to be pooled together in a systematic way which is more computationally efficient than pooling all the knowledge bases of the agents. In the process, it also preserves the privacy of the agents since only publicly shared information is used. This approach allows for the building of a modular explainable multiagent system in which the multiagent decisions can be made independently of the human-machine interface. For example, it can be used to provide justified decisions made by expert agents to a user using another explanatory protocol for human-machine interaction such as the one proposed by Ilia et al. [65]. In this case, the collective agreement store can serve as the interface between the two modules of the explainable Artificial Intelligence (XAI) system.

EDG relies on the locutions agree and retract to incrementally synchronise agreements from the agents’ individual commitment stores to the collective agreement store. However, if the agents fail to use these markers sufficiently, the burden of synchronising the agreement store will move to the end of the dialogue, stressing computational resources. Hence, the agents need to be made aware that explicit agreements will make the protocol more effective.

Promoting elicitation of justifications, explanations and clarifications allows EDG to keep track of collective agreements and resolve discrepancies in the agreement store. An example of this can be seen by comparing the example in Table 5 with the alternative scenario presented in Table 7. In the first case, the wh-request in turn T13 results in removing the disputed recommendation of e3 from the agreement store. In contrast, since γ never makes their stance explicit in the scenario in Table 7, e3 remains in the collective agreement store when the dialogue ends. So, the assumption that the agents are assertive is very important to ensure the success of EDG. An unassertive agent might end up being committed to beliefs that are not consistent with its knowledge base.

Turn-taking rules. EDG identifies two roles for the participants, initiator and participant. However, the initiator role ends after the first turn, whereby everyone becomes a participant. The initiator provides sufficient context for the dialogue through the locutions in the first turn. The protocol enforces turns but no particular turn-order is enforced. Each agent has to move at least one locution in response to the proponent’s moved locutions. Since multiple locutions are allowed in each turn, each agent has to end his turn with the pass locution to mark that he is finished.

Politeness rules. Structurally, dialogue games can allow participants to respond only once to each move (single-reply) or offer several responses as well (multi-reply), to use only one locution in each move (single-move) or more than one (multi-move) and to transfer the turn as soon as some objective condition is met (immediate-reply) or later (non-immediate-reply) [52]. Based on these definitions, we consider EDG to be multi-reply, multi-move and non-immediate-reply. A brief discussion justifying each of these properties follows next.

Multi-reply. The protocol achieves this in three ways. The first two enable this property for the respondent while the last one enables the speaker to proactively demand an additional response. For the respondent, it allows multiple arguments in one turn by not imposing any restrictions on the number of arguments included as content of each locution. For two, it allows respondents to come back to earlier choice points in the dialogue since it does not impose the restriction on addressing the preceding move. So they can move several arguments referring to different previous moves if desired. For the speaker, it enables them to direct the conversation back to issues that were not addressed to their satisfaction using locution L4.1.

Multi-move. The protocol does not limit the number of locutions that can be moved in one turn by each participant (see Section 4.4). Hence, it is by construction multi-move.

Non-immediate-reply. Since the protocol does not enforce an external condition to shift the turn, it allows each agent to complete its move uninterrupted and proactively transfer the turn, it is then non-immediate-reply.

All these properties make EDG very flexible and close to natural conversation. However, this flexibility can lead to dialogues that are incoherent or compromise the explanability and cooperative aspects of the dialogue. Hence, it calls for introducing the same mannerisms in place in natural conversations that act to counter these complications in real life conversation. So, EDG introduces two such mannerism into the dialogue as politeness rules. It identifies two such rules to ensure dialogue progression and conflict resolution. The first is related to wh-request. Since the protocol does not force a participant to respond to only the previous move, the participants can ignore explanation, clarification and justification requests, defeating the explanatory objectives of the dialogue. In order to mitigate this, the first politeness rule requires that all Wh-Requests must be responded to by the addressee first before they are allowed to respond to any other locution. Other participants who were not the direct addressee, can respond to a wh-request if they choose to do so. This allows the participants to collaboratively build explanations. The second rule concerns prompt. A prompt serves as a reminder to the participants that this particular agent is awaiting a response for the prompted locution. The second rule gives the receivers of the prompt, the flexibility to choose to respond to it immediately or in a later turn.

5.A platform for expert collaboration

A prototype of EDG was implemented as a web application in order to evaluate it with human experts through a user study. The web application allows the participants to ‘chat’ while enforcing EDG protocol. However, the participants do not need to remember the protocol, the web application enforces it for them. For each ‘message’ in the chat, it shows the possible locutions from Table 4 that can be used in response as a drop down menu. The participant can select a locution to frame their response and type their text in the corresponding text field. This section provides details on the implementation and the user study design.

5.1.Implementation

EDG was implemented as a prototype full-stack web application that allows human participants to engage in discussion regarding the best diagnosis and treatment options for a patient. Figure 3 shows a screenshot of graphical user interface of the web application with a hypothetical example. The application was implemented using JavaScript frameworks for client and server. The dialogue history is recorded in an SQLite database on the server. The server keeps track of the number of participants in a game and rotates the turns in a cyclic manner in the order in which the participants join the game session. The application enforces politeness rules by using highlights. It alerts the user who was the target of a wh-request by highlighting the request in red and not allowing this user to play any other locution until all the wh-requests to them have been discharged. Similarly, if a user plays the prompt locution, the target locution is highlighted in blue on all participants’ user interface to alert them on the request for response. However, they are not forced to respond to this alert. The web application was used to evaluate the usability of EDG through a user study.

Fig. 3.

Screenshot of the web application implementing EDG.

5.2.User study

We conducted a user study to evaluate the usability of the platform and its underlying protocol. According to the International Organization for Standardization (9241–11:2018), Usability measures how effectively, efficiently and satisfactorily a system, product or service can be used by the specified users for achieving their specified goals [26]. We carried out formative usability testing with a total of six participants. Formative usability testing is done during the development process with a relatively small number of participants to identify potential issues [4]. While traditional usability testing requires 30 to 50 test subjects, a type of formative usability testing approach known as discount usability testing has been shown to uncover 85% of the issues for the task at hand with 5 test subjects, with no significant subsequent increase in the ratio of testing cost to benefits gained as the number of participants is increased [47]. Due to the highly specialised profile (i.e. medical experts) required for the test subjects in this user study, it was difficult to recruit test subjects. So discount testing was done with the minimum number of participants for the formative study. The goal of the study was to elicit user’s perspectives on effectiveness, efficiency and satisfaction of the platform and the underlying protocol in meeting their professional communication needs.

Participants. The participants were final year medical students from a medical university in Barcelona, Spain. They were volunteers who responded to a call for participation after reading the advertised information sheet through their University’s human resource department.

Design. 

Fig. 4.

Workflow diagram of the user study design.

For each session of the usability testing, participants were divided into groups of three. They were then tasked with collaboratively deciding on the best possible diagnosis and advice for an anonymous patient with a thyroid disorder. The patient data was taken from the publicly available thyroid dataset from the UCI ML repository (https://archive.ics.uci.edu/ml/datasets/Thyroid+Disease). Each participant was given an identical task description but the patient data was unequally distributed between the participants to see whether transfer of information would take place. All sessions were conducted in a computer lab at a university where the participants had access to computers. All the participants in one session were in the same room at the same time. This was done to facilitate the administration of the study. However, participants were not allowed verbal or non-verbal (gestures such as eye contact) communication with each other during the study in order to ensure that all communication took place through the web application. After the participants finished the task, semi-structured interviews were conducted to get their qualitative feedback on the application and the underlying protocol. The participants were given 30 minutes for the task and 11–20 minutes for the post session interviews. All the participants who were in the same session were interviewed together as a group. Figure 4 shows the sequence of steps participants performed during the user study. First, all participants registered with the web application. The web application enforced the sign up order as the turn taking order in accordance with the turn taking rules. The first participant then made the opening move using the Graphical User Interface (GUI) of the web application. The turn was then passed onto the next participant in line. Each participant was notified by the web application when it was their turn. Each participant was free to choose which locutions they wanted to respond to and also which locution to use as their response. The online dialogue proceeded like this until one participant invoked the termination protocol by using the end locution. Afterwards, the termination protocol was followed as described in termination rules in Section 4.4.

Goals. The goal of the user study was to elicit perspectives of medical experts on aspects related to effectiveness, efficiency, engagement and ease of learning for the discussion platform and the underlying protocol. These aspects also tie in to the requirement specification from Section 3. However, they allow some additional usability considerations to be explicitly taken into account. Specifically, it aimed to answer the following questions for each of these aspects:

• (1) Effective

  • (a) Does the platform add value to professional discussions of medical experts?

  • (b) Did knowledge transfer take place as a result of the discussion?

  • (c) Are participants satisfied with the explanations provided?

  • (d) Are participants satisfied with the final decision and its justification?

• (2) Efficient

  • (a) Do participants have the moves they need at each step to express themselves?

  • (b) Does the application impede the participants in some way during the dialogue?

• (3) Engaging Do participants rate the experience as enjoyable?

• (4) Easy to Learn

  • (a) Does the application and the protocol promote discussion?

  • (b) Do participants find the classification of explanation requests useful or confusing?

The next section provides details on the result of the user study. Additionally it provides a detailed evaluation of EDG according to the requirement specification of Section 3.

6.Evaluation against requirements for expert collaboration

In this section we discuss how the protocol and its implementation measure up against the different types of requirements identified in Section 3. We introduce three evaluation criteria, referred to as levels, for this: dialogue, system design and user study. Each of these is introduced next.

Dialogue. This level determines how well the dialogue rules presented in Section 4 contribute towards satisfying each requirement.

System design. This level evaluates each requirement against the protocol implementation since some requirements can only be met at the implementation level.

User study. This level validates the satisfaction of each requirement through the user study described in Section 5.2.

Table 8 presents a summary of the results. The first column shows the id of each requirement, columns second to fourth show whether the corresponding requirement is verified through the dialogue, system design or user study. Finally, the last column shows the representative quote from a participant in case the requirement satisfaction is verified through the user study. The checkmark symbol in a table cell shows that the corresponding requirement is satisfied for the level indicated in the column header. The triangle symbol indicates that the corresponding requirement is satisfied indirectly by virtue of implementing the dialogue protocol. We distinguish it from the checkmark to show that the system design level does not make an active contribution to fulfilling the requirement for these cases. So, the evaluation for these requirements is superficial at this level. A blank value for the cell indicates that corresponding requirement is not satisfied by the level indicated in that column header. Following paragraphs give a detailed discussion on each row of Table 8.

7.User perspectives on expert collaboration system

The post session interviews from the user study were recorded with the consent of participants, transcribed and the interview data was thematically analysed to discover key insights. Thematic analysis is concerned with identifying patterns in qualitative data. The analysis can identify themes at the surface meaning level, referred to as semantic level or go beyond what was said to discover underlying concepts, known as latent level [37]. Attention was paid to both semantic and latent meaning implied in the feedback. Specifically, the comments from the participants were organised into related concepts following the bottom-up organisation method of affinity matching. Affinity matching is a bottom-up analysis technique for analysing data from a user study. In this case, relevant findings are grouped and the category labels are inferred from these groupings [5]. The advantage as opposed to a top-down approach with pre-defined labels is that it keeps an open mind to what the data might reveal. We identified six themes from the participants’ feedback on various aspects of the dialogue game. Table 9 shows the representative quotes form participants against each identified theme. Next, we describe the insights from users’ perspectives for each theme.

Value in real-life use. The most common theme was the practical value of such a discussion system in the medical community. All participants in group 1 agreed that the platform would facilitate professional communication between medical experts, especially multidisciplinary communication and communication between public and private sectors. Participants agreed that the platform facilitates knowledge transfer and allows for a productive discussion. One participant was of the opinion that the platform helps clear communication by taking on the burden of politeness, in that doctors in general do not ask each other for clarifications and justifications directly as it could be considered rude but since this is part of the platform’s functionality, it no longer seems like a personal affront, rather just the way the platform works. This is a really significant comment since providing a means of getting around personal issues that hamper communication was one of the basic requirements the platform and the underlying protocol aimed to fulfil.

Satisfaction with move options. One of the most important practical aspects of a dialogue game for expert discussion is whether it allows the participants to express themselves completely. This was evaluated through taking participants’ feedback on whether they found the dialogue locution sufficient for their discussion. All participants in group 1 expressed overall satisfaction with the request-response options that are part of the underlying protocol. They thought that it presented the ideal scenario. Three out of six participants thought that the response I agree was not sufficient by itself because they would have liked to express partial agreement as well. For example, I agree but. One participant was of the view that not having any I do not agree option explicitly was good because doctors are in general always coming to a deadlock because of this so it was useful to ask for an explanation instead rather than expressing explicit disagreement.

Utility of different explanation requests. In order to evaluate whether the classification of different explanation requests is useful in a practical scenario, participants were asked whether they found the categorisation useful. Three out of six participants in group 1 felt that all explanation requests were useful and they would use them in their communication. However, the other half argued that a justification request sounded really aggressive and unnatural and they would never use it in a real world scenario. They would prefer to use the explanation request instead. However, all participants agreed that they were not concerned about the subtle differences between explanation, clarification and justification requests as long as the intention of asking for an explanation was conveyed.

Effect of turn-taking. Since traditional collaboration between experts is real-time, it was an open research question for protocol design whether it should allow synchronous or asynchronous communication. In order to meet requirements RP5 and RP6, the protocol was designed to be synchronous and participants were asked to give their feedback based on their experience. Two different perspectives emerged on the turn-taking mechanism implemented in the platform and the underlying protocol. Two out of six participants in group 1 felt that the turns were good and helped to coordinate the discussion. One participant felt that it would be useful to be able to edit your response when it was not your turn because you might remember something after your turn had passed. One participant was of the view that ideas slipped your mind while waiting for your turn while another participant felt that the turn-taking put a lot of pressure on you to say something during your turn even when you did not think that you had anything to say. They suggested that a dynamic turn-taking mechanism would be better to preserve coordination of the discussion and to deal with the last two problems. They thought that an option to queue for the turn token would be best.

User interface. Although the main aim for the user study was to evaluate the dialogue game protocol, it was anticipated that participants would end up evaluating the system at the user interface level. This was confirmed in the user study where the participants ended up offering several valuable suggestions for user interface improvements. All participants in group 1 thought that the clear separation of the discussion into history, diagnosis, advice and concerns was very useful and efficient. Three out of six participants seemed happy with the user interface. Three out of six participants agreed that having the history on a side panel would be more efficient because it would help reduce scrolling time to check on it. One participant also felt that displaying history in separate lines would also improve presentation. One participant felt that nesting the messages would make the presentation more clear and efficient.

User study design. One of the themes that emerged was that the participants were surprised with how the task in the user study was designed. Specifically, they found the distribution of patient history amongst the different participants unnatural compared to their experiences in the professional scenarios. All participants in group 1 found the division of patient history between the participants unnatural compared to the professional real life scenarios in which all the history is presented upfront. While this was done to check if transfer of information took place, they argued that knowledge transfer and information took place irrespective of this small test. So for the second group all the patient history was provided upfront to participant 1.

8.Conclusion and future work

This work envisioned a human-artificial agent hybrid collaborative recommendation system. As a first step towards this end, it presented a requirement specification for collaborative interactions between experts and an inquiry dialogue game grounded in the specification. The dialogue game allows multiple expert agents to collaborative on the best recommendations for a user. The game combines explanatory illocutionary forces in an inquiry dialogue. The motivation for doing this is to make the inquiry process and consequently, the output of the multiagent system explainable by generating richer traces for the reasoning process itself. The game presents an approach towards incorporating explainability within multiagent systems. This work also presented an evaluation of the dialogue game against the requirement specification through a user study. The user study was also significant in that it highlighted the real life utility for such dialogue platforms in the medical domain. Such platforms can enable clearer and systematic communication across multiple healthcare disciplines and sectors. This work proposes to import the methodology of software engineering into the area of formal dialogues. This methodology consists of the following steps: the collection of requirements for a dialogue game in a selected domain application; the design and implementation of a protocol according to these requirements; and the evaluation of a dialogue system against the requirements.

The next step would be to implement and evaluate EDG for a multiagent system. This would involve evaluating formal properties of the system such as deadlocks, livelocks and termination guarantees. One possible approach for investigating runtime termination guarantees for EDG is to explore multiagent frameworks that can provide this kind of guarantee through an appropriate moderator role. For example, the governor role in Electronic Institutions [19] can be extended to close termination property at runtime. Another research direction could be to close the protocol against disruption by non-cooperative and malicious agents. It might also be interesting to investigate whether the protocol can do away with turn-taking and synchronous communication since it may not scale well to a system with many participants.

While EDG presents which locutions can be used in response to others, it does not investigate how an agent can select the best locution in response to another based on its knowledge base. This is a very important aspect to implement the protocol in a multiagent system. Hence, an important future direction is to develop reasoning strategies for agents for participating in the EDG. One possible approach for doing this is to explore argumentation-based reasoning for EDG on the lines of [10]. Subsequently, the next step would be to adapt and implement the protocol in a human-artificial agent hybrid system. Other possible interesting directions to investigate include investigating how well the requirement specification presented in this work generalises to other domains such as engineering or aviation. On the flip side, it can also be interesting to evaluate how well existing dialogue game protocols [10,51,58] conform to the requirement specification through a user study. Finally, the prototype of the platform developed as part of this work can be refined and released as open source software for facilitating communication between experts in the healthcare domain.

The politeness rules introduced here show that in order to make dialogue games more human-centred, we need to introduce the same societal machinery being employed in real life conversation in order to safeguard the integrity of the dialogue in a computational context.